[gentoo-amd64] gcc 4.1 + CFLAGS

[gentoo-amd64] gcc 4.1 + CFLAGS

[Fernando Boaglio]

Hi there!

I was told with gcc 4.1 you can't play with some CFLAGS because you
will really break your system (more dangerous than gcc 3.x !  ).

Have you tried "emerge -e system" with GCC +  some uncommon flag?

Can you share your CFLAGS with us  ?

TIA!
[]'s
boaglio@gmail.com
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[brian]

On Fri, Jun 09, 2006 at 12:59:09AM -0300, Fernando Boaglio wrote:
> Hi there!
> 
> I was told with gcc 4.1 you can't play with some CFLAGS because you
> will really break your system (more dangerous than gcc 3.x !  ).
> 
> Have you tried "emerge -e system" with GCC +  some uncommon flag?
> 
> Can you share your CFLAGS with us  ?

Are any of these uncommon or dangerous:

CFLAGS="-O2 -march=opteron -ffast-math -fomit-frame-pointer -mfpmath=sse -funit-
at-a-time -fpeel-loops -ftracer -funswitch-loops -pipe"

I did a recent emerge -e world with gcc 4.1.1 and those flags.

Haven't noticed any problems on my laptop or a workstation.

-- 
Brian Litzinger
The evolution of Unix: 1970 -x, 2000 --x, 2030, ----x
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Michael Weyershäuser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

CFLAGS is something you can easily break a system with, no matter what
compiler version. You should read up on any flag before applying it and
be very conservative on production systems / systems that you need and
that should always be in a working condition.

I have those CFLAGS on various systems:
Production server running amd64 and gcc-3.4.5:
CFLAGS="-O2 -march=k8 -pipe -fomit-frame-pointer -msse3"
CXXFLAGS="${CFLAGS}"

Home server running x86 and gcc-4.1.1:
CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe -mmmx -m3dnow
- -msse -mfpmath=sse"
CXXFLAGS=${CFLAGS}

Desktop machine running ~amd64 and gcc-4.1.1 (my box for testing,
experimenting and generally messing around with stuff):
CFLAGS="-O2 -march=k8 -fomit-frame-pointer -pipe -msse3"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"


There's a thread called "CFLAGS central" on forums.gentoo.org where
discussions about CFLAGS take place. It's long, it's sometimes very
controversial, but it's also quite informing. General rule of thumb: If
you don't know exactly what you are doing you shouldn't be doing it ^^
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEiP/X6q4f+IV6B/wRAryEAJwPlQ82ytAlnlveo/B/E0Th9VvDCgCdGkcI
fHptMLDBVNbDg3AxyVAZ4yQ=
=9zwc
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Michael Weyershäuser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

brian@WorldControl.com wrote:
> Are any of these uncommon or dangerous:
> 
> CFLAGS="-O2 -march=opteron -ffast-math -fomit-frame-pointer -mfpmath=sse -funit-
> at-a-time -fpeel-loops -ftracer -funswitch-loops -pipe"


I don't recommend -ffast-math on a global basis (or at all), it gets you
right where the Pentium fdiv bug brought us some years ago: floating
point operations will be faster, but they could get a wrong result in
some occasions...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEiQuJ6q4f+IV6B/wRAi/dAJ9hef/hQ8ZJVWnPgkEyKSOReRO2jQCeM1FK
SIkimKcsTbIUtfveycWmmGw=
=Wa1X
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Adam James]

On Fri, 9 Jun 2006 00:59:09 -0300
"Fernando Boaglio" <boaglio@gmail.com> wrote:

> I was told with gcc 4.1 you can't play with some CFLAGS because you
> will really break your system (more dangerous than gcc 3.x !  ).
> 
> Have you tried "emerge -e system" with GCC +  some uncommon flag?
> 
> Can you share your CFLAGS with us  ?

http://gentoo-wiki.com/Safe_Cflags

--Adam
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Simon Strandman]

Fernando Boaglio skrev:
> Hi there!
>
> I was told with gcc 4.1 you can't play with some CFLAGS because you
> will really break your system (more dangerous than gcc 3.x !  ).
>
> Have you tried "emerge -e system" with GCC +  some uncommon flag?
>
> Can you share your CFLAGS with us  ?
>
> TIA!
> []'s
> boaglio@gmail.com
Yes, experimenting with CFLAGS with gcc 4.1 is more dangerous than with 
3.x is it's not as stable yet. Though you shouldn't do it anyway as 
it'll gain you nothing and might cause breakage. Check the safe_cflags 
page on the wiki for some suggestions!
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Samir Mishra]

Fernando Boaglio wrote:
> Hi there!
>
> I was told with gcc 4.1 you can't play with some CFLAGS because you
> will really break your system (more dangerous than gcc 3.x !  ).
>
> Have you tried "emerge -e system" with GCC +  some uncommon flag?
>
> Can you share your CFLAGS with us  ?
>
> TIA!
> []'s
> boaglio@gmail.com

These are the flag settings I have. My WS has >2GB RAM so I'm using 
-mcmodel=medium. But as you can see, they are hardly "safe".

Of the list below, the LDFLAGS -Wl,-Bdirect -Wl,-hashvals is supposed to 
make the biggest difference. I have no means of comparison.

A few applications fail to compile, but so far from the >500 packages I 
currently have on my system, only the following have failed to compile 
-- glibc-2.4, gcc, sandbox, strace, transcode, libmpeg3. A few other 
applications, mainly noticed with audio applications, are behaving 
"strange". But I haven't had the opportunity to track all these problems 
down.

# For GCC 4+
CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -fforce-addr -ftracer 
-frename-registers -mno-tls-direct-seg-refs -mcmodel=medium"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--enable-new-dtags -Wl,-Bdirect 
-Wl,-hashvals -Wl,-zdynsort -s"

# For GCC -- 3.4.5
#CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -fforce-addr -ftracer 
-frename-registers"
#CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
#LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--enable-new-dtags -Wl,-zdynsort -s"

# For minimal variable definitions
#CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer"
#CXXFLAGS="${CFLAGS}"
#LDFLAGS="-Wl,-O1"


Samir
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Vladimir G. Ivanovic]

On Fri, 2006-06-09 at 07:47 +0200, Michael Weyershäuser wrote:
> I don't recommend -ffast-math on a global basis (or at all), it gets you
> right where the Pentium fdiv bug brought us some years ago: floating
> point operations will be faster, but they could get a wrong result in
> some occasions...

Linus seems to use -ffast-math:
http://gcc.gnu.org/ml/gcc/2001-07/msg02150.html. At least in 2001 he
did.

--- Vladimir


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Kirby Walborn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Samir Mishra wrote:
> Fernando Boaglio wrote:
>> Hi there!
>>
>> I was told with gcc 4.1 you can't play with some CFLAGS because you
>> will really break your system (more dangerous than gcc 3.x !  ).
>>
>> Have you tried "emerge -e system" with GCC +  some uncommon flag?
>>
>> Can you share your CFLAGS with us  ?
>>
>> TIA!
>> []'s
>> boaglio@gmail.com
> 
> These are the flag settings I have. My WS has >2GB RAM so I'm using
> -mcmodel=medium. But as you can see, they are hardly "safe".
> 
> Of the list below, the LDFLAGS -Wl,-Bdirect -Wl,-hashvals is supposed to
> make the biggest difference. I have no means of comparison.
> 
> A few applications fail to compile, but so far from the >500 packages I
> currently have on my system, only the following have failed to compile
> -- glibc-2.4, gcc, sandbox, strace, transcode, libmpeg3. A few other
> applications, mainly noticed with audio applications, are behaving
> "strange". But I haven't had the opportunity to track all these problems
> down.
> 
> # For GCC 4+
> CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -fforce-addr -ftracer
> -frename-registers -mno-tls-direct-seg-refs -mcmodel=medium"
> CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
> LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--enable-new-dtags -Wl,-Bdirect
> -Wl,-hashvals -Wl,-zdynsort -s"
> 
> # For GCC -- 3.4.5
> #CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -fforce-addr -ftracer
> -frename-registers"
> #CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
> #LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--enable-new-dtags -Wl,-zdynsort
> -s"
> 
> # For minimal variable definitions
> #CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer"
> #CXXFLAGS="${CFLAGS}"
> #LDFLAGS="-Wl,-O1"
> 
> 
> Samir
I see you have some ldflags listed.  Where can a person find information
on these.  I've tried to google around about them and haven't had much
luck trying to figure it out.

BTW my cflags are:

CFLAGS="-march=k8 -Os -pipe -fomit-frame-pointer -frename-registers
- -funit-at-a-time -fweb -freorder-blocks -freorder-blocks-and-partition
- -ftree-pre -fmerge-all-constants"
CXXFLAGS="-march=k8 -Os -pipe -fomit-frame-pointer -frename-registers
- -funit-at-a-time -fweb -freorder-blocks -ftree-pre -fmerge-all-constants"

Duncan mentioned these a while ago and I used them with no problems.
But I was curious about ldflags if anybody has pointers.


- --

Kirby Walborn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEiVxz5HAWgdRxRvURAmjEAJwPvXs5+G7TlRzlHfSX5CMonr2dnACgliCM
PYyHNTxLDEhZUzpMBiNPcXw=
=Wx6x
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Simon Stelling]

man ld

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Michael Weyershäuser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vladimir G. Ivanovic wrote:
 > Linus seems to use -ffast-math:
> http://gcc.gnu.org/ml/gcc/2001-07/msg02150.html. At least in 2001 he
> did.

Linus Torvalds wrote:
> I used -ffast-math myself, when I worked on the quake3 port to Linux (it's
> been five years, how time flies).

So it was actually in 1996 and he did it *in a game*. That is, at least
in my opinion, quite different from using it globally on the whole system...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEiWKx6q4f+IV6B/wRAkzYAJ93aSevVwSRVZP8Tv97H1ueSOUp9ACeJk+I
QojWJqo/dIjLPg8hK3n5nFI=
=WEbG
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Vladimir G. Ivanovic]

On Fri, 2006-06-09 at 13:40 +0200, Simon Stelling wrote:
> man ld
> 
Nope. Not on my system. Neither -Bdirect nor -hashvals is listed.

(I have sys-devel/binutils-2.16.1-r2 installed.)

--- Vladimir

Vladimir G. Ivanovic
Palo Alto, CA 94306
+1 650 678 8014
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Vladimir G. Ivanovic]

On Fri, 2006-06-09 at 13:59 +0200, Michael Weyershäuser wrote:

> Vladimir G. Ivanovic wrote:
>  > Linus seems to use -ffast-math:
> > http://gcc.gnu.org/ml/gcc/2001-07/msg02150.html. At least in 2001 he
> > did.
> 
> Linus Torvalds wrote:
> > I used -ffast-math myself, when I worked on the quake3 port to Linux (it's
> > been five years, how time flies).
> 
> So it was actually in 1996 and he did it *in a game*. That is, at least
> in my opinion, quite different from using it globally on the whole system...

You're right, it was in 1996. But judging from his comments, he is still
probably using -ffast-math.

Anyway, I've been using -ffast-math with gcc-4.1.0 and gcc-4.1.1. No
problems (except for busybox), and I've recompiled both system and
world.

--- Vladimir

-- 
Vladimir G. Ivanovic <vgivanovic@comcast.net>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Ian McCulloch]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 924 bytes --]


On Fri, 9 Jun 2006, Vladimir G. Ivanovic wrote:

> 
> On Fri, 2006-06-09 at 07:47 +0200, Michael Weyershäuser wrote:
> > I don't recommend -ffast-math on a global basis (or at all), it gets you
> > right where the Pentium fdiv bug brought us some years ago: floating
> > point operations will be faster, but they could get a wrong result in
> > some occasions...
> 
> Linus seems to use -ffast-math:
> http://gcc.gnu.org/ml/gcc/2001-07/msg02150.html. At least in 2001 he
> did.

I use it too, in my numerical simulations of the Schroedigner equation, I 
think it is fairly standard in the numerics community.  My understanding 
is that it results in a fairly consistent and predictable loss of 
precision for some operations, nothing like the catastrophic *errors* in 
the the intel fdiv bug.  Of course, for algorithms that are sensitive to 
precision, it can (and does) cause problems.

Cheers,
Ian

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Simon Stelling]

Neither here. I thought it was a general question about LDFLAGS in general, not
about specific flags, but I was obviously mistaken :)

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Mike Arthur]

> You're right, it was in 1996. But judging from his comments, he is still
> probably using -ffast-math.
I would bet £100 that he doesn't compile EVERY PACKAGE on his own system with 
that CFLAG like you do.

Unless you are a very competent programmer, and understand how compilers work, 
and understand exactly what difference to the resulting code every -f* will 
make, you should stick to using -02 -pipe -march=..

It's the mindless optimisation, that will eventually break a package, that 
gives Gentoo a very bad name, and which is why many creators of packages hate 
us.

You said youself, it doesn't work with busybox, so its likely it won't work 
with other packages too.

If you meet my above criteria, fair enough, else stop wasting your and package 
creators time by dealing with bugs which aren't anyones fault but your own.

Mike Arthur


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Samir Mishra]

Vladimir G. Ivanovic wrote:
> On Fri, 2006-06-09 at 13:40 +0200, Simon Stelling wrote:
>   
>> man ld
>>
>>     
> Nope. Not on my system. Neither -Bdirect nor -hashvals is listed.
>
> (I have sys-devel/binutils-2.16.1-r2 installed.)
>
> --- Vladimir
>
> Vladimir G. Ivanovic
> Palo Alto, CA 94306
> +1 650 678 8014
>   
The 2 above are GCC 4 specific and only valid with the new binutils. You 
also have to obtain a custom ebuild to turn these options on in 
GCC/glibc. I don't remember what I did any more. Also not sure where I 
got the information on these from, this was some time ago, but try 
Google. See gentoo-wiki to start off with.

As Mike A. says in response to another message -

It's the mindless optimisation, that will eventually break a package, that 
gives Gentoo a very bad name, and which is why many creators of packages hate 
us.

I have to concur here and recommend that one always do the necessary 
research on the flags and what they mean. Many of the flags may actually 
slow the system down. Or even have unwanted side effects. -Bdirect is a 
good example. It's why I try and keep my flags to a minimum.

BTW, I intended to run Xen on my system, that's why I have 
-mno-tls-direct-seg-refs in there.

Samir.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Hemmann, Volker Armin]

On Friday 09 June 2006 06:46, brian@worldcontrol.com wrote:
> On Fri, Jun 09, 2006 at 12:59:09AM -0300, Fernando Boaglio wrote:
> > Hi there!
> >
> > I was told with gcc 4.1 you can't play with some CFLAGS because you
> > will really break your system (more dangerous than gcc 3.x !  ).
> >
> > Have you tried "emerge -e system" with GCC +  some uncommon flag?
> >
> > Can you share your CFLAGS with us  ?
>
> Are any of these uncommon or dangerous:
>
> CFLAGS="-O2 -march=opteron -ffast-math -fomit-frame-pointer -mfpmath=sse
> -funit- at-a-time -fpeel-loops -ftracer -funswitch-loops -pipe"
>
> I did a recent emerge -e world with gcc 4.1.1 and those flags.
>
> Haven't noticed any problems on my laptop or a workstation.
>

because they were filtered out.

DO NEVER USE FFAST-MATH!

Apps that can use it safely, usually set it in their makefile.

Everything else is prone to break.

And that is the reason, that almost all ebuilds have 'filter-flags' 
and 'strip-flags'.

Again: NEVER USE IT.

And: NEVER TELL ANYBODY TO USE IT.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Hemmann, Volker Armin]

On Friday 09 June 2006 14:13, Vladimir G. Ivanovic wrote:
> On Fri, 2006-06-09 at 13:59 +0200, Michael Weyershäuser wrote:
> > Vladimir G. Ivanovic wrote:
> >  > Linus seems to use -ffast-math:
> > >
> > > http://gcc.gnu.org/ml/gcc/2001-07/msg02150.html. At least in 2001 he
> > > did.
> >
> > Linus Torvalds wrote:
> > > I used -ffast-math myself, when I worked on the quake3 port to Linux
> > > (it's been five years, how time flies).
> >
> > So it was actually in 1996 and he did it *in a game*. That is, at least
> > in my opinion, quite different from using it globally on the whole
> > system...
>
> You're right, it was in 1996. But judging from his comments, he is still
> probably using -ffast-math.
>
> Anyway, I've been using -ffast-math with gcc-4.1.0 and gcc-4.1.1. No
> problems (except for busybox), and I've recompiled both system and
> world.

yes, but not with that flag.

Check the ebuilds. It is filtered out almost everywhere.

It is 'ok' in most games, video apps and picture viewers. But everything that 
needs at least some correct math, is screwed. You maybe do not see the 
breakage now. But someday it will byte you in your behind.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Hemmann, Volker Armin]

On Friday 09 June 2006 05:59, Fernando Boaglio wrote:
> Hi there!
>
> I was told with gcc 4.1 you can't play with some CFLAGS because you
> will really break your system (more dangerous than gcc 3.x !  ).
>
> Have you tried "emerge -e system" with GCC +  some uncommon flag?
>
> Can you share your CFLAGS with us  ?
>
> TIA!
> []'s
> boaglio@gmail.com

CFLAGS="-march=k8 -O2 -fweb -ftracer -fpeel-loops -ftree-vectorize -frename-registers -floop-optimize2 -msse3 -pipe"

CXXFLAGS="${CFLAGS}"

I don't recommend them... I just use them.


no LDFLAGS, because they are known to break things. No visibilty stuff, 
because there is a useflag for KDE - and everything else is not save.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Vladimir G. Ivanovic]

On Fri, 2006-06-09 at 15:36 +0200, Hemmann, Volker Armin wrote:

> > Haven't noticed any problems on my laptop or a workstation.
> >
> 
> because they were filtered out.
> 
> DO NEVER USE FFAST-MATH!
> 
> Apps that can use it safely, usually set it in their makefile.
> 
> Everything else is prone to break.
> 
> And that is the reason, that almost all ebuilds have 'filter-flags' 
> and 'strip-flags'.
> 
> Again: NEVER USE IT.
> 
> And: NEVER TELL ANYBODY TO USE IT.

If -ffast-math is filtered or stripped out, there is no harm in leaving
it in CFLAGS, right?

But, on my system, only 14 packages filter out -ffast-math: gnubg
postgresql pgcluster libpq zoom mpfr gmp octave openoffice gsl goffice
rrdtool xv gimp. None strip it out. So, the huge majority of the
packages on my system are compiled with -ffast-math, unless I've made a
mistake in grepping for "fast-math" in ebuilds that contain
"filter-flags".

Here are 4 other opinions about using -ffast-math.

        http://forums.gentoo.org/viewtopic-t-10535.html
        --fast-math can and does cause errors, but as I understand it
        (can't remember where I read this) the errors it can create are
        only single-byte errors. IOW, your answer to a FP
        calculation /might/ be one least-signifigant digit off. 
        
        Unless you're doing important scientific calculations, you're
        probably never going to notice /or/ care. I would expect that
        any linux packages that would have a problem with this (ALSA, or
        GSL and the like) probably tell you not to use it if they don't
        like it.
        
        http://gcc.gnu.org/ml/gcc/2004-03/msg01459.html
        I've heard it argued that people who are serious about floating
        point don't use -ffast-math.  I consider myself serious, and
        make a very nice  living from selling software to solve
        finite-difference Poison-Boltzmann electrostatic calculations on
        regular grids, and molecular minimizations using quasi-newtonian
        numerical optimizers.  Toon does numerical weather forecasting,
        and he seems happy with -ffast-math.  Laurent performs large
        scale Monte-Carlo simulations, and he also seems happy with it.
        
        http://gcc.gnu.org/ml/gcc/2004-03/msg01511.html
        For me, it's very simple: If -ffast-math leads to answers that are less
        accurate (in the verification-against-observation-sense) or unphysical 
        (against theoretical limit analysis), then I'll inspect my Fortran code 
        and repair the formulation (either a single expression or the layout of 
        loop code) that is responsible for the mayhem.
        
        Under no circumstances I will give up using -ffast-math.
        
        http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32035.pdf
        -ffast-math is recommended by AMD.
        
These opinions seem to contradict your advice. Could you be more
specific about why -ffast-math should not be used? 

--- Vladimir 
-- 
Vladimir G. Ivanovic <vgivanovic@comcast.net>
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: gcc 4.1 + CFLAGS

[Duncan]

Kirby Walborn <kirby@walborncattle.com> posted
44895C73.7090207@walborncattle.com, excerpted below, on  Fri, 09 Jun 2006
05:33:07 -0600:

> I see you have some ldflags listed.  Where can a person find information
> on these.  I've tried to google around about them and haven't had much
> luck trying to figure it out.
> 
> BTW my cflags are:
> 
> CFLAGS="-march=k8 -Os -pipe -fomit-frame-pointer -frename-registers -
> -funit-at-a-time -fweb -freorder-blocks -freorder-blocks-and-partition -
> -ftree-pre -fmerge-all-constants"
> CXXFLAGS="-march=k8 -Os -pipe -fomit-frame-pointer -frename-registers -
> -funit-at-a-time -fweb -freorder-blocks -ftree-pre -fmerge-all-constants"
> 
> Duncan mentioned these a while ago and I used them with no problems. But I
> was curious about ldflags if anybody has pointers.

I noticed they looked familiar.  =8^)

The only ldflags I use are:

LDFLAGS="-Wl,-z,now"

If you pay attention to your emerge output, you will have likely seen
warnings about various SETUID/SETGID applications, where the ebuild hasn't
set this flag.  It's a minor security issue for these apps, as one attack
vector would be preloading an exploitable library into an otherwise safe
SETUID/SETGID app run as root, then exploiting the hole in the library to
run your choice of malware -- as root!  Obviously, this isn't a huge issue
on a system where all the human users have root access anyway, but those
running hardened systems (note that Gentoo-hardened has a slightly
different solution in their hardened-patched gcc that does the same thing,
a slightly different way) will be interested, and the flag is a good idea
for SETGID/SETUID executables even on single-human-user systems, as it
shrinks the potential exposure to crackers and malware, helping keep Linux
from becoming another MSWormOS.

What the flag actually does is cause the resolution of all called
routines up front at application load time, thus triggering the
immediate load of all required dynamic-load libraries they are in, rather
than leaving some of them to "lazy load" later, as they are actually
needed.

Other than the security aspect for SETGID/UID, this has the effect on
all apps of increasing the initial load time of apps somewhat, as the
various libraries are all loaded and linked in, resolving the various
stubs into the full routines. Memory use can also be slightly higher,
where libraries are loaded that otherwise wouldn't be, because the part of
the application that uses them never happens to be run in that particular
session. However, over time, they'd likely be loaded by some app or
another anyway, so the practical effect isn't much more than increasing
the initial load time slightly, at the same time increasing responsiveness
later, when the app would otherwise have to load that library off of disk
or at least load it into its memory space (if it's already in memory
generally) and fully resolve the call triggering the load.

Completely resolving at load time the calls that would otherwise be
resolved as needed also has a debugging/troubleshooting effect.  Any
failed resolutions happen right away, at application load, rather than
later.  This is one of the reasons I like it, as if it's possible, I much
prefer the failure up front to having it occur after I've spent some time
with the app and possibly have unsaved work.

So basically... it's not so much an optimization as a configuring my
system to work the way I prefer it to work.  I prefer to front-end load
the library loading and routine resolution process, and know right away if
there is a problem.  I prefer waiting a half-second or so longer at
application load time to a pause later.  On tight memory systems, the
additional memory use might be significant, but it certainly wasn't when I
had a gig of memory (I've since upgraded to eight).  Note that if the
memory is needed for something else and the library hasn't been used, that
memory will be flushed to swap along with other non-actively used memory,
so it's not as if it should be a big problem for most even with a half a
gig of memory, tho below that, I'd not recommend it.

Problems?  None I've found with one SIGNIFICANT exception, but I deal with
it. The exception is modular-X, specifically xorg-server and certain
xf86-video-* drivers (among them -ati, which I use, but also a via driver
IIRC and there may be others).  The problem is that for years, as xfree86
and xorg before it went modular, these things used a build and module load
system that encouraged seriously interlocking dependencies, and these
haven't been fully ironed out as yet.  Various modules depend on functions
from other modules, which in turn depend on functions in the first
modules, so it's impossible to create a load order that resolves all
function dependencies as they are loaded.  Resolution of certain
dependencies MUST be put off until later, to load the first module, so the
second one, that requires the first, can load, thereby resolving the stubs
in the first one as well.  After they are all loaded, everything is
resolved, but they are so interdependent that there is no order
they can be loaded in without at least a couple (temporarily) unresolved
symbols, so forcing all symbols to be resolved immediately simply doesn't
work, and X will fail to start with an error about unresolved symbols.

There are two possible fixes.  One is to simply remember which packages
won't work (simple since it's just two), and always either comment out
your LDFLAGS line before merging them, or use 

LDFLAGS="" emerge xorg-server

(and the same for xf86-drivers-ati or whatever your video driver is).  The
second is to add a simple filter-ldflags call to the ebuild's
package_setup() function.  Here's the patch I filed for xorg-server:

--- xorg-server-1.0.99.903.ebuild       2006-05-13 08:36:22.000000000 -0700
+++ xorg-server-1.0.99.903.ebuild.new   2006-05-14 03:57:03.000000000 -0700
@@ -519,6 +519,9 @@ pkg_setup() {
        # (#121394) Causes window corruption
        filter-flags -fweb

+       # (#116698) breaks loading
+       filter-ldflags -Wl,-z,now
+
        # Nothing else provides new enough glxtokens.h
        ewarn "Forcing on xorg-x11 for new enough glxtokens.h..."
        OLD_IMPLEM="$(eselect opengl show)"

You'll notice the bug number listed, but here's a link:

http://bugs.gentoo.org/show_bug.cgi?id=116698

If nothing else, it makes for interesting reading (for those into this
sort of thing <g>), with further links to the hardened bug it was
originally called a duplicate of, and to a related discussion on the
gentoo-devel list.  My main point was that while it's one thing to say
"don't use those flags then", it's quite another to say that when portage
itself is saying to use them, when merging that very package!  When
those only following the instructions output by portage when merging a
package end up with a broken installation as a result, the ebuild
shouldn't be cleared for stabilization (a certain amount of such things
might be expected in ~arch, but not for stable).  The bug, BTW, is marked
resolved/fixed, altho the fix to the ebuild wasn't quite the same as my
suggested patch and I've not yet verified that it indeed totally solves
the problem, as I had with my patch.

Anyway, since the ldflags I use cause can cause occasional problems, and
aren't much more than a personal preference thing with real tradeoffs even
when they work, it's not something I can recommend, but it's something
that works for me, and since you asked about what people had for their
ldflags and why, I thought I'd answer.

As for other LDFLAGS, I too haven't found a lot on them.  Since I
believe the advice elsewhere to only use them if you know what you are
doing, and I don't know enough about any others to be confident using
them, I don't.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Bob Sanders]

Vladimir G. Ivanovic, mused, then expounded:
> 
> 
> Here are 4 other opinions about using -ffast-math.
> 
>         http://forums.gentoo.org/viewtopic-t-10535.html
>         --fast-math can and does cause errors, but as I understand it
>         (can't remember where I read this) the errors it can create are
>         only single-byte errors. IOW, your answer to a FP
>         calculation /might/ be one least-signifigant digit off. 
>


If your file system driver is calculating where to place the beginning of a
file or where to link the tail of one record to the head or the following
record, one digit mis-calculation could have a bad consequence.  And way,
way back in the bad old PDP-11 days, file systems did use FP.  I'd
guess a few modern ones might be using it today.        

Also, most financial transactions require a minimum of 4 digits to the right
of the decimal place.  Again, a single digit error can cause some folks to
get very, very upset.

 
>         Unless you're doing important scientific calculations, you're
>         probably never going to notice /or/ care. I would expect that
>         any linux packages that would have a problem with this (ALSA, or
>         GSL and the like) probably tell you not to use it if they don't
>         like it.
>

>From my reading of the Linux Audio Dev mailing list they seem to prefer
using integers as some devices don't have FPUs.
         
Bob
-- 
-  
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Hemmann, Volker Armin]

On Friday 09 June 2006 19:11, Vladimir G. Ivanovic wrote:
> On Fri, 2006-06-09 at 15:36 +0200, Hemmann, Volker Armin wrote:
> > > Haven't noticed any problems on my laptop or a workstation.
> >
> > because they were filtered out.
> >
> > DO NEVER USE FFAST-MATH!
> >
> > Apps that can use it safely, usually set it in their makefile.
> >
> > Everything else is prone to break.
> >
> > And that is the reason, that almost all ebuilds have 'filter-flags'
> > and 'strip-flags'.
> >
> > Again: NEVER USE IT.
> >
> > And: NEVER TELL ANYBODY TO USE IT.
>
> If -ffast-math is filtered or stripped out, there is no harm in leaving
> it in CFLAGS, right?

no, because a lot of other flags are filtered too!
Some ebuilds filter ALL flags, only because some ricers had to use ffast-math 
and other 'controversial' flags.

And some day, you will hit a package, that will built a damaged binary doing 
the wrong stuff, that does not filter out, because nobody knew about it. And 
then you are f*.

>
> But, on my system, only 14 packages filter out -ffast-math: gnubg
> postgresql pgcluster libpq zoom mpfr gmp octave openoffice gsl goffice
> rrdtool xv gimp. None strip it out. So, the huge majority of the
> packages on my system are compiled with -ffast-math, unless I've made a
> mistake in grepping for "fast-math" in ebuilds that contain
> "filter-flags".

and look for 'strip-flags'


>         http://gcc.gnu.org/ml/gcc/2004-03/msg01511.html
>         For me, it's very simple: If -ffast-math leads to answers that are
> less accurate (in the verification-against-observation-sense) or unphysical
> (against theoretical limit analysis), then I'll inspect my Fortran code and
> repair the formulation (either a single expression or the layout of loop
> code) that is responsible for the mayhem.
>
>         Under no circumstances I will give up using -ffast-math.
>
>        
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/320
>35.pdf -ffast-math is recommended by AMD.

FOR SPECIAL APPS. AND THIS DOCUMENT IS MEANT FOR PROGRAMMERS! PEOPLE WHO KNOW 
THEIR CODE!

>
> These opinions seem to contradict your advice. Could you be more
> specific about why -ffast-math should not be used?

no, they don't contradict me. You did not understand them.

Nowhere does AMD tells endusers to build their complete system with that flag.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: gcc 4.1 + CFLAGS

[Duncan]

Samir Mishra <sqmishra@eim.ae> posted 44894503.5010302@eim.ae, excerpted
below, on  Fri, 09 Jun 2006 13:53:07 +0400:

> These are the flag settings I have. My WS has >2GB RAM so I'm using 
> -mcmodel=medium. But as you can see, they are hardly "safe".

> A few applications fail to compile, but so far from the >500 packages I
> currently have on my system, only the following have failed to compile
> -- glibc-2.4, gcc, sandbox, strace, transcode, libmpeg3. A few other
> applications, mainly noticed with audio applications, are behaving
> "strange". But I haven't had the opportunity to track all these problems
> down.
> 
> # For GCC 4+
> CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -fforce-addr -ftracer
> -frename-registers -mno-tls-direct-seg-refs -mcmodel=medium"

A couple questions:

-mcmodel=medium:  Here's the gcc 4.1.1 manpage entry:

-mcmodel=medium
  Generate code for the medium model: The program is linked in the lower 2
  GB of the address space but symbols can be located any-where in the
  address space.  Programs can be statically or dynamically linked, but
  building of shared libraries are not supported with the medium model.

What about that last part -- shared libraries not supported?

Also...  from my understanding, the address-space references here are
simply to the program's view of memory, from it's perspective.  More
specifically, it's not to absolute address space (the >2 gig memory you
mention), but to the program's virtual address space, the protected-mode
virtual address space unique to it, and rather independent from its actual
placement in physical memory or its placement in terms of the kernel's
virtual address space.

As I understand it, therefore, the only reason to use -mcmodel=medium
would be if the program itself was expected to manipulate memory on the
order of gigs at a time.  While this can legitimately happen, say with a
big database (think Oracle, which very likely uses such an option), the
vast majority of applications don't work with anywhere near that size of
data, at least not directly.  While they might handle gigs of data over
the lifetime of the program, it's megabytes not gigabytes at a time, and
much of it may be indirectly, thru the kernel, so they have little need
for a memory allocation model that can allocate structures of multiple
gigs at a time or to access anything outside a two-gigabyte model.  Even
on the big machines running apps where use of this model might be
legitimately called for, it would be inadvisable to compile /everything/
on the machine with it, only the specific apps that need it.

This would also explain why it only applies to applications, not shared
libraries, as only the linked application would need to reference the full
multi-gig allocations -- any library functions would presumably be working
with much smaller sections of that dataset.

Note that I'm specifically /not/ saying you are incorrect, only that it
disagrees with what I (think I) know, which itself may be incorrect.  I'm
running 8 gig of memory here, but it's a fairly new upgrade, so a new
experience, and it's quite possible what I thought I knew is wrong.  If
so, I'd like to know it, the better to make use of the memory I have here,
as well.  So, if you have references as to why you are using that memory
model, post 'em, as I'd certainly like to read them myself!

-ftracer: Of interest here are a couple other manpage entries:

-fprofile-generate
  Enable options usually used for instrumenting application to produce
  profile useful for later recompilation with profile feedback based
  optimization.  [snip]

-fprofile-use
  Enable profile feedback directed optimizations, and optimizations
  generally profitable only with profile feedback available.

  The following options are enabled: "-fbranch-probabilities", "-fvpt",
  "-funroll-loops", "-fpeel-loops", "-ftracer", "-fno-loop-optimize".

I don't see either of these in your CFLAGS, and you don't mention
compiling, then profiling the program, then recompiling.  Without that,
the -ftracer flag, which the manpage says "perform[s] tail duplication to
enlarge superblock size", would appear to enlarge your binaries for little
or no performance gain.

That said, I've seen a couple developers that use the -ftracer flag as
well, in various bug reports and the like, which has surprised me a bit
since it's common for devs to complain about others using flags they don't
understand the implications of. However, I've yet to find someone who can
suitably explain /why/ they use it, given the above and the rather
unlikely chance that they actually bother with that profiling and
recompilation with every package they use the flag with, tho I don't of
course go around posting the question to every bug where I see it used,
and I've had limited chance to ask the question in a suitable context, so
I've not asked that many about it.

Again, if you have a good reason to choose that flag, or if you've
actually done tests and /know/ it improves performance, please post it, so
folks (like me! =8^) can be informed and perhaps optimize their system
similarly. Until then, I can't reasonably defend or explain using the
flag if I'm not going to go to the trouble of profiling and recompiling,
and I don't think the performance gains would be enough to justify that
(if I were compiling for use by an entire distribution, not just me, the
effort would of course be justified) so I don't choose to use it.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Vladimir G. Ivanovic]

On Fri, 2006-06-09 at 10:56 -0700, Bob Sanders wrote:
> If your file system driver is calculating where to place the beginning of a
> file or where to link the tail of one record to the head or the following
> record, one digit mis-calculation could have a bad consequence.  And way,
> way back in the bad old PDP-11 days, file systems did use FP.  I'd
> guess a few modern ones might be using it today.

Blocks, offsets, inodes, and pointers (addresses) are all "integers", so
why would one use floating point? Anyway, floating point is not allowed
in the Linux kernel, and drivers are part of the kernel.

>         
> 
> Also, most financial transactions require a minimum of 4 digits to the right
> of the decimal place.  Again, a single digit error can cause some folks to
> get very, very upset.

http://en.wikipedia.org/wiki/Floating_point#Accuracy.2C_and_misconceptions_thereof
"...financial software tends not to use a binary floating-point number
representation. The "decimal" data type of the C# and Java programming
languages, and the IEEE 854 standard, are designed to avoid the problems
of binary floating point, and make the arithmetic always behave as
expected when numbers are printed in decimal." 

--- Vladimir

-- 
Vladimir G. Ivanovic <vgivanovic@comcast.net>
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Vladimir G. Ivanovic]

On Fri, 2006-06-09 at 20:50 +0200, Hemmann, Volker Armin wrote:

> > If -ffast-math is filtered or stripped out, there is no harm in leaving
> > it in CFLAGS, right?
> 
> no, because a lot of other flags are filtered too!

What??? Whether only -ffast-math is filtered or all flags are filtered,
-ffast-math still filtered. I don't see where the harm lies.

> Some ebuilds filter ALL flags, only because some ricers had to use ffast-math 
> and other 'controversial' flags.
> 
> And some day, you will hit a package, that will built a damaged binary doing 
> the wrong stuff, that does not filter out, because nobody knew about it. And 
> then you are f*.

> 
> >
> > But, on my system, only 14 packages filter out -ffast-math: gnubg
> > postgresql pgcluster libpq zoom mpfr gmp octave openoffice gsl goffice
> > rrdtool xv gimp. None strip it out. So, the huge majority of the
> > packages on my system are compiled with -ffast-math, unless I've made a
> > mistake in grepping for "fast-math" in ebuilds that contain
> > "filter-flags".
> 
> and look for 'strip-flags'

There are only small number of ebuilds that strip out all flags.
Certainly less than 30.

> 
> 
> >         http://gcc.gnu.org/ml/gcc/2004-03/msg01511.html
> >         For me, it's very simple: If -ffast-math leads to answers that are
> > less accurate (in the verification-against-observation-sense) or unphysical
> > (against theoretical limit analysis), then I'll inspect my Fortran code and
> > repair the formulation (either a single expression or the layout of loop
> > code) that is responsible for the mayhem.
> >
> >         Under no circumstances I will give up using -ffast-math.
> >
> >        
> > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/320
> >35.pdf -ffast-math is recommended by AMD.
> 
> FOR SPECIAL APPS. AND THIS DOCUMENT IS MEANT FOR PROGRAMMERS! PEOPLE WHO KNOW 
> THEIR CODE!

I didn't see anywhere that the AMD document is for special applications
only. Where does it say that?

What it does say is that applications the rely on exact implementation
of IEEE rules or specifications for floating-point behavior shouldn't
use -ffast-math.

> 
> >
> > These opinions seem to contradict your advice. Could you be more
> > specific about why -ffast-math should not be used?
> 
> no, they don't contradict me. You did not understand them.
> 
> Nowhere does AMD tells endusers to build their complete system with that flag.

Chapter 1 Introduction, Section 1.1 Audience says:

        This document is intended for ISVs and end-users of the AMD
        Athlon 64 processor-based platforms... 

It's clear that you think using -ffast-math is dangerous. I don't, so I
plan on continuing to use it. So far, the evidence from my system is in
my favor. (I did run across two more instances, just today, where, in
addition, to busybox, ebuilds fail with -ffast-math: cdparanoia and
pcmciautils.)

What would make me change my mind is some evidence, or some authority
who could convincingly explain why the experiences of those who do use
-ffast-math is anomalous. SHOUTING OR MERELY ASSERTING THAT IT'S A
PROBLEM is not really convincing. 

How about continuing this discussion offline?

--- Vladimir

-- 
Vladimir G. Ivanovic <vgivanovic@comcast.net>
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Barry.SCHWARTZ]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

"Vladimir G. Ivanovic" <vgivanovic@comcast.net> skribis:
> http://en.wikipedia.org/wiki/Floating_point#Accuracy.2C_and_misconceptions_thereof
> "...financial software tends not to use a binary floating-point number
> representation. The "decimal" data type of the C# and Java programming
> languages, and the IEEE 854 standard, are designed to avoid the problems
> of binary floating point, and make the arithmetic always behave as
> expected when numbers are printed in decimal." 

What you really want for financial applications is fixed point
decimal, because you can’t throw away any digits except when
dividing. For hand calculators you want binary floating point with
guard digits.

Enough research has gone into writing code for IEEE floating point
that I would not try to bypass it without a good reason. It’s there to
be your friend.

-- 
Barry.SCHWARTZ at chemoelectric.org   http://chemoelectric.org
        Free stuff / Senpagaj varoj:  http://crudfactory.com (PDF)
'Democracies don't war; democracies are peaceful countries.' - Bush
(http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Vladimir G. Ivanovic]

On Fri, 2006-06-09 at 16:14 -0500, Barry.SCHWARTZ@chemoelectric.org
wrote:

> Enough research has gone into writing code for IEEE floating point
> that I would not try to bypass it without a good reason. It’s there to
> be your friend.

Performance is the reason we have hardware FPUs and -ffast-math.

---Vladimir

-- 
Vladimir G. Ivanovic <vgivanovic@comcast.net>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Hemmann, Volker Armin]

On Friday 09 June 2006 23:42, Vladimir G. Ivanovic wrote:
> On Fri, 2006-06-09 at 16:14 -0500, Barry.SCHWARTZ@chemoelectric.org
>
> wrote:
> > Enough research has gone into writing code for IEEE floating point
> > that I would not try to bypass it without a good reason. It’s there to
> > be your friend.
>
> Performance is the reason we have hardware FPUs and -ffast-math.

no, ffast-math is for the case, that you

a) don't need accurate results

b) the FPU is not fast enough


since you can't say if you need accurate math for an app you did not wrote or 
examined, using ffast-math is highly dangerous. And sicne the hardware gets 
faster on an almost monthly basis, it is even less convincing why anybody 
should use it.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Hemmann, Volker Armin]

On Friday 09 June 2006 22:45, Vladimir G. Ivanovic wrote:
> On Fri, 2006-06-09 at 20:50 +0200, Hemmann, Volker Armin wrote:
> > > If -ffast-math is filtered or stripped out, there is no harm in leaving
> > > it in CFLAGS, right?
> >
> > no, because a lot of other flags are filtered too!
>
> What??? Whether only -ffast-math is filtered or all flags are filtered,
> -ffast-math still filtered. I don't see where the harm lies.

the harm lies in an app, that does not filter and breaks in subtle ways when 
compiled with fast-math.


> >
> > FOR SPECIAL APPS. AND THIS DOCUMENT IS MEANT FOR PROGRAMMERS! PEOPLE WHO
> > KNOW THEIR CODE!
>
> I didn't see anywhere that the AMD document is for special applications
> only. Where does it say that?
>
> What it does say is that applications the rely on exact implementation
> of IEEE rules or specifications for floating-point behavior shouldn't
> use -ffast-math.

again, that guide is for programmers, to optimze the code they wrote and they 
know in and out. Not end users, who turn on every flag because it sounds 
good.

>

>
> Chapter 1 Introduction, Section 1.1 Audience says:
>
>         This document is intended for ISVs and end-users of the AMD
>         Athlon 64 processor-based platforms...
>
> It's clear that you think using -ffast-math is dangerous. I don't, so I
> plan on continuing to use it. So far, the evidence from my system is in
> my favor. (I did run across two more instances, just today, where, in
> addition, to busybox, ebuilds fail with -ffast-math: cdparanoia and
> pcmciautils.)

I don't even think so, I know it. 
I have seen enough people breaking their systems with ffast-math and similar 
dangerous flags.

>
> What would make me change my mind is some evidence, or some authority
> who could convincingly explain why the experiences of those who do use
> -ffast-math is anomalous. SHOUTING OR MERELY ASSERTING THAT IT'S A
> PROBLEM is not really convincing.

maybe man gcc is evidence enough?
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Barry.SCHWARTZ]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

"Vladimir G. Ivanovic" <vgivanovic@comcast.net> skribis:
> On Fri, 2006-06-09 at 16:14 -0500, Barry.SCHWARTZ@chemoelectric.org
> wrote:
> 
> > Enough research has gone into writing code for IEEE floating point
> > that I would not try to bypass it without a good reason. It’s there to
> > be your friend.
> 
> Performance is the reason we have hardware FPUs and -ffast-math.

For home video games, maybe. For scientists and engineers I’d say
always use the complete standard arithmetic, because some of the
numerical routines may assume it, and for the ability to duplicate
results.


-- 
Barry.SCHWARTZ at chemoelectric.org   http://chemoelectric.org
        Free stuff / Senpagaj varoj:  http://crudfactory.com (PDF)
'Democracies don't war; democracies are peaceful countries.' - Bush
(http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: gcc 4.1 + CFLAGS

[Samir Mishra]

Duncan wrote:
> A couple questions:
>
> -mcmodel=medium:  Here's the gcc 4.1.1 manpage entry:
>
> -mcmodel=medium
>   Generate code for the medium model: The program is linked in the lower 2
>   GB of the address space but symbols can be located any-where in the
>   address space.  Programs can be statically or dynamically linked, but
>   building of shared libraries are not supported with the medium model.
>
> What about that last part -- shared libraries not supported?
>
>   
palladium ~ # file /bin/bash
/bin/bash: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for 
GNU/Linux 2.6.11, dynamically linked (uses shared libs), stripped
palladium ~ # file /lib/libc-2.4.so
/lib/libc-2.4.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 
(SYSV), stripped
palladium ~ # file /lib/libgcc_s.so.1
/lib/libgcc_s.so.1: ELF 64-bit LSB shared object, AMD x86-64, version 1 
(SYSV), stripped

I assume this is how to  check if a n executable or library is shared. I 
picked 3 common ones at random. I think I read somewhere that the above 
statement regarding lack of support for building shared libraries is not 
accurate. I assumed it to be inaccurate too since I get the above output 
against all files on my machine. If I tested the libraries incorrectly, 
could you indicate what would be the right way to check if GCC is 
generating shared libraries or not? Memory usage seems reasonable for 
all of the applications, but given how much I know, quite possible I got 
it wrong.
> Also...  from my understanding, the address-space references here are
> simply to the program's view of memory, from it's perspective.  More
> specifically, it's not to absolute address space (the >2 gig memory you
> mention), but to the program's virtual address space, the protected-mode
> virtual address space unique to it, and rather independent from its actual
> placement in physical memory or its placement in terms of the kernel's
> virtual address space.
>
> As I understand it, therefore, the only reason to use -mcmodel=medium
> would be if the program itself was expected to manipulate memory on the
> order of gigs at a time.  While this can legitimately happen, say with a
> big database (think Oracle, which very likely uses such an option), the
> vast majority of applications don't work with anywhere near that size of
> data, at least not directly.  While they might handle gigs of data over
> the lifetime of the program, it's megabytes not gigabytes at a time, and
> much of it may be indirectly, thru the kernel, so they have little need
> for a memory allocation model that can allocate structures of multiple
> gigs at a time or to access anything outside a two-gigabyte model.  Even
> on the big machines running apps where use of this model might be
> legitimately called for, it would be inadvisable to compile /everything/
> on the machine with it, only the specific apps that need it.
>
>   
I thought otherwise. I guess I'll have to do some research on this. In 
case you do come across any interesting pointers or references, please 
do let me know.
> This would also explain why it only applies to applications, not shared
> libraries, as only the linked application would need to reference the full
> multi-gig allocations -- any library functions would presumably be working
> with much smaller sections of that dataset.
>
> Note that I'm specifically /not/ saying you are incorrect, only that it
> disagrees with what I (think I) know, which itself may be incorrect.  I'm
> running 8 gig of memory here, but it's a fairly new upgrade, so a new
> experience, and it's quite possible what I thought I knew is wrong.  If
> so, I'd like to know it, the better to make use of the memory I have here,
> as well.  So, if you have references as to why you are using that memory
> model, post 'em, as I'd certainly like to read them myself!
>
> -ftracer: Of interest here are a couple other manpage entries:
>
>   
I thought -ftracer, like -fweb, automatically did the profiling and the 
optimization. I was under the impression that -ftracer not recommended 
since it increases compile times (which I wasn't worried about) but 
produces "better" executables. If the profiling has to be done manually, 
prior to optimization, I definitely need to take this one out for my CFLAGS.
> -fprofile-generate
>   Enable options usually used for instrumenting application to produce
>   profile useful for later recompilation with profile feedback based
>   optimization.  [snip]
>
> -fprofile-use
>   Enable profile feedback directed optimizations, and optimizations
>   generally profitable only with profile feedback available.
>
>   The following options are enabled: "-fbranch-probabilities", "-fvpt",
>   "-funroll-loops", "-fpeel-loops", "-ftracer", "-fno-loop-optimize".
>
>   
BTW I've heard bad things about using -fbranch-probabilities and -fweb. 
In fact, I tried -fweb with -ftracer and I began experiencing numerous 
compilation failures. Everything went back to OK when I took it out.
> I don't see either of these in your CFLAGS, and you don't mention
> compiling, then profiling the program, then recompiling.  Without that,
> the -ftracer flag, which the manpage says "perform[s] tail duplication to
> enlarge superblock size", would appear to enlarge your binaries for little
> or no performance gain.
>
> That said, I've seen a couple developers that use the -ftracer flag as
> well, in various bug reports and the like, which has surprised me a bit
> since it's common for devs to complain about others using flags they don't
> understand the implications of. However, I've yet to find someone who can
> suitably explain /why/ they use it, given the above and the rather
> unlikely chance that they actually bother with that profiling and
> recompilation with every package they use the flag with, tho I don't of
> course go around posting the question to every bug where I see it used,
> and I've had limited chance to ask the question in a suitable context, so
> I've not asked that many about it.
>
> Again, if you have a good reason to choose that flag, or if you've
> actually done tests and /know/ it improves performance, please post it, so
> folks (like me! =8^) can be informed and perhaps optimize their system
> similarly. Until then, I can't reasonably defend or explain using the
> flag if I'm not going to go to the trouble of profiling and recompiling,
> and I don't think the performance gains would be enough to justify that
> (if I were compiling for use by an entire distribution, not just me, the
> effort would of course be justified) so I don't choose to use it.
>   

In conclusion, I THOUGHT I had good reason, but I guess I need to do a 
bit more research.

I have not done any speed tests, From reading all the speed tests, I 
know these don't make any sense, because in a real use situation, many 
other factors matter. And anyway, I don't have the knowledge to them 
right :)


Thx.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: gcc 4.1 + CFLAGS

[Samir Mishra]

Also seems like something I said in another message about researching 
before adding CFLAGS to the list came right back to bite me on my ass :)


SM
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: gcc 4.1 + CFLAGS

[Duncan]

Samir Mishra <sqmishra@eim.ae> posted 448B34EC.9030009@eim.ae, excerpted
below, on  Sun, 11 Jun 2006 01:09:00 +0400:

> Duncan wrote:
>> A couple questions:
>>
>> -mcmodel=medium:  Here's the gcc 4.1.1 manpage entry:
>>
>> -mcmodel=medium
>>   [] Programs can be statically or dynamically linked, but
>>   building of shared libraries are not supported with the medium model.
>>
>> What about that last part -- shared libraries not supported?
>>
>>
> palladium ~ # file /bin/bash
> /bin/bash: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
> GNU/Linux 2.6.11, dynamically linked (uses shared libs), stripped
> palladium ~ # file /lib/libc-2.4.so
> /lib/libc-2.4.so: ELF 64-bit LSB shared object, AMD x86-64, version 1
> (SYSV), stripped

> I assume this is how to  check if a n executable or library is shared[.]
> I think I read somewhere that the above statement regarding lack of
> support for building shared libraries is not accurate[.] Memory usage
> seems reasonable for all of the applications, but given how much I know,
> quite possible I got it wrong.

Yes, that does check if it's shared, but unless there's something very
broken with your setup (I've seen it happen when an installation script
broke), shared libraries will always be *.so* (so is short for shared
object, and a *.so* file is comparable to the dll, dynamic link library,
so common on MSWormOS). Static libraries, OTOH, have the .a extension and
are collected and archived using shar (originally referring to
shell-archive, just like tar originally referred to tape-archive).

Static libraries must be compiled directly into the executable application
itself at compile time -- dynamic or shared libraries are loaded into the
application by ld at runtime.  Because static libraries are compiled into
the applications themselves, the resulting applications are much larger
(sometimes by several times), and consume much more memory, as there's a
copy of each library (or at least the parts of it used by the application)
for every application, all in memory at the same time.  Thus, the most
common parts of libc, for instance, will be duplicated in every single
app, both on disk and when they are loaded in memory!

Since you haven't noticed an extreme increase in memory usage, and the
*.so files seem to be there and usable, it's quite obvious that in fact
the gcc manpage IS inaccurate, in that case.  It obviously works for you
or by now you'd have a VERY VERY broken system and NOTHING would be
working.

So anyway, I learned that it at least isn't as bad as the gcc manpage
would lead one to believe. =8^)

That said, it /could/ be that gcc automatically disables that option for
shared objects, if it's such that it can do so.  I know it does so for
example with -freorder-blocks-and-partition, both because the manpage says
so, and because it spits out a warning when it does so that can be
problematic during the pre-compilation configure phase.  (It's for that
reason that I use that flag in CFLAGS but not in CXXFLAGS, because the use
of exceptions in C++ automatically disables it anyway, and the warning was
causing emerge failures.)  However, I'm not sure where the memory model
comes into use.  If it's only when linking the object files, gcc could
likely detect that it's creating a shared object and act accordingly.  If
it's while actually compiling the object files from source, then it
wouldn't necessarily know whether they were going to be shared objects or
applications at that point.

Thus, I'm not sure whether gcc is simply disabling that flag with shared
objects or whether it actually uses it but without the harm the use flag
implies will result.

Regardless, I remain of the opinion that for most apps, it's unnecessary
and will at minimum result in a larger binary than would otherwise be the
case, with no benefit, so it's all-negative, even if it doesn't actually
break anything.  Again, it's possible I'm wrong about that, but if I am,
it goes against all I've ever read on the subject.

I think the bit in your other reply about that comment of being sure you
research your CFLAGS before you use them coming back to bite you is a good
summation.  The discussion has been beneficial to both of us, however, as
my questioning is forcing a bit more research on your part, while I
learned that the results aren't quite as dire as the manpage implies they
are.  =8^)

>> -ftracer: Of interest here are a couple other manpage entries:
>>
>>
> I thought -ftracer, like -fweb, automatically did the profiling and the
> optimization. I was under the impression that -ftracer not recommended
> since it increases compile times (which I wasn't worried about) but
> produces "better" executables. If the profiling has to be done manually,
> prior to optimization, I definitely need to take this one out for my
> CFLAGS.

I'd still like to get a definitive answer from one of the devs that uses
it.  Presumably they won't be caught in the same trap of telling others to
know their CFLAGS, but not knowing their own, that this seems to have
caught you in.  =8^)  Maybe the manpage is incorrect here as well? <shrug>

> BTW I've heard bad things about using -fbranch-probabilities and -fweb.
> In fact, I tried -fweb with -ftracer and I began experiencing numerous
> compilation failures. Everything went back to OK when I took it out.

Very interesting.  I'd not been aware of such.

I wonder... maybe they are the automatic-profiling and manual-profiling
parallels of the same thing?  If so, it would explain both the problems
you experienced trying to use both together and the reason one is implied
to be manual while the other is evidently automatic.

I'm afraid I'm raising more questions than I have answers! =8^(

> In conclusion, I THOUGHT I had good reason, but I guess I need to do a
> bit more research.

You know... I've come to realize that ironically, I often value the
opinions of and discussions/debates/arguments with those I disagree with
most, particularly where they honestly challenge me and I them, more
highly than those I tend to agree with. The reason is precisely your
conclusion above -- those discussions/debates/arguments tend to spotlight
the weakest points in my reasoning that I'd be very unlikely to find it on
my own, thus stimulating an acknowledgement that I can't defend that
particular point at that particular time and further research, which
ultimately leads to either understanding my own position better, or a
retraction from it.  Had I not been forced by the other person to face
that weakness, I'd have never found it and therefore never had a chance to
adjust to it or for it.  For that reason, I consider that person to have
done me a favor for helping me find what I would have otherwise been
unaware of, and hold an even greater respect for them than I do for those
I always agreed with.

So, it seems we are both learning here.  I certainly had my misconception
that the medium memory model would result in a broken system if used in
CFLAGS while attempting to compile shared objects disproved, and you've
learned your position wasn't as secure as you believed it to be, either. 
I think that means we've both benefited!  =8^)

The great thing about doing this on the public mailing list, is that
others benefit as well.  I know I'm always learning things from the
discussions of others!



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: gcc 4.1 + CFLAGS

[Vladimir G. Ivanovic]

On Sun, 2006-06-11 at 14:33 +0000, Duncan wrote:

> Static libraries, OTOH, have the .a extension and
> are collected and archived using shar (originally referring to
> shell-archive, just like tar originally referred to tape-archive).
> 

Static libraries are created and manipulated with 'ar', not 'shar'. Shar
files are collections text files. Static libraries are collections
binary files.

        ar: http://en.wikipedia.org/wiki/Ar_%28Unix%29
        shar: http://en.wikipedia.org/wiki/Shar

--- Vladimir

-- 
Vladimir G. Ivanovic <vgivanovic@comcast.net>
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Re: gcc 4.1 + CFLAGS

[Duncan]

"Vladimir G. Ivanovic" <vgivanovic@comcast.net> posted
1150042269.12776.19.camel@scarlatti.leonora.org, excerpted below, on  Sun,
11 Jun 2006 09:11:09 -0700:

> On Sun, 2006-06-11 at 14:33 +0000, Duncan wrote:
> 
>> Static libraries, OTOH, have the .a extension and
>> are collected and archived using shar (originally referring to
>> shell-archive, just like tar originally referred to tape-archive).
> 
> Static libraries are created and manipulated with 'ar', not 'shar'. Shar
> files are collections text files. Static libraries are collections
> binary files.
> 
>         ar: http://en.wikipedia.org/wiki/Ar_%28Unix%29
>         shar: http://en.wikipedia.org/wiki/Shar

What about ARGH!?  <g>  I /knew/ I should have done a refresher on that b4
posting.  =8^(

Now /what/ was I saying about public errors being publicly corrected
being preferable to not risking it and thereby not having the
misconception corrected, despite the discomfort of being publicly wrong?

Thanks!



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: Re: gcc 4.1 + CFLAGS

[Barry.SCHWARTZ]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

Duncan <1i5t5.duncan@cox.net> wrote:
> Static libraries, OTOH, have the .a extension and
> are collected and archived using shar (originally referring to
> shell-archive, just like tar originally referred to tape-archive).

Then "Vladimir G. Ivanovic" <vgivanovic@comcast.net> wrote:
> Static libraries are created and manipulated with 'ar', not 'shar'. Shar
> files are collections text files. Static libraries are collections
> binary files....

Then Duncan <1i5t5.duncan@cox.net> wrote:
> What about ARGH!?  <g>  I /knew/ I should have done a refresher on that b4
> posting.  =8^(

There aren’t too many people using ar as their general purpose
bundling tool, these days, though I knew one person who did, and it
was less than 20 years ago.

Shar archives would really, really, really not work. :) But zip
archives might....

-- 
Barry.SCHWARTZ at chemoelectric.org   http://chemoelectric.org
        Free stuff / Senpagaj varoj:  http://crudfactory.com (PDF)
'Democracies don't war; democracies are peaceful countries.' - Bush
(http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

On Friday 09 June 2006 14:13, Ian McCulloch wrote:
> On Fri, 9 Jun 2006, Vladimir G. Ivanovic wrote:
> > On Fri, 2006-06-09 at 07:47 +0200, Michael Weyershäuser wrote:
> > > I don't recommend -ffast-math on a global basis (or at all), it
> > > gets you right where the Pentium fdiv bug brought us some years
> > > ago: floating point operations will be faster, but they could get a
> > > wrong result in some occasions...
> >
> > Linus seems to use -ffast-math:
> > http://gcc.gnu.org/ml/gcc/2001-07/msg02150.html. At least in 2001 he
> > did.
>
> I use it too, in my numerical simulations of the Schroedigner equation,
> I think it is fairly standard in the numerics community.  My
> understanding is that it results in a fairly consistent and predictable
> loss of precision for some operations, nothing like the catastrophic
> *errors* in the the intel fdiv bug.  Of course, for algorithms that are
> sensitive to precision, it can (and does) cause problems.

And all please remember that there are fairly easy equasions that can be 
very numerically  unstable. In such cases every bit of precision counts. 
Just do not enable it globally. If packages can use it, they can enable 
it themselves.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

On Saturday 10 June 2006 00:28, Hemmann, Volker Armin wrote:
> On Friday 09 June 2006 23:42, Vladimir G. Ivanovic wrote:
> > On Fri, 2006-06-09 at 16:14 -0500, Barry.SCHWARTZ@chemoelectric.org
> >
> > wrote:
> > > Enough research has gone into writing code for IEEE floating point
> > > that I would not try to bypass it without a good reason. It’s there
> > > to be your friend.
> >
> > Performance is the reason we have hardware FPUs and -ffast-math.
>
> no, ffast-math is for the case, that you
>
> a) don't need accurate results
>
> b) the FPU is not fast enough
>
>
> since you can't say if you need accurate math for an app you did not
> wrote or examined, using ffast-math is highly dangerous. And sicne the
> hardware gets faster on an almost monthly basis, it is even less
> convincing why anybody should use it.

I completely agree. The gcc info page puts it this way:
     This option should never be turned on by any `-O' option since it
     can result in incorrect output for programs which depend on an
     exact implementation of IEEE or ISO rules/specifications for math
     functions.

In short there is a very good reason it is not on by default and may never 
be turned on by default.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-amd64] gcc 4.1 + CFLAGS

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On Saturday 10 June 2006 00:32, Hemmann, Volker Armin wrote:
> On Friday 09 June 2006 22:45, Vladimir G. Ivanovic wrote:
> > On Fri, 2006-06-09 at 20:50 +0200, Hemmann, Volker Armin wrote:
> > > > If -ffast-math is filtered or stripped out, there is no harm in
> > > > leaving it in CFLAGS, right?
> > >
> > > no, because a lot of other flags are filtered too!
> >
> > What??? Whether only -ffast-math is filtered or all flags are
> > filtered, -ffast-math still filtered. I don't see where the harm
> > lies.
>
> the harm lies in an app, that does not filter and breaks in subtle ways
> when compiled with fast-math.

One may even argue that those ebuilds that filter out fast-math are broken 
as it is an unsupported flag. One that can not be expected to work 
globally. (And yes I'm maintainer of one of them (ooffice)). The reason 
that maintainers add them is just because there are too many people that 
insist on using broken flags, but still want to be able to have a useable 
system (including an office suite).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]