target/9080: optimisation on sparc leads to unalligned access in memcpy

target/9080: optimisation on sparc leads to unalligned access in memcpy

[Matthias Klose]

>Number:         9080
>Category:       target
>Synopsis:       optimisation on sparc leads to unalligned access in memcpy
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Sat Dec 28 05:56:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Bernd Eckenfels <lists@lina.inka.de>
>Release:        3.2.1 (Debian) (Debian unstable)
>Organization:
The Debian Project
>Environment:
System: Debian GNU/Linux (unstable)
Architecture: sparc
host: sparc-linux
gcc version 3.2.2 20021212 (Debian prerelease)
>Description:
[ Reported to the Debian BTS as report #136659.
  Please CC 136659@bugs.debian.org on replies.
  Log of report can be found at http://bugs.debian.org/136659 ]
	

[ rechecked with gcc-3.2 CVS 20021212 ]

To add to my problem (reported on debian devel) here is a test program to
reproduce it:

Output with o=2 (unaligned)

ecki@auric:~$ ./bla
Start of struct 0xeffffc70, content: a=aaaaaaaaaaaaaa rel-pos x=12 offset
o=2
Now we are going to memcpy dst=a+x+o=0xeffffc7e
result of a+x+o access: b=aaaabbbbbbbbbb
Now we are going to bcopy dst=&(tmp_iphdr->saddr)=0xeffffc7e
result of bcopy &(tmp_iphdr->saddr) access: b=aaaabbbbbbbbbb
Now we are going to memcpy dst=&(tmp_iphdr->saddr)=0xeffffc7e
Bus error

Output with o=4 (aligned)

ecki@auric:~$ gcc -O2 -o bla bla.c
ecki@auric:~$ ./bla
Start of struct 0xeffffc70, content: a=aaaaaaaaaaaaaa rel-pos x=12 offset
o=4
Now we are going to memcpy dst=a+x+o=0xeffffc80
result of a+x+o access: b=aaaabbbbbbbbbb
Now we are going to bcopy dst=&(tmp_iphdr->saddr)=0xeffffc80
result of bcopy &(tmp_iphdr->saddr) access: b=aaaabbbbbbbbbb
Now we are going to memcpy dst=&(tmp_iphdr->saddr)=0xeffffc80
result of memcpy &(tmp_iphdr->saddr) access: b=aaaabbbbbbbbbb

Note: in both cases the pointer to the target (of bcopy and memcpy) are the
same a+x+o=0xeffffc7e and &(tmp_iphdr->saddr)=0xeffffc7e. The first case
works with memcpy, the second doesnt. This looks clearly like some broken
optimization.

Indeed:

ecki@auric:~$ gcc -O0 -o bla bla.c
ecki@auric:~$ ./bla
Start of struct 0xeffffc70, content: a=aaaaaaaaaaaaaa rel-pos x=12 offset
o=2
Now we are going to memcpy dst=a+x+o=0xeffffc7e
result of a+x+o access: b=aaaabbbbbbbbbb
Now we are going to bcopy dst=&(tmp_iphdr->saddr)=0xeffffc7e
result of bcopy &(tmp_iphdr->saddr) access: b=aaaabbbbbbbbbb
Now we are going to memcpy dst=&(tmp_iphdr->saddr)=0xeffffc7e
result of memcpy &(tmp_iphdr->saddr) access: b=aaaabbbbbbbbbb
>How-To-Repeat:
	
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: target/9080: optimisation on sparc leads to unalligned access in memcpy

[rth]

Synopsis: optimisation on sparc leads to unalligned access in memcpy

Responsible-Changed-From-To: unassigned->rth
Responsible-Changed-By: rth
Responsible-Changed-When: Sun Jan 26 10:13:38 2003
Responsible-Changed-Why:
    .
State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Sun Jan 26 10:13:38 2003
State-Changed-Why:
    I'm fairly sure this has been discussed before, but I can't find
    the reference right away.  The problem is known, and I consider
    the input program incorrect.
    
    The problem is that alignof(struct iphdr) == 4, and yet the
    given pointer to that structure is only 2 byte aligned.  This
    violates section 6.3.2.3/7, to wit:
    
            If the resulting pointer is not correctly aligned for the
            pointed-to type, the behavior is undefined.
    
    GCC uses this clause to infer from the type of the pointer the
    alignment that it *must* have.
    
    There are two solutions for this piece of code.
    
    One, use packed data structures, so that they are 1 byte aligned.
    In this case something like
    
            struct iphdr_u {
              struct iphdr h __attribute__((packed));
            };
    
    followed by
            &tmp_iphdr->h.saddr
    
    Two, don't cast to struct iphdr at all.  Instead use offsetof
    to find the proper displacement into the buffer.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9080