[Bug tree-optimization/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[Bug tree-optimization/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin <danglin at gcc dot gnu.org> 2012-03-01 15:02:13 UTC ---
Program received signal SIGBUS, Bus error.
foo (t=...) at /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c:10
10        return t.i[0];
(gdb) p/x $pc
$3 = 0x2c30
(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0x2c20 to 0x2c40:
   0x00002c20 <lwp_setprivate+0>:       bv r0(rp)
   0x00002c24 <lwp_setprivate+4>:       mtctl r26,tr3
   0x00002c28 <lwp_getprivate+0>:       bv r0(rp)
   0x00002c2c <lwp_getprivate+4>:       mfctl tr3,ret0
=> 0x00002c30 <foo+0>:  ldw 0(r26),r20
   0x00002c34 <foo+4>:  stw r20,0(ret0)
   0x00002c38 <foo+8>:  ldw 4(r26),r20
   0x00002c3c <foo+12>: stw r20,4(ret0)
End of assembler dump.
(gdb) p/x $r26
$4 = 0x40003a49
(gdb) bt
#0  foo (t=...) at /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c:10
#1  0x00002d0c in main ()
    at /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c:26

[Bug tree-optimization/52450] New: FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[danglin at gcc dot gnu.org]

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

             Bug #: 52450
           Summary: FAIL: gcc.dg/torture/pr52402.c at -O1 and above
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: danglin@gcc.gnu.org
                CC: rguenth@gcc.gnu.org
              Host: hppa2.0w-hp-hpux11.11
            Target: hppa2.0w-hp-hpux11.11
             Build: hppa2.0w-hp-hpux11.11


Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c    -O1  -w -Wno-psabi 
-lm
   -o ./pr52402.exe    (timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/gcc/testsuite/gcc.dg/torture/pr52402.c -O1 -w -Wno-psabi -lm -o ./pr52402.exe
PASS: gcc.dg/torture/pr52402.c  -O1  (test for excess errors)
Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc::/test/gnu/gcc/objdir/gcc
spawn [open ...]
FAIL: gcc.dg/torture/pr52402.c  -O1  execution test

-bash-3.2$ ./pr52402.xg
Bus error

[Bug tree-optimization/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-03-01
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-01 15:52:52 UTC ---
I think that's expected if your target does not provide a movmisalign optab
for whatever mode is used for

typedef int v4si __attribute__((vector_size(16)));

because of the ever-existing bug with misaligned stores on STRICT_ALIGNMENT
targets.

Consider xfailing it.

[Bug target/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net 2012-03-05 00:12:35 UTC ---
On 1-Mar-12, at 10:52 AM, rguenth at gcc dot gnu.org wrote:

> I think that's expected if your target does not provide a  
> movmisalign optab
> for whatever mode is used for
>
> typedef int v4si __attribute__((vector_size(16)));
>
> because of the ever-existing bug with misaligned stores on  
> STRICT_ALIGNMENT
> targets.
>
> Consider xfailing it.


I'm not convinced that implementing the movmisalign optab would fix  
the problem
without a major degradation in performance.  Sparc and mips also don't  
implement
movmisalign.

Structs are passed by reference on this target if they are larger than  
64 bits and
the reference is misaligned in this testcase.

So, I agree the test should be xfailed.

Dave
--
John David Anglin    dave.anglin@bell.net

[Bug target/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> 2012-03-05 09:19:12 UTC ---
On Mon, 5 Mar 2012, dave.anglin at bell dot net wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450
> 
> --- Comment #3 from dave.anglin at bell dot net 2012-03-05 00:12:35 UTC ---
> On 1-Mar-12, at 10:52 AM, rguenth at gcc dot gnu.org wrote:
> 
> > I think that's expected if your target does not provide a  
> > movmisalign optab
> > for whatever mode is used for
> >
> > typedef int v4si __attribute__((vector_size(16)));
> >
> > because of the ever-existing bug with misaligned stores on  
> > STRICT_ALIGNMENT
> > targets.
> >
> > Consider xfailing it.
> 
> 
> I'm not convinced that implementing the movmisalign optab would fix  
> the problem
> without a major degradation in performance.  Sparc and mips also don't  
> implement
> movmisalign.
> 
> Structs are passed by reference on this target if they are larger than  
> 64 bits and
> the reference is misaligned in this testcase.

Ah, but that then hints at a possibly completely different bug.  Or
at a missed diagnostic from the C frontend that a misaligned
object is passed by reference to a function that expects it aligned
(the testcase expects that the pass-by-value will make it appear
aligned in foo()).

Wouldn't we need to perform a copy to aligned storage at the caller site
and pass that by reference instead?  Note that in this testcase
even the callee knows the struct is packed (and thus unaligned),
so maybe it's all well-defined and just the middle-end is wrong
in the usual way on STRICT_ALIGN targets.

[so yes, still XFAIL the testcase but have a frontend/middle-end bug
open for this issue]

Richard.

[Bug target/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin <danglin at gcc dot gnu.org> 2012-03-10 22:49:55 UTC ---
Author: danglin
Date: Sat Mar 10 22:49:51 2012
New Revision: 185184

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185184
Log:
    PR target/52450
    * gcc.dg/torture/pr52402.c: Skip execution on 32-bit hppa*-*-hpux*.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/torture/pr52402.c

[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |middle-end

--- Comment #6 from John David Anglin <danglin at gcc dot gnu.org> 2012-03-11 23:59:26 UTC ---
Test is xfailed on trunk.

Please note that this is an optimization bug as the test
doesn't fail at -O0.

While struct T is packed, I don't believe that this implies
that its address is misaligned.  i is the first field in
T.  Thus, its address shouldn't be misaligned on a big
endian target.

It would seem that the problem is the copy at the caller site
is being optimized away.

[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> 2012-03-12 09:55:54 UTC ---
On Sun, 11 Mar 2012, danglin at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450
> 
> John David Anglin <danglin at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>           Component|target                      |middle-end
> 
> --- Comment #6 from John David Anglin <danglin at gcc dot gnu.org> 2012-03-11 23:59:26 UTC ---
> Test is xfailed on trunk.
> 
> Please note that this is an optimization bug as the test
> doesn't fail at -O0.
> 
> While struct T is packed, I don't believe that this implies
> that its address is misaligned.  i is the first field in
> T.  Thus, its address shouldn't be misaligned on a big
> endian target.

Is that so?  If so then the testcase is invalid.

[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> 2012-03-12 09:58:02 UTC ---
On Mon, 12 Mar 2012, rguenther at suse dot de wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450
> 
> --- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> 2012-03-12 09:55:54 UTC ---
> On Sun, 11 Mar 2012, danglin at gcc dot gnu.org wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450
> > 
> > John David Anglin <danglin at gcc dot gnu.org> changed:
> > 
> >            What    |Removed                     |Added
> > ----------------------------------------------------------------------------
> >           Component|target                      |middle-end
> > 
> > --- Comment #6 from John David Anglin <danglin at gcc dot gnu.org> 2012-03-11 23:59:26 UTC ---
> > Test is xfailed on trunk.
> > 
> > Please note that this is an optimization bug as the test
> > doesn't fail at -O0.
> > 
> > While struct T is packed, I don't believe that this implies
> > that its address is misaligned.  i is the first field in
> > T.  Thus, its address shouldn't be misaligned on a big
> > endian target.
> 
> Is that so?  If so then the testcase is invalid.

Btw, alignof () of a packed struct type is 1 (it could be nested
in another packed struct).

Richard.

[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[danglin at gcc dot gnu.org]

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

--- Comment #9 from John David Anglin <danglin at gcc dot gnu.org> 2012-03-12 15:33:38 UTC ---
Author: danglin
Date: Mon Mar 12 15:33:32 2012
New Revision: 185239

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185239
Log:
    PR target/52450
    * gcc.dg/torture/pr52402.c: Skip execution on 32-bit hppa*-*-hpux*.


Modified:
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr52402.c

[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[dave.anglin at bell dot net]

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

--- Comment #10 from dave.anglin at bell dot net 2012-03-12 22:13:55 UTC ---
On 12-Mar-12, at 5:55 AM, rguenther at suse dot de wrote:

> Is that so?  If so then the testcase is invalid.

I had wondered about that, but packed is a GCC extension, and it seems  
the
middle at least initially generates a copy to align T.  I'll look at  
it some more
when I get a chance.

--
John David Anglin    dave.anglin@bell.net

[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[dave.anglin at bell dot net]

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

--- Comment #11 from dave.anglin at bell dot net 2012-03-13 14:41:57 UTC ---
On 3/12/2012 5:58 AM, rguenther at suse dot de wrote:
> Btw, alignof () of a packed struct type is 1 (it could be nested
> in another packed struct).

At -O0, the reference passed to foo is misaligned but the struct is 
copied in
foo with memcpy.;; Function foo (foo)

foo (struct T t)
{
   v4si D.1253;
   struct T t.0;

   # BLOCK 2
   # PRED: ENTRY (fallthru)
   t.0 = t;
   D.1253_1 = t.0.i[0];
<retval> = D.1253_1;
   return <retval>;
   # SUCC: EXIT

}

;; t.0 = t;

(insn 7 6 8 (set (reg/f:SI 99)
         (reg/f:SI 91 virtual-stack-vars)) 
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg
/torture/pr52402.c:10 -1
      (nil))

(insn 8 7 9 (set (reg/f:SI 100)
         (reg/v/f:SI 98)) 
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.
c:10 -1
      (nil))

(insn 9 8 10 (set (reg:SI 101)
         (const_int 36 [0x24])) 
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr
52402.c:10 -1
      (nil))

(insn 10 9 11 (set (reg:SI 26 %r26)
         (reg/f:SI 99)) 
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c:10 -1
      (nil))

(insn 11 10 12 (set (reg:SI 25 %r25)
         (reg/f:SI 100)) 
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c:10 -1
      (nil))

(insn 12 11 13 (set (reg:SI 24 %r24)
         (reg:SI 101)) 
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c:10 -1
      (nil))

(call_insn 13 12 14 (parallel [
             (set (reg:SI 28 %r28)
                 (call (mem:SI (symbol_ref/v:SI ("@memcpy") [flags 0x41] 
<function_decl 7af9ee00 memcpy>) [0 S4 A32])
                     (const_int 16 [0x10])))
             (clobber (reg:SI 1 %r1))
             (clobber (reg:SI 2 %r2))
             (use (const_int 0 [0]))
         ]) /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c:10 -1
      (expr_list:REG_EH_REGION (const_int 0 [0])
         (nil))
     (expr_list:REG_DEP_TRUE (use (reg:SI 24 %r24))
         (expr_list:REG_DEP_TRUE (use (reg:SI 25 %r25))
             (expr_list:REG_DEP_TRUE (use (reg:SI 26 %r26))
                 (nil)))))

(insn 14 13 0 (set (reg:SI 102)
         (reg:SI 28 %r28)) 
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c:10 -1
      (nil))


At -O1, there is no copy.

foo (struct T t)
{
   v4si SR.1;

   # BLOCK 2 freq:10000
   # PRED: ENTRY [100.0%]  (fallthru,exec)
   SR.1_5 = MEM[(struct T *)&t];
<retval> = SR.1_5;
   return <retval>;
   # SUCC: EXIT [100.0%]

}

;; <retval> = SR.1_5;

(insn 7 6 8 (set (reg:SI 99)
         (mem/c:SI (reg/v/f:SI 98) [0 MEM[(struct T *)&t]+0 S4 A8])) 
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c:12 -1
      (nil))

(insn 8 7 9 (set (mem/c/i:SI (reg/f:SI 97) [0 <retval>+0 S4 A128])
         (reg:SI 99)) 
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c:12 -1
      (nil))

(insn 9 8 10 (set (reg:SI 100)
         (mem/c:SI (plus:SI (reg/v/f:SI 98)
                 (const_int 4 [0x4])) [0 MEM[(struct T *)&t]+4 S4 A8])) 
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c:12 -1
      (nil))

(insn 10 9 11 (set (mem/c/i:SI (plus:SI (reg/f:SI 97)
                 (const_int 4 [0x4])) [0 <retval>+4 S4 A32])
         (reg:SI 100)) 
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr52402.c:12 -1
      (nil))

The alignment of the mem's in insns 7 and 9 is inconsistent with the 
alignment for the mode.

Dave

[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[danglin at gcc dot gnu.org]

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

--- Comment #12 from John David Anglin <danglin at gcc dot gnu.org> 2012-03-21 19:39:23 UTC ---
Seems fixed on trunk:
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02426.html

Started working on movmisalign but implementation is a bit
tricky.

[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[danglin at gcc dot gnu.org]

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

--- Comment #13 from John David Anglin <danglin at gcc dot gnu.org> 2012-12-01 20:17:22 UTC ---
Author: danglin
Date: Sat Dec  1 20:17:13 2012
New Revision: 194026

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194026
Log:
    PR middle-end/52450
    * gcc.dg/torture/pr52402.c: Remove xfail for hppa*-*-hpux*.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/torture/pr52402.c

[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=58253,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=52402
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fxied so closing.