[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           Priority|P3                          |P1

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #8 from dave at hiauly1 dot hia.nrc.ca 2010-10-09 20:46:54 UTC ---
Created attachment 22007
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22007
pr45722-2.c

--- Comment #9 from dave at hiauly1 dot hia.nrc.ca 2010-10-09 20:46:54 UTC ---
Created attachment 22008
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22008
pr45722-2.s

--- Comment #10 from dave at hiauly1 dot hia.nrc.ca 2010-10-09 20:46:54 UTC ---
Created attachment 22009
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22009
pr45722-2.c.145r.expand

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #7 from dave at hiauly1 dot hia.nrc.ca 2010-10-09 20:46:50 UTC ---
Took another at this bug.  At least at -O1 with r165177, the nature
of the FAIL seems to have changed.  The testcase now fails in testB
with a segmentation fault caused by a misaligned load.

Program received signal SIGBUS, Bus error.
0x00002d90 in testB () at pr45722.c:48
48      x = sB;
(gdb) disass 0x00002d80,0x00002da0
Dump of assembler code from 0x2d80 to 0x2da0:
   0x00002d80 <testB+152>:    ldb,ma 1(r31),r21
   0x00002d84 <testB+156>:    stb,ma r20,1(r22)
   0x00002d88 <testB+160>:    addib,>= -2,r19,0x2d7c <testB+148>
   0x00002d8c <testB+164>:    stb,ma r21,1(r22)
=> 0x00002d90 <testB+168>:    ldw 2(r4),r4
   0x00002d94 <testB+172>:    b,l 0x2c80 <fn3B>,rp
   0x00002d98 <testB+176>:    copy r5,r26
   0x00002d9c <testB+180>:    ldb 50(r3),r20
(gdb) p &sB
$1 = (struct B *) 0x40001a50
(gdb) p/x $r4
$2 = 0x40001a50

It appears the load for sB.l is not expanded correctly given that the
struct is packed:

;; x$l_3 = MEM[(struct B *)&sB + 2B];

(insn 106 105 107 (set (reg/f:SI 205)
        (high:SI (symbol_ref:SI ("sB") [flags 0x200]  <var_decl 7afa7f00 sB>)))
pr45722.c:48 -1
     (nil))

(insn 107 106 108 (set (reg/f:SI 204)
    (lo_sum:SI (reg/f:SI 205)
        (symbol_ref:SI ("sB") [flags 0x200]  <var_decl 7afa7f00 sB>)))
pr45722.c:48 -1
     (expr_list:REG_EQUAL (symbol_ref:SI ("sB") [flags 0x200]  <var_decl
7afa7f00 sB>)
    (nil)))

(insn 108 107 109 (set (reg/f:SI 206)
    (plus:SI (reg/f:SI 204)
        (const_int 0 [0]))) pr45722.c:48 -1
    (nil))

(insn 109 108 0 (set (reg:SI 142 [ x$l ])
    (mem/c:SI (plus:SI (reg/f:SI 206)
        (const_int 2 [0x2])) [0 MEM[(struct B *)&sB + 2B]+0 S4 A8]))
pr5722.c:48 -1
    (nil))

;; r_16 = fn3B (a_13);
--
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[danglin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--- Comment #11 from John David Anglin <danglin at gcc dot gnu.org> 2010-10-09 21:05:38 UTC ---
Breakpoint 1, emit_move_sequence (operands=0x7eff152c, mode=SImode, 
    scratch_reg=0x0) at ../../gcc/gcc/config/pa/pa.c:1501
1501      register rtx operand0 = operands[0];
(gdb) p debug_rtx (operands[0])
(reg:SI 142 [ x$l ])
$1 = void
(gdb) p debug_rtx (operands[1])
(mem/c:SI (plus:SI (reg/f:SI 206)
        (const_int 2 [0x2])) [0 MEM[(struct B *)&sB + 2B]+0 S4 A8])
$2 = void
(gdb) bt
#0  emit_move_sequence (operands=0x7eff152c, mode=SImode, scratch_reg=0x0)
    at ../../gcc/gcc/config/pa/pa.c:1501
#1  0x015587d0 in gen_movsi (operand0=0x7afe92e0, operand1=0x7afef050)
    at ../../gcc/gcc/config/pa/pa.md:2048
#2  0x007b7628 in emit_move_insn_1 (x=0x7afe92e0, y=0x7afef050)
    at ../../gcc/gcc/expr.c:3336
#3  0x007b7bb8 in emit_move_insn (x=0x7afe92e0, y=0x7afef050)
    at ../../gcc/gcc/expr.c:3426
#4  0x007be488 in store_expr (exp=0x7afb9d80, target=0x7afe92e0, 
    call_param_p=0, nontemporal=0 '\000') at ../../gcc/gcc/expr.c:4888
#5  0x007bb7d4 in expand_assignment (to=0x7afd2ed0, from=0x7afb9d80, 
    nontemporal=0 '\000') at ../../gcc/gcc/expr.c:4473
#6  0x01722c4c in expand_gimple_stmt_1 (stmt=0x7afd9390)
    at ../../gcc/gcc/cfgexpand.c:1892
#7  0x01723188 in expand_gimple_stmt (stmt=0x7afd9390)
    at ../../gcc/gcc/cfgexpand.c:2001
#8  0x0172a16c in expand_gimple_basic_block (bb=0x7afd1510)
    at ../../gcc/gcc/cfgexpand.c:3453
#9  0x0172c63c in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:3913
#10 0x00ca6da0 in execute_one_pass (pass=0x40021640)
    at ../../gcc/gcc/passes.c:1562
#11 0x00ca7098 in execute_pass_list (pass=0x40021640)
    at ../../gcc/gcc/passes.c:1617
---Type <return> to continue, or q <return> to quit---
#12 0x02548734 in tree_rest_of_compilation (fndecl=0x7afa6980)
    at ../../gcc/gcc/tree-optimize.c:419
#13 0x013ed6b0 in cgraph_expand_function (node=0x7afb5270)
    at ../../gcc/gcc/cgraphunit.c:1498
#14 0x013ed944 in cgraph_expand_all_functions ()
    at ../../gcc/gcc/cgraphunit.c:1557
#15 0x013ee374 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1813
#16 0x013eb62c in cgraph_finalize_compilation_unit ()
    at ../../gcc/gcc/cgraphunit.c:1020
#17 0x000c262c in c_write_global_declarations ()
    at ../../gcc/gcc/c-decl.c:9821
#18 0x00e2c434 in compile_file () at ../../gcc/gcc/toplev.c:946
#19 0x00e30508 in do_compile () at ../../gcc/gcc/toplev.c:2374
#20 0x00e30694 in toplev_main (argc=18, argv=0x7eff05b4)
    at ../../gcc/gcc/toplev.c:2415
#21 0x00373f34 in main (argc=18, argv=0x7eff05b4) at ../../gcc/gcc/main.c:36

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[danglin at gcc dot gnu.org]

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

--- Comment #12 from John David Anglin <danglin at gcc dot gnu.org> 2010-10-09 21:27:45 UTC ---
Hmmm, seems that we have somehow lost the fact that this load
should be a BLKmode load.

(gdb) frame 4
#4  0x007be488 in store_expr (exp=0x7afb9d80, target=0x7afe92e0, 
    call_param_p=0, nontemporal=0 '\000') at ../../gcc/gcc/expr.c:4888
4888            emit_move_insn (target, temp);
(gdb) p debug_tree (exp)
 <mem_ref 7afb9d80
    type <integer_type 7af37300 unsigned int sizes-gimplified public unsigned
SI
        size <integer_cst 7af2a2b8 constant 32>
        unit size <integer_cst 7af2a0f0 constant 4>
        align 32 symtab 0 alias set -1 canonical type 7af37300 precision 32 min
<integer_cst 7af2a2d0 0> max <integer_cst 7af2a2a0 4294967295>
        pointer_to_this <pointer_type 7af421e0>>

    arg 0 <addr_expr 7afb9d60
        type <pointer_type 7afb73c0 type <record_type 7afa5c00 B>
            unsigned SI size <integer_cst 7af2a2b8 32> unit size <integer_cst
7af2a0f0 4>
            align 32 symtab 0 alias set -1 canonical type 7afb73c0>
        constant
        arg 0 <var_decl 7afa5f00 sB type <record_type 7afa5c00 B>
            addressable used public static common BLK file pr45722.c line 18
col 10
            size <integer_cst 7afabdc8 constant 48>
            unit size <integer_cst 7afabdf8 constant 6>
            align 8 context <translation_unit_decl 7af3ee70 D.1260>
            (mem/s/c:BLK (symbol_ref:SI ("sB") [flags 0x200] <var_decl 7afa5f00
sB>) [0 sB+0 S6 A8]) chain <function_decl 7afa6880 retitB>>>
    arg 1 <integer_cst 7afb8930 type <pointer_type 7afb73c0> constant 2>
    pr45722.c:48:5>

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[danglin at gcc dot gnu.org]

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

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

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

--- Comment #13 from John David Anglin <danglin at gcc dot gnu.org> 2010-10-11 14:33:22 UTC ---
It turned out unaligned trap handler (linux) was on in my
initial debugging.  So, earlier misaligned loads did not
fault.

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[danglin at gcc dot gnu.org]

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

--- Comment #14 from John David Anglin <danglin at gcc dot gnu.org> 2010-10-11 16:30:09 UTC ---
At -O0, memcpy is used.  So, problem doesn't occur.

;; x = sB;

(insn 81 80 82 (set (reg/f:SI 160)        (high:SI (symbol_ref:SI ("sB") [flags
0x200]  <var_decl 0x4028f420 sB>))
) pr45722-2.c:48 -1
     (nil))

(insn 82 81 83 (set (reg/f:SI 159)
        (lo_sum:SI (reg/f:SI 160)
            (symbol_ref:SI ("sB") [flags 0x200]  <var_decl 0x4028f420 sB>)))
pr4
5722-2.c:48 -1
     (expr_list:REG_EQUAL (symbol_ref:SI ("sB") [flags 0x200]  <var_decl
0x4028f
420 sB>)
        (nil)))

(insn 83 82 84 (set (reg:SI 161)
        (plus:SI (reg/f:SI 91 virtual-stack-vars)
            (const_int 24 [0x18]))) pr45722-2.c:48 -1
     (nil))

(insn 84 83 85 (set (reg/f:SI 162)
        (reg/f:SI 159)) pr45722-2.c:48 -1
     (nil))

(insn 85 84 86 (set (reg:SI 163)
        (const_int 6 [0x6])) pr45722-2.c:48 -1
     (nil))

(insn 86 85 87 (set (reg:SI 26 %r26)
        (reg:SI 161)) pr45722-2.c:48 -1
     (nil))

(insn 87 86 88 (set (reg:SI 25 %r25)
        (reg/f:SI 162)) pr45722-2.c:48 -1
     (nil))

(insn 88 87 89 (set (reg:SI 24 %r24)
        (reg:SI 163)) pr45722-2.c:48 -1
     (nil))

(call_insn 89 88 90 (parallel [
            (set (reg:SI 28 %r28)
                (call (mem:SI (symbol_ref/v:SI ("@memcpy") [flags 0x41] 
<function_decl 0x402abf00 memcpy>) [0 S4 A32])
                    (const_int 16 [0x10])))
            (clobber (reg:SI 1 %r1))
            (clobber (reg:SI 2 %r2))
            (use (const_int 0 [0]))
        ]) pr45722-2.c:48 -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 90 89 0 (set (reg:SI 164)
        (reg:SI 28 %r28)) pr45722-2.c:48 -1
     (nil))

;; r_16 = fn3B (a_13);

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[danglin at gcc dot gnu.org]

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

--- Comment #15 from John David Anglin <danglin at gcc dot gnu.org> 2010-10-11 18:08:22 UTC ---
(In reply to comment #14)

Sorry, wrong expansion:

;; D.1972_24 = sB.l;

(insn 135 134 136 (set (reg/f:SI 194)
        (high:SI (symbol_ref:SI ("sB") [flags 0x200]  <var_decl 0x4028f420
sB>))
) pr45722-2.c:53 -1
     (nil))

(insn 136 135 137 (set (reg/f:SI 193)
        (lo_sum:SI (reg/f:SI 194)
            (symbol_ref:SI ("sB") [flags 0x200]  <var_decl 0x4028f420 sB>)))
pr4
5722-2.c:53 -1
     (expr_list:REG_EQUAL (symbol_ref:SI ("sB") [flags 0x200]  <var_decl
0x4028f
420 sB>)
        (nil)))

(insn 137 136 138 (set (reg:QI 196)
        (mem/s/c:QI (plus:SI (reg/f:SI 193)
                (const_int 2 [0x2])) [0+2 S1 A8])) pr45722-2.c:53 -1
     (nil))
(insn 138 137 139 (set (reg:SI 195)
        (zero_extend:SI (reg:QI 196))) pr45722-2.c:53 -1
     (nil))

(insn 139 138 140 (set (reg:SI 197)
        (ashift:SI (reg:SI 195)
            (const_int 24 [0x18]))) pr45722-2.c:53 -1
     (nil))

(insn 140 139 141 (set (reg:QI 199)
        (mem/s/c:QI (plus:SI (reg/f:SI 193)
                (const_int 3 [0x3])) [0+3 S1 A8])) pr45722-2.c:53 -1
     (nil))

(insn 141 140 142 (set (reg:SI 198)
        (zero_extend:SI (reg:QI 199))) pr45722-2.c:53 -1
     (nil))

(insn 142 141 143 (set (reg:SI 200)
        (ashift:SI (reg:SI 198)
            (const_int 16 [0x10]))) pr45722-2.c:53 -1
     (nil))

(insn 143 142 144 (set (reg:SI 201)
        (ior:SI (reg:SI 200)
            (reg:SI 197))) pr45722-2.c:53 -1
     (nil))

(insn 144 143 145 (set (reg:QI 203)
        (mem/s/c:QI (plus:SI (reg/f:SI 193)
                (const_int 4 [0x4])) [0+4 S1 A8])) pr45722-2.c:53 -1
     (nil))

(insn 145 144 146 (set (reg:SI 202)
        (zero_extend:SI (reg:QI 203))) pr45722-2.c:53 -1
     (nil))

(insn 146 145 147 (set (reg:SI 204)
        (ashift:SI (reg:SI 202)
            (const_int 8 [0x8]))) pr45722-2.c:53 -1
     (nil))

(insn 147 146 148 (set (reg:SI 205)
        (ior:SI (reg:SI 204)
            (reg:SI 201))) pr45722-2.c:53 -1
     (nil))

(insn 148 147 149 (set (reg:QI 207)
        (mem/s/c:QI (plus:SI (reg/f:SI 193)
                (const_int 5 [0x5])) [0+5 S1 A8])) pr45722-2.c:53 -1
     (nil))

(insn 149 148 150 (set (reg:SI 206)
        (zero_extend:SI (reg:QI 207))) pr45722-2.c:53 -1
     (nil))

(insn 150 149 151 (set (reg:SI 208)
        (ior:SI (reg:SI 206)
            (reg:SI 205))) pr45722-2.c:53 -1
     (nil))

(insn 151 150 0 (set (reg:SI 109 [ D.1972 ])
        (reg:SI 208)) pr45722-2.c:53 -1
     (nil))

;; if (D.1971_23 != D.1972_24)

At the moment, it appears to me that store_expr doesn't know how to handle
unaligned mem_ref's.

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[danglin at gcc dot gnu.org]

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

--- Comment #16 from John David Anglin <danglin at gcc dot gnu.org> 2010-10-11 19:09:48 UTC ---
At -O0, the operation is handled as a COMPONENT_REF.  At -O1,
we have a MEM_REF.  We get to this point in expand_expr_real_1:

        if (mode != BLKmode
            && (unsigned) align < GET_MODE_ALIGNMENT (mode)
            /* If the target does not have special handling for unaligned
               loads of mode then it can use regular moves for them.  */
            && ((icode = optab_handler (movmisalign_optab, mode))
                != CODE_FOR_nothing))
          {
            rtx reg, insn;

            /* We've already validated the memory, and we're creating a
               new pseudo destination.  The predicates really can't fail.  */
            reg = gen_reg_rtx (mode);

            /* Nor can the insn generator.  */
            insn = GEN_FCN (icode) (reg, temp);
            emit_insn (insn);

            return reg;
          }
        return temp;

As far as I know, there isn't a requirement for target backends to handle
unaligned loads and stores when STRICT_ALIGNMENT is defined.

Further, it's not clear that the code understands that we have an unaligned
load at this point:

(gdb) p debug_tree (exp)
 <mem_ref 0x402aea00
    type <integer_type 0x40216300 unsigned int sizes-gimplified asm_written
public unsigned SI
        size <integer_cst 0x402092b8 constant 32>
        unit size <integer_cst 0x402090f0 constant 4>
        align 32 symtab 1076433952 alias set -1 canonical type 0x40216300
precision 32 min <integer_cst 0x402092d0 0> max <integer_cst 0x402092a0
4294967295>
        pointer_to_this <pointer_type 0x40222360>>

    arg 0 <addr_expr 0x402ae9e0
        type <pointer_type 0x4028f8a0 type <record_type 0x4028f120 B>
            unsigned SI size <integer_cst 0x402092b8 32> unit size <integer_cst
0x402090f0 4>
            align 32 symtab 0 alias set -1 canonical type 0x4028f8a0>
        constant
        arg 0 <var_decl 0x4028f420 sB type <record_type 0x4028f120 B>
            addressable used public static common BLK file pr45722-2.c line 18
col 10
            size <integer_cst 0x402899f0 constant 48>
            unit size <integer_cst 0x40289a20 constant 6>
            align 8 context <translation_unit_decl 0x4021de70 D.1226>
            (mem/s/c:BLK (symbol_ref:SI ("sB") [flags 0x200] <var_decl
0x4028f420 sB>) [0 sB+0 S6 A8]) chain <function_decl 0x40282700 retitB>>>
    arg 1 <integer_cst 0x402ad540 type <pointer_type 0x4028f8a0> constant 2>
    pr45722-2.c:48:5>
$1 = void
(gdb) p align
$2 = 32
(gdb) p mode
$3 = SImode

align is not less than the mode alignment for SImode, so even if we had
movmisalign patterns, they wouldn't be used in this case.

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #17 from dave at hiauly1 dot hia.nrc.ca 2010-10-11 21:17:27 UTC ---
On Mon, 11 Oct 2010, danglin at gcc dot gnu.org wrote:

> At -O0, the operation is handled as a COMPONENT_REF.  At -O1,
> we have a MEM_REF.

The attached change probably can be improved to check whether
or not the object is aligned for its mode, but it seems to fix
the bug (second testcase).  Doing full build and check.

Dave

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|hppa*-*-* (32-bit)          |hppa*-*-* (32-bit),
                   |                            |sparc-sun-solaris2.*
                 CC|                            |ro at gcc dot gnu.org
               Host|hppa*-*-* (32-bit)          |hppa*-*-* (32-bit),
                   |                            |sparc-sun-solaris2.*
              Build|hppa*-*-* (32-bit)          |hppa*-*-* (32-bit),
                   |                            |sparc-sun-solaris2.*

--- Comment #18 from Rainer Orth <ro at gcc dot gnu.org> 2010-10-28 17:49:52 UTC ---
Also affects Solaris 2/SPARC (both 32 and 64-bit).

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #19 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-04 11:20:51 UTC ---
I assume this has been fixed (and thus is a dup of PR45678).  I can't see
the FAIL in recent testresult postings for hppa-linux.

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2010.11.04 20:24:00
         Resolution|FIXED                       |
     Ever Confirmed|0                           |1

--- Comment #20 from Rainer Orth <ro at gcc dot gnu.org> 2010-11-04 20:24:00 UTC ---
It keeps failing on Solaris 2/SPARC (just confirmed on sparc-sun-solaris2.10)
as of 20101104.

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-11 11:43:48 UTC ---
(In reply to comment #20)
> It keeps failing on Solaris 2/SPARC (just confirmed on sparc-sun-solaris2.10)
> as of 20101104.

What's the failure mode on sparc?

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2010-11-11 21:45:40 UTC ---
It dies with SIGBUS here:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00012d24 in testE ()
    at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:95
95      struct pck E { unsigned long long l, i : 12, j : 23, k : 29; }; T(E)
1: x/i $pc
=> 0x12d24 <testE+428>: ld  [ %i5 ], %i0
(gdb) p $i5
$1 = 162310

The source address (%i5) isn't 4-byte aligned as it should be.

I'm attaching the assembler output for the 32-bit -Os case.

Btw., IRIX 6.5 (mips-sgi-irix6.5) is equally affected, both 32 and
64-bit.  I haven't checked in more detail what's happening there yet.

    Rainer

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ro at gcc dot gnu.org]

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

--- Comment #23 from Rainer Orth <ro at gcc dot gnu.org> 2010-11-11 21:48:30 UTC ---
Created attachment 22376
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22376
preprocessed input for 32-bit Solaris 10/SPARC, -Os

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ro at gcc dot gnu.org]

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

--- Comment #24 from Rainer Orth <ro at gcc dot gnu.org> 2010-11-11 21:49:28 UTC ---
Created attachment 22377
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22377
assembler output for 32-bit Solaris 10/SPARC, -Os

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org
         AssignedTo|unassigned at gcc dot       |ebotcazou at gcc dot
                   |gnu.org                     |gnu.org

--- Comment #25 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-12 10:07:46 UTC ---
Investigating.

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #22376|0                           |1
        is obsolete|                            |
  Attachment #22377|0                           |1
        is obsolete|                            |

--- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-12 10:45:15 UTC ---
Created attachment 22381
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22381
reduced testcase (SPARC version)

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ebotcazou at gcc dot gnu.org]

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

--- Comment #27 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-12 10:48:47 UTC ---
The reduced testcase compiled with -O generates a SIGBUS at run time:

Program terminated with signal 10, Bus error.
#0  testE () at pr45722.c:50
50        x = sE;

   0x00010860 <+104>:   stb  %g3, [ %i5 + 0xe ]
   0x00010864 <+108>:   stb  %i4, [ %i5 + 0xf ]
=> 0x00010868 <+112>:   ld  [ %g2 + 0x3f6 ], %i2

(gdb) info reg g2
g2             0x20800  133120

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ebotcazou at gcc dot gnu.org]

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

--- Comment #28 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-12 11:20:12 UTC ---
AFAICS Dave's analysis still holds.  The problematic insn is

(insn 88 87 89 5 (set (reg:DI 134 [ x$l ])
        (mem/c:DI (reg/f:SI 185) [0 MEM[(struct E *)&sE]+0 S8 A8]))
pr45722.c:50 -1
     (nil))

(gdb) frame 1
#1  0x00000000007678ff in expand_assignment (to=0x7ffff7fbfcb8,
    from=0x7ffff7107000, nontemporal=0 '\000')
    at /home/eric/svn/gcc/gcc/expr.c:4474
4474      result = store_expr (from, to_rtx, 0, nontemporal);
(gdb) p debug_generic_expr(from)
MEM[(struct E *)&sE]
$9 = void
(gdb) p debug_generic_expr(to)
x$l_3

The we arrive in the MEM expander:

    align = MAX (TYPE_ALIGN (TREE_TYPE (exp)),
             get_object_alignment (exp, BIGGEST_ALIGNMENT));
    op0 = expand_expr (base, NULL_RTX, VOIDmode, EXPAND_SUM);
    op0 = convert_memory_address_addr_space (address_mode, op0, as);
    if (!integer_zerop (TREE_OPERAND (exp, 1)))
      {
        rtx off
          = immed_double_int_const (mem_ref_offset (exp), address_mode);
        op0 = simplify_gen_binary (PLUS, address_mode, op0, off);
      }
    op0 = memory_address_addr_space (mode, op0, as);
    temp = gen_rtx_MEM (mode, op0);
    set_mem_attributes (temp, exp, 0);
    set_mem_addr_space (temp, as);

(gdb) p align
$21 = 64
(gdb) p debug_rtx(temp)
(mem/c:DI (reg/f:SI 185) [0 MEM[(struct E *)&sE]+0 S8 A8])

so it's exactly the situation described in comment #16.

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #29 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-12 12:19:15 UTC ---
We indeed do rely on type align info on the MEM_REF (which I think is not
the very best idea, but I ended up re-instantiating that because it's all
a mess).  So if SRA rewrites an access it has to transfer misaligned
info to the MEM_REF.  OTOH, given that we have

;; x$l_3 = MEM[(struct B *)&sB + 2B];

we know the alignment exactly because we can infer it from the DECL
alignment of sB.  So we might run into the

void
set_mem_attributes_minus_bitpos (rtx ref, tree t, int objectp,
                                 HOST_WIDE_INT bitpos)
{
  alias_set_type alias = MEM_ALIAS_SET (ref);
  tree expr = MEM_EXPR (ref);
  rtx offset = MEM_OFFSET (ref);
  rtx size = MEM_SIZE (ref);
  unsigned int align = MEM_ALIGN (ref);
                      ^^^^^^^^^^^^^

bug on strict-alignment targets again here.  Uli promised to fix that up
but hasn't delivered yet.

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[rguenth at gcc dot gnu.org]

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

--- Comment #30 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-12 13:01:56 UTC ---
(insn 88 87 89 5 (set (reg:DI 134 [ x$l ])
        (mem/c:DI (reg/f:SI 185) [0 MEM[(struct E *)&sE]+0 S8 A8]))
pr45722.c:50 -1
     (nil))

The memory has MEM_ALIGN 8, but we of course just ignore that for
STRICT_ALIGNMENT targets.  So the situation is similar to the old
mishandling of

typedef int myint __attribute__((aligned(1)));

int foo (myint *p)
{
  return *p;
}

int main()
{
  char c[5];
  return foo (&c[1]);
}

where on old GCC releases we don't run into unaligned memory load
handling for STRICT_ALINGMENT targets either (INDIRECT_REF never
tried to handle that case, I tried to cover up for that with
usign movmisalign where available for MEM_REF).  Now as the alignment
info on the type of the mem-ref is bogus the

        align = MAX (TYPE_ALIGN (TREE_TYPE (exp)),
                     get_object_alignment (exp, BIGGEST_ALIGNMENT));

hunk will make that handling not trigger anyway.

So, it's a) SRAs fault to not preserve alignment b) a general and
very very old problem of GCC (the C FE also doesn't have proper
types when taking the address of a field of a packed struct).

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[rguenth at gcc dot gnu.org]

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

--- Comment #31 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-12 13:09:42 UTC ---
The patch in comment #16 makes sense (it's similar to what we do in
memcpy folding to avoid the situation - and to avoid re-writing of
strict-alignment target handling in memory reference expanding).

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[rguenth at gcc dot gnu.org]

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

--- Comment #32 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-12 13:14:06 UTC ---
In the long term (read: 4.7) I like to resurrect the lowering of bitfield
accesses from the (old) mem-ref branch and eventually treat unaligned
loads on strict-align targets as bitfield accesses and thus lower them as well
(somewhen after final inlining but for example before loop optimizations).

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ebotcazou at gcc dot gnu.org]

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

--- Comment #33 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-12 17:34:26 UTC ---
> The memory has MEM_ALIGN 8, but we of course just ignore that for
> STRICT_ALIGNMENT targets.  So the situation is similar to the old
> mishandling of
> 
> typedef int myint __attribute__((aligned(1)));
> 
> int foo (myint *p)
> {
>   return *p;
> }
> 
> int main()
> {
>   char c[5];
>   return foo (&c[1]);
> }
> 
> where on old GCC releases we don't run into unaligned memory load
> handling for STRICT_ALINGMENT targets either (INDIRECT_REF never
> tried to handle that case, I tried to cover up for that with
> usign movmisalign where available for MEM_REF).  Now as the alignment
> info on the type of the mem-ref is bogus the
> 
>         align = MAX (TYPE_ALIGN (TREE_TYPE (exp)),
>                      get_object_alignment (exp, BIGGEST_ALIGNMENT));
> 
> hunk will make that handling not trigger anyway.
> 
> So, it's a) SRAs fault to not preserve alignment b) a general and
> very very old problem of GCC (the C FE also doesn't have proper
> types when taking the address of a field of a packed struct).

Yes, accesses to unaligned stuff is an old problem, see for example PR c/18287,
and INDIRECT_REFs indeed never tried to handle this.  However, this shouldn't
be the problem here since there are no indirect accesses involved, it's just:

struct E sE;

struct E x;

  x = sE;

Why on earth does SRA now introduce indirect accesses to scalarize a direct
assignment between 2 structures with the same type?

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ebotcazou at gcc dot gnu.org]

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

--- Comment #34 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-12 17:36:43 UTC ---
> The patch in comment #16 makes sense (it's similar to what we do in
> memcpy folding to avoid the situation - and to avoid re-writing of
> strict-alignment target handling in memory reference expanding).

Why not always build the COMPONENT_REF if there is a COMPONENT_REF?  Testing
DECL_PACKED in the optimizer isn't really appropriate.

[Bug tree-optimization/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ebotcazou at gcc dot gnu.org]

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

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

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

--- Comment #36 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-14 11:26:15 UTC ---
At least on the SPARC.

[Bug tree-optimization/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ebotcazou at gcc dot gnu.org]

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

--- Comment #35 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-14 11:24:52 UTC ---
Author: ebotcazou
Date: Sun Nov 14 11:24:47 2010
New Revision: 166731

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166731
Log:
    PR tree-optimization/45722
    * tree-sra.c (build_ref_for_model): Always build a COMPONENT_REF if
    this is a reference to a component.
    * ipa-prop.c (ipa_get_member_ptr_load_param): Accept COMPONENT_REF.
    (ipa_note_param_call): Adjust comment.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-prop.c
    trunk/gcc/tree-sra.c

[Bug tree-optimization/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #37 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2010-11-22 17:05:48 UTC ---
The failures are gone on mips-sgi-irix6.5 (both 32 and 64-bit
multilibs), too.

Thanks.
    Rainer

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[danglin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|hppa*-*-* (32-bit),         |hppa*-*-* (32-bit)
                   |sparc-sun-solaris2.*,       |
                   |mips-sgi-irix6.5            |
   Last reconfirmed|2010-11-04 20:24:00         |
          Component|tree-optimization           |middle-end
               Host|hppa*-*-* (32-bit),         |hppa*-*-* (32-bit)
                   |sparc-sun-solaris2.*,       |
                   |mips-sgi-irix6.5            |
         AssignedTo|ebotcazou at gcc dot        |unassigned at gcc dot
                   |gnu.org                     |gnu.org
              Build|hppa*-*-* (32-bit),         |hppa*-*-* (32-bit)
                   |sparc-sun-solaris2.*,       |
                   |mips-sgi-irix6.5            |

--- Comment #38 from John David Anglin <danglin at gcc dot gnu.org> 2010-11-23 23:54:29 UTC ---
Fixed.

[Bug tree-optimization/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|hppa*-*-* (32-bit)          |hppa*-*-* (32-bit),
                   |                            |sparc-sun-solaris2.*,
                   |                            |mips-sgi-irix6.5
          Component|middle-end                  |tree-optimization
               Host|hppa*-*-* (32-bit)          |
         AssignedTo|unassigned at gcc dot       |ebotcazou at gcc dot
                   |gnu.org                     |gnu.org
              Build|hppa*-*-* (32-bit)          |

--- Comment #39 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-24 07:16:39 UTC ---
Undo latest bogus changes.

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-19 20:09 -------
Subject: Re:  [4.6 Regression] FAIL:
        gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

This bug was introduced in revision 164136.  My comment about 164202
being ok was somehow wrong.

Attached .s files from revisions 164135 and 164136.


------- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-19 20:09 -------
Created an attachment (id=21836)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21836&action=view)


------- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-19 20:09 -------
Created an attachment (id=21837)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21837&action=view)


-- 


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

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-18 19:39 -------
Subject: Re:  [4.6 Regression] FAIL:
        gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

On Sat, 18 Sep 2010, rguenth at gcc dot gnu dot org wrote:

> Can you please reduce preprocessed source?

Attached.


------- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-18 19:39 -------
Created an attachment (id=21831)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21831&action=view)


-- 


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

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2010-09-18 18:43 -------
Can you please reduce preprocessed source?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|FAIL: gcc.c-                |[4.6 Regression] FAIL:
                   |torture/execute/20040709-2.c|gcc.c-
                   |execution at -O1 and -Os    |torture/execute/20040709-2.c
                   |                            |execution at -O1 and -Os
   Target Milestone|---                         |4.6.0


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