https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
Bug ID: 99621
Summary: [5-11 REGRESSION] [bisected to
058e97ecf33ad0dfd926b3876a4bcf59ac9556ff] regression
with -m32 -O1 -fcaller-saves -fexpensive-optimizations
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: williambader at hotmail dot com
Target Milestone: ---
Created attachment 50402
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50402&action=edit
C program processed by creduce and reformatted
gcc generates incorrect code with -m32 -O1 -fcaller-saves
-fexpensive-optimizations.
It happens in the current git master (which is gcc 11) but dates back to gcc 4.
I have a function in a large program that parses postscript.
Adding any debug printfs or even a call to an empty function in another
compilation module fixes it.
I tracked it down to a combination of -m32 -O1 -fcaller-saves
-fexpensive-optimizations.
I made a small test and used it to do a gcc bisection.
The bisection found 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff , which is 16192
lines long. The commit makes heavy changes to gcc/caller-save.c, which is
probably the problem because the bug requires -fcaller-saves (one of the
optimizations included in -O2) and because adding a call to an empty function
makes it work.
I ran the test program through creduce, and that is what I am posting, along
with a data file that it reads.
In the full program, when I compile with the options to trigger the problem
plus -S with and without an extra function call and then compare the results, I
get
--- bad.s 2021-03-15 20:06:27.701846497 +0000
+++ good.s 2021-03-15 20:06:18.305695766 +0000
@@ -2068,8 +2068,10 @@
jne .L570
fstp %st(0)
.L197:
+ fstpl -13440(%ebp)
+ call gcc_bug_fix
fldl -13512(%ebp)
- fxch %st(1)
+ fldl -13440(%ebp)
fucomi %st(1), %st
fstp %st(1)
jp .L198
It looks like it does the same thing, but I haven't written Intel assembly
since MSDOS days.
Both good and bad compilations run clean with valgrind and with
bounds-checking-gcc-4.0.4. I also get the expected good results with clang.
The strangest part is that a bad executable gets good results under valgrind.
