| 1 |
"Boyd Stephen Smith Jr." <bss03@××××××××××.net> posted |
| 2 |
200609281452.44538.bss03@××××××××××.net, excerpted below, on Thu, 28 Sep |
| 3 |
2006 14:52:40 -0500: |
| 4 |
|
| 5 |
> If the code does not conform to the standard, the output of the compiler |
| 6 |
> is undefined. In particular, it is acceptable for the compiler produce |
| 7 |
> errors or produce a binary that crashes. The fault is with the code. |
| 8 |
> |
| 9 |
> If the code does conform to the standard, the behavior of the output of |
| 10 |
> the compiler is specified. In particular, subject to resource limitations |
| 11 |
> and hardware failure, the compile job must succeed and produce a binary |
| 12 |
> that, again subject to resources and hardware, does not crash and performs |
| 13 |
> the operations described in the source code. The fault is with the |
| 14 |
> compiler. |
| 15 |
|
| 16 |
See, that's the problem, we don't live in a perfect world, and neither the |
| 17 |
code nor the compiler are faultless. Additionally, it's well known that |
| 18 |
gcc is getting stricter (insisting the code hew closer to that standard |
| 19 |
you mentioned), so stuff that once worked fine now doesn't, and fancy new |
| 20 |
optimizations that cause code that again once worked fine to fail continue |
| 21 |
to appear. Since -O2 on a specific arch, with no further optimizations, |
| 22 |
tends to be the most commonly tested, and few if any "new" optimizations |
| 23 |
get invoked by it without at least a minor version span's testing first, |
| 24 |
that's the most solid choice for those who prefer to let others deal with |
| 25 |
all the "surprises". |
| 26 |
|
| 27 |
Fortunately, some of us like the challenge of surprises, however, and run |
| 28 |
these new optimizations, or it'd no longer be possible to widely test them |
| 29 |
and get the worst kinks worked out of both the code and the compiler |
| 30 |
optimizations before they could eventually be added to -O2 (or |
| 31 |
-O<whatever> as appropriate). There's nothing wrong with that, as long |
| 32 |
as one realizes the risks involved and is willing to put in the work |
| 33 |
necessary to overcome the obstacles when they popup. |
| 34 |
|
| 35 |
-- |
| 36 |
Duncan - List replies preferred. No HTML msgs. |
| 37 |
"Every nonfree program has a lord, a master -- |
| 38 |
and if you use the program, he is your master." Richard Stallman |
| 39 |
|
| 40 |
-- |
| 41 |
gentoo-amd64@g.o mailing list |
Archives