Re: buggy optimization levels...
On 01.08.2003 05:00, Erik Trulsson wrote: On Thu, Jul 31, 2003 at 10:30:57PM -0400, Chuck Swiger wrote: [...] problem of compiling the system with cc -O2 resulting in a buggy kernel. If you determine that compiling with cc -O -fgcse results in failures, [...] There is an open bug report in gcc belonging to gcse: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11741 You may create another report with your own research results or notify the gcc people to fix your problem when fixing optimization/11741, too. Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy optimization levels...
Erik Trulsson wrote: On Sat, Aug 02, 2003 at 03:52:25PM -0400, Chuck Swiger wrote: [ ... ] That wasn't my real point anyway. I was trying to refute your statement that Even if the code contains a bug, cc -O and cc -O -fgcse should produce the same results. I claim that if the code has a bug that results in undefined behaviour then the compiler is allowed to produce different results when invoked with different optimization flags. If the code being compiled has a bug that results in undefined behavior, the compiler is allowed to produce different results when invoked with different optimization flags. While true, that doesn't refute my statement: what the compiler is allowed to do, and what the compiler should do, is required not to diverge for code which does not involve undefined behavior. [ ... ] Page 586 of _Compilers: Principles, Techniques, and Tools_ states: First, a transformation must preserve the meaning of programs. That is, an optimization must not change the output produced by a program for a given input, or cause an error, such as a division by zero, that was not present in the original program. The influence of this criterion prevades this chapter; at all times we take the safe approach of missing an opportunity to apply a transformation rather than risk changing what the program does. -- Like your divide-by-zero example above, or this paragraph about semantics vs meaning, I'm not going to disagree if you want to state that the running time of a program is part of the behavior. However, using the terms in such a fashion precludes you from understanding the intended meaning in this particular context. I understand the intended meaning. I just don't agree completely with your reasoning. I would say that the compiler is not allowed to *introduce* errors, or to change the meaning of *correct* programs. So far, so good. (Correct here essentially meaning programs that do not invoke undefined behaviour.) For programs that do not have a defined 'meaning' the compiler is free to do anyting. This is wrong. The fact that integer divide-by-zero by not defined by ANSI C (C89, et al), means the following program does not have well-defined behavior: int main() { return 120 / 0; } ...however, what happens if you remove the semicolon after the zero? That results in a syntax error, and the compiler is _not_ free to do anything it likes in such a case: it is required to identify the syntax error in code which fails to parse by issuing an error message: d.c: In function `main': d.c:3: syntax error before `}' There is more to the point just above than just identifying syntax errors. If you have 5 input source files (call them translation units), of which four are valid code, and the fifth contains an error resulting in undefined behavior, the compiler is required to compile four of the five source files in a well-defined fashion. One can repeat that analysis for code within the fifth input source file: if you moved only the function containing the bug/undefined code to a sixth file, one would discover that the compiler will handle the rest of the code in that file in a well-defined fashion. One could repeat the analysis yet again, using units known as basic blocks, which may either be a single intermediate code instruction (that's intermediate code within the AST, not the input source code), or a sequence of instructions terminated by a flow-of-control instruction like a branch, return from subroutine, memory protection/barrier commands, etc. If a compiler was not allowed to change the result of running a program having undefined behaviour when compiled with different optimization flags, then this would preclude doing just about any optimization. No, it would not. Code optimization consists of transformations to the AST based on algebraic invariants, liveness analysis used by CSE and dead-code removal, loop invariants, and other techniques which are universal (platform-independant), as well as register allocation, peephole analysis, and other transformations to the target code which are platform-specific. What happens to source code with undefined semantics isn't particularly useful to the person writing compiler: valid optimization techniques are required to not change the meaning of any possible well-defined input source code, so being able to behave differently in the case of undefined semantics doesn't help. I am fairly certain that for *all* the specific optimizations available in gcc it is possible to find *some* program that will give different results depending on if that optimization ws used or not. Are you claiming that every specific optimization available in gcc contains bugs? :-) If one were to accept your claims that the compiler should not perform any optimizations that could change the behaviour any program, then it would not be able to do any optimization at all, which is clearly not a desirable situation. It is entirely possible to
Re: buggy optimization levels...
Erik Trulsson wrote: On Thu, Jul 31, 2003 at 10:30:57PM -0400, Chuck Swiger wrote: [ ... ] I understand that figuring out why the kernel died can be hard, particularly if the failures aren't concise and completely reproducable, and thus tracing the problem back to making the right change to gcc to fix the optimization that caused the observed failure is thus also hard. Note that it is not necessarily gcc which is at fault for such failures. It may be a bug in gcc, but it may also be a bug in the code being compiled that has a bug that only shows up under higher optimization levels. The latter is probably somewhat more common actually. Does the last comment mean that you can provide at least one example of code which behaves differently when compiled with cc -O versus cc -O2? Otherwise, what does more common mean in the context of zero examples? [ ... ] ...and makes it so that -O2, -O3, etc does not enable GCSE optimization. But if the bug is not in gcc but in the code being compiled (and which only happens to show up when compiled with GCSE optimization) Even if the code contains a bug, cc -O and cc -O -fgcse should produce the same results. Excluding certain well-defined exceptions (-ffast-math comes to mind), compiler optimizations likes -fgcse are not allowed to change the meaning of compiled code, do we agree? ...such a patch would disable this optimization for correct code also even though it is not necessary there. Such a patch would disable the optimization for all cases. If there exists any lexically correct input source code (ie, which parses validly) where compiling with -fgcse results in different behavior, that optimization is unsafe and should not be enabled by -O2 in any circumstance. -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy optimization levels...
Kris Kennaway wrote: [ ... ] This is the trivial part (you don't even need to modify gcc, because all the optimizations turned on by -Ofoo are also available as individual -fblah options). Indeed. If you've forgotten, I quoted the section of the gcc source code which indicates which individual -fblah options are enabled at -O1, -O2, -O3. As I've already said, once you have a self-contained test-case that demonstrates that a particular gcc optimization level generates broken code, the gcc people will fix it. Yes, I hope and believe they would. If you've also forgotten the origin of this thread, it was: | The known bugs section of the GCC info documentation lists 5 issues; man | gcc lists none. Can someone provide a test case for a bug involving cc -O | versus cc -O3 under FreeBSD 4-STABLE for the x86 architecture? One might (reasonably and correctly) conclude that I was asking for examples of such test-cases. -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy optimization levels...
On Sat, Aug 02, 2003 at 12:19:06PM -0400, Chuck Swiger wrote: Erik Trulsson wrote: On Thu, Jul 31, 2003 at 10:30:57PM -0400, Chuck Swiger wrote: [ ... ] I understand that figuring out why the kernel died can be hard, particularly if the failures aren't concise and completely reproducable, and thus tracing the problem back to making the right change to gcc to fix the optimization that caused the observed failure is thus also hard. Note that it is not necessarily gcc which is at fault for such failures. It may be a bug in gcc, but it may also be a bug in the code being compiled that has a bug that only shows up under higher optimization levels. The latter is probably somewhat more common actually. Does the last comment mean that you can provide at least one example of code which behaves differently when compiled with cc -O versus cc -O2? Otherwise, what does more common mean in the context of zero examples? If you want real world examples you can trawl through the mailing list archives. I am sure you can find at least a few examples if you look hard enough. (Searching through list archives is not so fun that I will do it myself unless there is something that *I* want to know.) A somewhat contrived example that behaves differently when compiled with -O3 or when compiled with -O2 or lower optimization follows: static int f(int a) { return a/0; } int main(void) { int x; x = f(5); return 0; } Compiling this with -O2 or lower and running the program will result in the program crashing. Compiled with -O3 the program just exits cleanly. (FreeBSD 4.8-stable ; gcc 2.95.4) (The code compiles just fine withouth warnings in either case even when compiled with -ansi -pedantic -Wall) Since there is a bug (division by zero) in the program that invokes undefined behaviour either result is perfectly acceptable, and the difference is not due to a bug in gcc, but due to a bug in my program. (The reason for the different behaviour is that -O3 turns on inlining of functions, and when the call to f() has been inlined gcc is able to determine that the call has no side-effects that need to be preserved, and since the result of the call is never used after being assigned to x the whole line 'x = f(5);' can safely be removed. When compiled with -O2 or lower the compiler is not able to determine that the call to f() can be omitted and therefore f() will be called.) [ ... ] ...and makes it so that -O2, -O3, etc does not enable GCSE optimization. But if the bug is not in gcc but in the code being compiled (and which only happens to show up when compiled with GCSE optimization) Even if the code contains a bug, cc -O and cc -O -fgcse should produce the same results. Excluding certain well-defined exceptions (-ffast-math comes to mind), compiler optimizations likes -fgcse are not allowed to change the meaning of compiled code, do we agree? Not quite. Compiler optimization flags (with a few exceptions like -ffast-math) are not allowed to change the semantics of the compiled code. For buggy code that invokes undefined behaviour (divison by zero, accessing unallocated memory, etc.) there is no semantics to preserve and therefore the compiled code may well produce different results when compiled with different flags. (Undefined behaviour in the context of the C standard means the compiler is allowed to do whatever it damn well pleases, including, but not limited to, doing what you wanted and expected it to do, formatting your harddisk or making demons fly out of your nose. ...such a patch would disable this optimization for correct code also even though it is not necessary there. Such a patch would disable the optimization for all cases. If there exists any lexically correct input source code (ie, which parses validly) where compiling with -fgcse results in different behavior, that optimization is unsafe and should not be enabled by -O2 in any circumstance. With that definition just about *all* optimizations would be unsafe. (And optimization is actually *supposed* to give different behaviour. The running time of a program is part of its behaviour and optimization is generally supposed to reduce the running time, thereby giving different behaviour.) -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy optimization levels...
Erik Trulsson wrote: [ ... ] A somewhat contrived example that behaves differently when compiled with -O3 or when compiled with -O2 or lower optimization follows: static int f(int a) { return a/0; } int main(void) { int x; x = f(5); return 0; } Contrived, but interesting and useful nonetheless; thanks for the response. [ ... ] Even if the code contains a bug, cc -O and cc -O -fgcse should produce the same results. Excluding certain well-defined exceptions (-ffast-math comes to mind), compiler optimizations likes -fgcse are not allowed to change the meaning of compiled code, do we agree? Not quite. Compiler optimization flags (with a few exceptions like -ffast-math) are not allowed to change the semantics of the compiled code. I really don't want to debate the use of meaning versus semantics. :-) For buggy code that invokes undefined behaviour (divison by zero, accessing unallocated memory, etc.) there is no semantics to preserve and therefore the compiled code may well produce different results when compiled with different flags. C code that permits a divide-by-zero condition will result in a runtime error, but I disagree that this has no semantics to preserve. If the code was using floating point, IEEE 754 defines semantics for divide-by-zero one could also have an 'Infinity' result, but that's not available with ints; your code results in a SIGFPE being generated. (Undefined behaviour in the context of the C standard means the compiler is allowed to do whatever it damn well pleases, including, but not limited to, doing what you wanted and expected it to do, formatting your harddisk or making demons fly out of your nose. Sure. I see and acknowledge the validity of your point: it's possible for a programmer to write code which has different behavior depending on (say) -finline-functions. However, that being said, the fact that the C standard says such-and-such gives undefined behavior does not preclude the implementation from defining the behavior for such-and-such. If there exists any lexically correct input source code (ie, which parses validly) where compiling with -fgcse results in different behavior, that optimization is unsafe and should not be enabled by -O2 in any circumstance. With that definition just about *all* optimizations would be unsafe. (And optimization is actually *supposed* to give different behaviour. The running time of a program is part of its behaviour and optimization is generally supposed to reduce the running time, thereby giving different behaviour.) What you say is so obviously correct that one should instead conclude that my use of the term 'behavior' with regard to compiler optimizations has a more specific meaning. Page 586 of _Compilers: Principles, Techniques, and Tools_ states: First, a transformation must preserve the meaning of programs. That is, an optimization must not change the output produced by a program for a given input, or cause an error, such as a division by zero, that was not present in the original program. The influence of this criterion prevades this chapter; at all times we take the safe approach of missing an opportunity to apply a transformation rather than risk changing what the program does. -- Like your divide-by-zero example above, or this paragraph about semantics vs meaning, I'm not going to disagree if you want to state that the running time of a program is part of the behavior. However, using the terms in such a fashion precludes you from understanding the intended meaning in this particular context. -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy optimization levels...
On Sat, Aug 02, 2003 at 03:52:25PM -0400, Chuck Swiger wrote: Erik Trulsson wrote: [ ... ] A somewhat contrived example that behaves differently when compiled with -O3 or when compiled with -O2 or lower optimization follows: static int f(int a) { return a/0; } int main(void) { int x; x = f(5); return 0; } Contrived, but interesting and useful nonetheless; thanks for the response. Real world examples tend to be a bit more complicated and difficult to detect, but this was the best I could come up with on short notice, and it should not be too different in kind from bugs that can actually occur. [ ... ] Even if the code contains a bug, cc -O and cc -O -fgcse should produce the same results. Excluding certain well-defined exceptions (-ffast-math comes to mind), compiler optimizations likes -fgcse are not allowed to change the meaning of compiled code, do we agree? Not quite. Compiler optimization flags (with a few exceptions like -ffast-math) are not allowed to change the semantics of the compiled code. I really don't want to debate the use of meaning versus semantics. :-) That wasn't my real point anyway. I was trying to refute your statement that Even if the code contains a bug, cc -O and cc -O -fgcse should produce the same results. I claim that if the code has a bug that results in undefined behaviour then the compiler is allowed to produce different results when invoked with different optimization flags. For buggy code that invokes undefined behaviour (divison by zero, accessing unallocated memory, etc.) there is no semantics to preserve and therefore the compiled code may well produce different results when compiled with different flags. C code that permits a divide-by-zero condition will result in a runtime error, but I disagree that this has no semantics to preserve. If the It hasn't any semantics to preserve. There is no guarantee that a division-by-zero will result in a runtime error. The C standard defines what the semantics (or meaning if you prefer) of a C programs is. For code that executes an integer division-by-zero it is not defined what the program should do. Therefore *any* result that occurs from running the code is conforming to the standard. If you believe differently please tell me what that program *should* do when run. (Without making any assumptions about which compiler, OS or hardware is being used.) code was using floating point, IEEE 754 defines semantics for divide-by-zero one could also have an 'Infinity' result, but that's not available with ints; your code results in a SIGFPE being generated. My code results in a SIGFPE when compiled with gcc on FreeBSD using a certain set of flags. I am sure that if you try it with other compilers, or on other operating systems you will see different results. (If you were to run it under AmigaOS, for example, you would probably get a system crash with an error code indicating an integer division-by-zero. Other systems might well just ignore such a division.) Programs that have undefined behaviour will very often behave differently when compiled with different compilers, so the fact that one compiler invoked with different flags will give different results is not surprising. (Undefined behaviour in the context of the C standard means the compiler is allowed to do whatever it damn well pleases, including, but not limited to, doing what you wanted and expected it to do, formatting your harddisk or making demons fly out of your nose. Sure. I see and acknowledge the validity of your point: it's possible for a programmer to write code which has different behavior depending on (say) -finline-functions. However, that being said, the fact that the C standard says such-and-such gives undefined behavior does not preclude the implementation from defining the behavior for such-and-such. Of course it doesn't preclude that, but few implementations actually does define what the behaviour will be for such cases, and code depending on such implementation-specific behaviour is highly non-portable anyway. If there exists any lexically correct input source code (ie, which parses validly) where compiling with -fgcse results in different behavior, that optimization is unsafe and should not be enabled by -O2 in any circumstance. With that definition just about *all* optimizations would be unsafe. (And optimization is actually *supposed* to give different behaviour. The running time of a program is part of its behaviour and optimization is generally supposed to reduce the running time, thereby giving different behaviour.) What you say is so obviously correct that one should instead conclude that my use of the term 'behavior' with regard to compiler optimizations has a more specific meaning. Generally yes. (Of course people involved with hard real-time systems will probably be very interested in how optimizations
Re: buggy optimization levels...
Chuck Swiger [EMAIL PROTECTED] writes: Hi, all-- The known bugs section of the GCC info documentation lists 5 issues; man gcc lists none. You are looking in the 'wrong' place for 'known bugs' (Or the GCC people aren't putting the info in the 'right' place :-) http://gcc.gnu.org/bugzilla/ Is where to look for known bugs. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy optimization levels...
On Mon, Jul 14, 2003 at 05:37:45PM -0400, Chuck Swiger wrote: Hi, all-- The known bugs section of the GCC info documentation lists 5 issues; man gcc lists none. Can someone provide a test case for a bug involving cc -O versus cc -O3 under FreeBSD 4-STABLE for the x86 architecture? Probably not, or it would have already been fixed. The warning against using FreeBSD with settings higher than -O1 (== -O) is because it often causes bugs that are difficult to track down (e.g. some aspect of the kernel just doesn't work properly). Kris pgp0.pgp Description: PGP signature
Re: buggy optimization levels...
Kris Kennaway wrote: On Mon, Jul 14, 2003 at 05:37:45PM -0400, Chuck Swiger wrote: The known bugs section of the GCC info documentation lists 5 issues; man gcc lists none. Can someone provide a test case for a bug involving cc -O versus cc -O3 under FreeBSD 4-STABLE for the x86 architecture? Probably not, or it would have already been fixed. Hopefully so, as the compiler toolchain is important. :-) The warning against using FreeBSD with settings higher than -O1 (== -O) is because it often causes bugs that are difficult to track down (e.g. some aspect of the kernel just doesn't work properly). OK. Can the existence of such problems be confirmed reliably, say by regression testing? /usr/src/contrib/gcc/toplev.c is clear enough which specific optimizations are involved at the different number levels: if (optimize = 1) { flag_defer_pop = 1; flag_thread_jumps = 1; #ifdef DELAY_SLOTS flag_delayed_branch = 1; #endif #ifdef CAN_DEBUG_WITHOUT_FP flag_omit_frame_pointer = 1; #endif } if (optimize = 2) { flag_cse_follow_jumps = 1; flag_cse_skip_blocks = 1; flag_gcse = 1; flag_expensive_optimizations = 1; flag_strength_reduce = 1; flag_rerun_cse_after_loop = 1; flag_rerun_loop_opt = 1; flag_caller_saves = 1; flag_force_mem = 1; #ifdef INSN_SCHEDULING flag_schedule_insns = 1; flag_schedule_insns_after_reload = 1; #endif flag_regmove = 1; } if (optimize = 3) { flag_inline_functions = 1; } Couldn't one compile with cc -O -finline-functions, and then iterate through -fcse-follow-jumps, -fgcse, etc and see which optimizations are safe? -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy optimization levels...
On Thu, Jul 31, 2003 at 09:34:17PM -0400, Chuck Swiger wrote: OK. Can the existence of such problems be confirmed reliably, say by regression testing? The problem is in identifying precisely which piece of code is failing. A regression test is only useful if it concisely exercises a specific set of tests. As I said, in theory any optimization problems can be tracked down to the failure of a certain piece of code, but in something as large as the kernel it is not usually easy. Kris pgp0.pgp Description: PGP signature
Re: buggy optimization levels...
Kris Kennaway wrote: On Thu, Jul 31, 2003 at 09:34:17PM -0400, Chuck Swiger wrote: OK. Can the existence of such problems be confirmed reliably, say by regression testing? The problem is in identifying precisely which piece of code is failing. A regression test is only useful if it concisely exercises a specific set of tests. As I said, in theory any optimization problems can be tracked down to the failure of a certain piece of code, but in something as large as the kernel it is not usually easy. Ah, my apologies-- I believe I see where the confusion lies. I understand that figuring out why the kernel died can be hard, particularly if the failures aren't concise and completely reproducable, and thus tracing the problem back to making the right change to gcc to fix the optimization that caused the observed failure is thus also hard. Fine. However, you don't _need_ to identify the reason why the kernel died, or solve the bug in global common expression elimination to solve the problem of compiling the system with cc -O2 resulting in a buggy kernel. If you determine that compiling with cc -O -fgcse results in failures, one does: --- toplev.c_oldThu Jul 31 22:23:22 2003 +++ toplev.cThu Jul 31 22:24:01 2003 @@ -4916,7 +4916,6 @@ { flag_cse_follow_jumps = 1; flag_cse_skip_blocks = 1; - flag_gcse = 1; flag_expensive_optimizations = 1; flag_strength_reduce = 1; flag_rerun_cse_after_loop = 1; ...and makes it so that -O2, -O3, etc does not enable GCSE optimization. -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy optimization levels...
On Thu, Jul 31, 2003 at 10:30:57PM -0400, Chuck Swiger wrote: Kris Kennaway wrote: On Thu, Jul 31, 2003 at 09:34:17PM -0400, Chuck Swiger wrote: OK. Can the existence of such problems be confirmed reliably, say by regression testing? The problem is in identifying precisely which piece of code is failing. A regression test is only useful if it concisely exercises a specific set of tests. As I said, in theory any optimization problems can be tracked down to the failure of a certain piece of code, but in something as large as the kernel it is not usually easy. Ah, my apologies-- I believe I see where the confusion lies. I understand that figuring out why the kernel died can be hard, particularly if the failures aren't concise and completely reproducable, and thus tracing the problem back to making the right change to gcc to fix the optimization that caused the observed failure is thus also hard. Note that it is not necessarily gcc which is at fault for such failures. It may be a bug in gcc, but it may also be a bug in the code being compiled that has a bug that only shows up under higher optimization levels. The latter is probably somewhat more common actually. Fine. However, you don't _need_ to identify the reason why the kernel died, or solve the bug in global common expression elimination to solve the problem of compiling the system with cc -O2 resulting in a buggy kernel. If you determine that compiling with cc -O -fgcse results in failures, one does: --- toplev.c_oldThu Jul 31 22:23:22 2003 +++ toplev.cThu Jul 31 22:24:01 2003 @@ -4916,7 +4916,6 @@ { flag_cse_follow_jumps = 1; flag_cse_skip_blocks = 1; - flag_gcse = 1; flag_expensive_optimizations = 1; flag_strength_reduce = 1; flag_rerun_cse_after_loop = 1; ...and makes it so that -O2, -O3, etc does not enable GCSE optimization. But if the bug is not in gcc but in the code being compiled (and which only happens to show up when compiled with GCSE optimization) such a patch would disable this optimization for correct code also even though it is not necessary there. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy optimization levels...
On Thu, Jul 31, 2003 at 10:30:57PM -0400, Chuck Swiger wrote: Fine. However, you don't _need_ to identify the reason why the kernel died, or solve the bug in global common expression elimination to solve the problem of compiling the system with cc -O2 resulting in a buggy kernel. If you determine that compiling with cc -O -fgcse results in failures, one does: This is the trivial part (you don't even need to modify gcc, because all the optimizations turned on by -Ofoo are also available as individual -fblah options). As I've already said, once you have a self-contained test-case that demonstrates that a particular gcc optimization level generates broken code, the gcc people will fix it. Kris pgp0.pgp Description: PGP signature
buggy optimization levels...
Hi, all-- The known bugs section of the GCC info documentation lists 5 issues; man gcc lists none. Can someone provide a test case for a bug involving cc -O versus cc -O3 under FreeBSD 4-STABLE for the x86 architecture? What is the preferred solution? The Dragon book and other compiler references have a definition of safe versus unsafe optimizations; is the problem that -O3 enables something unsafe? Who is responsible (FreeBSD, GNU compiler team, others?) for changing the compiler defaults so that -Ox will not produce known-invalid results, for any x? -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy optimization levels...
Chuck Swiger [EMAIL PROTECTED] writes: Hi, all-- The known bugs section of the GCC info documentation lists 5 issues; man gcc lists none. Can someone provide a test case for a bug involving cc -O versus cc -O3 under FreeBSD 4-STABLE for the x86 architecture? You could probably find a few by searching the bug data base at: http://gcc.gnu.org/bugzilla/ What is the preferred solution? The Dragon book and other compiler references have a definition of safe versus unsafe optimizations; is the problem that -O3 enables something unsafe? I believe that none of -O[0-3s] are intended to enable unsafe optimizations. (There are some optimization flags, which are *not* enabled by any -O opt, like -ffast-math, which are documented to be unsafe in some fashion or another; see http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Optimize-Options.html#Optimize%20Options) Who is responsible (FreeBSD, GNU compiler team, others?) for changing the compiler defaults so that -Ox will not produce known-invalid results, for any x? [snip] If gcc produces invalid results or bad code at any optimization level, I think you should report it as a bug according to the instructions at http://gcc.gnu.org/bugs.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]