On Sat, Apr 17, 2010 at 4:00 AM, Xavier Chantry <chantry.xavier@xxxxxxxxx> wrote: > On Sat, Apr 17, 2010 at 3:48 AM, Emmanuel Benisty <benisty.e@xxxxxxxxx> wrote: >> Thanks for your reply Allan. >> >> On Sat, Apr 17, 2010 at 5:30 AM, Allan McRae <allan@xxxxxxxxxxxxx> wrote: >>> On 17/04/10 00:03, Emmanuel Benisty wrote: >>>> >>>> Just out of curiosity, what is the plan regarding this issue (quoted >>>> from the gcc changelog): >>>> >>>> On x86 targets, code containing floating-point calculations may run >>>> significantly slower when compiled with GCC 4.5 in strict C99 >>>> conformance mode than they did with earlier GCC versions. This is due >>>> to stricter standard conformance of the compiler and can be avoided by >>>> using the option -fexcess-precision=fast; >>>> >>> >>> From what I understand, this requires passing -std=c99 (or equivalent) to >>> the compiler for it to use strict C99 mode. So most software will not be >>> affected. Of course, the maintainer of any software the does set C99 mode >>> should consider this. >> >> If it does affect only that type of code and if you recommend the >> maintainers to use this option in those cases then wouldn't it simpler >> to add it to /etc/makepkg.conf by default and thus make it a >> no-brainer for maintainers? >> > > What's wrong with stricter standard conformance ? That sounds like a > good change. > How can you tell that these apps with floating-point calculations were > not actually buggy with previous versions of gcc (or with > -fexcess-precision=fast now) ? > > It does not seem a very good idea to set that globally. I think that > should be done case per case, and not by maintainers, but by the > developers of the apps, who know well their code, and can make a > reasonable decision whether they want/need performance or > conformance/accuracy. > And you *need* to know how these two aspects are affected if you want > to make a reasoned and informed change, rather than a blind and > clueless one. You would be hard-pressed to find a program that uses C99 as default. If they do, they probably do it for good reason and the burden would not even be on the Arch maintainer but upstream to figure out why that choice was made. -Dan
