* Change x86 default arch for 4.5? @ 2010-02-18 22:09 Jason Merrill 2010-02-18 23:30 ` Joe Buck 2010-02-19 0:46 ` Joseph S. Myers 0 siblings, 2 replies; 75+ messages in thread From: Jason Merrill @ 2010-02-18 22:09 UTC (permalink / raw) To: GCC I periodically get bitten by bug 34115: a compiler configured without --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would only need to bump the default to i486 to get atomic support. Can we reconsider the default for 4.5? Jason ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-18 22:09 Change x86 default arch for 4.5? Jason Merrill @ 2010-02-18 23:30 ` Joe Buck 2010-02-19 0:31 ` David Daney 2010-02-19 0:46 ` Joseph S. Myers 1 sibling, 1 reply; 75+ messages in thread From: Joe Buck @ 2010-02-18 23:30 UTC (permalink / raw) To: Jason Merrill; +Cc: GCC On Thu, Feb 18, 2010 at 02:09:14PM -0800, Jason Merrill wrote: > I periodically get bitten by bug 34115: a compiler configured without > --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we > would only need to bump the default to i486 to get atomic support. Can > we reconsider the default for 4.5? Is anyone still manufacturing x86 CPUs that don't support the atomic instructions? ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-18 23:30 ` Joe Buck @ 2010-02-19 0:31 ` David Daney 2010-02-19 0:54 ` Joe Buck 0 siblings, 1 reply; 75+ messages in thread From: David Daney @ 2010-02-19 0:31 UTC (permalink / raw) To: Joe Buck; +Cc: Jason Merrill, GCC On 02/18/2010 03:30 PM, Joe Buck wrote: > On Thu, Feb 18, 2010 at 02:09:14PM -0800, Jason Merrill wrote: >> I periodically get bitten by bug 34115: a compiler configured without >> --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we >> would only need to bump the default to i486 to get atomic support. Can >> we reconsider the default for 4.5? > > Is anyone still manufacturing x86 CPUs that don't support the atomic > instructions? Should it just be a question of 'manufacturing'? Or should 'using' be a criterion for any decision? Not that I disagree with Jason's suggestion, it is probably the right choice. David Daney ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-19 0:31 ` David Daney @ 2010-02-19 0:54 ` Joe Buck 2010-02-19 2:00 ` Tim Prince 0 siblings, 1 reply; 75+ messages in thread From: Joe Buck @ 2010-02-19 0:54 UTC (permalink / raw) To: David Daney; +Cc: Jason Merrill, GCC On Thu, Feb 18, 2010 at 04:31:37PM -0800, David Daney wrote: > On 02/18/2010 03:30 PM, Joe Buck wrote: > > On Thu, Feb 18, 2010 at 02:09:14PM -0800, Jason Merrill wrote: > >> I periodically get bitten by bug 34115: a compiler configured without > >> --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we > >> would only need to bump the default to i486 to get atomic support. Can > >> we reconsider the default for 4.5? > > > > Is anyone still manufacturing x86 CPUs that don't support the atomic > > instructions? > > Should it just be a question of 'manufacturing'? Or should 'using' be a > criterion for any decision? > Not that I disagree with Jason's suggestion, it is probably the right > choice. "using" would be the right criterion if Jason were advocating removing support for i386 but he only proposed changing the default. But maybe I didn't ask the right question: can any x86 experts comment on recently made x86 CPUs that would not function correctly with code produced by --with-arch=i486? Are there any? ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-19 0:54 ` Joe Buck @ 2010-02-19 2:00 ` Tim Prince 2010-02-19 17:31 ` Joe Buck 2010-02-19 20:56 ` Florian Weimer 0 siblings, 2 replies; 75+ messages in thread From: Tim Prince @ 2010-02-19 2:00 UTC (permalink / raw) To: gcc On 2/18/2010 4:54 PM, Joe Buck wrote: > > But maybe I didn't ask the right question: can any x86 experts comment on > recently made x86 CPUs that would not function correctly with code > produced by --with-arch=i486? Are there any? > > All CPUs still in production are at least SSE3 capable, unless someone can come up with one of which I'm not aware. Intel compilers made the switch last year to requiring SSE2 capability for the host, as well as in the default target options, even for 32-bit. All x86_64 or X64 CPUs for which any compiler was produced had SSE2 capability, so it is required for those 64-bit targets. -- Tim Prince ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-19 2:00 ` Tim Prince @ 2010-02-19 17:31 ` Joe Buck 2010-02-20 7:58 ` Erik Trulsson 2010-02-21 11:18 ` Steven Bosscher 2010-02-19 20:56 ` Florian Weimer 1 sibling, 2 replies; 75+ messages in thread From: Joe Buck @ 2010-02-19 17:31 UTC (permalink / raw) To: tprince; +Cc: gcc On Thu, Feb 18, 2010 at 06:00:07PM -0800, Tim Prince wrote: > On 2/18/2010 4:54 PM, Joe Buck wrote: > > > > But maybe I didn't ask the right question: can any x86 experts comment on > > recently made x86 CPUs that would not function correctly with code > > produced by --with-arch=i486? Are there any? > > > > > All CPUs still in production are at least SSE3 capable, unless someone > can come up with one of which I'm not aware. Intel compilers made the > switch last year to requiring SSE2 capability for the host, as well as > in the default target options, even for 32-bit. All x86_64 or X64 CPUs > for which any compiler was produced had SSE2 capability, so it is > required for those 64-bit targets. I'm sure that Intel and AMD haven't made any in ages, I just wanted to make sure that there are no low-end third-party cores made recently (say, by Cyrix, VIA, or someone else) that lack atomics. I guess that the answer is no. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-19 17:31 ` Joe Buck @ 2010-02-20 7:58 ` Erik Trulsson 2010-02-21 11:18 ` Steven Bosscher 1 sibling, 0 replies; 75+ messages in thread From: Erik Trulsson @ 2010-02-20 7:58 UTC (permalink / raw) To: Joe Buck; +Cc: tprince, gcc On Fri, Feb 19, 2010 at 09:31:12AM -0800, Joe Buck wrote: > On Thu, Feb 18, 2010 at 06:00:07PM -0800, Tim Prince wrote: > > On 2/18/2010 4:54 PM, Joe Buck wrote: > > > > > > But maybe I didn't ask the right question: can any x86 experts comment on > > > recently made x86 CPUs that would not function correctly with code > > > produced by --with-arch=i486? Are there any? > > > > > > > > All CPUs still in production are at least SSE3 capable, unless someone > > can come up with one of which I'm not aware. Intel compilers made the > > switch last year to requiring SSE2 capability for the host, as well as > > in the default target options, even for 32-bit. All x86_64 or X64 CPUs > > for which any compiler was produced had SSE2 capability, so it is > > required for those 64-bit targets. > > I'm sure that Intel and AMD haven't made any in ages, Depends on what you mean by ages. Intel did not stop producing actual 80386 (and 80486) processors until as late as 2007 (for use in embedded systems.) Looking around at Intel's homepage for embedded processors I find references to Pentium-MMX processors, but I am not sure about the actual status of those. (Those old CPUs probably haven't been used for any new designs for quite a while, but older designs using them might still be in prodcution.) Amd seems to still be producing the Geode-LX series which do not seem to support SSE at all (only MMX and 3dnow.) However to answer the original question I believe that all x86 variants that are still actively developed for support at least the full 80486 instruction set. > I just wanted to > make sure that there are no low-end third-party cores made recently (say, > by Cyrix, VIA, or someone else) that lack atomics. I guess that the > answer is no. > -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-19 17:31 ` Joe Buck 2010-02-20 7:58 ` Erik Trulsson @ 2010-02-21 11:18 ` Steven Bosscher 2010-02-21 12:06 ` Geert Bosch 1 sibling, 1 reply; 75+ messages in thread From: Steven Bosscher @ 2010-02-21 11:18 UTC (permalink / raw) To: Joe Buck; +Cc: tprince, gcc On Fri, Feb 19, 2010 at 6:31 PM, Joe Buck <Joe.Buck@synopsys.com> wrote: > On Thu, Feb 18, 2010 at 06:00:07PM -0800, Tim Prince wrote: >> On 2/18/2010 4:54 PM, Joe Buck wrote: >> > >> > But maybe I didn't ask the right question: can any x86 experts comment on >> > recently made x86 CPUs that would not function correctly with code >> > produced by --with-arch=i486? Are there any? >> > >> > >> All CPUs still in production are at least SSE3 capable, unless someone >> can come up with one of which I'm not aware. Intel compilers made the >> switch last year to requiring SSE2 capability for the host, as well as >> in the default target options, even for 32-bit. All x86_64 or X64 CPUs >> for which any compiler was produced had SSE2 capability, so it is >> required for those 64-bit targets. > > I'm sure that Intel and AMD haven't made any in ages, I just wanted to > make sure that there are no low-end third-party cores made recently (say, > by Cyrix, VIA, or someone else) that lack atomics. I guess that the > answer is no. Forgive me my ignorance, but... Why is this important/relevant? As a user of GCC, I would expect the compiler to generate good code for reasonably modern targets in the default settings. The number of machines that are still based on i386, i486, or even Pentium, is a barely significant minority, yet gcc will by default satisfy the needs of this minority and make it more difficult for the average user to get good code out of the compiler. I work a lot with software developers that use gcc as just one of the many compilers they use (usually they use gcc on linux-ix86 and linux-x86_64, but hp for hppa, intel for itanium-linux, etc.). So far, most of them do not add any -march or -mtune parameters to gcc, so they end up with a program (a structural analysis code) that performs less-than-optimal. One of these users had actually dropped gcc on ix86-linux and x86_64-linux in favor of icc because gcc generated a much slower program. I explained how to change the default settings from i386 to pentium3, narrowing the performance gap to almost nothing. This user now uses gcc for all supported linux based platforms again. My point: gcc may fail to attract users (and/or may be losing users) when it tries to tailor to the needs of minorities. IMHO it would be much more reasonable to change the defaults to generate code that can run on, say, 95% of the computers still in use. If a user want to use the latest-and-greatest gcc for a really old machine, the burden of adding extra flags to change the default behavior of the compiler should be on that user. In this case of the i386 back end, that probably means changing the default to something like pentium3. Ciao! Steven ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 11:18 ` Steven Bosscher @ 2010-02-21 12:06 ` Geert Bosch 2010-02-21 12:13 ` Richard Guenther 0 siblings, 1 reply; 75+ messages in thread From: Geert Bosch @ 2010-02-21 12:06 UTC (permalink / raw) To: Steven Bosscher; +Cc: Joe Buck, tprince, gcc On Feb 21, 2010, at 06:18, Steven Bosscher wrote: > My point: gcc may fail to attract users (and/or may be losing users) > when it tries to tailor to the needs of minorities. > > IMHO it would be much more reasonable to change the defaults to > generate code that can run on, say, 95% of the computers still in use. > If a user want to use the latest-and-greatest gcc for a really old > machine, the burden of adding extra flags to change the default > behavior of the compiler should be on that user. > > In this case of the i386 back end, that probably means changing the > default to something like pentium3. The biggest change we need to make for x86 is to enable SSE2, so we can get proper rounding behavior for float and double, as well as significant performance increases. -Geert ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 12:06 ` Geert Bosch @ 2010-02-21 12:13 ` Richard Guenther 2010-02-21 12:33 ` Paolo Carlini ` (3 more replies) 0 siblings, 4 replies; 75+ messages in thread From: Richard Guenther @ 2010-02-21 12:13 UTC (permalink / raw) To: Geert Bosch; +Cc: Steven Bosscher, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 1:06 PM, Geert Bosch <bosch@adacore.com> wrote: > > On Feb 21, 2010, at 06:18, Steven Bosscher wrote: >> My point: gcc may fail to attract users (and/or may be losing users) >> when it tries to tailor to the needs of minorities. >> >> IMHO it would be much more reasonable to change the defaults to >> generate code that can run on, say, 95% of the computers still in use. >> If a user want to use the latest-and-greatest gcc for a really old >> machine, the burden of adding extra flags to change the default >> behavior of the compiler should be on that user. >> >> In this case of the i386 back end, that probably means changing the >> default to something like pentium3. > > The biggest change we need to make for x86 is to enable SSE2, > so we can get proper rounding behavior for float and double, > as well as significant performance increases. I think Joseph fixed the rounding behavior for 4.5. Also without an adjusted ABI you'd introduce x87 <-> SSE register moves which are not helpful for performance. The present discussion is about defaulting to at least 486 when not configured for i386-linux. That sounds entirely reasonable to me. Richard. > -Geert > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 12:13 ` Richard Guenther @ 2010-02-21 12:33 ` Paolo Carlini 2010-02-21 14:58 ` Joseph S. Myers ` (2 subsequent siblings) 3 siblings, 0 replies; 75+ messages in thread From: Paolo Carlini @ 2010-02-21 12:33 UTC (permalink / raw) To: Richard Guenther; +Cc: Geert Bosch, Steven Bosscher, Joe Buck, tprince, gcc On 02/21/2010 01:13 PM, Richard Guenther wrote: > The present discussion is about defaulting to at least 486 when not > configured for i386-linux. That sounds entirely reasonable to me. > Again for the record, I like this too, if we can't do what Joseph suggests. Paolo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 12:13 ` Richard Guenther 2010-02-21 12:33 ` Paolo Carlini @ 2010-02-21 14:58 ` Joseph S. Myers 2010-02-21 17:15 ` Geert Bosch 2010-02-21 17:22 ` H.J. Lu 2010-02-22 1:41 ` Geert Bosch 2010-02-22 10:27 ` Andrew Haley 3 siblings, 2 replies; 75+ messages in thread From: Joseph S. Myers @ 2010-02-21 14:58 UTC (permalink / raw) To: Richard Guenther; +Cc: Geert Bosch, Steven Bosscher, Joe Buck, tprince, gcc On Sun, 21 Feb 2010, Richard Guenther wrote: > > The biggest change we need to make for x86 is to enable SSE2, > > so we can get proper rounding behavior for float and double, > > as well as significant performance increases. > > I think Joseph fixed the rounding behavior for 4.5. Also without an adjusted Well, I provided the option for rounding that is predictable and in accordance with C99 when using the default -mfpmath=387. But that option does carry the performance cost of storing to / loading from memory at various points, as required to get the rounding on 387 (and there are still cases where excess precision means double rounding). > ABI you'd introduce x87 <-> SSE register moves which are not helpful > for performance. As I understand it, whether -mfpmath=387 (with excess precision) or -mfpmath=sse is the default is also considered part of the platform API (like whether char is signed or unsigned by default, for example), in addition to the ABI issues that can slow things down when SSE is used. If people really want a new 32-bit x86 ABI I'd suggest making it an ILP32 ABI for processors running in 64-bit mode, so 64-bit registers are available without the additional memory cost of 64-bit pointers for code not needing them - you could also assume a minimum of -march=x86-64, which implies SSE2. But if there were significant demand for such an ABI I think we'd have seen it by now, and you probably run into the various syscall interface problems that MIPS n32 has had. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 14:58 ` Joseph S. Myers @ 2010-02-21 17:15 ` Geert Bosch 2010-02-21 17:27 ` H.J. Lu ` (2 more replies) 2010-02-21 17:22 ` H.J. Lu 1 sibling, 3 replies; 75+ messages in thread From: Geert Bosch @ 2010-02-21 17:15 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Richard Guenther, Steven Bosscher, Joe Buck, tprince, gcc On Feb 21, 2010, at 09:58, Joseph S. Myers wrote: > On Sun, 21 Feb 2010, Richard Guenther wrote: >>> The biggest change we need to make for x86 is to enable SSE2, >>> so we can get proper rounding behavior for float and double, >>> as well as significant performance increases. >> >> I think Joseph fixed the rounding behavior for 4.5. Also without an adjusted > > Well, I provided the option for rounding that is predictable and in > accordance with C99 when using the default -mfpmath=387. But that option > does carry the performance cost of storing to / loading from memory at > various points, as required to get the rounding on 387 (and there are > still cases where excess precision means double rounding). This clearly is worse in all areas than using SSE2: there STILL is double rounding, and performance goes down the drain. On any recent machine there is the SSE2 hardware to do the operations correctly without going through memory and without double rounding. >> ABI you'd introduce x87 <-> SSE register moves which are not helpful >> for performance. > > As I understand it, whether -mfpmath=387 (with excess precision) or > -mfpmath=sse is the default is also considered part of the platform API > (like whether char is signed or unsigned by default, for example), in > addition to the ABI issues that can slow things down when SSE is used. No, this is not a new ABI. The ABI stays exactly the same. The I of ABI stands for Interface. That is, the ABI has nothing to say about how a function will compute any results. That is the area of language standards. The only way we'd violate the ABI is the reliance on SSE2 instructions being available and SSE2 registers being saved by the OS. However, since any other compiler uses SSE2 instructions by default, I don't see why GCC should be any different. If anything, since the GCC target audience is more focused on Free and open source software, we could be more aggressive in taking advantage of newer hardware. What about an autoconf test for availability of 486 atomic instructions, and SSE2 instructions in order, and choosing the default target based on the host? Not too crazy, is it? > If people really want a new 32-bit x86 ABI I'd suggest making it an ILP32 > ABI for processors running in 64-bit mode, so 64-bit registers are > available without the additional memory cost of 64-bit pointers for code > not needing them - you could also assume a minimum of -march=x86-64, which > implies SSE2. But if there were significant demand for such an ABI I > think we'd have seen it by now, and you probably run into the various > syscall interface problems that MIPS n32 has had. Let's keep that can of worms closed, has nothing to do with changing our -march defaults. -Geert PS. If anyone has SPEC-like figures for performance difference between -msse2 -mfpmath=sse,x87 and default, I'd be interested in seeing those results. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 17:15 ` Geert Bosch @ 2010-02-21 17:27 ` H.J. Lu 2010-02-21 20:23 ` Erik Trulsson ` (2 more replies) 2010-02-21 17:34 ` Joseph S. Myers 2010-02-21 17:34 ` Richard Guenther 2 siblings, 3 replies; 75+ messages in thread From: H.J. Lu @ 2010-02-21 17:27 UTC (permalink / raw) To: Geert Bosch Cc: Joseph S. Myers, Richard Guenther, Steven Bosscher, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 9:15 AM, Geert Bosch <bosch@adacore.com> wrote: >> As I understand it, whether -mfpmath=387 (with excess precision) or >> -mfpmath=sse is the default is also considered part of the platform API >> (like whether char is signed or unsigned by default, for example), in >> addition to the ABI issues that can slow things down when SSE is used. > > No, this is not a new ABI. The ABI stays exactly the same. The I of > ABI stands for Interface. That is, the ABI has nothing to say about > how a function will compute any results. That is the area of language > standards. The only way we'd violate the ABI is the reliance on SSE2 > instructions being available and SSE2 registers being saved by the OS. > > However, since any other compiler uses SSE2 instructions by default, > I don't see why GCC should be any different. If anything, since the > GCC target audience is more focused on Free and open source software, > we could be more aggressive in taking advantage of newer hardware. > What about an autoconf test for availability of 486 atomic instructions, > and SSE2 instructions in order, and choosing the default target based > on the host? Not too crazy, is it? > I agreed that gcc for x86 should choose a sensible default for 95% of current x86 processors in use. People with those old processors can use older gcc or -march=. Default to SSE2 is a good first step. -- H.J. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 17:27 ` H.J. Lu @ 2010-02-21 20:23 ` Erik Trulsson 2010-02-21 20:27 ` H.J. Lu 2010-02-21 21:54 ` Steven Bosscher 2010-02-21 22:05 ` H.J. Lu 2010-02-23 9:25 ` Piotr Wyderski 2 siblings, 2 replies; 75+ messages in thread From: Erik Trulsson @ 2010-02-21 20:23 UTC (permalink / raw) To: H.J. Lu Cc: Geert Bosch, Joseph S. Myers, Richard Guenther, Steven Bosscher, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 09:27:13AM -0800, H.J. Lu wrote: > On Sun, Feb 21, 2010 at 9:15 AM, Geert Bosch <bosch@adacore.com> wrote: > > >> As I understand it, whether -mfpmath=387 (with excess precision) or > >> -mfpmath=sse is the default is also considered part of the platform API > >> (like whether char is signed or unsigned by default, for example), in > >> addition to the ABI issues that can slow things down when SSE is used. > > > > No, this is not a new ABI. The ABI stays exactly the same. The I of > > ABI stands for Interface. That is, the ABI has nothing to say about > > how a function will compute any results. That is the area of language > > standards. The only way we'd violate the ABI is the reliance on SSE2 > > instructions being available and SSE2 registers being saved by the OS. > > > > However, since any other compiler uses SSE2 instructions by default, > > I don't see why GCC should be any different. If anything, since the > > GCC target audience is more focused on Free and open source software, > > we could be more aggressive in taking advantage of newer hardware. One of the great advantages of much free/open software is the way it will work just fine even on older hardware. > > What about an autoconf test for availability of 486 atomic instructions, > > and SSE2 instructions in order, and choosing the default target based > > on the host? Not too crazy, is it? Actually that is too crazy. Assuming that the binaries produced by any given compiler installation will only be used on the machine the compiler runs on is not a safe assumption. > > > > I agreed that gcc for x86 should choose a sensible default for 95% of > current x86 processors in use. People with those old processors can > use older gcc or -march=. > > Default to SSE2 is a good first step. I think you vastly underestimate the number of older x86 processors in use. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 20:23 ` Erik Trulsson @ 2010-02-21 20:27 ` H.J. Lu 2010-02-21 21:14 ` Erik Trulsson 2010-02-21 21:54 ` Steven Bosscher 1 sibling, 1 reply; 75+ messages in thread From: H.J. Lu @ 2010-02-21 20:27 UTC (permalink / raw) To: Erik Trulsson Cc: Geert Bosch, Joseph S. Myers, Richard Guenther, Steven Bosscher, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 12:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote: >> >> I agreed that gcc for x86 should choose a sensible default for 95% of >> current x86 processors in use. People with those old processors can >> use older gcc or -march=. >> >> Default to SSE2 is a good first step. > > I think you vastly underestimate the number of older x86 processors in > use. > There is nothing which stops them from using -march=i386. It just may not be the default. -- H.J. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 20:27 ` H.J. Lu @ 2010-02-21 21:14 ` Erik Trulsson 2010-02-21 21:54 ` H.J. Lu 2010-02-21 21:59 ` Steven Bosscher 0 siblings, 2 replies; 75+ messages in thread From: Erik Trulsson @ 2010-02-21 21:14 UTC (permalink / raw) To: H.J. Lu Cc: Geert Bosch, Joseph S. Myers, Richard Guenther, Steven Bosscher, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 12:27:34PM -0800, H.J. Lu wrote: > On Sun, Feb 21, 2010 at 12:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote: > >> > >> I agreed that gcc for x86 should choose a sensible default for 95% of > >> current x86 processors in use. People with those old processors can > >> use older gcc or -march=. > >> > >> Default to SSE2 is a good first step. > > > > I think you vastly underestimate the number of older x86 processors in > > use. > > > > There is nothing which stops them from using -march=i386. It just may not > be the default. That argument cuts both ways you know. There is nothing stopping people with the latest CPUs from using -march= to get code optimised for their hardware. It just may not be the default. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 21:14 ` Erik Trulsson @ 2010-02-21 21:54 ` H.J. Lu 2010-02-21 21:59 ` Steven Bosscher 1 sibling, 0 replies; 75+ messages in thread From: H.J. Lu @ 2010-02-21 21:54 UTC (permalink / raw) To: Erik Trulsson Cc: Geert Bosch, Joseph S. Myers, Richard Guenther, Steven Bosscher, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 1:07 PM, Erik Trulsson <ertr1013@student.uu.se> wrote: > On Sun, Feb 21, 2010 at 12:27:34PM -0800, H.J. Lu wrote: >> On Sun, Feb 21, 2010 at 12:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote: >> >> >> >> I agreed that gcc for x86 should choose a sensible default for 95% of >> >> current x86 processors in use. People with those old processors can >> >> use older gcc or -march=. >> >> >> >> Default to SSE2 is a good first step. >> > >> > I think you vastly underestimate the number of older x86 processors in >> > use. >> > >> >> There is nothing which stops them from using -march=i386. It just may not >> be the default. > > That argument cuts both ways you know. There is nothing stopping > people with the latest CPUs from using -march= to get code optimised > for their hardware. It just may not be the default. That is where majority comes in. -- H.J. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 21:14 ` Erik Trulsson 2010-02-21 21:54 ` H.J. Lu @ 2010-02-21 21:59 ` Steven Bosscher 2010-02-21 23:10 ` Erik Trulsson 1 sibling, 1 reply; 75+ messages in thread From: Steven Bosscher @ 2010-02-21 21:59 UTC (permalink / raw) To: Erik Trulsson Cc: H.J. Lu, Geert Bosch, Joseph S. Myers, Richard Guenther, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 10:07 PM, Erik Trulsson <ertr1013@student.uu.se> wrote: >> There is nothing which stops them from using -march=i386. It just may not >> be the default. > > That argument cuts both ways you know. There is nothing stopping > people with the latest CPUs from using -march= to get code optimised > for their hardware. It just may not be the default. Which brings us back to the discussion of satisfying the needs of a tiny minority while hurting the vast majority of users. I prefer to satisfy the need of the majority. Ciao! Steven ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 21:59 ` Steven Bosscher @ 2010-02-21 23:10 ` Erik Trulsson 2010-02-22 2:09 ` Vincent Lefevre 2010-02-27 17:27 ` Gerald Pfeifer 0 siblings, 2 replies; 75+ messages in thread From: Erik Trulsson @ 2010-02-21 23:10 UTC (permalink / raw) To: Steven Bosscher Cc: H.J. Lu, Geert Bosch, Joseph S. Myers, Richard Guenther, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 10:59:05PM +0100, Steven Bosscher wrote: > On Sun, Feb 21, 2010 at 10:07 PM, Erik Trulsson <ertr1013@student.uu.se> wrote: > >> There is nothing which stops them from using -march=i386. It just may not > >> be the default. > > > > That argument cuts both ways you know. There is nothing stopping > > people with the latest CPUs from using -march= to get code optimised > > for their hardware. It just may not be the default. > > Which brings us back to the discussion of satisfying the needs of a > tiny minority while hurting the vast majority of users. I prefer to > satisfy the need of the majority. That would depend on how large the majority is compared to the minority and how much they will be hurt in the respective cases. As for the relative sizes of the groups, the above comments were in context of using SSE2 by default. I do not believe that the vast majority of x86 CPUs currently in use do support SSE2. A majority of them, possibly, but not a vast majority. As for the relative hurts. Code compiled for a newer CPU (making use of newer instructions) will not run at all on older CPUs not supporting those newer instructions. Much hurt there. On the other hand code compiled for an older CPU that is run a newer CPU will run just fine, if slightly slower than they could have due to not making use of new instructions in the newer CPU. For most programs the performance increase of re-compiling for the newer CPU would be barely noticable so the hurt of not having that is very little. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 23:10 ` Erik Trulsson @ 2010-02-22 2:09 ` Vincent Lefevre 2010-02-27 17:27 ` Gerald Pfeifer 1 sibling, 0 replies; 75+ messages in thread From: Vincent Lefevre @ 2010-02-22 2:09 UTC (permalink / raw) To: gcc On 2010-02-22 00:02:39 +0100, Erik Trulsson wrote: > On the other hand code compiled for an older CPU that is run a newer > CPU will run just fine, if slightly slower than they could have due to > not making use of new instructions in the newer CPU. It will run, but may give unexpected or even incorrect flaoting-point results. See the number of duplicates (some of them can involve double rounding) in: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 23:10 ` Erik Trulsson 2010-02-22 2:09 ` Vincent Lefevre @ 2010-02-27 17:27 ` Gerald Pfeifer 1 sibling, 0 replies; 75+ messages in thread From: Gerald Pfeifer @ 2010-02-27 17:27 UTC (permalink / raw) To: Erik Trulsson Cc: Steven Bosscher, H.J. Lu, Geert Bosch, Joseph S. Myers, Richard Guenther, Joe Buck, tprince, gcc On Mon, 22 Feb 2010, Erik Trulsson wrote: > As for the relative hurts. Code compiled for a newer CPU (making use > of newer instructions) will not run at all on older CPUs not supporting > those newer instructions. Much hurt there. > > On the other hand code compiled for an older CPU that is run a newer > CPU will run just fine, if slightly slower than they could have due > to not making use of new instructions in the newer CPU. That can well be seen as a point for _making_ the change: when it fails, the user/admin knows there is a need to adjust, whereas silent degradation will continue to make look GCC bad and hurt its traction and adoption (as Steven and others have experienced). Gerald ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 20:23 ` Erik Trulsson 2010-02-21 20:27 ` H.J. Lu @ 2010-02-21 21:54 ` Steven Bosscher 2010-02-21 22:19 ` Dave Korn 2010-02-21 22:50 ` Erik Trulsson 1 sibling, 2 replies; 75+ messages in thread From: Steven Bosscher @ 2010-02-21 21:54 UTC (permalink / raw) To: Erik Trulsson Cc: H.J. Lu, Geert Bosch, Joseph S. Myers, Richard Guenther, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote: > One of the great advantages of much free/open software is the way it > will work just fine even on older hardware. Yes, but that doesn't change if the compiler changes the default target processor. And, let's face it, most users of gcc don't use it because it is free software but because it performs just fine for them. And when it does not, they just as easily switch to another compiler. To be competitive with alternatives, is why, IMHO, gcc should target newer processors. Because "the other guys" are doing it also, and it hurts the gcc user base if gcc chooses to lag behind. > I think you vastly underestimate the number of older x86 processors in > use. Yes, of course -- but what is the advantage of using the latest GCC for such an older processor? This is something no-one has ever been able to explain to me (I've asked before). I can give some disadvantages, though. The newer compilers usually add nothing much more than support for the newer processors and their new instruction sets, and newer compilers tend to be tuned for newer processors too (simply because the developers work with newer boxes). An older compiler will be no worse than a newer compiler for those older processors -- probably sometimes even better. Ciao! Steven ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 21:54 ` Steven Bosscher @ 2010-02-21 22:19 ` Dave Korn 2010-02-21 23:28 ` Martin Guy 2010-02-21 22:50 ` Erik Trulsson 1 sibling, 1 reply; 75+ messages in thread From: Dave Korn @ 2010-02-21 22:19 UTC (permalink / raw) To: Steven Bosscher Cc: Erik Trulsson, H.J. Lu, Geert Bosch, Joseph S. Myers, Richard Guenther, Joe Buck, tprince, gcc On 21/02/2010 21:53, Steven Bosscher wrote: > Yes, of course -- but what is the advantage of using the latest GCC > for such an older processor? Tree-SSA? LTO? Fixed bugs? New languages? Etc? I can see plenty of good reasons for it. > The newer compilers usually add nothing much more than support for the > newer processors and their new instruction sets, That doesn't sound like any GCC that I'm familiar with! cheers, DaveK ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 22:19 ` Dave Korn @ 2010-02-21 23:28 ` Martin Guy 2010-02-22 0:06 ` Steven Bosscher 0 siblings, 1 reply; 75+ messages in thread From: Martin Guy @ 2010-02-21 23:28 UTC (permalink / raw) To: Dave Korn Cc: Steven Bosscher, Erik Trulsson, H.J. Lu, Geert Bosch, Joseph S. Myers, Richard Guenther, Joe Buck, tprince, gcc On 2/21/10, Dave Korn <dave.korn.cygwin@googlemail.com> wrote: > On 21/02/2010 20:03, Martin Guy wrote: > > The point about defaults is that the GCC default tends to filter down > > into the default for distributions; > I'd find it surprising if that was really the way it happens; don't > distributions make deliberate and conscious decisions about binary standards > and things like that? Changing the default without losing that compatability would assume that every distro (and there are hundreds of them) either already specifies a specific arch or that its GCC maintainer notices the change in GCC and adds explicit configuration options to revert the change. The big ones with dedicated maintainers for GCC probably already do that; others just configure and make the standard distro and take what comes. On 2/21/10, H.J. Lu <hjl.tools@gmail.com> wrote: > There is nothing which stops them from using -march=i386. It just may not > be the default. There is: the arch that the libraries in their distro were compiled to run on. On 2/21/10, Steven Bosscher <stevenb.gcc@gmail.com> wrote: > On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote: > > One of the great advantages of much free/open software is the way it > > will work just fine even on older hardware. > And, let's face it, most users of gcc don't use it because it is free > software but because it performs just fine for them. And when it does > not, they just as easily switch to another compiler. Hardly. At present there is a GCC monoculture, both in what is the standard compiler with most systems and in what compiler packages will build with, either because the build system uses GCC-specific flags or because the code using GCC extensions. On 2/21/10, Steven Bosscher <stevenb.gcc@gmail.com> wrote: > Which brings us back to the discussion of satisfying the needs of a > tiny minority while hurting the vast majority of users. There's a difference in quality between the two. The "hurt" is that powerful modern PCs might take 20% longer to encode a DVD, while the "needs" is that the bulk of software will run at all on their poor hardware. It's usual in modern societies to give priority to enabling the underprivileged to function at all over giving the well-off the maximum of comfort and speed, but how you value the two aspects probably depends on your personal experience of the two realities. On 2/21/10, Dave Korn <dave.korn.cygwin@googlemail.com> wrote: > On 21/02/2010 21:53, Steven Bosscher wrote: > > Yes, of course -- but what is the advantage of using the latest GCC > > for such an older processor? > Tree-SSA? LTO? Fixed bugs? New languages? Etc? I can see plenty of good > reasons for it. Apart from those factors (and one hopes that in general all code generation improves from release to release), users may not really have a choice, being most likely to try (or be given) the most recent stable version of whatever distro, and distros tend to try to ship the most recent stable gcc in each new release. Let me add another example from my own experience: In 2001 I was stuck for months in a crumbling house in the countryside with nothing but an 8MB 25MHz 386 because that's all l I had available at the time (green screen, yay!) and I completed what would have been my postgraduate degree project, begun in 1985: an unlimited precision floating point math library in a pure functional language. The fact that I could do that at all may be due to GCC's "work on the minimum" policy of the time, both in the distro and on whatever machine David Turner used to compile the binary-only release of the Miranda interpreter. If I recall correctly, the default is currently arched and tuned for 486, and the 386's lacks are trapped and emulated in the kernel. On 2/21/10, Steven Bosscher <stevenb.gcc@gmail.com> wrote: > Well, as Martin already pointed out (contradicting his own point): > Apparently a lot of distributions *do* change the defaults. That's OK, I don't have The Truth in my pocket. Nor do I have any quantifiable measure of the number of different systems in use in the whole world, just a value judgement based on a different set of experiences of the outcome of restrictive and generous policies in munimum CPU targetting, which I'm sharing. My direct experience is that low-end PCs are widely used in societies where things are hard, and that upstream software developers are always given the latest, fastest computers to make them more productive and are unaware of the struggling masses :) Cheers M ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 23:28 ` Martin Guy @ 2010-02-22 0:06 ` Steven Bosscher 0 siblings, 0 replies; 75+ messages in thread From: Steven Bosscher @ 2010-02-22 0:06 UTC (permalink / raw) To: Martin Guy Cc: Dave Korn, Erik Trulsson, H.J. Lu, Geert Bosch, Joseph S. Myers, Richard Guenther, Joe Buck, tprince, gcc On Mon, Feb 22, 2010 at 12:28 AM, Martin Guy <martinwguy@gmail.com> wrote: > On 2/21/10, Steven Bosscher <stevenb.gcc@gmail.com> wrote: >> On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote: >> > One of the great advantages of much free/open software is the way it >> > will work just fine even on older hardware. >> And, let's face it, most users of gcc don't use it because it is free >> software but because it performs just fine for them. And when it does >> not, they just as easily switch to another compiler. > Hardly. At present there is a GCC monoculture, both in what is the > standard compiler with most systems and in what compiler packages will > build with, either because the build system uses GCC-specific flags or > because the code using GCC extensions. This is certainly true on most linux machines. But on non-linux machines GCC is usually just another option. And at least on ix86-linux and x86_64 linux, it is very easy to install other compilers. Most people I know who do software development, have at least gcc and icc installed, and sometimes llvm and some proprietary compilers (Absoft, Pathscale, etc.). This is probably because... > (...) The "hurt" is that > powerful modern PCs might take 20% longer to encode a DVD, while the > "needs" is that the bulk of software will run at all on their poor > hardware. ...this 20% costs a lot of money (time, energy (!), other resources) if you do high-end computing. And in many cases, it is a lot more than 20%. The structural analysis code I worked with, runs about 2.5 times faster if SSE2 and vectorization are enabled. Since this is an interactive application, it saves money by keeping busy the otherwise idly waiting engineers. The developers of this code were not aware of the options you have to pass to GCC to get this win. Arguably that's their problem, but I don't think so. They just chose the way of least resistance: compare gcc and icc and take the fastest. The hurt is on gcc, because it loses users. For home machines: You should realize that if that DVD encodes 20% faster, or that movie plays without flickering, or ... on Windows 7, people switch. It is what users do: they find the machine+OS that works best for them. I honestly believe it works like that. I see it all around me, and I even still have a dual-boot installation because of this. If a change in the defaults of GCC helps proliferate free software better (an FSF political goal, which are relevant, unlike political views you've mentioned) then this change should be seriously considered. >> > Yes, of course -- but what is the advantage of using the latest GCC >> > for such an older processor? >> Tree-SSA? LTO? Fixed bugs? New languages? Etc? I can see plenty of good >> reasons for it. > Apart from those factors (and one hopes that in general all code > generation improves from release to release), users may not really > have a choice, being most likely to try (or be given) the most recent > stable version of whatever distro, and distros tend to try to ship the > most recent stable gcc in each new release. If these users try to run the latest distro/GCC on such older hardware, it probably doesn't even work. Tree-SSA has increased the resources required by GCC significantly. LTO will almost certainly not work for any meaningful application on older hardware. The only new languages in recent years in GCC are ObjC++, which nobody uses, and Fortran 95, which nobody uses on old hardware (except perhaps for educational purposes, but if you use Fortran then you probably have access to better hardware than a 20 year old desktop). Ciao! Steven ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 21:54 ` Steven Bosscher 2010-02-21 22:19 ` Dave Korn @ 2010-02-21 22:50 ` Erik Trulsson 2010-02-21 23:17 ` Dave Korn 2010-02-22 1:21 ` Geert Bosch 1 sibling, 2 replies; 75+ messages in thread From: Erik Trulsson @ 2010-02-21 22:50 UTC (permalink / raw) To: Steven Bosscher Cc: H.J. Lu, Geert Bosch, Joseph S. Myers, Richard Guenther, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 10:53:54PM +0100, Steven Bosscher wrote: > On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote: > > One of the great advantages of much free/open software is the way it > > will work just fine even on older hardware. > > Yes, but that doesn't change if the compiler changes the default > target processor. Yes, it does if the user is using binaries compiled by somebody else, and that somebody else did not explicitly specify any CPU-flags. I believe that is the situation when installing most Linux-distributions for example. > > And, let's face it, most users of gcc don't use it because it is free > software but because it performs just fine for them. And when it does > not, they just as easily switch to another compiler. No, most users of gcc use it beacause it is the default compiler that came with the system they are using. Switching to another compiler is not always as easy as it might be. > > To be competitive with alternatives, is why, IMHO, gcc should target > newer processors. Because "the other guys" are doing it also, and it > hurts the gcc user base if gcc chooses to lag behind. Considering that most code will not run noticably faster just because you optimize it for the newest CPU, the majority of the user base are not hurt at all. > > > I think you vastly underestimate the number of older x86 processors in > > use. > > Yes, of course -- but what is the advantage of using the latest GCC > for such an older processor? This is something no-one has ever been > able to explain to me (I've asked before). I can give some > disadvantages, though. > > The newer compilers usually add nothing much more than support for the > newer processors and their new instruction sets, and newer compilers > tend to be tuned for newer processors too (simply because the > developers work with newer boxes). An older compiler will be no worse > than a newer compiler for those older processors -- probably sometimes > even better. Newer compilers usually have better generic optimizations that are not CPU-dependent. Newer compilers also typically have improved support for new language-features (and new languages for that matter.) Newer compilers are often better at warning about dubious (or simply wrong) code making it easier to find bugs in the code. Plenty of reasons for using a newer compiler regardless of if your target-CPU is new or old. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 22:50 ` Erik Trulsson @ 2010-02-21 23:17 ` Dave Korn 2010-02-22 0:29 ` Erik Trulsson 2010-02-22 1:21 ` Geert Bosch 1 sibling, 1 reply; 75+ messages in thread From: Dave Korn @ 2010-02-21 23:17 UTC (permalink / raw) To: Erik Trulsson Cc: Steven Bosscher, H.J. Lu, Geert Bosch, Joseph S. Myers, Richard Guenther, Joe Buck, tprince, gcc On 21/02/2010 22:42, Erik Trulsson wrote: > Yes, it does if the user is using binaries compiled by somebody else, > and that somebody else did not explicitly specify any CPU-flags. > > I believe that is the situation when installing most > Linux-distributions for example. No, surely not. The linux distributions use configure options when they package their compilers to choose the default with-cpu and with-arch options, and those are quite deliberately chosen according to the binary standards of the distro. It is hardly a case of "somebody else did not explicitly specify" cpu flags; they in fact explicitly specified them according to the system requirements for the distro. If your distro says it doesn't support i386, this is *why*! > Considering that most code will not run noticably faster just because > you optimize it for the newest CPU, Considering nobody is suggesting that, it is an irrelevant red herring. We're talking about optimising for "any CPU built in the past five years" vs. "any cpu built in the past twentyfive years"; not switching on some option that will break code on any but the very latest models. You're also wrong about how much difference switching on SSE makes to real applications. Any application that isn't I/O bound but does a lot of in-memory processing will run noticeably better, anything that uses loops or stdlib string or memory copy/move functions, this is not some tiny minor tweak we're looking at. cheers, DaveK ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 23:17 ` Dave Korn @ 2010-02-22 0:29 ` Erik Trulsson 2010-02-22 11:04 ` Andrew Haley 0 siblings, 1 reply; 75+ messages in thread From: Erik Trulsson @ 2010-02-22 0:29 UTC (permalink / raw) To: Dave Korn Cc: Steven Bosscher, H.J. Lu, Geert Bosch, Joseph S. Myers, Richard Guenther, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 11:35:11PM +0000, Dave Korn wrote: > On 21/02/2010 22:42, Erik Trulsson wrote: > > > Yes, it does if the user is using binaries compiled by somebody else, > > and that somebody else did not explicitly specify any CPU-flags. > > > > I believe that is the situation when installing most > > Linux-distributions for example. > > No, surely not. The linux distributions use configure options when they > package their compilers to choose the default with-cpu and with-arch options, > and those are quite deliberately chosen according to the binary standards of > the distro. It is hardly a case of "somebody else did not explicitly specify" > cpu flags; they in fact explicitly specified them according to the system > requirements for the distro. If your distro says it doesn't support i386, > this is *why*! Are you sure of that? Really sure? Some Linux distributions almost certainly do as you describe, but all of them? I doubt it. > > > Considering that most code will not run noticably faster just because > > you optimize it for the newest CPU, > > Considering nobody is suggesting that, it is an irrelevant red herring. > We're talking about optimising for "any CPU built in the past five years" vs. > "any cpu built in the past twentyfive years"; not switching on some option > that will break code on any but the very latest models. There certainly have been x86 CPUs built in the past five years that do not support SSE, let alone SSE2. Besides, five years is not a very long time at all. Not in this context anyway. > > You're also wrong about how much difference switching on SSE makes to real > applications. Any application that isn't I/O bound but does a lot of > in-memory processing will run noticeably better, anything that uses loops or > stdlib string or memory copy/move functions, this is not some tiny minor tweak > we're looking at. I remain sceptical. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-22 0:29 ` Erik Trulsson @ 2010-02-22 11:04 ` Andrew Haley 2010-02-22 17:09 ` Dave Korn 0 siblings, 1 reply; 75+ messages in thread From: Andrew Haley @ 2010-02-22 11:04 UTC (permalink / raw) To: gcc On 02/22/2010 12:29 AM, Erik Trulsson wrote: > On Sun, Feb 21, 2010 at 11:35:11PM +0000, Dave Korn wrote: >> On 21/02/2010 22:42, Erik Trulsson wrote: >> >>> Yes, it does if the user is using binaries compiled by somebody else, >>> and that somebody else did not explicitly specify any CPU-flags. >>> >>> I believe that is the situation when installing most >>> Linux-distributions for example. >> >> No, surely not. The linux distributions use configure options >> when they package their compilers to choose the default with-cpu >> and with-arch options, and those are quite deliberately chosen >> according to the binary standards of the distro. It is hardly a >> case of "somebody else did not explicitly specify" cpu flags; they >> in fact explicitly specified them according to the system >> requirements for the distro. If your distro says it doesn't >> support i386, this is *why*! > > Are you sure of that? Really sure? > Some Linux distributions almost certainly do as you describe, but all > of them? I doubt it. And I doubt otherwise. Linux distros put a great deal of thought into which machines they are targeting with their binary distributions. And the existence of one tiny distro somewhere that doesn't would not change that fact. Andrew. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-22 11:04 ` Andrew Haley @ 2010-02-22 17:09 ` Dave Korn 0 siblings, 0 replies; 75+ messages in thread From: Dave Korn @ 2010-02-22 17:09 UTC (permalink / raw) To: gcc On 22/02/2010 11:04, Andrew Haley wrote: > On 02/22/2010 12:29 AM, Erik Trulsson wrote: >> On Sun, Feb 21, 2010 at 11:35:11PM +0000, Dave Korn wrote: >>> On 21/02/2010 22:42, Erik Trulsson wrote: >>> >>>> Yes, it does if the user is using binaries compiled by somebody else, >>>> and that somebody else did not explicitly specify any CPU-flags. >>>> >>>> I believe that is the situation when installing most >>>> Linux-distributions for example. >>> No, surely not. The linux distributions use configure options >>> when they package their compilers to choose the default with-cpu >>> and with-arch options, and those are quite deliberately chosen >>> according to the binary standards of the distro. It is hardly a >>> case of "somebody else did not explicitly specify" cpu flags; they >>> in fact explicitly specified them according to the system >>> requirements for the distro. If your distro says it doesn't >>> support i386, this is *why*! >> Are you sure of that? Really sure? >> Some Linux distributions almost certainly do as you describe, but all >> of them? I doubt it. > > And I doubt otherwise. Linux distros put a great deal of thought into > which machines they are targeting with their binary distributions. > And the existence of one tiny distro somewhere that doesn't would not > change that fact. Actually, there are probably dozens or hundreds of tiny distros out there that are basically somebody's home-made repackaging-and-minor-variant of existing bundles. However, I think that these are the same distros that constitute the 90% referred to in Sturgeon's Law, and so I would still not see that as any reason to change GCC's defaults! cheers, DaveK ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 22:50 ` Erik Trulsson 2010-02-21 23:17 ` Dave Korn @ 2010-02-22 1:21 ` Geert Bosch 2010-02-22 1:57 ` Joseph S. Myers 1 sibling, 1 reply; 75+ messages in thread From: Geert Bosch @ 2010-02-22 1:21 UTC (permalink / raw) To: Erik Trulsson Cc: Steven Bosscher, H.J. Lu, Joseph S. Myers, Richard Guenther, Joe Buck, tprince, gcc On Feb 21, 2010, at 17:42, Erik Trulsson wrote: > Newer compilers usually have better generic optimizations that are not > CPU-dependent. Newer compilers also typically have improved support > for new language-features (and new languages for that matter.) This is exactly where CPU dependence comes into play. I'd like for example take advantage of IEEE floating point semantics in our Ada compiler. Fifteen years ago, we had to face the fact that some systems were not compliant and therefore we developed least-common-denominator libraries that catered to all. However, nowadays even OpenVMS supports IEEE floating point. I'd like to get rid of hacks in GNAT avoid relying on strict IEEE compliance. Currently we end up doing some conversions and computations in the widest floating-point type to avoid double rounding. So, I'd like to be able to put all this behind me, and only have to think about fully IEEE compliant systems. Similarly, there is no way to fully implement C99 Annex F without using SSE2. As a last point, because not many GCC users take advantage of the hardware their systems have, there is less focus and feedback on improving SSE2 code generation, vectorization and the like. In conclusion, I think GCC is being held back by us sticking to 20-year old hardware. For GCC to be the best compiler possible on current and future systems, we have to start compiling for those systems by default. This is essential for GCC's long term relevance. -Geert ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-22 1:21 ` Geert Bosch @ 2010-02-22 1:57 ` Joseph S. Myers 2010-02-22 2:25 ` Vincent Lefevre 2010-02-22 2:33 ` Geert Bosch 0 siblings, 2 replies; 75+ messages in thread From: Joseph S. Myers @ 2010-02-22 1:57 UTC (permalink / raw) To: Geert Bosch Cc: Erik Trulsson, Steven Bosscher, H.J. Lu, Richard Guenther, Joe Buck, tprince, gcc On Sun, 21 Feb 2010, Geert Bosch wrote: > On Feb 21, 2010, at 17:42, Erik Trulsson wrote: > > Newer compilers usually have better generic optimizations that are not > > CPU-dependent. Newer compilers also typically have improved support > > for new language-features (and new languages for that matter.) > > This is exactly where CPU dependence comes into play. I'd like > for example take advantage of IEEE floating point semantics in > our Ada compiler. Fifteen years ago, we had to face the fact that It's up to the Ada maintainers what is or is not considered floating-point behavior expected to be stable between versions, and so whether making Ada use -mfpmath=sse when SSE2 is available would be appropriate. > So, I'd like to be able to put all this behind me, and only > have to think about fully IEEE compliant systems. Similarly, > there is no way to fully implement C99 Annex F without using > SSE2. I know some people have claimed (e.g. glibc bug 6981) that you can't conform to Annex F when you have excess precision, but this does not appear to be the view of WG14. A proper implementation of Annex F is also likely to result in generating slower floating-point code if we keep the present default of -ftrapping-math being on by default (I think it would end up inhibiting optimizations as much as -frounding-math to ensure exactly the right set of exceptions is raised). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-22 1:57 ` Joseph S. Myers @ 2010-02-22 2:25 ` Vincent Lefevre 2010-02-22 2:58 ` Joseph S. Myers 2010-02-22 2:33 ` Geert Bosch 1 sibling, 1 reply; 75+ messages in thread From: Vincent Lefevre @ 2010-02-22 2:25 UTC (permalink / raw) To: gcc On 2010-02-22 01:57:48 +0000, Joseph S. Myers wrote: > I know some people have claimed (e.g. glibc bug 6981) that you can't > conform to Annex F when you have excess precision, but this does not > appear to be the view of WG14. I wonder what their view is. Annex F says: The +, â, *, and / operators provide the IEC 60559 add, subtract, multiply, and divide operations. As IEC 60559 (= IEEE 754-1985) requires correct rounding to the target format, double rounding is forbidden. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-22 2:25 ` Vincent Lefevre @ 2010-02-22 2:58 ` Joseph S. Myers 2010-02-22 4:23 ` Vincent Lefevre 0 siblings, 1 reply; 75+ messages in thread From: Joseph S. Myers @ 2010-02-22 2:58 UTC (permalink / raw) To: Vincent Lefevre; +Cc: gcc On Mon, 22 Feb 2010, Vincent Lefevre wrote: > On 2010-02-22 01:57:48 +0000, Joseph S. Myers wrote: > > I know some people have claimed (e.g. glibc bug 6981) that you can't > > conform to Annex F when you have excess precision, but this does not > > appear to be the view of WG14. > > I wonder what their view is. Annex F says: For example, N1421 (Markham minutes) has a discussion that's clearly presuming that a conditional #if defined(__STDC_IEC_559__) && (FLT_EVAL_METHOD == 1) may hold. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-22 2:58 ` Joseph S. Myers @ 2010-02-22 4:23 ` Vincent Lefevre 2010-02-22 4:32 ` Vincent Lefevre 0 siblings, 1 reply; 75+ messages in thread From: Vincent Lefevre @ 2010-02-22 4:23 UTC (permalink / raw) To: gcc On 2010-02-22 02:58:19 +0000, Joseph S. Myers wrote: > For example, N1421 (Markham minutes) has a discussion that's clearly > presuming that a conditional > > #if defined(__STDC_IEC_559__) && (FLT_EVAL_METHOD == 1) > > may hold. Well, this is a bit unclear. I think this is OK, as long as rounding of a float operation is done to single precision (the exponent range may still be the one of the double format, in which case the value of FLT_EVAL_METHOD should be 1 as above). IEEE 754-1985 says: 4.3. Rounding Precision Normally, a result is rounded to the precision of its destination. However, some systems deliver results only to double or extended destinations. On such a system the user, which may be a high-level language compiler, shall be able to specify that a result be rounded instead to single precision, though it may be stored in the double or extended format with its wider exponent range. [...] -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-22 4:23 ` Vincent Lefevre @ 2010-02-22 4:32 ` Vincent Lefevre 0 siblings, 0 replies; 75+ messages in thread From: Vincent Lefevre @ 2010-02-22 4:32 UTC (permalink / raw) To: gcc On 2010-02-22 05:23:39 +0100, Vincent Lefevre wrote: > On 2010-02-22 02:58:19 +0000, Joseph S. Myers wrote: > > For example, N1421 (Markham minutes) has a discussion that's clearly > > presuming that a conditional > > > > #if defined(__STDC_IEC_559__) && (FLT_EVAL_METHOD == 1) > > > > may hold. > > Well, this is a bit unclear. I think this is OK, as long as rounding > of a float operation is done to single precision (the exponent range > may still be the one of the double format, in which case the value of > FLT_EVAL_METHOD should be 1 as above). IEEE 754-1985 says: [...] Hmm... This doesn't seem to be allowed by the C language, though, as C99 says for FLT_EVAL_METHOD == 1: evaluate operations and constants of type float and double to the range and precision of the double type, ^^^^^^^^^^^^^ So, this means that the precision of the double type should be single precision in this case, but this is not allowed. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-22 1:57 ` Joseph S. Myers 2010-02-22 2:25 ` Vincent Lefevre @ 2010-02-22 2:33 ` Geert Bosch 1 sibling, 0 replies; 75+ messages in thread From: Geert Bosch @ 2010-02-22 2:33 UTC (permalink / raw) To: Joseph S. Myers Cc: Erik Trulsson, Steven Bosscher, H.J. Lu, Richard Guenther, Joe Buck, tprince, gcc On Feb 21, 2010, at 20:57, Joseph S. Myers wrote: > I know some people have claimed (e.g. glibc bug 6981) that you can't > conform to Annex F when you have excess precision, but this does not > appear to be the view of WG14. That may be the case, but I really wonder how much sense it can make to declare things like: > The expressions x − y and −(y − x) are not equivalent because 1 − 1 is +0 but −(1 − 1) is −0 (in the default rounding direction) if you than have to wave hands and admit that either side might be off by an arbitrary amount due to presence or absence of double rounding, the whole statement becomes meaningless. In the end, what counts is thay users have complained for ages about unexpected floating-point results on x86. We have always argued that that was just the way things are on x86: sorry, hardware issue, can't fix. However, we have progressed 25 years, and through the wonders of SSE2 we now can have both extended precision when we need it and accurate, predictable single and double floating-point for the rest. If we get this issue out of the way, and make GCC by default have IEEE 754 compliant floating point on hardware supporting it, that would be a great step forward. -Geert ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 17:27 ` H.J. Lu 2010-02-21 20:23 ` Erik Trulsson @ 2010-02-21 22:05 ` H.J. Lu 2010-02-23 9:25 ` Piotr Wyderski 2 siblings, 0 replies; 75+ messages in thread From: H.J. Lu @ 2010-02-21 22:05 UTC (permalink / raw) To: Geert Bosch Cc: Joseph S. Myers, Richard Guenther, Steven Bosscher, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 9:27 AM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Sun, Feb 21, 2010 at 9:15 AM, Geert Bosch <bosch@adacore.com> wrote: > >>> As I understand it, whether -mfpmath=387 (with excess precision) or >>> -mfpmath=sse is the default is also considered part of the platform API >>> (like whether char is signed or unsigned by default, for example), in >>> addition to the ABI issues that can slow things down when SSE is used. >> >> No, this is not a new ABI. The ABI stays exactly the same. The I of >> ABI stands for Interface. That is, the ABI has nothing to say about >> how a function will compute any results. That is the area of language >> standards. The only way we'd violate the ABI is the reliance on SSE2 >> instructions being available and SSE2 registers being saved by the OS. >> >> However, since any other compiler uses SSE2 instructions by default, >> I don't see why GCC should be any different. If anything, since the >> GCC target audience is more focused on Free and open source software, >> we could be more aggressive in taking advantage of newer hardware. >> What about an autoconf test for availability of 486 atomic instructions, >> and SSE2 instructions in order, and choosing the default target based >> on the host? Not too crazy, is it? >> > > I agreed that gcc for x86 should choose a sensible default for 95% of > current x86 processors in use. People with those old processors can > use older gcc or -march=. > > Default to SSE2 is a good first step. > FWIW, here is a patch to add --with-math=sse for x86: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00714.html -- H.J. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 17:27 ` H.J. Lu 2010-02-21 20:23 ` Erik Trulsson 2010-02-21 22:05 ` H.J. Lu @ 2010-02-23 9:25 ` Piotr Wyderski 2 siblings, 0 replies; 75+ messages in thread From: Piotr Wyderski @ 2010-02-23 9:25 UTC (permalink / raw) To: H.J. Lu Cc: Geert Bosch, Joseph S. Myers, Richard Guenther, Steven Bosscher, Joe Buck, tprince, gcc H.J. Lu wrote: > Default to SSE2 is a good first step. I concur; all the programs I'm working on require SSE2 and are not supposed to be back-portable to SSE or fpu. Simply too many vital optimizations require that ISA. Best regards Piotr Wyderski ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 17:15 ` Geert Bosch 2010-02-21 17:27 ` H.J. Lu @ 2010-02-21 17:34 ` Joseph S. Myers 2010-02-21 17:36 ` Richard Guenther 2010-02-22 1:39 ` Geert Bosch 2010-02-21 17:34 ` Richard Guenther 2 siblings, 2 replies; 75+ messages in thread From: Joseph S. Myers @ 2010-02-21 17:34 UTC (permalink / raw) To: Geert Bosch; +Cc: Richard Guenther, Steven Bosscher, Joe Buck, tprince, gcc On Sun, 21 Feb 2010, Geert Bosch wrote: > > As I understand it, whether -mfpmath=387 (with excess precision) or > > -mfpmath=sse is the default is also considered part of the platform API > > (like whether char is signed or unsigned by default, for example), in > > addition to the ABI issues that can slow things down when SSE is used. > > No, this is not a new ABI. The ABI stays exactly the same. The I of Correct - I said API, not ABI. The API for C programs on x86 GNU/Linux involves FLT_EVAL_METHOD == 2, whereas that on x86 Darwin involves FLT_EVAL_METHOD == 0 and that on FreeBSD involves FLT_EVAL_METHOD == 2 but with FPU rounding precision set to 53 bits so only excess range, not precision, applies. You can support multiple APIs within one ABI - you can support both versions of -mfpmath just as you can support both signed and unsigned char, or both signed and unsigned bit-fields. It is not however appropriate for -march options (whether explicit, or configured defaults from the noncanonical target name or otherwise) to change either ABI or API. Configure options to configure with a different API would be fine, as would target names such as i686-pc-linux-gnussemath. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 17:34 ` Joseph S. Myers @ 2010-02-21 17:36 ` Richard Guenther 2010-02-21 17:48 ` Joseph S. Myers 2010-02-21 18:25 ` Martin Guy 2010-02-22 1:39 ` Geert Bosch 1 sibling, 2 replies; 75+ messages in thread From: Richard Guenther @ 2010-02-21 17:36 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Geert Bosch, Steven Bosscher, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 6:34 PM, Joseph S. Myers <joseph@codesourcery.com> wrote: > On Sun, 21 Feb 2010, Geert Bosch wrote: > >> > As I understand it, whether -mfpmath=387 (with excess precision) or >> > -mfpmath=sse is the default is also considered part of the platform API >> > (like whether char is signed or unsigned by default, for example), in >> > addition to the ABI issues that can slow things down when SSE is used. >> >> No, this is not a new ABI. The ABI stays exactly the same. The I of > > Correct - I said API, not ABI. The API for C programs on x86 GNU/Linux > involves FLT_EVAL_METHOD == 2, whereas that on x86 Darwin involves > FLT_EVAL_METHOD == 0 and that on FreeBSD involves FLT_EVAL_METHOD == 2 > but with FPU rounding precision set to 53 bits so only excess range, not > precision, applies. > > You can support multiple APIs within one ABI - you can support both > versions of -mfpmath just as you can support both signed and unsigned > char, or both signed and unsigned bit-fields. It is not however > appropriate for -march options (whether explicit, or configured defaults > from the noncanonical target name or otherwise) to change either ABI or > API. Configure options to configure with a different API would be fine, > as would target names such as i686-pc-linux-gnussemath. We could very well enable -mfpmath=sse as a side-effect of -ffast-math though. Richard. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 17:36 ` Richard Guenther @ 2010-02-21 17:48 ` Joseph S. Myers 2010-02-21 18:25 ` Martin Guy 1 sibling, 0 replies; 75+ messages in thread From: Joseph S. Myers @ 2010-02-21 17:48 UTC (permalink / raw) To: Richard Guenther; +Cc: Geert Bosch, Steven Bosscher, Joe Buck, tprince, gcc On Sun, 21 Feb 2010, Richard Guenther wrote: > We could very well enable -mfpmath=sse as a side-effect of -ffast-math though. Yes, or sse+387 if that helps. As documented: @option{-fexcess-precision=standard} is not implemented for languages other than C, and has no effect if @option{-funsafe-math-optimizations} or @option{-ffast-math} is specified. On the x86, it also has no effect if @option{-mfpmath=sse} or @option{-mfpmath=sse+387} is specified; in the former case, IEEE semantics apply without excess precision, and in the latter, rounding is unpredictable. -funsafe-math-optimizations is expected to have sufficient effects on floating-point results that they can no longer be said to follow a particular API as regards excess precision, and so whichever API is fastest can be used. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 17:36 ` Richard Guenther 2010-02-21 17:48 ` Joseph S. Myers @ 2010-02-21 18:25 ` Martin Guy 2010-02-21 19:09 ` Steven Bosscher 1 sibling, 1 reply; 75+ messages in thread From: Martin Guy @ 2010-02-21 18:25 UTC (permalink / raw) To: Richard Guenther Cc: Joseph S. Myers, Geert Bosch, Steven Bosscher, Joe Buck, tprince, gcc I disagree with the "default cpu should 95% of what is currently on sale" argument. The default affects naive users most strongly, so it should "just work" on as many processors as is reasonable, not be as fast as possible on most of the majority of the processors currently on sale. Naive users might have anything. As an example of the results of that kind of thinking, we've had years of pain and wasted time in the ARM world due to the default architecture being armv5t instead of armv4t. The results are that user after user, making their first steps compiling a cross toolchain, turns up on the mailing lists having got "illegal instruction" after days of work, and that almost all the distributions are forced to carry an "unbreak armv4t" patch to GCC. Lord, someone was even compelled to try and get Android working on their Openmoko, while it was binary-only, by emulating the few trivial instructions in the kernel. Ubuntu, similarly, excludes the lower end by leaving the default unchanged. When users get interested in maximal speed, the first thing they do is go for -mcpu=xyz, which doesn't require them to recompile the compiler and is educational, while software distributions who build their own compilers make their own choices about the minimum processors they want to support. Of course, most GCC developers and 95% of the people they know probably do all have big new PCs using processors that are currently in production, so to their eyes it might seem that all the world has SSE2. However most people in the world cherish anything that works at all; why make life harder for them? We don't see the bottom end in the various usage stats because most people using them don't have the internet (or a landline phone, come to that). The time-honoured policy of having the default settings work on as wide a range hardware as possible is a socially inclusive one. Some manifestos chisel the "low bar" into their constitutions (Debian for example); it would be nice for GCC to do so too. Cheers M "You can't buy a computer these days with less that a gigabyte." -- A.S.Tanenbaum, trying to defend Minix's fixed-size kernel arrays at FOSDEM 2010 ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 18:25 ` Martin Guy @ 2010-02-21 19:09 ` Steven Bosscher 2010-02-21 19:29 ` Dave Korn 2010-02-21 19:46 ` Martin Guy 0 siblings, 2 replies; 75+ messages in thread From: Steven Bosscher @ 2010-02-21 19:09 UTC (permalink / raw) To: Martin Guy Cc: Richard Guenther, Joseph S. Myers, Geert Bosch, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 7:25 PM, Martin Guy <martinwguy@gmail.com> wrote: > I disagree with the "default cpu should 95% of what is currently on > sale" argument. > > The default affects naive users most strongly, so it should "just > work" on as many processors as is reasonable, not be as fast as > possible on most of the majority of the processors currently on sale. > Naive users might have anything. It is interesting how this conflicts with your signature: > "You can't buy a computer these days with less that a gigabyte." > -- A.S.Tanenbaum, trying to defend Minix's fixed-size kernel arrays > at FOSDEM 2010 I take it you disagree with this? Because most people do not expect to need 1GB for a Minix installation. ;-) Anyway, naive users also expect reasonable performance, which they don't get with the existing defaults [*]. And there are far many more default naive users who have systems with CPUs of designs less than 5 years old. You want to cater for a minority with old hardware. I actually expect you'll find that those users are less naive than the average gcc user. ([*] I sometimes even have to explain -O2, because icc has optimizations on by default. Many Fortran users do not use gfortran because they don't know about this difference...) > As an example of the results of that kind of thinking, we've had years > of pain and wasted time in the ARM world due to the default > architecture being armv5t instead of armv4t. The results are that user > after user, making their first steps compiling a cross toolchain, > turns up on the mailing lists having got "illegal instruction" after > days of work, and that almost all the distributions are forced to > carry an "unbreak armv4t" patch to GCC. Can you name these distributions? I can only name Debian (http://lists.debian.org/debian-arm/2006/06/msg00015.html) > Lord, someone was even compelled to try and get Android working on > their Openmoko, while it was binary-only, by emulating the few trivial > instructions in the kernel. Ubuntu, similarly, excludes the lower end > by leaving the default unchanged. Ubuntu also requires i686 or later. As do most other Linux distributions. But anyway, bringing ARM into this discussion is neither here nor there. > When users get interested in maximal speed, the first thing they do is > go for -mcpu=xyz Your naive users (and mine) don't even know about -mcpu and -march. >, which doesn't require them to recompile the compiler Neither does compiling for i386/i486 or armv4 if you have a cross-compiler for another default -- you can use -mcpu to "downgrade" too. > The time-honoured policy of having the default settings work on as > wide a range hardware as possible is a socially inclusive one. > Some manifestos chisel the "low bar" into their constitutions (Debian > for example); it would be nice for GCC to do so too. You're off it with the "socially inclusive" argument. No-one is excluded at all, if the defaults are changed. The only thing that happens is that the small number of users with exceptional configurations get the burden of dealing with the -march/-mtune options. (**/me mumbles something incoherent about Pareto, etc...***) Ciao! Steven ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 19:09 ` Steven Bosscher @ 2010-02-21 19:29 ` Dave Korn 2010-02-21 20:03 ` Martin Guy 2010-02-21 19:46 ` Martin Guy 1 sibling, 1 reply; 75+ messages in thread From: Dave Korn @ 2010-02-21 19:29 UTC (permalink / raw) To: Steven Bosscher Cc: Martin Guy, Richard Guenther, Joseph S. Myers, Geert Bosch, Joe Buck, tprince, gcc On 21/02/2010 19:09, Steven Bosscher wrote: > On Sun, Feb 21, 2010 at 7:25 PM, Martin Guy <martinwguy@gmail> wrote: >> As an example of the results of that kind of thinking, we've had years >> of pain and wasted time in the ARM world due to the default >> architecture being armv5t instead of armv4t. The results are that user >> after user, making their first steps compiling a cross toolchain, >> turns up on the mailing lists having got "illegal instruction" after >> days of work, and that almost all the distributions are forced to >> carry an "unbreak armv4t" patch to GCC. > But anyway, bringing ARM into this discussion is neither here nor there. Except inasmuch as that the proposed fix for i?86 could be extended with similar behaviour for arm and then people could set the default by using the right cpu name in the --target setting and it would solve this problem too. >> The time-honoured policy of having the default settings work on as >> wide a range hardware as possible is a socially inclusive one. >> Some manifestos chisel the "low bar" into their constitutions (Debian >> for example); it would be nice for GCC to do so too. > > You're off it with the "socially inclusive" argument. No-one is > excluded at all, if the defaults are changed. The only thing that > happens is that the small number of users with exceptional > configurations get the burden of dealing with the -march/-mtune > options. I too am having a hard time envisaging exactly who would be in this class of users who are simultaneously so naive that they don't know about -march or -mcpu or think to read the manual, and yet so advanced that they are trying to write programs for and rebuild modern compilers on ancient equipment.... cheers, DaveK ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 19:29 ` Dave Korn @ 2010-02-21 20:03 ` Martin Guy 2010-02-21 20:26 ` Dave Korn 0 siblings, 1 reply; 75+ messages in thread From: Martin Guy @ 2010-02-21 20:03 UTC (permalink / raw) To: Dave Korn Cc: Steven Bosscher, Richard Guenther, Joseph S. Myers, Geert Bosch, Joe Buck, tprince, gcc On 2/21/10, Dave Korn <dave.korn.cygwin@googlemail.com> wrote: > I too am having a hard time envisaging exactly who would be in this class of > users who are simultaneously so naive that they don't know about -march or > -mcpu or think to read the manual, and yet so advanced that they are trying to > write programs for and rebuild modern compilers on ancient equipment.... Old equipment is retro in rich places, but we built the first public-access email lab from stuff found in skips in inner-city Sicily and were very glad that Slackware, Debian and so on ran on 386 and 486's. At that time "everyone who was anyone" had pentium MMXs at least. The point about defaults is that the GCC default tends to filter down into the default for distributions; if GCC had been following the "90% of people have Pentiums" rule, and the distros followed the default, our low-budget lab would have been two terminals instead of about a dozen (or had to run SCO Xenix or something). I'm ex-UK-university computing lecturer myself, but been both rich and poor, both many times, so I know how the other half lives. Incidentally, one of the hackers who used Linux in that Sicilian squat at the age of 13 has just been accepted to do a computing degree at Cambridge University, UK. Not this this *still* has anything to do with the thread, but it's Sunday, so... Bless M ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 20:03 ` Martin Guy @ 2010-02-21 20:26 ` Dave Korn 2010-02-21 20:37 ` Laurent GUERBY ` (2 more replies) 0 siblings, 3 replies; 75+ messages in thread From: Dave Korn @ 2010-02-21 20:26 UTC (permalink / raw) To: Martin Guy Cc: Dave Korn, Steven Bosscher, Richard Guenther, Joseph S. Myers, Geert Bosch, Joe Buck, tprince, gcc On 21/02/2010 20:03, Martin Guy wrote: > The point about defaults is that the GCC default tends to filter down > into the default for distributions; I'd find it surprising if that was really the way it happens; don't distributions make deliberate and conscious decisions about binary standards and things like that? They certainly ought to be doing so, IMO, rather than just going with whatever-the-compiler-does-when-you-don't-tell-it-what-to-do. cheers, DaveK ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 20:26 ` Dave Korn @ 2010-02-21 20:37 ` Laurent GUERBY 2010-02-21 21:55 ` Steven Bosscher 2010-02-22 20:32 ` Toon Moene 2 siblings, 0 replies; 75+ messages in thread From: Laurent GUERBY @ 2010-02-21 20:37 UTC (permalink / raw) To: Dave Korn Cc: Martin Guy, Steven Bosscher, Richard Guenther, Joseph S. Myers, Geert Bosch, Joe Buck, tprince, gcc On Sun, 2010-02-21 at 20:44 +0000, Dave Korn wrote: > On 21/02/2010 20:03, Martin Guy wrote: > > > The point about defaults is that the GCC default tends to filter down > > into the default for distributions; > > I'd find it surprising if that was really the way it happens; don't > distributions make deliberate and conscious decisions about binary standards > and things like that? They certainly ought to be doing so, IMO, rather than > just going with whatever-the-compiler-does-when-you-don't-tell-it-what-to-do. Distributions do tweak to meet their goals: for example nearly all distributions ship with Ada enabled whereas GCC configure defaults with Ada disabled even when an Ada compiler is available to bootstrap with. Debian on mips (currently) defaults to o32 whereas GCC configure defaults to n32. I assume there are many other examples. Laurent ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 20:26 ` Dave Korn 2010-02-21 20:37 ` Laurent GUERBY @ 2010-02-21 21:55 ` Steven Bosscher 2010-02-22 20:32 ` Toon Moene 2 siblings, 0 replies; 75+ messages in thread From: Steven Bosscher @ 2010-02-21 21:55 UTC (permalink / raw) To: Dave Korn Cc: Martin Guy, Richard Guenther, Joseph S. Myers, Geert Bosch, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 9:44 PM, Dave Korn <dave.korn.cygwin@googlemail.com> wrote: > On 21/02/2010 20:03, Martin Guy wrote: > >> The point about defaults is that the GCC default tends to filter down >> into the default for distributions; > > I'd find it surprising if that was really the way it happens; don't > distributions make deliberate and conscious decisions about binary standards > and things like that? They certainly ought to be doing so, IMO, rather than > just going with whatever-the-compiler-does-when-you-don't-tell-it-what-to-do. Well, as Martin already pointed out (contradicting his own point): Apparently a lot of distributions *do* change the defaults, see armv4t discussion. Ciao! Steven ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 20:26 ` Dave Korn 2010-02-21 20:37 ` Laurent GUERBY 2010-02-21 21:55 ` Steven Bosscher @ 2010-02-22 20:32 ` Toon Moene 2010-02-22 20:37 ` Dave Korn 2 siblings, 1 reply; 75+ messages in thread From: Toon Moene @ 2010-02-22 20:32 UTC (permalink / raw) To: Dave Korn Cc: Martin Guy, Steven Bosscher, Richard Guenther, Joseph S. Myers, Geert Bosch, Joe Buck, tprince, gcc Dave Korn wrote: > On 21/02/2010 20:03, Martin Guy wrote: >> The point about defaults is that the GCC default tends to filter down >> into the default for distributions; > > I'd find it surprising if that was really the way it happens; don't > distributions make deliberate and conscious decisions about binary standards > and things like that? They certainly ought to be doing so, IMO, rather than > just going with whatever-the-compiler-does-when-you-don't-tell-it-what-to-do. This is Debian Testing as of last Sunday - note that it has had --with-arch-32=i486 for more time than I care to remember ... hirlam@super:~$ gfortran -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.2-9' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9) Hope this helps, -- Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-22 20:32 ` Toon Moene @ 2010-02-22 20:37 ` Dave Korn 0 siblings, 0 replies; 75+ messages in thread From: Dave Korn @ 2010-02-22 20:37 UTC (permalink / raw) To: Toon Moene Cc: Dave Korn, Martin Guy, Steven Bosscher, Richard Guenther, Joseph S. Myers, Geert Bosch, Joe Buck, tprince, gcc On 22/02/2010 20:32, Toon Moene wrote: [ Not singling you out here, yours just happens to be the latest reply: ] > Dave Korn wrote: > >> On 21/02/2010 20:03, Martin Guy wrote: > >>> The point about defaults is that the GCC default tends to filter down >>> into the default for distributions; >> >> I'd find it surprising if that was really the way it happens; don't >> distributions make deliberate and conscious decisions about binary >> standards and things like that? > This is Debian Testing Enough with the examples, already! It was a rhetorical question! :-) cheers, DaveK ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 19:09 ` Steven Bosscher 2010-02-21 19:29 ` Dave Korn @ 2010-02-21 19:46 ` Martin Guy 2010-02-21 20:03 ` Dave Korn 2010-02-21 20:10 ` Joe Buck 1 sibling, 2 replies; 75+ messages in thread From: Martin Guy @ 2010-02-21 19:46 UTC (permalink / raw) To: Steven Bosscher Cc: Richard Guenther, Joseph S. Myers, Geert Bosch, Joe Buck, tprince, gcc On 2/21/10, Steven Bosscher <stevenb.gcc@gmail.com> wrote: > It is interesting how this conflicts with your signature: > > "You can't buy a computer these days with less that a gigabyte." > > -- A.S.Tanenbaum, trying to defend Minix's fixed-size kernel arrays > > at FOSDEM 2010 > I take it you disagree with this? Because most people do not expect to > need 1GB for a Minix installation. ;-) It's a straw man, another example of bogus reasoning. Of course you can buy new computers with 64MB, and they are particularly suitable for simple kernels. The embedded Linux/BSD crowd at the presentation didn't seem very impressed either. > You want to cater for a minority with old hardware. I > actually expect you'll find that those users are less naive than the > average gcc user. I want to cater for everyone, especially youngsters, learners and the poor struggling with whatever they can get their hands on. It's not even a rich country/poor country thing: I live in a run down industrial area of England where the local kids are gagging for anything that works. > Can you name these distributions? I can only name Debian > (http://lists.debian.org/debian-arm/2006/06/msg00015.html) A quick search for "unbreak-armv4t.patch" shows, at a glance on the first ten hits, fedora, openembedded, slind, openmoko, mamona, android-porting. I'll leave you to peruse page two on :) > Ubuntu also requires i686 or later. Ubuntu also needs 384MB to work these days, so it is a reasonable application-specific choice for that distro. GCC should not be tailored to high-end desktop, laptop and server machines. > But anyway, bringing ARM into this discussion is neither here nor there. It is a specific example of a pointlessly higher cpu default (for "arm-*") where such a decision was made in GCC and the annoyances it causes. which is what this thread had drifted into. > Your naive users (and mine) don't even know about -mcpu and -march. Exactly, so they go "cc hello.c; a.out" and get "Illegal instruction" unless they have a relatively new first-world PC. > >, which doesn't require them to recompile the compiler > Neither does compiling for i386/i486 or armv4 if you have a > cross-compiler for another default -- you can use -mcpu to "downgrade" > too. Of course. However it does bite cross-compilers because people end up distributing the C library compiled for a high-end CPU, so no program will run even when you do drop the -mcpu level. Raising it instead still works for everyone. > (**/me mumbles something incoherent about Pareto, etc...***) Moore's Law suggests that we should optimise most intensely for the physically slower processors, where sloth or speed translates into more real time, but I forgot that point in the last post :) Actually, this is irrelevant to the thread, since one always has to specify a CPU model in the tuple when configuring for i?86, and the thread was about an i686-* configuration tuple still producing a compiler that outputs i386 code by default, which does seem silly. Happy Sunday. M ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 19:46 ` Martin Guy @ 2010-02-21 20:03 ` Dave Korn 2010-02-21 20:10 ` Joe Buck 1 sibling, 0 replies; 75+ messages in thread From: Dave Korn @ 2010-02-21 20:03 UTC (permalink / raw) To: Martin Guy Cc: Steven Bosscher, Richard Guenther, Joseph S. Myers, Geert Bosch, Joe Buck, tprince, gcc On 21/02/2010 19:45, Martin Guy wrote: > On 2/21/10, Steven Bosscher <stevenb.gcc@gmail> wrote: >> Your naive users (and mine) don't even know about -mcpu and -march. > Exactly, so they go "cc hello.c; a.out" and get "Illegal instruction" > unless they have a relatively new first-world PC. So learning to program is difficult. I don't think any compiler default commandline setting can change that, but on the brights side, learning about commandline options is pretty much the first thing any newbie will need to learn in order to drive a compiler. > Of course. However it does bite cross-compilers because people end up > distributing the C library compiled for a high-end CPU, so no program > will run even when you do drop the -mcpu level. What do these people think they are doing posing as distributors without knowing the first thing about packaging and binary distribution? > Actually, this is irrelevant to the thread, since one always has to > specify a CPU model in the tuple when configuring for i?86, and the > thread was about an i686-* configuration tuple still producing a > compiler that outputs i386 code by default, which does seem silly. A quick browse through config.gcc suggests most of the arm targets match the "arm*-*-<something>" pattern, so it might be quite easy to adopt the same use-the-precise-cpu-model-in-the-target-triplet scheme for ARM, mightn't it? (Though obviously with the proviso of making it actually work, as proposed but not yet implemented for x86!) cheers, DaveK ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 19:46 ` Martin Guy 2010-02-21 20:03 ` Dave Korn @ 2010-02-21 20:10 ` Joe Buck 1 sibling, 0 replies; 75+ messages in thread From: Joe Buck @ 2010-02-21 20:10 UTC (permalink / raw) To: Martin Guy Cc: Steven Bosscher, Richard Guenther, Joseph S. Myers, Geert Bosch, tprince, gcc On Sun, Feb 21, 2010 at 11:45:49AM -0800, Martin Guy wrote: > > You want to cater for a minority with old hardware. I > > actually expect you'll find that those users are less naive than the > > average gcc user. > I want to cater for everyone, especially youngsters, learners and the > poor struggling with whatever they can get their hands on. > It's not even a rich country/poor country thing: I live in a run down > industrial area of England where the local kids are gagging for > anything that works. Let's step back a bit and look at the tradeoffs. I see two main inflection points where the choice of default has a real impact. First, you have to assume i486 if you want a libstdc++ that supports locking correctly. If you default to i386, you screw every user of an i486-or-later processor by giving them locking that doesn't work, for the benefit of a processor that hasn't been manufactured in several years, and was only used in embedded markets for a number of years before that. To me, that's a no-brainer; we should assume 486 and ask the tiny minority trying to make an ancient system work to use the appropriate switches. Right now, GNU/Linux distros are already doing that. The second inflection point is being able to assume enough SSE to generate improved floating point. Here, it seems less clear that it's better to change the default, as it's more possible that the users of older systems that you champion could be impacted. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 17:34 ` Joseph S. Myers 2010-02-21 17:36 ` Richard Guenther @ 2010-02-22 1:39 ` Geert Bosch 1 sibling, 0 replies; 75+ messages in thread From: Geert Bosch @ 2010-02-22 1:39 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Richard Guenther, Steven Bosscher, Joe Buck, tprince, gcc On Feb 21, 2010, at 12:34, Joseph S. Myers wrote: > Correct - I said API, not ABI. The API for C programs on x86 GNU/Linux > involves FLT_EVAL_METHOD == 2, whereas that on x86 Darwin involves > FLT_EVAL_METHOD == 0 and that on FreeBSD involves FLT_EVAL_METHOD == 2 > but with FPU rounding precision set to 53 bits so only excess range, not > precision, applies. Your following paragraph "If people really want a new 32-bit x86 ABI..." threw me off. Your message contained the word ABI 4 times, and API once. I missed it, apologies. However, I think this is a bit of a red herring. There really is no consistent well-defined model for our current floating-point semantics on x86. Wether a value is computed with extra precision or not depends on many factors, such as optimization. The best way to describe the current situation is that any operation may or may not keep excess precision or range. Your patch to incur more double rounding by going through memory more often does not really solve this issue, it will just make results a little more consistent, but possible also less accurate and less precise. So, in short, we all will lose in a quest to support C99 on least common denominator hardware. We will not be able to achieve full compliance, we will all have to deal with worse performance due to additional spilling. All at the same time any other compiler will happily take advantage of the user's hardware and compile great code that is faster and produces better results. -Geert ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 17:15 ` Geert Bosch 2010-02-21 17:27 ` H.J. Lu 2010-02-21 17:34 ` Joseph S. Myers @ 2010-02-21 17:34 ` Richard Guenther 2 siblings, 0 replies; 75+ messages in thread From: Richard Guenther @ 2010-02-21 17:34 UTC (permalink / raw) To: Geert Bosch; +Cc: Joseph S. Myers, Steven Bosscher, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 6:15 PM, Geert Bosch <bosch@adacore.com> wrote: > > On Feb 21, 2010, at 09:58, Joseph S. Myers wrote: >> On Sun, 21 Feb 2010, Richard Guenther wrote: >>>> The biggest change we need to make for x86 is to enable SSE2, >>>> so we can get proper rounding behavior for float and double, >>>> as well as significant performance increases. >>> >>> I think Joseph fixed the rounding behavior for 4.5. Also without an adjusted >> >> Well, I provided the option for rounding that is predictable and in >> accordance with C99 when using the default -mfpmath=387. But that option >> does carry the performance cost of storing to / loading from memory at >> various points, as required to get the rounding on 387 (and there are >> still cases where excess precision means double rounding). > > This clearly is worse in all areas than using SSE2: there STILL is > double rounding, and performance goes down the drain. On any recent > machine there is the SSE2 hardware to do the operations correctly > without going through memory and without double rounding. > >>> ABI you'd introduce x87 <-> SSE register moves which are not helpful >>> for performance. >> >> As I understand it, whether -mfpmath=387 (with excess precision) or >> -mfpmath=sse is the default is also considered part of the platform API >> (like whether char is signed or unsigned by default, for example), in >> addition to the ABI issues that can slow things down when SSE is used. > > No, this is not a new ABI. The ABI stays exactly the same. The I of > ABI stands for Interface. That is, the ABI has nothing to say about > how a function will compute any results. That is the area of language > standards. The only way we'd violate the ABI is the reliance on SSE2 > instructions being available and SSE2 registers being saved by the OS. > > However, since any other compiler uses SSE2 instructions by default, > I don't see why GCC should be any different. If anything, since the > GCC target audience is more focused on Free and open source software, > we could be more aggressive in taking advantage of newer hardware. > What about an autoconf test for availability of 486 atomic instructions, > and SSE2 instructions in order, and choosing the default target based > on the host? Not too crazy, is it? > >> If people really want a new 32-bit x86 ABI I'd suggest making it an ILP32 >> ABI for processors running in 64-bit mode, so 64-bit registers are >> available without the additional memory cost of 64-bit pointers for code >> not needing them - you could also assume a minimum of -march=x86-64, which >> implies SSE2. But if there were significant demand for such an ABI I >> think we'd have seen it by now, and you probably run into the various >> syscall interface problems that MIPS n32 has had. > > Let's keep that can of worms closed, has nothing to do with changing > our -march defaults. > > -Geert > > PS. If anyone has SPEC-like figures for performance difference between -msse2 > -mfpmath=sse,x87 and default, I'd be interested in seeing those results. http://gcc.opensuse.org/SPEC/CFP/sb-frescobaldi.suse.de-head-64-32o-32bit/recent.html http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64-32o-32bit/recent.html note that SSE is still used by the vectorizer in both base/peak due to -march=native. Richard. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 14:58 ` Joseph S. Myers 2010-02-21 17:15 ` Geert Bosch @ 2010-02-21 17:22 ` H.J. Lu 1 sibling, 0 replies; 75+ messages in thread From: H.J. Lu @ 2010-02-21 17:22 UTC (permalink / raw) To: Joseph S. Myers Cc: Richard Guenther, Geert Bosch, Steven Bosscher, Joe Buck, tprince, gcc On Sun, Feb 21, 2010 at 6:58 AM, Joseph S. Myers <joseph@codesourcery.com> wrote: > On Sun, 21 Feb 2010, Richard Guenther wrote: > >> > The biggest change we need to make for x86 is to enable SSE2, >> > so we can get proper rounding behavior for float and double, >> > as well as significant performance increases. >> >> I think Joseph fixed the rounding behavior for 4.5. Also without an adjusted > > Well, I provided the option for rounding that is predictable and in > accordance with C99 when using the default -mfpmath=387. But that option > does carry the performance cost of storing to / loading from memory at > various points, as required to get the rounding on 387 (and there are > still cases where excess precision means double rounding). > I think your C99 change caused a regression on ia32: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128#c10 -- H.J. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 12:13 ` Richard Guenther 2010-02-21 12:33 ` Paolo Carlini 2010-02-21 14:58 ` Joseph S. Myers @ 2010-02-22 1:41 ` Geert Bosch 2010-02-22 10:27 ` Andrew Haley 3 siblings, 0 replies; 75+ messages in thread From: Geert Bosch @ 2010-02-22 1:41 UTC (permalink / raw) To: Richard Guenther; +Cc: Steven Bosscher, Joe Buck, tprince, gcc On Feb 21, 2010, at 07:13, Richard Guenther wrote: > The present discussion is about defaulting to at least 486 when not > configured for i386-linux. That sounds entirely reasonable to me. I fully agree with the "at least 486" part. However, if we only change the default once every 20 years, it seems we should bump it up more than to just 486... People who compile GCC from sources, mostly use it to compile other code from source for their own use. The only reason to by default generate code for an older chip than the one on the host, is to distribute binaries. Why would a GNU compiler by default give up performance and numerical stability to facilitate binary distribution? Basically, GCC has to compete with other compilers, such as those from Microsoft and Intel. When GCC arbitrarily decides to tie one hand behind its back, so that code by default targets a 25-year-old chip, it is no surprise it comes out looking bad. -Geert ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 12:13 ` Richard Guenther ` (2 preceding siblings ...) 2010-02-22 1:41 ` Geert Bosch @ 2010-02-22 10:27 ` Andrew Haley 2010-02-22 10:39 ` Richard Guenther 3 siblings, 1 reply; 75+ messages in thread From: Andrew Haley @ 2010-02-22 10:27 UTC (permalink / raw) To: gcc On 02/21/2010 12:13 PM, Richard Guenther wrote: > On Sun, Feb 21, 2010 at 1:06 PM, Geert Bosch <bosch@adacore.com> wrote: >> >> On Feb 21, 2010, at 06:18, Steven Bosscher wrote: >>> My point: gcc may fail to attract users (and/or may be losing users) >>> when it tries to tailor to the needs of minorities. >>> >>> IMHO it would be much more reasonable to change the defaults to >>> generate code that can run on, say, 95% of the computers still in use. >>> If a user want to use the latest-and-greatest gcc for a really old >>> machine, the burden of adding extra flags to change the default >>> behavior of the compiler should be on that user. >>> >>> In this case of the i386 back end, that probably means changing the >>> default to something like pentium3. >> >> The biggest change we need to make for x86 is to enable SSE2, >> so we can get proper rounding behavior for float and double, >> as well as significant performance increases. > > I think Joseph fixed the rounding behavior for 4.5. Also without an adjusted > ABI you'd introduce x87 <-> SSE register moves which are not helpful > for performance. Exactly. For example, double plus(double a, double b) { return a+b; } plus: pushl %ebp movl %esp, %ebp subl $8, %esp movsd 16(%ebp), %xmm0 addsd 8(%ebp), %xmm0 movsd %xmm0, -8(%ebp) fldl -8(%ebp) leave ret Andrew. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-22 10:27 ` Andrew Haley @ 2010-02-22 10:39 ` Richard Guenther 0 siblings, 0 replies; 75+ messages in thread From: Richard Guenther @ 2010-02-22 10:39 UTC (permalink / raw) To: Andrew Haley; +Cc: gcc On Mon, Feb 22, 2010 at 11:27 AM, Andrew Haley <aph@redhat.com> wrote: > On 02/21/2010 12:13 PM, Richard Guenther wrote: >> On Sun, Feb 21, 2010 at 1:06 PM, Geert Bosch <bosch@adacore.com> wrote: >>> >>> On Feb 21, 2010, at 06:18, Steven Bosscher wrote: >>>> My point: gcc may fail to attract users (and/or may be losing users) >>>> when it tries to tailor to the needs of minorities. >>>> >>>> IMHO it would be much more reasonable to change the defaults to >>>> generate code that can run on, say, 95% of the computers still in use. >>>> If a user want to use the latest-and-greatest gcc for a really old >>>> machine, the burden of adding extra flags to change the default >>>> behavior of the compiler should be on that user. >>>> >>>> In this case of the i386 back end, that probably means changing the >>>> default to something like pentium3. >>> >>> The biggest change we need to make for x86 is to enable SSE2, >>> so we can get proper rounding behavior for float and double, >>> as well as significant performance increases. >> >> I think Joseph fixed the rounding behavior for 4.5. Also without an adjusted >> ABI you'd introduce x87 <-> SSE register moves which are not helpful >> for performance. > > Exactly. For example, > > double plus(double a, double b) > { > return a+b; > } > > plus: > pushl %ebp > movl %esp, %ebp > subl $8, %esp > movsd 16(%ebp), %xmm0 > addsd 8(%ebp), %xmm0 > movsd %xmm0, -8(%ebp) > fldl -8(%ebp) > leave > ret Yep. As the issue only concerns return values we could start to return in both %sp0 and %xmm0 for externally visible functions. That would still have a spurios set of %sp0 and FP stack adjustment but the caller could use %xmm0 and hope performance wouldn't be affected too much. Of course that's an ABI change that is only compatible in one direction. Richard. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-19 2:00 ` Tim Prince 2010-02-19 17:31 ` Joe Buck @ 2010-02-19 20:56 ` Florian Weimer 2010-02-19 23:06 ` Joel Dice 1 sibling, 1 reply; 75+ messages in thread From: Florian Weimer @ 2010-02-19 20:56 UTC (permalink / raw) To: tprince; +Cc: gcc * Tim Prince: > All CPUs still in production are at least SSE3 capable, unless someone > can come up with one of which I'm not aware. What about some of the AMD Geode processors? ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-19 20:56 ` Florian Weimer @ 2010-02-19 23:06 ` Joel Dice 0 siblings, 0 replies; 75+ messages in thread From: Joel Dice @ 2010-02-19 23:06 UTC (permalink / raw) To: Florian Weimer; +Cc: tprince, gcc On Fri, 19 Feb 2010, Florian Weimer wrote: > * Tim Prince: > >> All CPUs still in production are at least SSE3 capable, unless someone >> can come up with one of which I'm not aware. > > What about some of the AMD Geode processors? These only support a subset of SSE1, according to http://wiki.laptop.org/go/Geode_instruction_set. Here is an excerpt from /proc/cpuinfo on my Geode LX: flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-18 22:09 Change x86 default arch for 4.5? Jason Merrill 2010-02-18 23:30 ` Joe Buck @ 2010-02-19 0:46 ` Joseph S. Myers 2010-02-19 2:57 ` Jason Merrill ` (2 more replies) 1 sibling, 3 replies; 75+ messages in thread From: Joseph S. Myers @ 2010-02-19 0:46 UTC (permalink / raw) To: Jason Merrill; +Cc: GCC On Thu, 18 Feb 2010, Jason Merrill wrote: > I periodically get bitten by bug 34115: a compiler configured without > --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would > only need to bump the default to i486 to get atomic support. Can we > reconsider the default for 4.5? My position remains that configuring for i686-* should default to -march=i686 rather than -mtune=i686. http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html Perhaps someone would like to review HJ's patch to that effect? http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html This will probably break building glibc, as problems building when __i686 is a predefined macro have been known since at least 2002 but none of the many patches proposed since then have been accepted. http://sourceware.org/ml/libc-alpha/2002-10/msg00156.html ... http://sourceware.org/ml/libc-alpha/2009-07/msg00072.html -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-19 0:46 ` Joseph S. Myers @ 2010-02-19 2:57 ` Jason Merrill 2010-02-19 17:02 ` Paolo Bonzini 2010-02-21 11:21 ` Paolo Carlini 2010-02-24 23:00 ` Jason Merrill 2 siblings, 1 reply; 75+ messages in thread From: Jason Merrill @ 2010-02-19 2:57 UTC (permalink / raw) To: Joseph S. Myers; +Cc: GCC, H.J. Lu On 02/18/2010 07:46 PM, Joseph S. Myers wrote: > On Thu, 18 Feb 2010, Jason Merrill wrote: > >> I periodically get bitten by bug 34115: a compiler configured without >> --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would >> only need to bump the default to i486 to get atomic support. Can we >> reconsider the default for 4.5? > > My position remains that configuring for i686-* should default to > -march=i686 rather than -mtune=i686. That makes sense to me. > Perhaps someone would like to review HJ's patch to that effect? > > http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html Using all the noncanonical variants as arch defaults makes me a bit nervous, but I suppose if someone actually writes $GCC/configure nocona-pc-linux-gnu that's what they would expect to get... > This will probably break building glibc, as problems building when __i686 > is a predefined macro have been known since at least 2002 but none of the > many patches proposed since then have been accepted. I imagine changing the default would help with that...and packagers can work around it. Jason ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-19 2:57 ` Jason Merrill @ 2010-02-19 17:02 ` Paolo Bonzini 0 siblings, 0 replies; 75+ messages in thread From: Paolo Bonzini @ 2010-02-19 17:02 UTC (permalink / raw) To: Jason Merrill; +Cc: Joseph S. Myers, GCC, H.J. Lu >> This will probably break building glibc, as problems building when __i686 >> is a predefined macro have been known since at least 2002 but none of the >> many patches proposed since then have been accepted. > > I imagine changing the default would help with that...and packagers can > work around it. I think that many packagers already are. Paolo ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-19 0:46 ` Joseph S. Myers 2010-02-19 2:57 ` Jason Merrill @ 2010-02-21 11:21 ` Paolo Carlini 2010-02-21 18:02 ` Dave Korn 2010-02-24 23:00 ` Jason Merrill 2 siblings, 1 reply; 75+ messages in thread From: Paolo Carlini @ 2010-02-21 11:21 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Jason Merrill, GCC On 02/19/2010 01:46 AM, Joseph S. Myers wrote: > On Thu, 18 Feb 2010, Jason Merrill wrote: > >> I periodically get bitten by bug 34115: a compiler configured without >> --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would >> only need to bump the default to i486 to get atomic support. Can we >> reconsider the default for 4.5? >> > My position remains that configuring for i686-* should default to > -march=i686 rather than -mtune=i686. > > http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html > http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html > > Perhaps someone would like to review HJ's patch to that effect? > Yes, please: for the record, I totally support this position. Paolo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 11:21 ` Paolo Carlini @ 2010-02-21 18:02 ` Dave Korn 2010-02-21 18:28 ` Martin Guy 0 siblings, 1 reply; 75+ messages in thread From: Dave Korn @ 2010-02-21 18:02 UTC (permalink / raw) To: Paolo Carlini; +Cc: Joseph S. Myers, Jason Merrill, GCC On 21/02/2010 11:21, Paolo Carlini wrote: > On 02/19/2010 01:46 AM, Joseph S. Myers wrote: >> On Thu, 18 Feb 2010, Jason Merrill wrote: >> >>> I periodically get bitten by bug 34115: a compiler configured without >>> --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would >>> only need to bump the default to i486 to get atomic support. Can we >>> reconsider the default for 4.5? >>> >> My position remains that configuring for i686-* should default to >> -march=i686 rather than -mtune=i686. >> >> http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html >> http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html >> >> Perhaps someone would like to review HJ's patch to that effect? >> > Yes, please: for the record, I totally support this position. > > Paolo. Likewise, I was very surprised when I found out that this wasn't already how configure worked. It makes perfect sense that configuring for i686-*-* should get you an i686 compiler and configuring for i586-*-* should get you an i586 compiler and so on, rather than that you get an i386 compiler no matter what you asked for. It seems a no-brainer that the default should match the target name that is embedded into the compiler executable itself, so that it "does what it says on the tin" (I'm all in favour of accuracy in labelling!), and since you can always override the default with explicit command-line options, no generality is lost. cheers, DaveK ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-21 18:02 ` Dave Korn @ 2010-02-21 18:28 ` Martin Guy 0 siblings, 0 replies; 75+ messages in thread From: Martin Guy @ 2010-02-21 18:28 UTC (permalink / raw) To: Dave Korn; +Cc: Paolo Carlini, Joseph S. Myers, Jason Merrill, GCC On 2/21/10, Dave Korn <dave.korn.cygwin@googlemail.com> wrote: > It makes perfect sense that configuring for i686-*-* should > get you an i686 compiler and configuring for i586-*-* should get you an i586 > compiler and so on, rather than that you get an i386 compiler no matter what > you asked for. Agreed M ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-19 0:46 ` Joseph S. Myers 2010-02-19 2:57 ` Jason Merrill 2010-02-21 11:21 ` Paolo Carlini @ 2010-02-24 23:00 ` Jason Merrill 2010-02-25 7:07 ` Uros Bizjak 2 siblings, 1 reply; 75+ messages in thread From: Jason Merrill @ 2010-02-24 23:00 UTC (permalink / raw) To: Richard Henderson, Jan Hubicka, Uros Bizjak; +Cc: GCC On 02/18/2010 07:46 PM, Joseph S. Myers wrote: > On Thu, 18 Feb 2010, Jason Merrill wrote: > >> I periodically get bitten by bug 34115: a compiler configured without >> --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would >> only need to bump the default to i486 to get atomic support. Can we >> reconsider the default for 4.5? > > My position remains that configuring for i686-* should default to > -march=i686 rather than -mtune=i686. > > http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html > http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html > > Perhaps someone would like to review HJ's patch to that effect? > > http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html Perhaps one of the i386 maintainers? Jason ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-24 23:00 ` Jason Merrill @ 2010-02-25 7:07 ` Uros Bizjak 2010-02-25 10:37 ` Paolo Bonzini 0 siblings, 1 reply; 75+ messages in thread From: Uros Bizjak @ 2010-02-25 7:07 UTC (permalink / raw) To: Jason Merrill; +Cc: Richard Henderson, Jan Hubicka, GCC, Paolo Bonzini On Thu, Feb 25, 2010 at 12:00 AM, Jason Merrill <jason@redhat.com> wrote: > On 02/18/2010 07:46 PM, Joseph S. Myers wrote: >> >> On Thu, 18 Feb 2010, Jason Merrill wrote: >> >>> I periodically get bitten by bug 34115: a compiler configured without >>> --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we >>> would >>> only need to bump the default to i486 to get atomic support. Can we >>> reconsider the default for 4.5? >> >> My position remains that configuring for i686-* should default to >> -march=i686 rather than -mtune=i686. >> >> http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html >> http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html >> >> Perhaps someone would like to review HJ's patch to that effect? >> >> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html > > Perhaps one of the i386 maintainers? The default arch should be based on what _users_ expect from the configure process, so it is IMO up to distributors and finally Release Managers to decide. As far as the proposed patch is concerned, I think that it is the step in the right direction, and is OK for 4.6, but also please also add -march=native choice. It works OK nowadays. Since this is build patch, it also needs OK from build maintainer (CCd). Uros. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-25 7:07 ` Uros Bizjak @ 2010-02-25 10:37 ` Paolo Bonzini 2010-02-25 10:48 ` Paolo Bonzini 2010-02-25 23:14 ` Jason Merrill 0 siblings, 2 replies; 75+ messages in thread From: Paolo Bonzini @ 2010-02-25 10:37 UTC (permalink / raw) To: Uros Bizjak; +Cc: Jason Merrill, Richard Henderson, Jan Hubicka, GCC On 02/25/2010 08:07 AM, Uros Bizjak wrote: > On Thu, Feb 25, 2010 at 12:00 AM, Jason Merrill<jason@redhat.com> wrote: >> On 02/18/2010 07:46 PM, Joseph S. Myers wrote: >>> >>> On Thu, 18 Feb 2010, Jason Merrill wrote: >>> >>>> I periodically get bitten by bug 34115: a compiler configured without >>>> --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we >>>> would >>>> only need to bump the default to i486 to get atomic support. Can we >>>> reconsider the default for 4.5? >>> >>> My position remains that configuring for i686-* should default to >>> -march=i686 rather than -mtune=i686. >>> >>> http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html >>> http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html >>> >>> Perhaps someone would like to review HJ's patch to that effect? >>> >>> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html >> >> Perhaps one of the i386 maintainers? > > The default arch should be based on what _users_ expect from the > configure process, so it is IMO up to distributors and finally Release > Managers to decide. > > As far as the proposed patch is concerned, I think that it is the step > in the right direction, and is OK for 4.6, but also please also add > -march=native choice. It works OK nowadays. > > Since this is build patch, it also needs OK from build maintainer (CCd). There are plenty of global reviewers in the CC list. :-) Paolo ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-25 10:37 ` Paolo Bonzini @ 2010-02-25 10:48 ` Paolo Bonzini 2010-02-25 23:14 ` Jason Merrill 1 sibling, 0 replies; 75+ messages in thread From: Paolo Bonzini @ 2010-02-25 10:48 UTC (permalink / raw) To: gcc; +Cc: Jason Merrill, Richard Henderson, Jan Hubicka, GCC On 02/25/2010 08:07 AM, Uros Bizjak wrote: > On Thu, Feb 25, 2010 at 12:00 AM, Jason Merrill<jason@redhat.com> wrote: >> On 02/18/2010 07:46 PM, Joseph S. Myers wrote: >>> >>> On Thu, 18 Feb 2010, Jason Merrill wrote: >>> >>>> I periodically get bitten by bug 34115: a compiler configured without >>>> --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we >>>> would >>>> only need to bump the default to i486 to get atomic support. Can we >>>> reconsider the default for 4.5? >>> >>> My position remains that configuring for i686-* should default to >>> -march=i686 rather than -mtune=i686. >>> >>> http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html >>> http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html >>> >>> Perhaps someone would like to review HJ's patch to that effect? >>> >>> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html >> >> Perhaps one of the i386 maintainers? > > The default arch should be based on what _users_ expect from the > configure process, so it is IMO up to distributors and finally Release > Managers to decide. > > As far as the proposed patch is concerned, I think that it is the step > in the right direction, and is OK for 4.6, but also please also add > -march=native choice. It works OK nowadays. > > Since this is build patch, it also needs OK from build maintainer (CCd). There are plenty of global reviewers in the CC list. :-) Paolo ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-25 10:37 ` Paolo Bonzini 2010-02-25 10:48 ` Paolo Bonzini @ 2010-02-25 23:14 ` Jason Merrill 2010-02-26 11:00 ` H.J. Lu 1 sibling, 1 reply; 75+ messages in thread From: Jason Merrill @ 2010-02-25 23:14 UTC (permalink / raw) To: Paolo Bonzini, H.J. Lu; +Cc: Uros Bizjak, Richard Henderson, Jan Hubicka, GCC On 02/25/2010 05:37 AM, Paolo Bonzini wrote: >> Since this is build patch, it also needs OK from build maintainer (CCd). > > There are plenty of global reviewers in the CC list. :-) Yep, I've just been trying to get people who might know why the status quo is the way it is to weigh in before I approve it. H.J., could you update your patch to support --with-arch/cpu=native as Uros requested? Jason ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Change x86 default arch for 4.5? 2010-02-25 23:14 ` Jason Merrill @ 2010-02-26 11:00 ` H.J. Lu 0 siblings, 0 replies; 75+ messages in thread From: H.J. Lu @ 2010-02-26 11:00 UTC (permalink / raw) To: Jason Merrill Cc: Paolo Bonzini, Uros Bizjak, Richard Henderson, Jan Hubicka, GCC On Thu, Feb 25, 2010 at 2:01 PM, Jason Merrill <jason@redhat.com> wrote: > On 02/25/2010 05:37 AM, Paolo Bonzini wrote: >>> >>> Since this is build patch, it also needs OK from build maintainer (CCd). >> >> There are plenty of global reviewers in the CC list. :-) > > Yep, I've just been trying to get people who might know why the status quo > is the way it is to weigh in before I approve it. > > H.J., could you update your patch to support --with-arch/cpu=native as Uros > requested? > Here it is: http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01095.html -- H.J. ^ permalink raw reply [flat|nested] 75+ messages in thread
end of thread, other threads:[~2010-02-27 13:16 UTC | newest] Thread overview: 75+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-02-18 22:09 Change x86 default arch for 4.5? Jason Merrill 2010-02-18 23:30 ` Joe Buck 2010-02-19 0:31 ` David Daney 2010-02-19 0:54 ` Joe Buck 2010-02-19 2:00 ` Tim Prince 2010-02-19 17:31 ` Joe Buck 2010-02-20 7:58 ` Erik Trulsson 2010-02-21 11:18 ` Steven Bosscher 2010-02-21 12:06 ` Geert Bosch 2010-02-21 12:13 ` Richard Guenther 2010-02-21 12:33 ` Paolo Carlini 2010-02-21 14:58 ` Joseph S. Myers 2010-02-21 17:15 ` Geert Bosch 2010-02-21 17:27 ` H.J. Lu 2010-02-21 20:23 ` Erik Trulsson 2010-02-21 20:27 ` H.J. Lu 2010-02-21 21:14 ` Erik Trulsson 2010-02-21 21:54 ` H.J. Lu 2010-02-21 21:59 ` Steven Bosscher 2010-02-21 23:10 ` Erik Trulsson 2010-02-22 2:09 ` Vincent Lefevre 2010-02-27 17:27 ` Gerald Pfeifer 2010-02-21 21:54 ` Steven Bosscher 2010-02-21 22:19 ` Dave Korn 2010-02-21 23:28 ` Martin Guy 2010-02-22 0:06 ` Steven Bosscher 2010-02-21 22:50 ` Erik Trulsson 2010-02-21 23:17 ` Dave Korn 2010-02-22 0:29 ` Erik Trulsson 2010-02-22 11:04 ` Andrew Haley 2010-02-22 17:09 ` Dave Korn 2010-02-22 1:21 ` Geert Bosch 2010-02-22 1:57 ` Joseph S. Myers 2010-02-22 2:25 ` Vincent Lefevre 2010-02-22 2:58 ` Joseph S. Myers 2010-02-22 4:23 ` Vincent Lefevre 2010-02-22 4:32 ` Vincent Lefevre 2010-02-22 2:33 ` Geert Bosch 2010-02-21 22:05 ` H.J. Lu 2010-02-23 9:25 ` Piotr Wyderski 2010-02-21 17:34 ` Joseph S. Myers 2010-02-21 17:36 ` Richard Guenther 2010-02-21 17:48 ` Joseph S. Myers 2010-02-21 18:25 ` Martin Guy 2010-02-21 19:09 ` Steven Bosscher 2010-02-21 19:29 ` Dave Korn 2010-02-21 20:03 ` Martin Guy 2010-02-21 20:26 ` Dave Korn 2010-02-21 20:37 ` Laurent GUERBY 2010-02-21 21:55 ` Steven Bosscher 2010-02-22 20:32 ` Toon Moene 2010-02-22 20:37 ` Dave Korn 2010-02-21 19:46 ` Martin Guy 2010-02-21 20:03 ` Dave Korn 2010-02-21 20:10 ` Joe Buck 2010-02-22 1:39 ` Geert Bosch 2010-02-21 17:34 ` Richard Guenther 2010-02-21 17:22 ` H.J. Lu 2010-02-22 1:41 ` Geert Bosch 2010-02-22 10:27 ` Andrew Haley 2010-02-22 10:39 ` Richard Guenther 2010-02-19 20:56 ` Florian Weimer 2010-02-19 23:06 ` Joel Dice 2010-02-19 0:46 ` Joseph S. Myers 2010-02-19 2:57 ` Jason Merrill 2010-02-19 17:02 ` Paolo Bonzini 2010-02-21 11:21 ` Paolo Carlini 2010-02-21 18:02 ` Dave Korn 2010-02-21 18:28 ` Martin Guy 2010-02-24 23:00 ` Jason Merrill 2010-02-25 7:07 ` Uros Bizjak 2010-02-25 10:37 ` Paolo Bonzini 2010-02-25 10:48 ` Paolo Bonzini 2010-02-25 23:14 ` Jason Merrill 2010-02-26 11:00 ` H.J. Lu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).