Re: [arch-general] [arch-dev-public] [signoff] gcc-4.5 toolchain rebuild
Hi, On Fri, Apr 16, 2010 at 7:32 PM, Allan McRae <allan@archlinux.org> wrote:
The gcc-4.5 toolchain rebuild is in [testing]. Here is a summary of the changes I made:
gcc-4.5.0-1: upstream update add new deps (libmpc, libelf) enable link time optimization tidy up configure add c89 and c99 launcher scripts (POSIX compatibility)
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; Thanks.
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. Allan
Thanks for your reply Allan. On Sat, Apr 17, 2010 at 5:30 AM, Allan McRae <allan@archlinux.org> 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?
On Sat, Apr 17, 2010 at 3:48 AM, Emmanuel Benisty <benisty.e@gmail.com> wrote:
Thanks for your reply Allan.
On Sat, Apr 17, 2010 at 5:30 AM, Allan McRae <allan@archlinux.org> 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.
On Sat, Apr 17, 2010 at 4:00 AM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Sat, Apr 17, 2010 at 3:48 AM, Emmanuel Benisty <benisty.e@gmail.com> wrote:
Thanks for your reply Allan.
On Sat, Apr 17, 2010 at 5:30 AM, Allan McRae <allan@archlinux.org> 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
participants (4)
-
Allan McRae
-
Dan McGee
-
Emmanuel Benisty
-
Xavier Chantry