On Tue, 2011-07-05 at 13:02 +0000, gentoo-amd64+help@lists.gentoo.org
wrote:
> On Thu, 30 Jun 2011 21:36:38 -0700
> Mark Knecht <markknecht@gmail.com> wrote:
>
> >
> > I think it's completely appropriate for this list. This
> distro expects
> > that we put CFLAG options in make.conf so I need to hear
> about this
> > stuff even if I don't have to background to completely
> understand
> > what's really causing the problem.
> >
>
> In this case, or in the case of any program where
> "-fno-strict-aliasing"
> could make a difference, the maintainer of the program would
> include
> the option in the ebuild. The user would not have to worry
> too much
> about it.
>
> But yes, it is always good to know about the compiler flags.
>
> To see exactly what compile flags are being used in your
> programs, here
> is a neat method I picked up from somewhere. Just open a
> terminal and
> enter the following command:
>
> echo 'int main(){return 0;}' > test.c && gcc -v -Q $CFLAGS
> test.c -o test && rm test.c test
>
> In place of $CFLAGS just substitute any option of interest.
> There will
> be a flood of output, but just scroll back a few lines to find
> the "options
> passed:" and "options enabled:" sections.
>
> For example, using "-O2" for $CFLAGS indicates that
> "-fstrict-aliasing" is
> used, but it is not used with "-O1."
>
> It also shows that with "-O2" the option "-mno-sse4" is used,
> and so if
> you want to use SSE4 for certain programs (e.g. video, audio)
> you will
> need to specifically enable it.
>
> There may be an even slicker way to reveal the flags, but this
> is the
> only way I know.
>
> Frank Peters
>
An example of the issue discussed
https://bugs.gentoo.org/show_bug.cgi?id=347818
see in particular comment #3 they are understaffed and have a ton to do
but in the norm don't care to here it.
https://bugs.gentoo.org/show_bug.cgi?id=339485
Is a discussion/flame about the report upstream qa messages.
Help me out here guys and weigh in. (dons flame suit)
Further on the conversations wandered-to in the topic 'optimization'
in the kernel config menu under the heading 'General Setup' lies
[*] Optimize trace point call sites
CONFIG_JUMP_LABEL:
If it is detected that the compiler has support for "asm goto", the
kernel will compile trace point locations with just a nop instruction.
When trace points are enabled, the nop will be converted to a jump to
the trace function. This technique lowers overhead and stress on the
branch prediction of the processor.
I've had this checked for a good deal of time and see no issues because
of it.
David J Cozatt
aka user99
wrote:
> On Thu, 30 Jun 2011 21:36:38 -0700
> Mark Knecht <markknecht@gmail.com> wrote:
>
> >
> > I think it's completely appropriate for this list. This
> distro expects
> > that we put CFLAG options in make.conf so I need to hear
> about this
> > stuff even if I don't have to background to completely
> understand
> > what's really causing the problem.
> >
>
> In this case, or in the case of any program where
> "-fno-strict-aliasing"
> could make a difference, the maintainer of the program would
> include
> the option in the ebuild. The user would not have to worry
> too much
> about it.
>
> But yes, it is always good to know about the compiler flags.
>
> To see exactly what compile flags are being used in your
> programs, here
> is a neat method I picked up from somewhere. Just open a
> terminal and
> enter the following command:
>
> echo 'int main(){return 0;}' > test.c && gcc -v -Q $CFLAGS
> test.c -o test && rm test.c test
>
> In place of $CFLAGS just substitute any option of interest.
> There will
> be a flood of output, but just scroll back a few lines to find
> the "options
> passed:" and "options enabled:" sections.
>
> For example, using "-O2" for $CFLAGS indicates that
> "-fstrict-aliasing" is
> used, but it is not used with "-O1."
>
> It also shows that with "-O2" the option "-mno-sse4" is used,
> and so if
> you want to use SSE4 for certain programs (e.g. video, audio)
> you will
> need to specifically enable it.
>
> There may be an even slicker way to reveal the flags, but this
> is the
> only way I know.
>
> Frank Peters
>
An example of the issue discussed
https://bugs.gentoo.org/show_bug.cgi?id=347818
see in particular comment #3 they are understaffed and have a ton to do
but in the norm don't care to here it.
https://bugs.gentoo.org/show_bug.cgi?id=339485
Is a discussion/flame about the report upstream qa messages.
Help me out here guys and weigh in. (dons flame suit)
Further on the conversations wandered-to in the topic 'optimization'
in the kernel config menu under the heading 'General Setup' lies
[*] Optimize trace point call sites
CONFIG_JUMP_LABEL:
If it is detected that the compiler has support for "asm goto", the
kernel will compile trace point locations with just a nop instruction.
When trace points are enabled, the nop will be converted to a jump to
the trace function. This technique lowers overhead and stress on the
branch prediction of the processor.
I've had this checked for a good deal of time and see no issues because
of it.
David J Cozatt
aka user99