[Bug c/80706] New: peephole2 uses uninitialized stack variables on i686

[staticfloat at gmail dot com]

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

            Bug ID: 80706
           Summary: peephole2 uses uninitialized stack variables on i686
           Product: gcc
           Version: 7.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: staticfloat at gmail dot com
  Target Milestone: ---

This is a GCC bug stemming from this issue [1] on the JuliaLang bug tracker.

While compiling the project openlibm [2] using GCC 7.1.0 targeting i686, the
peephole2 optimization pass generates code that uses uninitialized stack
memory.  The process of discovery can be seen in [1], but I will summarize
here.

Openlibm is a replacement for libm on various platforms.  It contains an acos()
implementation that compiles properly on GCC 6.3.0, or GCC 7.1.0 with
-fno-peephole2.  If peephole2 is enabled, the acos() function returns incorrect
results because it pulls in a piece of uninitialized stack.  From a library
user's perspective, this can be triggered through the use of a .C program such
as this one [3] (there is example shell output shown at the bottom of that
link).  This example sets up the stack such that any uninitialized access
results in extremely large numbers.  Note that we call acos() twice, because
the first time we call, the dl_runtime_resolve() stuff that patches the
openlibm library's acos() function into the C process sets up the stack such
that uninitialized access sees extremely small values.

We then took this example, ran it through creduce, and ended up with this
reduced case [4].  This reduced case still calculates the correct value of
acos(0.8), however when compiled with -fpeephole2, the uninitialized memory
causes the computation to change.  Note that because this reduced case does not
purposefully set up the stack like the code in [3] does, the change in the
computation depends on the vagaries of how the stack is setup.


[1] https://github.com/JuliaLang/julia/issues/21742
[2] https://github.com/JuliaLang/openlibm
[3] https://gist.github.com/staticfloat/70651dfd50a9995492ac494d47065d26
[4] https://gist.github.com/staticfloat/d357b985eab757f393fa7e5ff1ee4101