[Bug c/99621] New: [5-11 REGRESSION] [bisected to 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff] regression with -m32 -O1 -fcaller-saves -fexpensive-optimizations

[Bug c/99621] New: [5-11 REGRESSION] [bisected to 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff] regression with -m32 -O1 -fcaller-saves -fexpensive-optimizations

[williambader at hotmail dot com]

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.

[Bug rtl-optimization/99621] [5-11 REGRESSION] [bisected to 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff] regression with -m32 -O1 -fcaller-saves -fexpensive-optimizations

[williambader at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #1 from William Bader <williambader at hotmail dot com> ---
Created attachment 50403
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50403&action=edit
Data file that the test program reads.

postscript test file compressed with bzip2.
It needs to be uncompresses.
The test program has the filename hard-coded in one of the last lines.
The test program does not take any command line options.

[Bug target/99621] [8,9,10,11 REGRESSION] [bisected to 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff] regression with -m32 -O1 -fcaller-saves -fexpensive-optimizations

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[5-11 REGRESSION] [bisected |[8,9,10,11 REGRESSION]
                   |to                          |[bisected to
                   |058e97ecf33ad0dfd926b3876a4 |058e97ecf33ad0dfd926b3876a4
                   |bcf59ac9556ff] regression   |bcf59ac9556ff] regression
                   |with -m32 -O1               |with -m32 -O1
                   |-fcaller-saves              |-fcaller-saves
                   |-fexpensive-optimizations   |-fexpensive-optimizations
   Target Milestone|---                         |8.5

[Bug target/99621] [8/9/10/11 REGRESSION] [bisected to 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff] regression with -m32 -O1 -fcaller-saves -fexpensive-optimizations

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-03-17
           Assignee|unassigned at gcc dot gnu.org      |marxin at gcc dot gnu.org
                 CC|                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed. I'm trying to simplify the test-case..

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8/9/10/11 REGRESSION]      |[8/9/10/11 Regression]
                   |[bisected to                |Wrong code with -m32 -O1
                   |058e97ecf33ad0dfd926b3876a4 |-fcaller-saves
                   |bcf59ac9556ff] regression   |-fexpensive-optimizations
                   |with -m32 -O1               |since
                   |-fcaller-saves              |g:058e97ecf33ad0dfd926b3876
                   |-fexpensive-optimizations   |a4bcf59ac9556ff
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
I just removed all the warnings that were reported:

#include <stdio.h>
int a = 12243, g, ad, o, p;
enum { b = 8 };
typedef struct {
  int data_len;
} d;
double e;
struct j ak;
struct j am_sj;
d main_breaks_blob;
double q(char *aa, int *ab, int c) {
  double n;
  int i = *ab;
  g = 1;
  if (aa[i] == '-') {
    g = -1;
    i++;
  }
  n = 0;
  while (aa[i] >= '0') {
    n = n * 10 + aa[i] - '0';
    i++;
  }
  if (aa[i] == '.')
    i++;
  e = 1.0;
  while (aa[i] >= '0') {
    e *= 10;
    n += (aa[i] - '0') / e;
    i++;
  }
  n *= g;
  *ab = i;
  return n;
}
struct j {
  FILE *k;
} l(d *m, int r) {
  int ae = 1;
  ad = r;
  while (ad >= 10) {
    ae++;
    ad /= 10;
  }
  m->data_len += ae;
  m->data_len++;
}
void af(char *aa, int ag, int ah, double *ai, int aj) {
  for (; p < ah; p++) {
    double n = 0;
    o++;
    while (aa[o] >= '0') {
      n = n * 10 + aa[o] - '0';
      o++;
    }
    ai[p] = n;
  }
}
void am(char *an, d *m) {
  int ao, ap, aq, ac, ag, ab, aw;
  double ar, as, at, au, av;
  char aa[8192];
  struct j *ay, *f = &am_sj;
  FILE *az;
  char *ba = an;
  f->k = fopen(ba, "r");
  ak = *f;
  ay = &ak;
  az = ay->k;
  m->data_len = b + 1;
  while (aw != EOF) {
    ag = 0;
    while (aw != '\r' && ag < 92) {
      aa[ag++] = aw;
      aw = getc(az);
    }
    while (aw == '\n' || aw == '\r')
      aw = getc(az);
    if (__builtin_strncmp(aa, "%%HiResBoundingBox", 9) == 0) {
      int i;
      double ai[4];
      i = 19;
      af(&aa[i], i, 4, ai, 0);
      ar = ai[3];
    }
    ab = 0;
    int bb;
    double bc, bd;
    bb = 0;
    if (aa[ab] == 'g')
      bb = ab = 2;
    bc = q(aa, &ab, ac);
    ab++;
    bd = q(aa, &ab, ac);
    ab++;
    if (bb)
      au += bc;
    if (!as && __builtin_memcmp(&aa[ab], "1 dup neg S t", 3) == 0) {
      as = au = bc;
      av = bd;
    }
    if (aa[ab] == 'm' && aw == '<') {
      bc += au;
      bd += av + ar;
      if (bd > at || bc > a * 72 / 7227) {
        double be;
        int bf = bd < at;
        be = bd;
        if (bd - at < 2)
          be += 8;
        if (bf)
          aq += ap;
        at = bd;
        ap = be;
        ao = (aq + be) * 7227 / 72;
        l(m, ao);
      }
    }
  }
}
int main() {
  am("4329652-1.eps", &main_breaks_blob);
  printf("%d %s\n", main_breaks_blob,
         main_breaks_blob.data_len == 5167 ? "bug" : "ok");
}

Leaving that to Vlad.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Are you sure this just isn't an excess precision problem in all the floating
point calculations?
-mfpmath=sse -msse2 makes it go away, -fexcess-precision=standard too.
Why is 5167 bad but both 4806 and 5749 I'm getting with other options are good?
When I try it on with -m64, at -O0 I get 7019, at -O1 and higher 4806.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #5 from William Bader <williambader at hotmail dot com> ---
`gcc -S -m32 -O2 bfinal-format.c` with Fedora 32 gcc 10.2.1 gives a section
similar to one in my first comment. In particular, it calls fucomi "floating
unordered compare of st(0) and st(i)" and then fstp "floating store of st(0)
and then pop fpu 
 stack". fstp can change the condition registers set by fucomi. It sets C1 for
stack underflow, and its actions on C0, C2, and C3 are undefined. Does every
place that generates fstp in config/i386/i386.c know that it can modify the C
flags? Maybe the bad executable still works correctly in valgrind because
valgrind's emulation of fstp doesn't trash the C flags.
.L42:
        testl   %esi, %esi
        je      .L43
        fldl    8(%esp)
        faddl   (%esp)
        fstpl   8(%esp)
.L43:
        fldz
        fldl    16(%esp)
        fucomi  %st(1), %st 
        fstp    %st(1)
        jp      .L105
        jne     .L106

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
fucomi sets %eflags in addition to some effects on c[0-3] in FPU flags, fstp
has some effects on c[0-3] in FPU flags.  Nothing in the program really cares
about the FPU flags.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #7 from William Bader <williambader at hotmail dot com> ---
>Are you sure this just isn't an excess precision problem in all the floating point calculations?


I am pretty sure that it isn't a precision problem because the original program
is parsing numbers from postscript, and they are all in a reasonable range
between 0 and 3000 with at most 4 decimal places.

>-mfpmath=sse -msse2 makes it go away, -fexcess-precision=standard too.
>Why is 5167 bad but both 4806 and 5749 I'm getting with other options are good?


The original program makes list with the starting Y position of each line.
The buffer ends up 4287 when it runs correctly and 5167 when it fails.

I cut the program down with creduce, targeting 5167.
creduce eliminated the saves of Y position to the buffer.


I don't think that it is a precision problem because the output would still
work if it was off by a little bit.

Also, the original program works correctly with -m32 and -m64 with various
options and with clang with various options. If fails only with gcc -m32 -O2. A
precision problem would probably give different results with different
optimization levels, different architectures, or different compilers. Also, the
original program has an #if that calls an empty function. Enabling that call
makes it work with gcc -m32 -O2. I think that is a strong sign that it is not a
precision error.

If you want, I can post the program before I fed it to creduce. It is 962 lines
and is human-readable.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #8 from William Bader <williambader at hotmail dot com> ---
Created attachment 50404
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50404&action=edit
example program before creduce

This is the example that I cut from a much larger module. The problematic area
is around the line `#if DBUG_FIX`.

$ rm a.out ; gcc -Wall -O9 gcc-bug1-init.c ; a.out # ok in m64
len 4287, good
$ rm a.out ; gcc -m32 -Wall -O9 gcc-bug1-init.c ; a.out # fails in m32 -O9
len 5167, expected bad
$ rm a.out ; gcc -m32 -Wall -O0 gcc-bug1-init.c ; a.out # ok in m32 -O0
len 4287, good
$ rm a.out ; gcc -m32 -Wall -O9 -DBUG_FIX=1 gcc-bug1-init.c gcc-bug1b.c ; a.out
# ok in m32 -O9 calling an empty function
gcc-bug1-init.c: In function ‘find_ad_image_breaks’:
gcc-bug1-init.c:756:4: warning: implicit declaration of function ‘gcc_bug_fix’
[-Wimplicit-function-declaration]
  756 |    gcc_bug_fix();
      |    ^~~~~~~~~~~
len 4287, good
$ cat gcc-bug1b.c 
void gcc_bug_fix(void) { }
$ rm a.out ; clang -m32 -Wall -O3 gcc-bug1-init.c ; a.out # ok in clang
gcc-bug1-init.c:154:19: warning: illegal character encoding in string literal
[-Winvalid-source-encoding]
      memcmp(buf, COREL_HEADER_STRING, COREL_HEADER_STRING_LEN) != 0) {
                  ^~~~~~~~~~~~~~~~~~~
gcc-bug1-init.c:130:30: note: expanded from macro 'COREL_HEADER_STRING'
#define COREL_HEADER_STRING     "<C5><D0><D3><C6>"          /* start of header
*/
                                 ^~~~~~~~~~~~~~~~
1 warning generated.
len 4287, good
$ uname -a
Linux laptop 5.10.22-100.fc32.x86_64 #1 SMP Tue Mar 9 17:40:24 UTC 2021 x86_64
x86_64 x86_64 GNU/Linux
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) (GCC)

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to William Bader from comment #8)
> Created attachment 50404 [details]
> example program before creduce

I modified the file to:
  find_ad_image_breaks("123", "4329652-1.eps", 0, 0, &breaks_blob,

but I see the following:
$ gcc pr99621-2.c && ./a.out 
len 9, unknown bad

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #10 from William Bader <williambader at hotmail dot com> ---
The program before creduce has debug code. Setting the variable to print the
debug code makes the program work. Usually for something like this, I would put
in debug code and see where the good and bad versions first differ, but that
doesn't work because any call to an external function (even to an empty
function) makes the program work. That is why I first suspected it was related
to -fcaller-saves.
In MSDOS days, stdio data was often in low memory, and null pointer references
would sometimes get into stdio buffers, and adding a printf would keep it from
doing damage, but I do not think that is the case with this program because
just calling a an empty function makes it work. Also, the program runs cleanly
in valgrind, gcc -fsanitize=undefined, and bounds-checking-gcc
http://williambader.com/bounds/example.html 
and neither gcc, gcc -fanalyzer, or clang give warnings about uninitialized
variables.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to William Bader from comment #10)
> The program before creduce has debug code. Setting the variable to print the
> debug code makes the program work.

Can you please attach a version that works with the provided .eps file?

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #12 from William Bader <williambader at hotmail dot com> ---
>I modified the file to:

Sorry about that. I hadn't originally intended to post that file, and I forgot
to clean it up.

>len 9, unknown bad

That means that the data file isn't valid. I posted a binary file that needs to
be uncompressed by bzip2 to make a viewable EPSF (eps with an embedded TIFF
preview). The program needs the uncompressed file. I had to compress it to get
under the byte limit for attachments.
The buffer that the program generates has a count and then a list of Y
positions of lines.
A length of 9 is probably just the count and one Y position of 0 from not being
able to parse the file.
I cut it from a much larger program, and I removed some of the error checks.
My guess is that the test program was looking at the compressed file or that
the decompression was done in text mode on a system that converts to msdos line
endings.
This is what the data file should be
$ ls -l 4329652-1.eps
-rw-rw-rw- 1 william william 32 Mar 17 09:09 4329652-1.eps
$ sum 4329652-1.eps
21790     1
$ md5sum 4329652-1.eps
3b34996094eb7f27ae046d9cae25587e  4329652-1.eps

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #13 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to William Bader from comment #12)
> >I modified the file to:
> 
> Sorry about that. I hadn't originally intended to post that file, and I
> forgot to clean it up.

I understand that.

> 
> >len 9, unknown bad
> 
> This is what the data file should be
> $ ls -l 4329652-1.eps
> -rw-rw-rw- 1 william william 32 Mar 17 09:09 4329652-1.eps
> $ sum 4329652-1.eps
> 21790     1
> $ md5sum 4329652-1.eps
> 3b34996094eb7f27ae046d9cae25587e  4329652-1.eps

It seems you attached a different file then:
$ ls -l 4329652-1.eps
-rw-r--r-- 1 marxin users 2134013 Mar 17 10:21 4329652-1.eps
$ md5sum 4329652-1.eps
25607f50713e15f2bae5c322b95a8014  4329652-1.eps

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #14 from William Bader <williambader at hotmail dot com> ---
>It seems you attached a different file then:

Sorry. I was testing how the 9 result came out, and I put in a small file. I've
been up all night. It is 9:30am my time.

This is the real file. It looks like it matches your file.

$ ls -l 4329652-1.eps 
-r--r--r-- 1 william william 2134013 Mar 16 23:05 4329652-1.eps
$ sum 4329652-1.eps 
32813  2084
$ md5sum 4329652-1.eps 
25607f50713e15f2bae5c322b95a8014  4329652-1.eps

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #15 from Martin Liška <marxin at gcc dot gnu.org> ---
> This is the real file. It looks like it matches your file.

Good. But then my comment 9 is still and I cannot reproduce your problem..

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #16 from William Bader <williambader at hotmail dot com> ---
Is your pr99621-2.c somewhere that I can look at it?
I tried downloading all of the attachments, and it all works for me, on my
Fedora 32 laptop and on a CentOS 6 test server.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #17 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to William Bader from comment #16)
> Is your pr99621-2.c somewhere that I can look at it?

Sure, it's here:
https://gist.githubusercontent.com/marxin/21562b2795430152de5a18ee89fc4e89/raw/5ffbcfb5d7f433c191816b1a27ffedcb88547a35/pr99621-2.c

> I tried downloading all of the attachments, and it all works for me, on my
> Fedora 32 laptop and on a CentOS 6 test server.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #18 from William Bader <williambader at hotmail dot com> ---
Created attachment 50405
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50405&action=edit
the example program with the binary string constant replaced

Thanks for posting it. Your copy of the example C program was corrupted.

The example program has binary text at line 130: 
#define COREL_HEADER_STRING should define xC5 xD0 xD3 xC6
in pr99621-2.c, they have been encoded as UTF-8.

I changed the constant to use "\xC5\xD0\xD3\xC6"

I think that in one of the comments, I showed a clang diagnostic complaining
about that constant.

In addition, I removed the path from the file name at the end.

Also, if you are not on Linux, the second parameter to the fopen() at line 218
might need to be changed from "r" to "rb".

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #19 from Martin Liška <marxin at gcc dot gnu.org> ---
> Thanks for posting it. Your copy of the example C program was corrupted.

Thanks, now I can reproduce it. I'll try to reduce it ..

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd say before reducing, it would be nice to see what is and is not inlined and
see which function is problematic (e.g. by trying different optimize
attributes).

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #21 from Martin Liška <marxin at gcc dot gnu.org> ---
All right, I think it's a well-known problem called X87 FP unit.
The test-case is fixed with:

$ gcc pr99621-3.c -O2 -m32 && ./a.out
len 5167, expected bad
$ gcc pr99621-3.c -O2 -m32 -ffloat-store && ./a.out
len 4287, good
$ gcc pr99621-3.c -O2 -m32 -mfpmath=sse && ./a.out
len 4287, good

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #22 from Martin Liška <marxin at gcc dot gnu.org> ---
https://gcc.gnu.org/wiki/x87note

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Which is why I was talking about excess precision, depending on the
optimizations if something needs to be spilled from the FPU stack where it is
computed in 80-bit precision to stack where the spilling then rounds it to
double precision.
With -fexcess-precision=standard one gets the excess precision predictably
everywhere, with -mfpmath=sse -msse2 there is no excess precision, double is
supported naturally.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621

--- Comment #24 from William Bader <williambader at hotmail dot com> ---
Jakub was right. I didn't understand what he meant at first. Sorry about that.

I can confirm `gcc -m32 -O9 -fexcess-precision=standard gcc-bug1-init.c` on the
original example works correctly for me.

If I change line 758 (the line after #if BUG_FIX) from
  if (new_qxd4_y == cur_qxd4_y && new_qxd4_x > cur_qxd4_x) {
to
  if (new_qxd4_y >= cur_qxd4_y - 0.001 && new_qxd4_y <= cur_qxd4_y + 0.001 &&
new_qxd4_x > cur_qxd4_x) {

then it also works.

Years ago I did scientific programming in fortran, and I should have remembered
from that never to compare two real numbers for equality.