[Bug tree-optimization/63288] New: [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2

[Bug tree-optimization/63288] New: [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2

[zsojka at seznam dot cz]

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

            Bug ID: 63288
           Summary: [5 Regression] gcc.c-torture/execute/20140326-1.c
                    FAILs with -Og -fgcse -fif-conversion2
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz

Created attachment 33508
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33508&action=edit
reduced testcase

Output:
$ gcc -Og -fgcse -fif-conversion2 testcase.c
$ valgrind -q ./a.out 
==13302== Invalid read of size 1
==13302==    at 0x400528: main (in /home/smatz/gcc-bug/1278/a.out)
==13302==  Address 0xfff01f9d8 is not stack'd, malloc'd or (recently) free'd
==13302== 
==13302== 
==13302== Process terminating with default action of signal 11 (SIGSEGV)
==13302==  Access not within mapped region at address 0xFFF01F9D8
==13302==    at 0x400528: main (in /home/smatz/gcc-bug/1278/a.out)
==13302==  If you believe this happened as a result of a stack
==13302==  overflow in your program's main thread (unlikely but
==13302==  possible), you can try to increase the size of the
==13302==  main thread stack using the --main-stacksize= flag.
==13302==  The main thread stack size used in this run was 8388608.
Segmentation fault

The segfault caused by e[131072] being speculatively loaded before the
comparison:

main:
    # crashes here
    movzx    eax, BYTE PTR [rsp+131056]
    cmp    DWORD PTR a[rip], 131072
    je    .L2
        mov    eax, 0
.L2:
    movsx    eax, al
    ret

Tested revisions:
r215315 - fail
r214876 - fail
4_9 r213788 - OK

[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka <zsojka at seznam dot cz> ---
The original testcase also fails with a very different set of flags:
$ gcc -Os -fno-if-conversion -fsched2-use-superblocks
--param=tracer-min-branch-probability=14 20140326-1.i
$ valgrind -q ./a.out 
==8525== Invalid read of size 1
==8525==    at 0x40043A: main (in /home/smatz/Downloads/xx/a.out)
==8525==  Address 0xfff01f9e6 is not stack'd, malloc'd or (recently) free'd
==8525== 
==8525== 
==8525== Process terminating with default action of signal 11 (SIGSEGV)
==8525==  Access not within mapped region at address 0xFFF01F9E6
==8525==    at 0x40043A: main (in /home/smatz/Downloads/xx/a.out)
==8525==  If you believe this happened as a result of a stack
==8525==  overflow in your program's main thread (unlikely but
==8525==  possible), you can try to increase the size of the
==8525==  main thread stack using the --main-stacksize= flag.
==8525==  The main thread stack size used in this run was 8388608.
Segmentation fault

[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-24
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Started with r210492.

[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2

[zsojka at seznam dot cz]

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

--- Comment #4 from Zdenek Sojka <zsojka at seznam dot cz> ---
(In reply to Marek Polacek from comment #3)
> Started with r210492.

In that case the issue might be latent at least in 4_9.

[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
PR60452 only taught rtx_addr_can_trap_p_1 about frame_pointer + offset,
the others are not handled right now:
      /* ??? Need to add a similar guard for nonsensical offsets.  */
      if (x == hard_frame_pointer_rtx
          || x == stack_pointer_rtx
          /* The arg pointer varies if it is not a fixed register.  */
          || (x == arg_pointer_rtx && fixed_regs[ARG_POINTER_REGNUM]))
        return 0;
In this particular case it is the stack_pointer_rtx.
The question is how to derive limits on what is and what is not acceptable
around stack_pointer_rtx.  Negative range needs to include red zone range if
any, positive can be very large if the current function uses VLAs or alloca
(but then hopefully the nonsensical offsets are used against frame/hard frame
pointer, not stack pointer).

[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Let's stop using random set of options...

*** This bug has been marked as a duplicate of bug 61047 ***

[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger at hotmail dot de

--- Comment #7 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
I always wondered if it could be possible to have out-of
bounds accesses via the argument pointer too, that means
accessing an non-existent argument,
maybe a large var-arg, which is not given, like this

int f(int x, ...)
{
  if (x != 0)
  {
     va_list ap;
     va_start(ap, x);

     type z = va_arg(ap, type);
  }
}