[Bug target/56897] New: unaligned memory access on alpha

[Bug target/56897] New: unaligned memory access on alpha

[martynas at venck dot us]

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

             Bug #: 56897
           Summary: unaligned memory access on alpha
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: martynas@venck.us


Hi,

After looking at the RTL dumps here and there, I've noticed that
GCC generates unaligned loads in the following manner:

foo = ([reg:X & -8] << (64 - (((reg:FP+reg:Y) & 0x7) << 3))) >> 56

Obviously, we're losing every eighth byte here (consider FP-0,FP-8).
Since FP is aligned, GCC optimizes this to foo = 0.  The right way
to do this is:

foo = ([reg:X & -8] << (56 - (((reg:FP+reg:Y-1) & 0x7) << 3))) >> 56

To reproduce, try this out:

unsigned long foo = 0x010203040a0b0c0d;
printf("%02x",   *((char *)&foo + 7));

With -O (and onwards) it will turn out to be zero;  at every &X+15,
&X+23, etc.  Depending on the offset from the frame pointer.

Attached the diff against trunk.

Martynas.

[Bug target/56897] unaligned memory access on alpha

[martynas at venck dot us]

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

--- Comment #1 from Martynas Venckus <martynas at venck dot us> 2013-04-10 03:55:11 UTC ---
Created attachment 29845
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29845
gcc-unalign-alpha.diff

[Bug target/56897] unaligned memory access on alpha

[ubizjak at gmail dot com]

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

--- Comment #2 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-10 06:43:14 UTC ---

> Attached the diff against trunk.

Please post patches to gcc-patches mailing list, as described in [1].

[1] http://gcc.gnu.org/contribute.html

[Bug target/56897] unaligned memory access on alpha

[ubizjak at gmail dot com]

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

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-04-15
     Ever Confirmed|0                           |1

--- Comment #3 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-15 07:53:58 UTC ---
(In reply to comment #0)

> To reproduce, try this out:
> 
> unsigned long foo = 0x010203040a0b0c0d;
> printf("%02x",   *((char *)&foo + 7));
> 
> With -O (and onwards) it will turn out to be zero;  at every &X+15,
> &X+23, etc.  Depending on the offset from the frame pointer.

Please create a self-sufficient executable testcase, following the instructions
at [1]. I was not able to confirm the problem from the lines you posted.

[1] http://gcc.gnu.org/bugs/

[Bug target/56897] unaligned memory access on alpha

[martynas at venck dot us]

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

--- Comment #4 from Martynas Venckus <martynas at venck dot us> 2013-04-16 04:11:52 UTC ---
Hi,

(In reply to comment #3)
> Please create a self-sufficient executable testcase, following the instructions
> at [1]. I was not able to confirm the problem from the lines you posted.

Thanks for the feedback, Uros.  Did you try it together with the frame 
growing downwards diff posted in #56898?  If so, the locals are actually
at the negative offsets and unaligned loads like foo%8-5 will expose this,
instead of foo%8-1.

I'm attaching the ab-pre.tgz (before the diff) and ab-post.tgz (after 
the diff) which exercise both frame growing upwards and downwards;  RTL
dumps included.  Feel free to turn it into a testcase (I can't do that
at the moment).

I'm 100% busy at work this week, so I would appreciate if you took 
care of this (and #56898).  Otherwise, I'll follow up with the official
contribution guidelines in the weekend.

Martynas.

[Bug target/56897] unaligned memory access on alpha

[martynas at venck dot us]

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

--- Comment #5 from Martynas Venckus <martynas at venck dot us> 2013-04-16 04:16:39 UTC ---
Created attachment 29878
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29878
ab-pre.tgz

> gcc a.c; ./a.out

0d0a
0d0a0401
0d0a0401

> gcc -O a.c; ./a.out

0d0a
0d0a0400
0d0a0400

> cp a.c b.c
> gcc -S -dall a.c
> gcc -O -S -dall b.c

[Bug target/56897] unaligned memory access on alpha

[martynas at venck dot us]

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

--- Comment #6 from Martynas Venckus <martynas at venck dot us> 2013-04-16 04:18:16 UTC ---
Created attachment 29879
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29879
ab-post.tgz

> gcc a.c; ./a.out

0d0a
0d0a0401
0d0a0401

> gcc -O a.c; ./a.out

0d0a
0d0a0401
0d0a0401

> cp a.c b.c
> gcc -S -dall a.c
> gcc -O -S -dall b.c

[Bug target/56897] unaligned memory access on alpha

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-16 15:15:14 UTC ---
(In reply to comment #4)
> Hi,
> 
> (In reply to comment #3)
> > Please create a self-sufficient executable testcase, following the instructions
> > at [1]. I was not able to confirm the problem from the lines you posted.
> 
> Thanks for the feedback, Uros.  Did you try it together with the frame 
> growing downwards diff posted in #56898?  If so, the locals are actually
> at the negative offsets and unaligned loads like foo%8-5 will expose this,
> instead of foo%8-1.

No, I am using unpatched compiler. Compiling your ab-pre.tgz test, I got:

~/gcc-build-47/gcc/xgcc -B ~/gcc-build-47/gcc -O a.c
uros@monolith ~/test $ ./a.out
0d0a
0d0a0401
0d0a0401

~/gcc-build-47/gcc/xgcc -B ~/gcc-build-47/gcc -O -mcpu=ev4 a.c
uros@monolith ~/test $ ./a.out
0d0a
0d0a0401
0d0a0401

with:

GNU C (GCC) version 4.7.3 20130228 (prerelease) [gcc-4_7-branch revision
196343] (alphaev68-unknown-linux-gnu)

and the same result (with the same flags) with:

GNU C (GCC) version 4.9.0 20130407 (experimental) [trunk revision 197551]
(alphaev68-unknown-linux-gnu)

The compilers imply -mcpu=ev67 when invoked without -mcpu command.