[Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with

[Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

           Summary: New testsuite failures with arm-linux-gnueabi
                    comp-goto failing with
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ramana@gcc.gnu.org
              Host: i686-linux-gnu
            Target: arm-linux-gnueabi


These failures have shown up in the last few days with arm-linux-gnueabi 

FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -O2 
FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -Os 
FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -O2 -flto
-flto-partition=none 
FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -O2 -flto 


I haven't looked at in great detail yet to analyse what causes this problem but
it appears to have appeared in the last week or so.



GCC was configured as : 

--target=arm-none-linux-gnueabi --enable-languages=c,c++,fortran
--with-cpu=cortex-a9 --with-fpu=neon --with-float=softfp


cheers
Ramana

[Bug tree-optimization/49452] New testsuite failures with arm-linux-gnueabi comp-goto failing with

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #1 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2011-06-17 12:02:10 UTC ---
One of the differences I must say I noticed is that at O2 - the call to y has a
NORETURN attribute marked to it but there's no reason why this should be marked
as NORETURN - surely there is a flow of control that allows control to go out
of the function. 


x(a)
{
  __label__ xlab;
  void y(a)
    {
      void *x = &&llab;
      if (a==-1)
 goto *x;
      if (a==0)
 goto xlab;
    llab:
      y (a-1);
    }
  y (a);
 xlab:;
  return a;
}




(call_insn/c/i 11 10 12 3 (parallel [
            (call (mem:SI (symbol_ref:SI ("y.2104") [flags 0x3]  <function_decl
0xb7499400 y>) [0 y S4 A32])
                (const_int 0 [0]))
            (use (const_int 0 [0]))
            (clobber (reg:SI 14 lr))
        ])
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:23
-1
     (expr_list:REG_NORETURN (const_int 0 [0])
        (expr_list:REG_EH_REGION (const_int 0 [0])
            (nil)))
    (expr_list:REG_DEP_TRUE (use (reg:SI 0 r0))
        (expr_list:REG_DEP_TRUE (use (reg:SI 12 ip))
            (nil))))

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

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

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

--- Comment #2 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-17 16:51:41 UTC ---
> NORETURN attribute marked to it but there's no reason why this should be marked
> as NORETURN - surely there is a flow of control that allows control to go out
> of the function. 
> 
> 
> x(a)
> {
>   __label__ xlab;
>   void y(a)
>     {
>       void *x = &&llab;
>       if (a==-1)
>  goto *x;
>       if (a==0)
>  goto xlab;
>     llab:
>       y (a-1);
>     }
>   y (a);
>  xlab:;
>   return a;
> }

Yes, but this isn't a return, this is a non-local goto so NORETURN is correct.

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-17 16:55:48 UTC ---
> I haven't looked at in great detail yet to analyse what causes this problem but
> it appears to have appeared in the last week or so.

Maybe r175063 (significant dse.c change).

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #4 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2011-06-18 08:37:06 UTC ---
(In reply to comment #3)
> > I haven't looked at in great detail yet to analyse what causes this problem but
> > it appears to have appeared in the last week or so.
> 
> Maybe r175063 (significant dse.c change).

It does appear to be that revision triggering this change. 
The problem essentially here is that the backend generates 


(insn/f 36 35 37 2 (set (reg/f:SI 11 fp)
        (plus:SI (reg/f:SI 13 sp)
            (const_int 96 [0x60])))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
-1
     (nil))

(insn/f 37 36 38 2 (set (reg/f:SI 13 sp)
        (plus:SI (reg/f:SI 13 sp)
            (const_int -28 [0xffffffffffffffe4])))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
-1
     (nil))

(insn 38 37 39 2 (set (mem:BLK (scratch) [0 A8])
        (unspec:BLK [
                (reg/f:SI 13 sp)
                (reg/f:SI 11 fp)
            ] UNSPEC_PRLG_STK))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
-1
     (nil))

(note 39 38 5 2 NOTE_INSN_PROLOGUE_END)

(note 5 39 8 2 NOTE_INSN_FUNCTION_BEG)

(note 8 5 9 2 NOTE_INSN_DELETED)

(insn 9 8 2 2 (set (reg:SI 12 ip)
        (plus:SI (reg/f:SI 11 fp)
            (const_int -112 [0xffffffffffffff90])))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:23
4 {*arm_addsi3}
     (nil))

(insn 2 9 33 2 (set (mem/c:SI (plus:SI (reg/f:SI 11 fp)
                (const_int -120 [0xffffffffffffff88])) [6 %sfp+-20 S4 A32])
        (reg:SI 0 r0 [ a ]))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
632 {*arm_movsi_vfp}
     (nil))

(insn 33 2 3 2 (set (reg:SI 3 r3)
        (plus:SI (reg/f:SI 11 fp)
            (const_int -100 [0xffffffffffffff9c])))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
4 {*arm_addsi3}
     (nil))

(insn 3 33 4 2 (set (mem/s/f/c:SI (plus:SI (reg/f:SI 11 fp)
                (const_int -112 [0xffffffffffffff90])) [5
FRAME.0.__nl_goto_buf+0 S4 A32])
        (reg:SI 3 r3))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
632 {*arm_movsi_vfp}
     (nil))

(insn 4 3 11 2 (set (mem/s/f/c:SI (plus:SI (reg/f:SI 11 fp)
                (const_int -108 [0xffffffffffffff94])) [5
FRAME.0.__nl_goto_buf+4 S4 A32])
        (reg/f:SI 13 sp))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
632 {*arm_movsi_vfp}
     (nil))



but the corresponding load into r0 is from a different offset but the alias
sets appear to be correct. 


(insn 24 16 30 3 (set (reg/i:SI 0 r0)
        (mem/c:SI (plus:SI (reg/f:SI 11 fp)
                (const_int -20 [0xffffffffffffffec])) [6 %sfp+-20 S4 A32]))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:26
632 {*arm_movsi_vfp}
     (nil))



cheers
Ramana

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.06.20 14:52:06
                 CC|                            |eraman at google dot com
     Ever Confirmed|0                           |1

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[janis at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

Janis Johnson <janis at gcc dot gnu.org> changed:

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

--- Comment #5 from Janis Johnson <janis at gcc dot gnu.org> 2011-06-24 22:00:07 UTC ---
Starting with r175063, arm-none-linux-gnueabi using default configuration for
arch/cpu/fpu/float-abi gets these failures:

FAIL: gcc.c-torture/execute/920501-7.c execution,  -Os
FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -Os
FAIL: gcc.dg/torture/stackalign/comp-goto-1.c  -Os  execution test
FAIL: gcc.dg/torture/stackalign/non-local-goto-4.c  -Os  execution test

The failures are only for -Os, not for other optimization levels that Ramana
sees for his configuration.  Let me know if this needs a separate PR.

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[eraman at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #6 from Easwaran Raman <eraman at google dot com> 2011-06-24 22:19:40 UTC ---
Could you please test if r175384 fixes these failures? Otherwise please run one
of the smaller tests with -fdump-rtl-dse1-all and -fdump-rtl-cse2 (the pass
before DSE) and upload those dumps and I will take a look.

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[janis at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #7 from Janis Johnson <janis at gcc dot gnu.org> 2011-06-24 23:01:40 UTC ---
Created attachment 24600
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24600
rtl dump for -Os failure

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[janis at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #9 from Janis Johnson <janis at gcc dot gnu.org> 2011-06-24 23:02:58 UTC ---
I still get the -Os failures (I never had the others) with r175389 and have
attached the requested rtl dumps.

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[janis at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #8 from Janis Johnson <janis at gcc dot gnu.org> 2011-06-24 23:02:12 UTC ---
Created attachment 24601
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24601
rtl dump for -Os failure

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[eraman at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #10 from Easwaran Raman <eraman at google dot com> 2011-06-24 23:07:58 UTC ---
(In reply to comment #9)
> I still get the -Os failures (I never had the others) with r175389 and have
> attached the requested rtl dumps.

This doesn't look like a DSE related bug to me. The RTL dump shows that no
store has been deleted by DSE in any of the functions.

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[janis at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #11 from Janis Johnson <janis at gcc dot gnu.org> 2011-06-27 18:05:41 UTC ---
I have confirmed that the -Os failures began with r175063 and that the tests
pass for several revision before that and pass for several after, so it's
unlikely to be an intermittent failure.  If it would help I can send dump files
for r175063 and the one just before that.

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |4.7.0
   Target Milestone|---                         |4.7.0
            Summary|comp-goto-2.c regresses in  |[4.7 regression]
                   |testing                     |comp-goto-2.c regresses in
                   |                            |testing
           Severity|normal                      |major

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[eraman at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #12 from Easwaran Raman <eraman at google dot com> 2011-07-14 17:16:06 UTC ---
(In reply to comment #11)
> I have confirmed that the -Os failures began with r175063 and that the tests
> pass for several revision before that and pass for several after, so it's
> unlikely to be an intermittent failure.  If it would help I can send dump files
> for r175063 and the one just before that.

It is possible that the second DSE invocation deletes a necessary store. My
understanding was that it only acts on spilled stores and all my changes are in
the _nospill version, but that seems not to be the case. Could you send me all
the RTL dumps with and without this patch as a tar file? That will be very
useful in narrowing it down.

Thanks,
Easwaran

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[eraman at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #13 from Easwaran Raman <eraman at google dot com> 2011-07-14 22:10:16 UTC ---
I looked at the dumps for 920501-7.c and second invocation of DSE removes a
necessary store. The relevant dump for function x from
920501-7.c.198r.pro_and_epilogue is below:

(insn 2 58 53 2 (set (mem/c:SI (plus:SI (reg/f:SI 11 fp)
                (const_int -56 [0xffffffffffffffc8])) [6 %sfp+-20 S4 A32])
        (reg:SI 0 r0 [ a ]))
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.reghunt/920501-7.c:12
176 {*arm_movsi_insn}
     (nil))
...

(call_insn/c/i 11 9 12 2 (parallel [
            (call (mem:SI (symbol_ref:SI ("y.1271") [flags 0x3]  <function_decl
0x5578cb80 y>) [0 y S4 A32])
                (const_int 0 [0]))
            (use (const_int 0 [0]))
            (clobber (reg:SI 14 lr))
        ])
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.reghunt/920501-7.c:20
242 {*call_symbol}
     (expr_list:REG_NORETURN (const_int 0 [0])
        (expr_list:REG_EH_REGION (const_int 0 [0])
            (nil)))
    (expr_list:REG_DEP_TRUE (use (reg:SI 0 r0))
        (expr_list:REG_DEP_TRUE (use (reg:SI 12 ip))
            (nil))))

...
(insn 24 18 30 3 (set (reg/i:SI 0 r0)
        (mem/c:SI (plus:SI (reg/f:SI 11 fp)
                (const_int -20 [0xffffffffffffffec])) [6 %sfp+-20 S4 A32]))
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.reghunt/920501-7.c:23
176 {*arm_movsi_insn}
     (nil))



Instruction 2 and 24 refer to the same location, but have different offset
relative to FP because the call to y changes FP. DSE doesn't (and can not, if
it is intra-procedural) know that they both refer to the same location and
hence thinks insn 2 is dead. 

It seems to me this (FP having different value after the call) can only happen
at postreload. It seems to me that setting wild_read (not just
non_frame_wild_read) on all calls after postreload will fix this problem.
What's the best way to do that? Will checking for clear_alias_sets != NULL
work?

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-15 06:26:17 UTC ---
> Instruction 2 and 24 refer to the same location, but have different offset
> relative to FP because the call to y changes FP. DSE doesn't (and can not, if
> it is intra-procedural) know that they both refer to the same location and
> hence thinks insn 2 is dead. 
> 
> It seems to me this (FP having different value after the call) can only happen
> at postreload.

Hum, this shouldn't happen at all I think.  This looks like a latent bug in the
implementation of non-local gotos then.

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #15 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-16 21:18:39 UTC ---
The machine-dependent reorg pass does something unexpected:

(insn 30 18 14 3 (set (reg/f:SI 11 fp)
        (plus:SI (reg/f:SI 11 fp)
            (const_int 36 [0x24]))) 4 {*arm_addsi3}
     (nil))

(insn 14 30 16 3 (use (reg/f:SI 11 fp)) -1
     (nil))

(insn 16 14 24 3 (unspec_volatile [
            (const_int 0 [0])
        ] VUNSPEC_BLOCKAGE) 252 {blockage}
     (nil))

(insn 24 16 27 3 (set (reg/i:SI 0 r0)
        (mem/c:SI (plus:SI (reg/f:SI 11 fp)
                (const_int -56 [0xffffffffffffffc8])) [6 %sfp+-20 S4 A32]))
comp-goto-2.c:26 176 {*arm_movsi_insn}
     (nil))

is reordered into:

(insn 14 18 16 (use (reg/f:SI 11 fp)) -1
     (nil))

(insn 16 14 24 (unspec_volatile [
            (const_int 0 [0])
        ] VUNSPEC_BLOCKAGE) 252 {blockage}
     (nil))

(insn 24 16 30 (set (reg/i:SI 0 r0)
        (mem/c:SI (plus:SI (reg/f:SI 11 fp)
                (const_int -20 [0xffffffffffffffec])) [6 %sfp+-20 S4 A32]))
comp-goto-2.c:26 176 {*arm_movsi_insn}
     (nil))

(insn 30 24 27 (set (reg/f:SI 11 fp)
        (plus:SI (reg/f:SI 11 fp)
            (const_int 36 [0x24]))) 4 {*arm_addsi3}
     (nil))

despite the blockage.

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #16 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2011-07-18 16:31:12 UTC ---
(In reply to comment #15)
> The machine-dependent reorg pass does something unexpected:
> 
> (insn 30 18 14 3 (set (reg/f:SI 11 fp)
>         (plus:SI (reg/f:SI 11 fp)
>             (const_int 36 [0x24]))) 4 {*arm_addsi3}
>      (nil))
> 
> (insn 14 30 16 3 (use (reg/f:SI 11 fp)) -1
>      (nil))
> 
> (insn 16 14 24 3 (unspec_volatile [
>             (const_int 0 [0])
>         ] VUNSPEC_BLOCKAGE) 252 {blockage}
>      (nil))
> 
> (insn 24 16 27 3 (set (reg/i:SI 0 r0)
>         (mem/c:SI (plus:SI (reg/f:SI 11 fp)
>                 (const_int -56 [0xffffffffffffffc8])) [6 %sfp+-20 S4 A32]))
> comp-goto-2.c:26 176 {*arm_movsi_insn}
>      (nil))
> 
> is reordered into:
> 
> (insn 14 18 16 (use (reg/f:SI 11 fp)) -1
>      (nil))
> 
> (insn 16 14 24 (unspec_volatile [
>             (const_int 0 [0])
>         ] VUNSPEC_BLOCKAGE) 252 {blockage}
>      (nil))
> 
> (insn 24 16 30 (set (reg/i:SI 0 r0)
>         (mem/c:SI (plus:SI (reg/f:SI 11 fp)
>                 (const_int -20 [0xffffffffffffffec])) [6 %sfp+-20 S4 A32]))
> comp-goto-2.c:26 176 {*arm_movsi_insn}
>      (nil))
> 
> (insn 30 24 27 (set (reg/f:SI 11 fp)
>         (plus:SI (reg/f:SI 11 fp)
>             (const_int 36 [0x24]))) 4 {*arm_addsi3}
>      (nil))
> 
> despite the blockage.

Hmmm I'm not sure I see this - what's the configure and arch. specific flags
you used just in case ? 


cheers
Ramana

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #17 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2011-07-18 16:35:22 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
> > The machine-dependent reorg pass does something unexpected:
> > 
> > (insn 30 18 14 3 (set (reg/f:SI 11 fp)
> >         (plus:SI (reg/f:SI 11 fp)
> >             (const_int 36 [0x24]))) 4 {*arm_addsi3}
> >      (nil))
> > 
> > (insn 14 30 16 3 (use (reg/f:SI 11 fp)) -1
> >      (nil))
> > 
> > (insn 16 14 24 3 (unspec_volatile [
> >             (const_int 0 [0])
> >         ] VUNSPEC_BLOCKAGE) 252 {blockage}
> >      (nil))
> > 
> > (insn 24 16 27 3 (set (reg/i:SI 0 r0)
> >         (mem/c:SI (plus:SI (reg/f:SI 11 fp)
> >                 (const_int -56 [0xffffffffffffffc8])) [6 %sfp+-20 S4 A32]))
> > comp-goto-2.c:26 176 {*arm_movsi_insn}
> >      (nil))
> > 
> > is reordered into:
> > 
> > (insn 14 18 16 (use (reg/f:SI 11 fp)) -1
> >      (nil))
> > 
> > (insn 16 14 24 (unspec_volatile [
> >             (const_int 0 [0])
> >         ] VUNSPEC_BLOCKAGE) 252 {blockage}
> >      (nil))
> > 
> > (insn 24 16 30 (set (reg/i:SI 0 r0)
> >         (mem/c:SI (plus:SI (reg/f:SI 11 fp)
> >                 (const_int -20 [0xffffffffffffffec])) [6 %sfp+-20 S4 A32]))
> > comp-goto-2.c:26 176 {*arm_movsi_insn}
> >      (nil))
> > 
> > (insn 30 24 27 (set (reg/f:SI 11 fp)
> >         (plus:SI (reg/f:SI 11 fp)
> >             (const_int 36 [0x24]))) 4 {*arm_addsi3}
> >      (nil))
> > 
> > despite the blockage.
> 
> Hmmm I'm not sure I see this - what's the configure and arch. specific flags
> you used just in case ? 
> 

Just in case - I am using -march=armv5t -marm -Os on the command line.

Ramana
> 
> cheers
> Ramana

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #18 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-18 17:59:04 UTC ---
> Hmmm I'm not sure I see this - what's the configure and arch. specific flags
> you used just in case ? 

Flags are just -Os.

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[carrot at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

Carrot <carrot at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carrot at google dot com

--- Comment #19 from Carrot <carrot at google dot com> 2011-09-13 08:37:52 UTC ---
(In reply to comment #15)
> The machine-dependent reorg pass does something unexpected:
> 
> (insn 30 18 14 3 (set (reg/f:SI 11 fp)
>         (plus:SI (reg/f:SI 11 fp)
>             (const_int 36 [0x24]))) 4 {*arm_addsi3}
>      (nil))
> 
> (insn 14 30 16 3 (use (reg/f:SI 11 fp)) -1
>      (nil))
> 
> (insn 16 14 24 3 (unspec_volatile [
>             (const_int 0 [0])
>         ] VUNSPEC_BLOCKAGE) 252 {blockage}
>      (nil))
> 
> (insn 24 16 27 3 (set (reg/i:SI 0 r0)
>         (mem/c:SI (plus:SI (reg/f:SI 11 fp)
>                 (const_int -56 [0xffffffffffffffc8])) [6 %sfp+-20 S4 A32]))
> comp-goto-2.c:26 176 {*arm_movsi_insn}
>      (nil))
> 
> is reordered into:
> 
> (insn 14 18 16 (use (reg/f:SI 11 fp)) -1
>      (nil))
> 
> (insn 16 14 24 (unspec_volatile [
>             (const_int 0 [0])
>         ] VUNSPEC_BLOCKAGE) 252 {blockage}
>      (nil))
> 
> (insn 24 16 30 (set (reg/i:SI 0 r0)
>         (mem/c:SI (plus:SI (reg/f:SI 11 fp)
>                 (const_int -20 [0xffffffffffffffec])) [6 %sfp+-20 S4 A32]))
> comp-goto-2.c:26 176 {*arm_movsi_insn}
>      (nil))
> 
> (insn 30 24 27 (set (reg/f:SI 11 fp)
>         (plus:SI (reg/f:SI 11 fp)
>             (const_int 36 [0x24]))) 4 {*arm_addsi3}
>      (nil))
> 
> despite the blockage.

I observed the same transformation, but in postreload pass. My command line is

"-march=armv7-a" "-mfloat-abi=soft" -Os -w

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[carrot at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #20 from Carrot <carrot at google dot com> 2011-09-14 03:02:03 UTC ---
> Instruction 2 and 24 refer to the same location, but have different offset
> relative to FP because the call to y changes FP. DSE doesn't (and can not, if
> it is intra-procedural) know that they both refer to the same location and
> hence thinks insn 2 is dead. 
> 
> It seems to me this (FP having different value after the call) can only happen
> at postreload. It seems to me that setting wild_read (not just
> non_frame_wild_read) on all calls after postreload will fix this problem.
> What's the best way to do that? Will checking for clear_alias_sets != NULL
> work?

All callee saved registers should never changed after function call. Here fp
has been changed is not because it is after a function call, it is because it
is after the target of non local goto. I'm not familiar with the implementation
of non local goto, but I guess there is some convention/protocol defines which
registers may be changed after the target of a non local goto.

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-09-14 06:48:01 UTC ---
> All callee saved registers should never changed after function call. Here fp
> has been changed is not because it is after a function call, it is because it
> is after the target of non local goto. I'm not familiar with the implementation
> of non local goto, but I guess there is some convention/protocol defines which
> registers may be changed after the target of a non local goto.

That's not the problem.  The problem is that the blockage isn't honored.

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[ramana.r at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #22 from Ramana Radhakrishnan <ramana.r at gmail dot com> 2011-09-14 20:26:43 UTC ---
On 14 Sep 2011, at 07:48, "ebotcazou at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
> 
> --- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-09-14 06:48:01 UTC ---
>> All callee saved registers should never changed after function call. Here fp
>> has been changed is not because it is after a function call, it is because it
>> is after the target of non local goto. I'm not familiar with the implementation
>> of non local goto, but I guess there is some convention/protocol defines which
>> registers may be changed after the target of a non local goto.
> 
> That's not the problem.  The problem is that the blockage isn't honored.


By ?
> 
> -- 
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[carrot at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #23 from Carrot <carrot at google dot com> 2011-09-16 06:57:15 UTC ---
(In reply to comment #21)
> > All callee saved registers should never changed after function call. Here fp
> > has been changed is not because it is after a function call, it is because it
> > is after the target of non local goto. I'm not familiar with the implementation
> > of non local goto, but I guess there is some convention/protocol defines which
> > registers may be changed after the target of a non local goto.
> 
> That's not the problem.  The problem is that the blockage isn't honored.

It seems postreload.c should be changed to the following to avoid combining

--- postreload.c    (revision 178904)
+++ postreload.c    (working copy)
@@ -1312,7 +1312,7 @@ reload_combine (void)
      is and then later disable any optimization that would cross it.  */
       if (LABEL_P (insn))
     last_label_ruid = reload_combine_ruid;
-      else if (BARRIER_P (insn))
+      else if (BARRIER_P (insn) || BLOCKAGE_P (insn))
     for (r = 0; r < FIRST_PSEUDO_REGISTER; r++)
       if (! fixed_regs[r])
           reg_state[r].use_index = RELOAD_COMBINE_MAX_USES;

BLOCKAGE_P (insn) is used to detect if insn is a blockage insn, is there any
available function/macro that implement this functionality?

[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #24 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-09-16 21:24:30 UTC ---
> It seems postreload.c should be changed to the following to avoid combining
> 
> --- postreload.c    (revision 178904)
> +++ postreload.c    (working copy)
> @@ -1312,7 +1312,7 @@ reload_combine (void)
>       is and then later disable any optimization that would cross it.  */
>        if (LABEL_P (insn))
>      last_label_ruid = reload_combine_ruid;
> -      else if (BARRIER_P (insn))
> +      else if (BARRIER_P (insn) || BLOCKAGE_P (insn))
>      for (r = 0; r < FIRST_PSEUDO_REGISTER; r++)
>        if (! fixed_regs[r])
>            reg_state[r].use_index = RELOAD_COMBINE_MAX_USES;
> 
> BLOCKAGE_P (insn) is used to detect if insn is a blockage insn, is there any
> available function/macro that implement this functionality?

volatile_insn_p would seem to be appropriate.

[Bug rtl-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[carrot at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #25 from carrot at gcc dot gnu.org 2011-09-20 00:57:44 UTC ---
Author: carrot
Date: Tue Sep 20 00:57:39 2011
New Revision: 178995

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178995
Log:
    PR rtl-optimization/49452
    * postreload.c (reload_combine): Invalidate use information when across
    volatile insn.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/postreload.c

[Bug rtl-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

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

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

--- Comment #26 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-10 11:52:26 UTC ---
I supposed fixed.