[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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=gccview=revrev=162624 Log: 2010-07-28 Richard Guenther rguent...@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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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 ken...@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 ken...@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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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=21314action=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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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=21179action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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|-00-00 00:00:00 |2010-07-11 16:23:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- 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
