Re: target/7815: ARM Bug

Re: target/7815: ARM Bug

[Richard Earnshaw]

The following reply was made to PR target/7815; it has been noted by GNATS.

From: Richard Earnshaw <rearnsha@cambridge.arm.com>
To: "Matt Kuenzel" <matt@mapopolis.com>
Cc: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org,
        gcc-gnats@gcc.gnu.org
Subject: Re: target/7815: ARM Bug 
Date: Tue, 03 Sep 2002 13:27:23 +0100

 > 
 > Hi,
 > 
 > Thanks for the explanation. But shouldn't gcc know that=20
 > 
 > ldr r0, [r3, #2]
 > 
 > will try to read a 32-bit word at a non 32-bit boundary thus causing an =
 > alignment fault?
 
 You only get code that is safe from alignment traps if you compile with 
 -malignment-traps.
 
 > 
 > Shouldn't it use the ldrh (load halfword) instruction?
 
 For that you need -march=armv4
 
 R.
 
 Note that armv4 code will never generate alignment traps since it has no 
 need to generate unaligned memory instructions.
 
 
 
 

Re: target/7815: ARM Bug

[rearnsha]

Synopsis: ARM Bug

Responsible-Changed-From-To: unassigned->rearnsha
Responsible-Changed-By: rearnsha
Responsible-Changed-When: Tue Sep  3 01:34:03 2002
Responsible-Changed-Why:
    .
State-Changed-From-To: open->closed
State-Changed-By: rearnsha
State-Changed-When: Tue Sep  3 01:34:03 2002
State-Changed-Why:
    Not a bug.
    
    Gcc knows that your PointType must, by the ARM APCS structure
    alignment rules, always start on a 32-bit boundary.  Therefore,
    it can eliminate one of the shift instructions by using a 
    load-with-rotation instruction.  Note that in this case
    the interesting data is in the top 16 bits of r0.  The
    instruction that follows shifts the interesting bits down
    into the bottom 16 bits, with sign extension.

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

target/7815: ARM Bug

[matt]

>Number:         7815
>Category:       target
>Synopsis:       ARM Bug
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 02 16:16:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Me
>Release:        unknown-1.0
>Organization:
>Environment:
Windows GCC for ARM
>Description:
 
 
GCC for ARM Bug Report
 
from Matt Kuenzel (matt@mapopolis.com)
 
/////////////////////////////////////
 
command line:
 
gcc -nostdinc -O1 -I%PALMOS_PATH% -c "bug" -o "bug".o
 
/////////////////////////////////////
 
source code:
 

typedef struct
 
{
 short x;
 short y;
}
 
PointType;
 
PointType * pixels;
 
short test1()
 
{
 return pixels[0].x;
}
 
short test2()
 
{
 return pixels[0].y;
}
 
short test3()
 
{
 return pixels[1].x;
}
 
short test4()
 
{
 return pixels[1].y;
}
 
/////////////////////////////////////
 
bug.c.o:     file format a.out-arm-little
 
Disassembly of section .text:
 
00000000 <_test1>:
   0: e1a0c00d  mov ip, sp
   4: e92dd800  stmdb sp!, {fp, ip, lr, pc}
   8: e24cb004  sub fp, ip, #4
   c: e59f300c  ldr r3, 20 <L2>
  10: e5933000  ldr r3, [r3]
  14: e5930002  ldr r0, [r3, #2]  //////// this should be #0 ?
  18: e1a00840  mov r0, r0, asr #16
  1c: e95ba800  ldmdb fp, {fp, sp, pc}^
 
00000020 <L2>:
  20: 00000000  andeq r0, r0, r0
 
00000024 <_test2>:
  24: e1a0c00d  mov ip, sp
  28: e92dd800  stmdb sp!, {fp, ip, lr, pc}
  2c: e24cb004  sub fp, ip, #4
  30: e59f3010  ldr r3, 48 <L5>
  34: e5933000  ldr r3, [r3]
  38: e5930002  ldr r0, [r3, #2]  //////// correct
  3c: e1a00800  mov r0, r0, lsl #16
  40: e1a00840  mov r0, r0, asr #16
  44: e95ba800  ldmdb fp, {fp, sp, pc}^
 
00000048 <L5>:
  48: 00000000  andeq r0, r0, r0
 
0000004c <_test3>:
  4c: e1a0c00d  mov ip, sp
  50: e92dd800  stmdb sp!, {fp, ip, lr, pc}
  54: e24cb004  sub fp, ip, #4
  58: e59f3010  ldr r3, 70 <L8>
  5c: e5933000  ldr r3, [r3]
  60: e5930004  ldr r0, [r3, #4]  //////// correct
  64: e1a00800  mov r0, r0, lsl #16
  68: e1a00840  mov r0, r0, asr #16
  6c: e95ba800  ldmdb fp, {fp, sp, pc}^
 
00000070 <L8>:
  70: 00000000  andeq r0, r0, r0
 
00000074 <_test4>:
  74: e1a0c00d  mov ip, sp
  78: e92dd800  stmdb sp!, {fp, ip, lr, pc}
  7c: e24cb004  sub fp, ip, #4
  80: e59f3010  ldr r3, 98 <L11>
  84: e5933000  ldr r3, [r3]
  88: e5930006  ldr r0, [r3, #6]  //////// correct
  8c: e1a00800  mov r0, r0, lsl #16
  90: e1a00840  mov r0, r0, asr #16
  94: e95ba800  ldmdb fp, {fp, sp, pc}^
 
00000098 <L11>:
 ...
 
 
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: