* [Bug tree-optimization/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
@ 2010-07-10 19:46 ` danglin at gcc dot gnu dot org
2010-07-10 21:29 ` [Bug target/44903] " rguenth at gcc dot gnu dot org
` (19 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: danglin at gcc dot gnu dot org @ 2010-07-10 19:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from danglin at gcc dot gnu dot org 2010-07-10 19:46 -------
Introduced in revision 161655.
--
danglin at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu dot
| |org
Summary|FAIL: gcc.dg/pr35258.c |[4.6 Regression] FAIL:
|execution test |gcc.dg/pr35258.c execution
| |test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
2010-07-10 19:46 ` [Bug tree-optimization/44903] [4.6 Regression] " danglin at gcc dot gnu dot org
@ 2010-07-10 21:29 ` rguenth at gcc dot gnu dot org
2010-07-10 23:35 ` dave at hiauly1 dot hia dot nrc dot ca
` (18 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-10 21:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-10 21:29 -------
I get for all memory accesses an alignment of 8 at expansion time which looks
correct (on i?86). Please debug this a bit, set_mem_attributes_minus_bitpos
looks conservative enough.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Component|tree-optimization |target
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
2010-07-10 19:46 ` [Bug tree-optimization/44903] [4.6 Regression] " danglin at gcc dot gnu dot org
2010-07-10 21:29 ` [Bug target/44903] " rguenth at gcc dot gnu dot org
@ 2010-07-10 23:35 ` dave at hiauly1 dot hia dot nrc dot ca
2010-07-11 10:47 ` rguenth at gcc dot gnu dot org
` (17 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2010-07-10 23:35 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-10 23:34 -------
Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c
execution test
On Sat, 10 Jul 2010, rguenth at gcc dot gnu dot org wrote:
> I get for all memory accesses an alignment of 8 at expansion time which looks
> correct (on i?86). Please debug this a bit, set_mem_attributes_minus_bitpos
> looks conservative enough.
The rtl in question is the following:
(insn 8 6 11 /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr35258.c:16 (set (reg:SI
28 %r28 [orig:94 D.1980 ] [94])
(mem/c:SI (plus:SI (reg/f:SI 1 %r1 [95])
(const_int 1 [0x1])) [0 MEM[(char * {ref-all})&str +
1B]+0 S4 A8])) 37 {*pa.md:2102} (nil))
An alignment of 8 is not sufficient for a 4 byte (SImode) load on targets
that define STRICT_ALIGNMENT. We need an alignment of 32.
I believe the i?86 hardware allows unaligned addresses, so you wouldn't
see the problem.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (2 preceding siblings ...)
2010-07-10 23:35 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2010-07-11 10:47 ` rguenth at gcc dot gnu dot org
2010-07-11 15:17 ` dave at hiauly1 dot hia dot nrc dot ca
` (16 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-11 10:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-11 10:47 -------
(In reply to comment #3)
> Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c
> execution test
>
> On Sat, 10 Jul 2010, rguenth at gcc dot gnu dot org wrote:
>
> > I get for all memory accesses an alignment of 8 at expansion time which looks
> > correct (on i?86). Please debug this a bit, set_mem_attributes_minus_bitpos
> > looks conservative enough.
>
> The rtl in question is the following:
>
> (insn 8 6 11 /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr35258.c:16 (set (reg:SI
> 28 %r28 [orig:94 D.1980 ] [94])
> (mem/c:SI (plus:SI (reg/f:SI 1 %r1 [95])
> (const_int 1 [0x1])) [0 MEM[(char * {ref-all})&str +
> 1B]+0 S4 A8])) 37 {*pa.md:2102} (nil))
>
> An alignment of 8 is not sufficient for a 4 byte (SImode) load on targets
> that define STRICT_ALIGNMENT. We need an alignment of 32.
>
> I believe the i?86 hardware allows unaligned addresses, so you wouldn't
> see the problem.
Hm. So the MEM_REF path goes the same way as the INDIRECT_REF path for
typedef int t __attribute__((aligned(1),may_alias));
int foo(t *p)
{
return *p;
}
int main()
{
char c[5] = {};
if (foo(&c[1]) != 0)
abort ();
return 0;
}
for example on the 4.5 branch. I see no provision to handle not properly
aligned pointer dereferences in expansion. So I believe this is a latent
issue - but I am quite lost here in the myriads of RTL expansion (which
isn't exactly a piece of GCC I am familiar with).
In fact with Erics fix for PRxyz (all 32bit sparc tests fail) we now claim
an alignment of 32 for the integer load. (CCing Eric - we should factor
in the alignemnt of the pointer type as minimum here).
But back to the above testcase. On the 4.5 branch I get on i?86:
(insn 6 5 7 3 t.c:4 (set (reg:SI 58 [ D.1952 ])
(mem:SI (reg/f:SI 60) [0 S4 A8])) -1 (nil))
(good), but with a cross to ia64-hp-hpux11.23 (I happened to have that around)
(insn 7 6 8 3 t.c:4 (set (reg/f:DI 341)
(unspec:DI [
(reg:SI 342)
] 24)) -1 (nil))
(insn 8 7 9 3 t.c:4 (set (reg:SI 339 [ D.2007 ])
(mem:SI (reg/f:DI 341) [0 S4 A32])) -1 (nil))
thus an alignment of 32!? A nice way of "fixing" ;)
I am curious if the above testcase works for you on the 4.5 branch (or
for any version).
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ebotcazou at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (3 preceding siblings ...)
2010-07-11 10:47 ` rguenth at gcc dot gnu dot org
@ 2010-07-11 15:17 ` dave at hiauly1 dot hia dot nrc dot ca
2010-07-11 16:24 ` rguenth at gcc dot gnu dot org
` (15 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2010-07-11 15:17 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-11 15:17 -------
Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c
execution test
On Sun, 11 Jul 2010, rguenth at gcc dot gnu dot org wrote:
>
>
> ------- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-11 10:47 -------
> (In reply to comment #3)
> > Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c
> > execution test
> >
> > On Sat, 10 Jul 2010, rguenth at gcc dot gnu dot org wrote:
> >
> > > I get for all memory accesses an alignment of 8 at expansion time which looks
> > > correct (on i?86). Please debug this a bit, set_mem_attributes_minus_bitpos
> > > looks conservative enough.
> >
> > The rtl in question is the following:
> >
> > (insn 8 6 11 /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr35258.c:16 (set (reg:SI
> > 28 %r28 [orig:94 D.1980 ] [94])
> > (mem/c:SI (plus:SI (reg/f:SI 1 %r1 [95])
> > (const_int 1 [0x1])) [0 MEM[(char * {ref-all})&str +
> > 1B]+0 S4 A8])) 37 {*pa.md:2102} (nil))
> >
> > An alignment of 8 is not sufficient for a 4 byte (SImode) load on targets
> > that define STRICT_ALIGNMENT. We need an alignment of 32.
> >
> > I believe the i?86 hardware allows unaligned addresses, so you wouldn't
> > see the problem.
>
> Hm. So the MEM_REF path goes the same way as the INDIRECT_REF path for
>
> typedef int t __attribute__((aligned(1),may_alias));
> int foo(t *p)
> {
> return *p;
> }
> int main()
> {
> char c[5] = {};
> if (foo(&c[1]) != 0)
> abort ();
> return 0;
> }
>
> for example on the 4.5 branch. I see no provision to handle not properly
> aligned pointer dereferences in expansion. So I believe this is a latent
> issue - but I am quite lost here in the myriads of RTL expansion (which
> isn't exactly a piece of GCC I am familiar with).
Yes, I don't believe that there ever was a general provision to handle
improperly aligned pointer dereferences in expansion. However, I think
memcpy was special.
> But back to the above testcase. On the 4.5 branch I get on i?86:
>
> (insn 6 5 7 3 t.c:4 (set (reg:SI 58 [ D.1952 ])
> (mem:SI (reg/f:SI 60) [0 S4 A8])) -1 (nil))
>
> (good), but with a cross to ia64-hp-hpux11.23 (I happened to have that around)
>
> (insn 7 6 8 3 t.c:4 (set (reg/f:DI 341)
> (unspec:DI [
> (reg:SI 342)
> ] 24)) -1 (nil))
>
> (insn 8 7 9 3 t.c:4 (set (reg:SI 339 [ D.2007 ])
> (mem:SI (reg/f:DI 341) [0 S4 A32])) -1 (nil))
>
> thus an alignment of 32!? A nice way of "fixing" ;)
>
> I am curious if the above testcase works for you on the 4.5 branch (or
> for any version).
The test always passed before. I've attached the .expand file generated using
the 4.5 branch (32-bit) for comparison.
Dave
------- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-11 15:17 -------
Created an attachment (id=21179)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21179&action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (4 preceding siblings ...)
2010-07-11 15:17 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2010-07-11 16:24 ` rguenth at gcc dot gnu dot org
2010-07-11 16:33 ` danglin at gcc dot gnu dot org
` (14 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-11 16:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-11 16:23 -------
(In reply to comment #5)
> Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c
> execution test
>
> On Sun, 11 Jul 2010, rguenth at gcc dot gnu dot org wrote:
>
> >
> >
> > ------- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-11 10:47 -------
> > (In reply to comment #3)
> > > Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c
> > > execution test
> > >
> > > On Sat, 10 Jul 2010, rguenth at gcc dot gnu dot org wrote:
> > >
> > > > I get for all memory accesses an alignment of 8 at expansion time which looks
> > > > correct (on i?86). Please debug this a bit, set_mem_attributes_minus_bitpos
> > > > looks conservative enough.
> > >
> > > The rtl in question is the following:
> > >
> > > (insn 8 6 11 /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr35258.c:16 (set (reg:SI
> > > 28 %r28 [orig:94 D.1980 ] [94])
> > > (mem/c:SI (plus:SI (reg/f:SI 1 %r1 [95])
> > > (const_int 1 [0x1])) [0 MEM[(char * {ref-all})&str +
> > > 1B]+0 S4 A8])) 37 {*pa.md:2102} (nil))
> > >
> > > An alignment of 8 is not sufficient for a 4 byte (SImode) load on targets
> > > that define STRICT_ALIGNMENT. We need an alignment of 32.
> > >
> > > I believe the i?86 hardware allows unaligned addresses, so you wouldn't
> > > see the problem.
> >
> > Hm. So the MEM_REF path goes the same way as the INDIRECT_REF path for
> >
> > typedef int t __attribute__((aligned(1),may_alias));
> > int foo(t *p)
> > {
> > return *p;
> > }
> > int main()
> > {
> > char c[5] = {};
> > if (foo(&c[1]) != 0)
> > abort ();
> > return 0;
> > }
> >
> > for example on the 4.5 branch. I see no provision to handle not properly
> > aligned pointer dereferences in expansion. So I believe this is a latent
> > issue - but I am quite lost here in the myriads of RTL expansion (which
> > isn't exactly a piece of GCC I am familiar with).
>
> Yes, I don't believe that there ever was a general provision to handle
> improperly aligned pointer dereferences in expansion. However, I think
> memcpy was special.
In the above case the int type the pointer points to is specified as
being unaligned, so the testcase is valid.
> > But back to the above testcase. On the 4.5 branch I get on i?86:
> >
> > (insn 6 5 7 3 t.c:4 (set (reg:SI 58 [ D.1952 ])
> > (mem:SI (reg/f:SI 60) [0 S4 A8])) -1 (nil))
> >
> > (good), but with a cross to ia64-hp-hpux11.23 (I happened to have that around)
> >
> > (insn 7 6 8 3 t.c:4 (set (reg/f:DI 341)
> > (unspec:DI [
> > (reg:SI 342)
> > ] 24)) -1 (nil))
> >
> > (insn 8 7 9 3 t.c:4 (set (reg:SI 339 [ D.2007 ])
> > (mem:SI (reg/f:DI 341) [0 S4 A32])) -1 (nil))
> >
> > thus an alignment of 32!? A nice way of "fixing" ;)
> >
> > I am curious if the above testcase works for you on the 4.5 branch (or
> > for any version).
>
> The test always passed before. I've attached the .expand file generated using
> the 4.5 branch (32-bit) for comparison.
The above testcase worked? Not the pr35258.c, but the one I gave, with
the int aligned(1)? The difference on the 4.5 branch is that we left the
memcpy call alone and did not inline-expand it on the tree level.
I am trying to say that we hit a latent bug here, and that it's finally time
to fix it (but I don't easily see how to do that in the most efficient way).
> Dave
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2010-07-11 16:23:49
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (5 preceding siblings ...)
2010-07-11 16:24 ` rguenth at gcc dot gnu dot org
@ 2010-07-11 16:33 ` danglin at gcc dot gnu dot org
2010-07-11 16:55 ` dave at hiauly1 dot hia dot nrc dot ca
` (13 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: danglin at gcc dot gnu dot org @ 2010-07-11 16:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from danglin at gcc dot gnu dot org 2010-07-11 16:33 -------
With 4.5, the block move was emitted as follows:
Breakpoint 2, emit_block_move_hints (x=0x7afcb550, y=0x7afcb630,
size=0x7af312d8, method=BLOCK_OP_NORMAL, expected_align=64,
expected_size=-1) at ../../gcc/gcc/expr.c:1170
1170 rtx retval = 0;
(gdb) bt
#0 emit_block_move_hints (x=0x7afcb550, y=0x7afcb630, size=0x7af312d8,
method=BLOCK_OP_NORMAL, expected_align=64, expected_size=-1)
at ../../gcc/gcc/expr.c:1170
#1 0x002d5e8c in expand_builtin_memcpy (exp=0x7afaae10, target=0x7af312b8)
at ../../gcc/gcc/builtins.c:3326
#2 0x002dc884 in expand_builtin (exp=0x7afaae10, target=0x7af312b8,
subtarget=0x0, mode=VOIDmode, ignore=1) at ../../gcc/gcc/builtins.c:5972
#3 0x004d0cbc in expand_expr_real_1 (exp=0x7afaae10, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/gcc/expr.c:9262
#4 0x00e043dc in expand_call_stmt (stmt=0x7af299c0)
at ../../gcc/gcc/cfgexpand.c:1789
#5 0x00e045cc in expand_gimple_stmt_1 (stmt=0x7af299c0)
at ../../gcc/gcc/cfgexpand.c:1822
#6 0x00e04bfc in expand_gimple_stmt (stmt=0x7af299c0)
at ../../gcc/gcc/cfgexpand.c:1978
#7 0x00e09348 in expand_gimple_basic_block (bb=0x7afcc240)
at ../../gcc/gcc/cfgexpand.c:3401
#8 0x00e0ab3c in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:3851
#9 0x0077b644 in execute_one_pass (pass=0x4003c990)
at ../../gcc/gcc/passes.c:1568
#10 0x0077b928 in execute_pass_list (pass=0x4003c990)
at ../../gcc/gcc/passes.c:1623
#11 0x016891fc in tree_rest_of_compilation (fndecl=0x7afa4900)
at ../../gcc/gcc/tree-optimize.c:413
#12 0x00bd40f8 in cgraph_expand_function (node=0x7afb3000)
at ../../gcc/gcc/cgraphunit.c:1574
#13 0x00bd4460 in cgraph_expand_all_functions ()
at ../../gcc/gcc/cgraphunit.c:1653
#14 0x00bd4ea4 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1909
#15 0x00bd2cc4 in cgraph_finalize_compilation_unit ()
at ../../gcc/gcc/cgraphunit.c:1122
#16 0x000a8524 in c_write_global_declarations ()
at ../../gcc/gcc/c-decl.c:9519
#17 0x0087a810 in compile_file () at ../../gcc/gcc/toplev.c:1065
#18 0x0087ddb4 in do_compile () at ../../gcc/gcc/toplev.c:2417
#19 0x0087df34 in toplev_main (argc=17, argv=0x7eff05bc)
at ../../gcc/gcc/toplev.c:2459
#20 0x00252d94 in main (argc=17, argv=0x7eff05bc) at ../../gcc/gcc/main.c:35
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (6 preceding siblings ...)
2010-07-11 16:33 ` danglin at gcc dot gnu dot org
@ 2010-07-11 16:55 ` dave at hiauly1 dot hia dot nrc dot ca
2010-07-11 22:04 ` rguenth at gcc dot gnu dot org
` (12 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2010-07-11 16:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-11 16:54 -------
Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
> The above testcase worked? Not the pr35258.c, but the one I gave, with
> the int aligned(1)? The difference on the 4.5 branch is that we left the
> memcpy call alone and did not inline-expand it on the tree level.
The above testcase doesn't work with 4.5 and I doubt it ever worked on
PA. The pointer passed to foo is used as is. It's only the memcpy special
case that is handled by 4.5 and earlier.
> I am trying to say that we hit a latent bug here, and that it's finally time
> to fix it (but I don't easily see how to do that in the most efficient way).
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (7 preceding siblings ...)
2010-07-11 16:55 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2010-07-11 22:04 ` rguenth at gcc dot gnu dot org
2010-07-11 22:22 ` dave at hiauly1 dot hia dot nrc dot ca
` (11 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-11 22:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from rguenth at gcc dot gnu dot org 2010-07-11 22:04 -------
(In reply to comment #9)
> Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
>
> > The above testcase worked? Not the pr35258.c, but the one I gave, with
> > the int aligned(1)? The difference on the 4.5 branch is that we left the
> > memcpy call alone and did not inline-expand it on the tree level.
>
> The above testcase doesn't work with 4.5 and I doubt it ever worked on
> PA. The pointer passed to foo is used as is. It's only the memcpy special
> case that is handled by 4.5 and earlier.
On i?86 we get correct 1-byte alignment for the pointer access while on
my ia64-cross the MEM has 4-byte alignment which is wrong. t is properly
1-byte aligned (and pointer-to packed structs for example will work only
because there's a handled_component_ref around the pointer dereference).
> > I am trying to say that we hit a latent bug here, and that it's finally time
> > to fix it (but I don't easily see how to do that in the most efficient way).
>
> Dave
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (8 preceding siblings ...)
2010-07-11 22:04 ` rguenth at gcc dot gnu dot org
@ 2010-07-11 22:22 ` dave at hiauly1 dot hia dot nrc dot ca
2010-07-11 22:37 ` rguenth at gcc dot gnu dot org
` (10 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2010-07-11 22:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-11 22:22 -------
Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
> > The above testcase doesn't work with 4.5 and I doubt it ever worked on
> > PA. The pointer passed to foo is used as is. It's only the memcpy special
> > case that is handled by 4.5 and earlier.
>
> On i?86 we get correct 1-byte alignment for the pointer access while on
> my ia64-cross the MEM has 4-byte alignment which is wrong. t is properly
> 1-byte aligned (and pointer-to packed structs for example will work only
> because there's a handled_component_ref around the pointer dereference).
On hppa64, I see
(insn 7 6 8 3 xxx.c:3 (set (reg:SI 71)
(mem:SI (reg/v/f:DI 69 [ p ]) [0 *p_1(D)+0 S4 A32])) -1 (nil))
in expand. The alignment is passed into the move expander.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (9 preceding siblings ...)
2010-07-11 22:22 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2010-07-11 22:37 ` rguenth at gcc dot gnu dot org
2010-07-13 13:53 ` rguenth at gcc dot gnu dot org
` (9 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-11 22:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from rguenth at gcc dot gnu dot org 2010-07-11 22:37 -------
(In reply to comment #11)
> Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
>
> > > The above testcase doesn't work with 4.5 and I doubt it ever worked on
> > > PA. The pointer passed to foo is used as is. It's only the memcpy special
> > > case that is handled by 4.5 and earlier.
> >
> > On i?86 we get correct 1-byte alignment for the pointer access while on
> > my ia64-cross the MEM has 4-byte alignment which is wrong. t is properly
> > 1-byte aligned (and pointer-to packed structs for example will work only
> > because there's a handled_component_ref around the pointer dereference).
>
> On hppa64, I see
>
> (insn 7 6 8 3 xxx.c:3 (set (reg:SI 71)
> (mem:SI (reg/v/f:DI 69 [ p ]) [0 *p_1(D)+0 S4 A32])) -1 (nil))
>
> in expand. The alignment is passed into the move expander.
For reference, on i?86 I see (on the 4.5 branch):
(insn 6 5 7 3 t.c:3 (set (reg:SI 62)
(mem:SI (reg/v/f:DI 60 [ p ]) [0 S4 A8])) -1 (nil))
and on trunk:
(insn 6 5 7 3 t.c:3 (set (reg:SI 62)
(mem:SI (reg/v/f:DI 60 [ p ]) [0 *p_1(D)+0 S4 A8])) -1 (nil))
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (10 preceding siblings ...)
2010-07-11 22:37 ` rguenth at gcc dot gnu dot org
@ 2010-07-13 13:53 ` rguenth at gcc dot gnu dot org
2010-07-13 17:41 ` mikpe at it dot uu dot se
` (8 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-13 13:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from rguenth at gcc dot gnu dot org 2010-07-13 13:53 -------
Does
Index: expr.c
===================================================================
--- expr.c (revision 162140)
+++ expr.c (working copy)
@@ -8778,6 +8778,11 @@ expand_expr_real_1 (tree exp, rtx target
set_mem_addr_space (temp, as);
if (TREE_THIS_VOLATILE (exp))
MEM_VOLATILE_P (temp) = 1;
+ if (STRICT_ALIGNMENT
+ && GET_MODE (temp) != BLKmode
+ && GET_MODE (temp) != VOIDmode
+ && GET_MODE_ALIGNMENT (GET_MODE (temp)) > MEM_ALIGN (temp))
+ PUT_MODE (temp, BLKmode);
return temp;
}
make any difference?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (11 preceding siblings ...)
2010-07-13 13:53 ` rguenth at gcc dot gnu dot org
@ 2010-07-13 17:41 ` mikpe at it dot uu dot se
2010-07-14 0:19 ` danglin at gcc dot gnu dot org
` (7 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: mikpe at it dot uu dot se @ 2010-07-13 17:41 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from mikpe at it dot uu dot se 2010-07-13 17:40 -------
Also fails on sparc64-linux, with SIGBUS due to misaligned load in bar().
On armv5tel-unknown-linux-gnueabi it triggers an alignment exception, which the
Linux kernel may emulate/fixup (there's a kernel tunable for that).
--
mikpe at it dot uu dot se changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikpe at it dot uu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (12 preceding siblings ...)
2010-07-13 17:41 ` mikpe at it dot uu dot se
@ 2010-07-14 0:19 ` danglin at gcc dot gnu dot org
2010-07-23 12:14 ` rguenth at gcc dot gnu dot org
` (6 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: danglin at gcc dot gnu dot org @ 2010-07-14 0:19 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from danglin at gcc dot gnu dot org 2010-07-14 00:18 -------
We get a segv here:
Program received signal SIGSEGV, Segmentation fault.
0x0017686c in emit_block_move_hints (x=0x7afb3610, y=0x7afb36f0,
size=0x7af312d8, method=1074100336, expected_align=0, expected_size=-1)
at ../../gcc/gcc/expr.c:1146
1146 align = MIN (MEM_ALIGN (x), MEM_ALIGN (y));
(gdb) p debug_rtx (x)
(reg:SI 94 [ D.1980 ])
$2 = void
(gdb) p debug_rtx (y)
(mem/c:BLK (plus:SI (reg/f:SI 97)
(const_int 1 [0x1])) [0 MEM[(char * {ref-all})&str + 1B]+0 S4 A8])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (13 preceding siblings ...)
2010-07-14 0:19 ` danglin at gcc dot gnu dot org
@ 2010-07-23 12:14 ` rguenth at gcc dot gnu dot org
2010-07-26 12:22 ` rguenth at gcc dot gnu dot org
` (5 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-23 12:14 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from rguenth at gcc dot gnu dot org 2010-07-23 12:14 -------
Mine.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2010-07-11 16:23:49 |2010-07-23 12:14:22
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (14 preceding siblings ...)
2010-07-23 12:14 ` rguenth at gcc dot gnu dot org
@ 2010-07-26 12:22 ` rguenth at gcc dot gnu dot org
2010-07-26 12:45 ` rguenth at gcc dot gnu dot org
` (4 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-26 12:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from rguenth at gcc dot gnu dot org 2010-07-26 12:21 -------
One of the issues is
/* For a MEM rtx, the alignment in bits. We can use the alignment of the
mode as a default when STRICT_ALIGNMENT, but not if not. */
#define MEM_ALIGN(RTX) \
(MEM_ATTRS (RTX) != 0 ? MEM_ATTRS (RTX)->align \
: (STRICT_ALIGNMENT && GET_MODE (RTX) != BLKmode \
? GET_MODE_ALIGNMENT (GET_MODE (RTX)) : BITS_PER_UNIT))
this might be true during RTL, but certainly during expansion this is wrong.
It invents alignment out of thin air.
Invented by Kenner via
+Tue Oct 23 13:05:53 2001 Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
+
...
+ * rtl.h (MEM_ALIGN): Take default from mode, if not BLKmode, and
+ change default if unknown from 1 to BITS_PER_UNIT.
and "fixed up" partly
+Sun Jan 27 13:23:40 2002 Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
+
+ * emit-rtl.c (get_mem_attrs): Don't default alignment for non-BLKmode
+ if not STRICT_ALIGNMENT.
+ * rtl.h (MEM_ALIGN): Likewise.
which conditionalized it on STRICT_ALIGNMENT.
But store_field still tries to compare MEM_ALIGN for alignment. This
could have never worked properly.
Thus, for stores I can "fix" it by doing
Index: gcc/emit-rtl.c
===================================================================
--- gcc/emit-rtl.c (revision 162526)
+++ gcc/emit-rtl.c (working copy)
@@ -1543,7 +1543,7 @@ set_mem_attributes_minus_bitpos (rtx ref
tree expr = MEM_EXPR (ref);
rtx offset = MEM_OFFSET (ref);
rtx size = MEM_SIZE (ref);
- unsigned int align = MEM_ALIGN (ref);
+ unsigned int align = MEM_ATTRS (ref) ? MEM_ALIGN (ref) : BITS_PER_UNIT;
HOST_WIDE_INT apply_bitpos = 0;
tree type;
Index: gcc/expr.c
===================================================================
--- gcc/expr.c (revision 162526)
+++ gcc/expr.c (working copy)
@@ -4168,7 +4168,7 @@ expand_assignment (tree to, tree from, b
Assignment of an array element at a constant index, and assignment of
an array element in an unaligned packed structure field, has the same
problem. */
- if (handled_component_p (to)
+ if (1 || handled_component_p (to)
/* ??? We only need to handle MEM_REF here if the access is not
a full access of the base object. */
|| (TREE_CODE (to) == MEM_REF
but unaligned loads are not fixed by that.
Pre-existing mess. I am not qualified to stir it more.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (15 preceding siblings ...)
2010-07-26 12:22 ` rguenth at gcc dot gnu dot org
@ 2010-07-26 12:45 ` rguenth at gcc dot gnu dot org
2010-07-26 12:46 ` rguenth at gcc dot gnu dot org
` (3 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-26 12:45 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from rguenth at gcc dot gnu dot org 2010-07-26 12:45 -------
Created an attachment (id=21314)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21314&action=view)
patch
Please check whether the attached patch fixes the testcase this bug is about.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (16 preceding siblings ...)
2010-07-26 12:45 ` rguenth at gcc dot gnu dot org
@ 2010-07-26 12:46 ` rguenth at gcc dot gnu dot org
2010-07-28 0:22 ` dave at hiauly1 dot hia dot nrc dot ca
` (2 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-26 12:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from rguenth at gcc dot gnu dot org 2010-07-26 12:45 -------
Mine again (only for restoring the pre-MEM_REF behavior).
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2010-07-23 12:14:22 |2010-07-26 12:45:37
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (17 preceding siblings ...)
2010-07-26 12:46 ` rguenth at gcc dot gnu dot org
@ 2010-07-28 0:22 ` dave at hiauly1 dot hia dot nrc dot ca
2010-07-28 10:33 ` rguenth at gcc dot gnu dot org
2010-07-28 10:33 ` rguenth at gcc dot gnu dot org
20 siblings, 0 replies; 22+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2010-07-28 0:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-28 00:22 -------
Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c
execution test
On Mon, 26 Jul 2010, rguenth at gcc dot gnu dot org wrote:
> Please check whether the attached patch fixes the testcase this bug is about.
Fixes testcase. Tested on hppa2.0w-hp-hpux11.11.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (18 preceding siblings ...)
2010-07-28 0:22 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2010-07-28 10:33 ` rguenth at gcc dot gnu dot org
2010-07-28 10:33 ` rguenth at gcc dot gnu dot org
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-28 10:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from rguenth at gcc dot gnu dot org 2010-07-28 10:33 -------
Subject: Bug 44903
Author: rguenth
Date: Wed Jul 28 10:32:54 2010
New Revision: 162624
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162624
Log:
2010-07-28 Richard Guenther <rguenther@suse.de>
PR middle-end/44903
* builtins.c (fold_builtin_memory_op): On STRICT_ALIGNMENT
targets try harder to not generate unaligned accesses.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
2010-07-10 15:17 [Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test danglin at gcc dot gnu dot org
` (19 preceding siblings ...)
2010-07-28 10:33 ` rguenth at gcc dot gnu dot org
@ 2010-07-28 10:33 ` rguenth at gcc dot gnu dot org
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-28 10:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from rguenth at gcc dot gnu dot org 2010-07-28 10:33 -------
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
^ permalink raw reply [flat|nested] 22+ messages in thread