This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
- From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 11 Jul 2010 16:23:49 -0000
- Subject: [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
- References: <bug-44903-276@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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