https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
Bug ID: 92131
Summary: incorrect assumption that (ao >= 0) is always false
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arigo at tunes dot org
Target Milestone: ---
Created attachment 47053
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47053&action=edit
creduce'd C source that miscompiles in -O>=1
The attached reduced snippet miscompiles with "gcc -O1 foo.c -S", or with any
higher optimization level. It works fine with "gcc -Og foo.c -S". It also
works fine with "gcc -O1 -fwrapv foo.c -S". This may sound suspicious, but I'm
rather convinced that it is a bug anyway: -fwrapv should have no effect here,
which should be easy to check because the code contains only a few arithmetic
operations. Most values involved are loaded from unknown globals, too.
The problem is that the compiled code removes the "if (ao >= 0) {..}"
completely. This is unexpected, and most likely wrong, because there is no
reason for why ao should always be negative here. In fact, we can check that
during the first iteration of the loop it will be equal to 0.
The various apparently unrelated checks that come before the loop cannot be
removed. This code contains a lot of "goto" because it comes from generated
code (pypy project); attempting to change them into equivalent if-else logic
usually makes the bug disappear too.
Reproducers:
* gcc (GCC) 9.1.0 (arch linux x86-64)
$ gcc -O1 foomin1.c -S
$ cat foomin1.s
...
call see_me_here@PLT
.L11:
call error@PLT
...
* gcc (Debian 8.3.0-6) 8.3.0, aarch64
$ gcc -O1 foomin1.c -S
$ cat foomin1.s
...
bl see_me_here
bl error
...
