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 ...