[Bug c/61812] New: gcc ICE says "The bug is not reproducible, so it is likely a hardware or OS problem."

[Bug c/61812] New: gcc ICE says "The bug is not reproducible, so it is likely a hardware or OS problem."

[dhowells at redhat dot com]

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

            Bug ID: 61812
           Summary: gcc ICE says "The bug is not reproducible, so it is
                    likely a hardware or OS problem."
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dhowells at redhat dot com

gcc ICE says "The bug is not reproducible, so it is likely a hardware or OS
problem." at the end - even when this isn't true.

[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com <dhowells at redhat dot com> ---
For an example ICE, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737

This is easily reproducible, so the line is incorrect.  It might be better
stated conditionally:

    "If the bug is not reproducible, it is likely a hardware or OS problem."

[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."

[schwab@linux-m68k.org]

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

Andreas Schwab <schwab@linux-m68k.org> changed:

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

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
You must be using some distro patch.

[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."

[dhowells at redhat dot com]

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

--- Comment #3 from dhowells at redhat dot com <dhowells at redhat dot com> ---
Hmmm... It appears you're right.  The 'upstream tarball' in the Fedora gcc SRPM
seems already to be altered from what's upstream - even before the spec file
applies any patches to it.  I wonder where it is coming from.

[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also even though it might be a true gcc issue, it does not say it is a hardware
issue, the message says likely. This could also mean a gc or a memory issue
inside gcc. Except detecting that vs a memory issue is much harder.

[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."

[dhowells at redhat dot com]

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

--- Comment #5 from dhowells at redhat dot com <dhowells at redhat dot com> ---
(In reply to Andrew Pinski from comment #4)
> Also even though it might be a true gcc issue, it does not say it is a
> hardware issue, the message says likely. This could also mean a gc or a
> memory issue inside gcc. Except detecting that vs a memory issue is much
> harder.

It's a bug with the code on the redhat/ branch that generates this message. 
The problem is that when it detects an ICE, the gcc driver runs the cc1 binary
twice more and compares the output - but the output contains a userspace
pointer from within gcc itself, eg:

            (call (mem:QI (symbol_ref:SI ("abort") [flags 0x41] <function_decl 
             0x7f5784e05d00 abort>) [0 __builtin_abort S1 A8])


and this may legitimately differ due to the kernel mapping things in different
places during execve() and mmap().

[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is with the original version of the
http://gcc.gnu.org/ml/gcc-patches/2014-07/msg00819.html
As discussed on IRC, the issue is that the RTL includes host address in the
stderr output, which due to stack randomization differs in between runs.

Supposedly either we should append -fdump-noaddr option to cc1/cc1plus when we
retry, or turn off address space randomization for the retries (through
personality syscall on Linux).