Even when these bugs can affect djgpp programs nobody found the bugs using djgpp, that's because some of them are very hard to hit. The number 10 was reported to the djgpp list.
Most of them are fixed in 2.8.0 so consider the upgrade.
-funroll-loops generates bad code in do-while statements using wrap-around exit conditions Ok 2.8.0
The scheduler for assigments of the compiler fails using -O under some complex situations (3 examples) Ok 2.8.0
The extentions to initialize structures naming the members fails Ok 2.8.0
The C++ front end compares (void *)array and (void *)&array as different values even when they are the same Ok 2.8.0
GCC fails to generate code for some struct definitions Ok 2.8.0
The && extention produces a silly error on some C++ code Ok 2.8.0
GCC generates code that can change your results just adding a line when optimizing Not considered a bug by FSF
When moving arithmetic outside loops GCC sometimes fails Ok 2.8.0
-O2 removes important boolean operations in some cases Ok 2.8.0
Internal error when parsing some C++ code In 2.8.0
Parameters passed as registers fails (regparm(3)) In 2.8.0/1
GCC reports wrong line numbers when you use multiline macros with strings. In 2.8.0/1
Description: -funroll-loops generates bad code in do-while statements using wrap-around exit conditions.
Example to test the bug:
Effect: The loop will never end (press ^Break to stop it), compiling with only -O2 works OK.
Detailed explanation: The code generated by GCC for this loop is:
Analized by SET.
GCC 2.8.0 Test:
Description: The scheduler for assigments of the compiler fails using -O under some complex situations.
Example 1 to test the bug:
Effect: GCC assigns a wrong value to SP[3] because he destroyed the right value when reordering the instructions. See comments in the source.
To test it better you can use a debugger and you'll see how gcc reorders the assigments and fails.
There are an unofitial patch for it.
Reported to bug-gcc by: Mikael Pettersson.
Example 2 to test the bug:
Effect: GCC assigns a wrong value to this.result. Compiling the code without -O the program outputs: 5555aaaa but with -O aaaaaaaa.
Detailed explanation: The code generated by GCC is:
Reported to bug-gcc by: Wim Colgate.
Analized by SET.
Example 3 to test the bug:
Effect: The first loop produces the right result just because the line bug_fix+=f; that forces to avoid the destruction of f. This time appears because of the -funroll-loops interference.
Reported to bug-gcc by: Uwe F. Mayer.
Description: The extentions to initialize structures naming the members fails.
Example to test the bug:
Detailed explanation:
GCC fails in the initialization:
Reported to bug-gcc by: Christof Petig.
GCC 2.8.0 Test:
Description: The C++ front end compares (void *)array and (void *)&array as different values even when they are the same.
Example to test the bug:
If you compile it in C you'll get the right answer, both values are equal so the ? : works OK. But if you compile it in C++ you'll get too equal values but the ? : says they are different.
Reported to bug-gcc by: Daniel W. Moore.
Adapted to be more explanatory by SET.
Description: GCC fails to generate code for some struct definitions.
Example to test the bug:
Description: The && extention produces a silly error on some C++ code.
Example to test the bug:
The && extention allows to GCC programs know the address of a C label. If the example is compiled in C it works fine, but in C++ reports:
Reported to bug-gcc by: Kevin P Lawton.
Description: GCC generates code that can change your results just adding a line when optimizing.
Example to test the bug:
Effect: Compiling with -O the returned value is different that without -O, uncommenting the code the result is like without -O.
Detailed explanation:
That's a result of what optimizations are turned on with -O, one of them is -fno-float-store, this switch produces code that process values in the internal 80 bits FPU format, adding more resolution. The problem here is that some code that depends on the resolution will be affected and behave different when -Ox is enabled. From my point of view (the same point of view of the reporter) this switch must not be on with -O. BTW -ffast-math isn't on because of similar problems.
Reported to bug-gcc by: Mans Karlberg.
Description: When moving arithmetic outside loops GCC sometimes fails
Example to test the bug:
Effect: Compiling with -O2 the output is wrong, the program reports x=340 and x=510 instead of 170 and 340.
Detailed explanation:
This bug is produced when GCC moves the multiplication outside the loop, it makes 170+17*t instead of 17*t. I guess is trying to make 17*t for one part and 170*(i+1) by other and when combinating the both things interfers.
Analized by SET.
Description: -O2 removes important boolean operations in some cases
Example to test the bug:
Effect: Compiling with -O2 the value returned by test_func is very wrong, in fact the not operation is removed.
Detailed explanation:
This bug is produced because GCC tries to reduce the number of operations for the other_tables calculation (in fact GCC reduces it to 0) but in the operation the not is lost.
Analized by SET.
Description: Parsing a member data pointer to a member function can produce an internal error
Example to test the bug:
Introduced in 2.8.0 is in 2.8.1 too
Description: When passign parameters as registers and calling functions through pointers gcc clobbers one of the parameters.
Example to test the bug:
Detailed explanation:
Looks like gcc choose the wrong register to make the call through a pointer, here is the assembler produced:
Introduced in 2.8.0 is in 2.8.1 too
Description: GCC changed the way to preprocess multiline strings, it produces wrong line number reports when you use multiline strings in a macro. Additionally it breaks some assembler programs.
Example to test the bug:
The strings aren't preprocessed letting this job to the compiler, here is the output produced by the preprocessor (gcc -V 2.8.1 -E /tmp/f.c):