[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces

2018-08-11 Thread staticfloat at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033

Elliot Saba  changed:

   What|Removed |Added

 CC||staticfloat at gmail dot com

--- Comment #41 from Elliot Saba  ---
Has there been any progress on this?  We are running into this while trying to
cross-compile GCC for Darwin.  Has this been fixed in 8.3.0?

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

2017-05-10 Thread 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

[Bug target/80706] peephole2 uses uninitialized stack variables on i686

2017-05-10 Thread staticfloat at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80706

--- Comment #1 from Elliot Saba  ---
I should also note that this is fixed if I provide `-mfpmath=sse` in addition
to any other optimization flags.