[Bug target/26721] New: [4.2 Regression]: Gcc generates unaligned access

[Bug target/26721] New: [4.2 Regression]: Gcc generates unaligned access

[hjl at lucon dot org]

With gcc version 4.2.0 20060316 (experimental) [trunk revision 112138 clean],
I got

lt-gcj-dbtool(10892): unaligned access to 0x60000fffffff9d63,
ip=0x20000000017a02e0
lt-gcj-dbtool(10892): unaligned access to 0x60000fffffff9d6b,
ip=0x20000000017a0301
lt-gcj-dbtool(10892): unaligned access to 0x60000fffffff9d73,
ip=0x20000000017a0321
lt-gcj-dbtool(10892): unaligned access to 0x60000fffffff9d7b,
ip=0x20000000017a0341
strncpy-chk.x1(16065): unaligned access to 0x60000fffffff9201,
ip=0x4000000000001c00
strncpy-chk.x2(16153): unaligned access to 0x60000fffffff9201,
ip=0x4000000000001ba1
strncpy-chk.x3(16260): unaligned access to 0x60000fffffff9201,
ip=0x4000000000001f71
strncpy-chk.x4(16419): unaligned access to 0x60000fffffff9201,
ip=0x4000000000001f50
PR9577(17600): unaligned access to 0x60000fffffff8b03, ip=0x20000000018c82e0
PR9577(17600): unaligned access to 0x60000fffffff8b0b, ip=0x20000000018c8301
PR9577(17600): unaligned access to 0x60000fffffff8b13, ip=0x20000000018c8321
PR9577(17600): unaligned access to 0x60000fffffff8b1b, ip=0x20000000018c8341

For example,

/export/build/gnu/gcc/build-ia64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-ia64-linux/gcc/
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strncpy-chk.c
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strncpy-chk-lib.c
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
 -w -O2  -fno-show-column  -lm   -o
/export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gcc/strncpy-chk.x2
[hjl@gnu-11 gcc]$ ./strncpy-chk.x2
strncpy-chk.x2(23626): unaligned access to 0x60000fffffffb611,
ip=0x4000000000001b81
[hjl@gnu-11 gcc]$


-- 
           Summary: [4.2 Regression]: Gcc generates unaligned access
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl at lucon dot org
 GCC build triplet: ia64-unknown-linux-gnu
  GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-03-16 18:42 -------
self contained testcase?


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[hjl at lucon dot org]

------- Comment #2 from hjl at lucon dot org  2006-03-16 18:58 -------
The testcases are in gcc testsuites. I got tens of those. Pick one from

lt-gcj-dbtool(10892):
strncpy-chk.x1(16065):
strncpy-chk.x2(16153):
strncpy-chk.x3(16260):
strncpy-chk.x4(16419):
PR9577(17600):
strncpy-chk.x2(23626):
simple(1268):
bytebuffer(2845):
directbuffer(4306):
findclass(5567):
jniutf(6710):
overload(7649):
pr23739(8578):
throwit(9569):
ArrayStore.exe(10563):
ArrayStore.exe(11775):
ArrayStore2.exe(12943):
Array_1.exe(14205):
Array_2.exe(15497):
Array_3.exe(16646):
lt-gij(17680):
CompareNaN.exe(18830):
Divide_1.exe(19824):
EvaluationOrder(20965):
ExtraClassLoade(22160):
ExtraClassLoade(22671):
ExtraClassLoade(24410):
FileHandleGcTes(25103):
Final.exe(25774):
Float_1.exe(26750):
G19990301_01.ex(27669):
G19990302_02.ex(28600):
G19990303_01.ex(29565):
G19990303_02.ex(30518):
G19990304_01.ex(31505):
G19990310_01.ex(32504):
II.exe(883):
InterfaceDispat(1433):
InterfaceDispat(1891):
InvokeInterface(2495):
lt-gij(2868):
Invoke_1.exe(3481):
Invoke_2.exe(4204):
KeepInline.exe(5078):
LargeFile.exe(6022):
MathBuiltin.exe(6974):
Matrix4f.exe(7904):
N19990310_02.ex(8902):
N19990310_3.exe(9754):
N19990310_4.exe(10670):
N19990310_5.exe(11558):
Overflow.exe(12477):
PR12350.exe(13149):
PR12416.exe(14016):
PR12656_base.ex(14769):
PR12915.exe(15332):
PR12915.exe(16019):
PR141.exe(24548):
PR160.exe(25479):
PR162.exe(26278):
PR16867.exe(26883):
lt-gij(27225):
PR19870.exe(27799):
PR19870_2.exe(28666):
PR19921.exe(29313):
PR20056.exe(30213):
PR218.exe(31172):
PR242.exe(32268):
PR25535.exe(742):
PR260.exe(1622):
PR3096.exe(2540):
PR3731.exe(3574):
PR5057.exe(4557):
PR5057_2.exe(5500):
PR55.exe(6474):
PR56.exe(7086):
PR6085.exe(7670):
PR6204.exe(8561):
PR6729.exe(9564):
PR6820.exe(10511):
PR7482.exe(11535):
Process_1.exe(12553):
Process_2.exe(13582):
Process_3.exe(14557):
Process_4.exe(15582):
Process_5.exe(16569):
Process_6.exe(17592):
Serialization.e(18525):
Shazam.exe(19533):
StaticConstruct(20513):
StringBuffer_1.(21501):
StringBuffer_ov(22495):
String_overflow(23505):
SyncGlobal.exe(24179):
SyncTest.exe(24828):
SyncTest.exe(25202):
Synch.exe(25669):
TLtest.exe(25998):
TestProxy.exe(26363):
Thread_Alive.ex(26878):
Thread_HoldsLoc(27318):
Thread_Interrup(27803):
Thread_Join.exe(28187):
lt-gij(28543):
Thread_Monitor.(29000):
Thread_Sleep.ex(29593):
Thread_Wait.exe(29982):
lt-gij(30315):
Thread_Wait_2.e(30692):
Thread_Wait_Int(31015):
Throw_1.exe(31324):
Throw_2.exe(31734):
anfi.exe(32146):
anon.exe(32571):
anon2.exe(526):
anon3.exe(947):
anon4.exe(1371):
anon_ctor_itf_a(1819):
anonarray.exe(2245):
anonarray2.exe(2659):
anonarray3.exe(3110):
assign.exe(3541):
assign2.exe(3962):
bclink.exe(4393):
bytearray.exe(4800):
gnu-11:pts/1[38]> cat /tmp/x
lt-gcj-dbtool(10892):
strncpy-chk.x1(16065):
strncpy-chk.x2(16153):
strncpy-chk.x3(16260):
strncpy-chk.x4(16419):
PR9577(17600):
strncpy-chk.x2(23626):
simple(1268):
bytebuffer(2845):
directbuffer(4306):
findclass(5567):
jniutf(6710):
overload(7649):
pr23739(8578):
throwit(9569):
ArrayStore.exe(10563):
ArrayStore.exe(11775):
ArrayStore2.exe(12943):
Array_1.exe(14205):
Array_2.exe(15497):
Array_3.exe(16646):
lt-gij(17680):
CompareNaN.exe(18830):
Divide_1.exe(19824):
EvaluationOrder(20965):
ExtraClassLoade(22160):
ExtraClassLoade(22671):
ExtraClassLoade(24410):
FileHandleGcTes(25103):
Final.exe(25774):
Float_1.exe(26750):
G19990301_01.ex(27669):
G19990302_02.ex(28600):
G19990303_01.ex(29565):
G19990303_02.ex(30518):
G19990304_01.ex(31505):
G19990310_01.ex(32504):
II.exe(883):
InterfaceDispat(1433):
InterfaceDispat(1891):
InvokeInterface(2495):
lt-gij(2868):
Invoke_1.exe(3481):
Invoke_2.exe(4204):
KeepInline.exe(5078):
LargeFile.exe(6022):
MathBuiltin.exe(6974):
Matrix4f.exe(7904):
N19990310_02.ex(8902):
N19990310_3.exe(9754):
N19990310_4.exe(10670):
N19990310_5.exe(11558):
Overflow.exe(12477):
PR12350.exe(13149):
PR12416.exe(14016):
PR12656_base.ex(14769):
PR12915.exe(15332):
PR12915.exe(16019):
PR141.exe(24548):
PR160.exe(25479):
PR162.exe(26278):
PR16867.exe(26883):
lt-gij(27225):
PR19870.exe(27799):
PR19870_2.exe(28666):
PR19921.exe(29313):
PR20056.exe(30213):
PR218.exe(31172):
PR242.exe(32268):
PR25535.exe(742):
PR260.exe(1622):
PR3096.exe(2540):
PR3731.exe(3574):
PR5057.exe(4557):
PR5057_2.exe(5500):
PR55.exe(6474):
PR56.exe(7086):
PR6085.exe(7670):
PR6204.exe(8561):
PR6729.exe(9564):
PR6820.exe(10511):
PR7482.exe(11535):
Process_1.exe(12553):
Process_2.exe(13582):
Process_3.exe(14557):
Process_4.exe(15582):
Process_5.exe(16569):
Process_6.exe(17592):
Serialization.e(18525):
Shazam.exe(19533):
StaticConstruct(20513):
StringBuffer_1.(21501):
StringBuffer_ov(22495):
String_overflow(23505):
SyncGlobal.exe(24179):
SyncTest.exe(24828):
SyncTest.exe(25202):
Synch.exe(25669):
TLtest.exe(25998):
TestProxy.exe(26363):
Thread_Alive.ex(26878):
Thread_HoldsLoc(27318):
Thread_Interrup(27803):
Thread_Join.exe(28187):
lt-gij(28543):
Thread_Monitor.(29000):
Thread_Sleep.ex(29593):
Thread_Wait.exe(29982):
lt-gij(30315):
Thread_Wait_2.e(30692):
Thread_Wait_Int(31015):
Throw_1.exe(31324):
Throw_2.exe(31734):
anfi.exe(32146):
anon.exe(32571):
anon2.exe(526):
anon3.exe(947):
anon4.exe(1371):
anon_ctor_itf_a(1819):
anonarray.exe(2245):
anonarray2.exe(2659):
anonarray3.exe(3110):
assign.exe(3541):
assign2.exe(3962):
bclink.exe(4393):
bytearray.exe(4800):

I will post it here.


-- 

hjl at lucon dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[hjl at lucon dot org]

------- Comment #3 from hjl at lucon dot org  2006-03-16 19:08 -------
It may be related to

http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01001.html
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01000.html
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00999.html
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00997.html
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00998.html

Maxim, can you verify that?


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[hjl at lucon dot org]

------- Comment #4 from hjl at lucon dot org  2006-03-16 19:17 -------
BTW, I saw it on RHEL 4 U3.


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[mkuvyrkov at gcc dot gnu dot org]

------- Comment #5 from mkuvyrkov at gcc dot gnu dot org  2006-03-16 20:32 -------
(In reply to comment #3)
> It may be related to
> 
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01001.html
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01000.html
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00999.html
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00997.html
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00998.html
> 
> Maxim, can you verify that?
> 

I've tested the mainline r18717 (the one just before my patches) on the
strncpy-chk.x2 test and it reported the same unalligned access.
The unalligned access itself is due to store of a char as an int:

;; (insn 170 ...)
add r38 = r12, 17 ;; r12 is a stack pointer.
...
;; (insn 172 ...)
st4 [r38] = r37 ;; unalligned store.

I don't know which pass is responsible to eliminate unalligned references, but
it seems to me that that pass skips this one case. BTW, the very first rtl dump
.expand has the same instructions.


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[sje at cup dot hp dot com]

------- Comment #6 from sje at cup dot hp dot com  2006-03-16 22:25 -------
Here is a cut down test case, I guess GCC is trying to map the strncpy into an
integer move without taking alignment into account.



extern char *strncpy (char *, const char *, __SIZE_TYPE__);
int main()
{
  const char *const foo = "hello world";
  char dst [64];

  strncpy (dst + 1, foo + 1, 4);
  return 0;
}


-- 

sje at cup dot hp dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sje at cup dot hp dot com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-03-16 22:25:02
               date|                            |


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[sje at cup dot hp dot com]

------- Comment #7 from sje at cup dot hp dot com  2006-03-16 23:06 -------
It looks to me like this is due to Richard Guenther's patch at:

http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00737.html

When I removed the non-structure part of this patch the problem went away.
specifically I changed 
    align = MIN (inner, DECL_ALIGN (exp));
back to
    align = MIN (align, DECL_ALIGN (exp));
for the DECL_P case.


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2006-03-16 23:09 -------
(In reply to comment #7)
> It looks to me like this is due to Richard Guenther's patch at:
> 
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00737.html
> 
> When I removed the non-structure part of this patch the problem went away.
> specifically I changed 

If you do that you will cause a real testcase failure on powerpc-*.  Now does
this really show up as failure or is IA64 target for GNU/Linux does not set
strict alignment?  If GCC for ia64-linux-gnu does not set STRICT alignment,
then is not the bug but instead a bug somewhere else.


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-03-16 23:10 -------
Why is ia64-linux-gnu setting STRICT_ALIGNMENT to true even though it works by
default?  Yes it is slower but there is setting for that.


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2006-03-16 23:13 -------
(In reply to comment #6)
> Here is a cut down test case, I guess GCC is trying to map the strncpy into an
> integer move without taking alignment into account.
This is all dead code, this testcase does nothing for me on PPC-darwin, it just
returns 0.
_main:
        li r3,0
        blr


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[sje at cup dot hp dot com]

------- Comment #11 from sje at cup dot hp dot com  2006-03-16 23:16 -------
I compiled the test case at -O1 on IA64 HP-UX to get the bus error due to the
unaligned access.  IA64 HP-UX does require STRICT_ALIGNMENT.


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[schwab at suse dot de]

------- Comment #12 from schwab at suse dot de  2006-03-16 23:37 -------
(In reply to comment #9)
> Why is ia64-linux-gnu setting STRICT_ALIGNMENT to true even though it works by
> default?

prctl --unaligned=signal will make it generate bus errors.


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[pinskia at physics dot uc dot edu]

------- Comment #13 from pinskia at gcc dot gnu dot org  2006-03-16 23:54 -------
Subject: Re:  [4.2 Regression]: Gcc generates unaligned access


On Mar 16, 2006, at 6:37 PM, schwab at suse dot de wrote:

>
>
> ------- Comment #12 from schwab at suse dot de  2006-03-16 23:37 
> -------
> (In reply to comment #9)
>> Why is ia64-linux-gnu setting STRICT_ALIGNMENT to true even though it 
>> works by
>> default?
>
> prctl --unaligned=signal will make it generate bus errors.

But that is a different issue and really this should be handled 
correctly
in that since the target supported by default the unaligned handlers, it
should not set STRICT_ALIGNMENT to 1.  Now the target can have an option
to turn it on, witness PPC-elf/PPC-linux which has one as some embedded
hardware/OS's don't support the unalignement trap.

-- Pinski


-- 


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

Re: [Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[Andrew Pinski]

On Mar 16, 2006, at 6:37 PM, schwab at suse dot de wrote:

>
>
> ------- Comment #12 from schwab at suse dot de  2006-03-16 23:37 
> -------
> (In reply to comment #9)
>> Why is ia64-linux-gnu setting STRICT_ALIGNMENT to true even though it 
>> works by
>> default?
>
> prctl --unaligned=signal will make it generate bus errors.

But that is a different issue and really this should be handled 
correctly
in that since the target supported by default the unaligned handlers, it
should not set STRICT_ALIGNMENT to 1.  Now the target can have an option
to turn it on, witness PPC-elf/PPC-linux which has one as some embedded
hardware/OS's don't support the unalignement trap.

-- Pinski

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2006-03-17 00:22 -------
Now ia64-hpux is a different story.
Maybe the real question is why DSE/DCE is not deleting the dead code which it
is?

But for future reference the docs for STRICT_ALIGNMENT is:
@defmac STRICT_ALIGNMENT
Define this macro to be the value 1 if instructions will fail to work
if given data not on the nominal alignment.  If instructions will merely
go slower in that case, define this macro as 0.
@end defmac

Which means by default on ia64-linux-gnu, it should be defined to 1 and then
SLOW_UNALIGNED_ACCESS should return 1.
The docs for that:
@defmac SLOW_UNALIGNED_ACCESS (@var{mode}, @var{alignment})
Define this macro to be the value 1 if memory accesses described by the
@var{mode} and @var{alignment} parameters have a cost many times greater
than aligned accesses, for example if they are emulated in a trap
handler.

When this macro is nonzero, the compiler will act as if
@code{STRICT_ALIGNMENT} were nonzero when generating code for block
moves.  This can cause significantly more instructions to be produced.
Therefore, do not set this macro nonzero if unaligned accesses only add a
cycle or two to the time for a memory access.

If the value of this macro is always zero, it need not be defined.  If
this macro is defined, it should produce a nonzero value when
@code{STRICT_ALIGNMENT} is nonzero.
@end defmac


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[schwab at suse dot de]

------- Comment #15 from schwab at suse dot de  2006-03-17 00:37 -------
Both alpha and sparc can emulate unaligned accesses, and both set
STRICT_ALIGNMENT.


-- 


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

Re: [Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[Andrew Pinski]

On Mar 16, 2006, at 7:37 PM, schwab at suse dot de wrote:

>
>
> ------- Comment #15 from schwab at suse dot de  2006-03-17 00:37 
> -------
> Both alpha and sparc can emulate unaligned accesses, and both set
> STRICT_ALIGNMENT.

And PPC can emulate unalgined access (and does by default) and it
sets STRICT_ALIGNMENT to 0.  Lets define it correctly for new targets
if they implement unaligned access in software.


-- Pinski

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[pinskia at physics dot uc dot edu]

------- Comment #16 from pinskia at gcc dot gnu dot org  2006-03-17 00:40 -------
Subject: Re:  [4.2 Regression]: Gcc generates unaligned access


On Mar 16, 2006, at 7:37 PM, schwab at suse dot de wrote:

>
>
> ------- Comment #15 from schwab at suse dot de  2006-03-17 00:37 
> -------
> Both alpha and sparc can emulate unaligned accesses, and both set
> STRICT_ALIGNMENT.

And PPC can emulate unalgined access (and does by default) and it
sets STRICT_ALIGNMENT to 0.  Lets define it correctly for new targets
if they implement unaligned access in software.


-- Pinski


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[schwab at suse dot de]

------- Comment #17 from schwab at suse dot de  2006-03-17 01:06 -------
PPC does not trap on unaligned integer load and store.  Neither ia64 nor alpha
nor sparc can do unaligned load and store in hardware.


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[pinskia at physics dot uc dot edu]

------- Comment #18 from pinskia at gcc dot gnu dot org  2006-03-17 01:12 -------
Subject: Re:  [4.2 Regression]: Gcc generates unaligned access


On Mar 16, 2006, at 8:06 PM, schwab at suse dot de wrote:
> ------- Comment #17 from schwab at suse dot de  2006-03-17 01:06 
> -------
> PPC does not trap on unaligned integer load and store.

That is not true, it traps on some.  It all depends on the hardware.
Please don't say it does not trap on none because that is not true.
I don't have access to my PPC PEM right now but IIRC, it says some
implementations can trap.

This is one of the reasons why in sysv4.h, there is a define for
STRICT_ALIGNMENT as:
#define STRICT_ALIGNMENT (TARGET_STRICT_ALIGN)

Yes most of the non embedded processors don't trap but does not
mean anything in general.

-- Pinski


-- 


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

Re: [Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[Andrew Pinski]

On Mar 16, 2006, at 8:06 PM, schwab at suse dot de wrote:
> ------- Comment #17 from schwab at suse dot de  2006-03-17 01:06 
> -------
> PPC does not trap on unaligned integer load and store.

That is not true, it traps on some.  It all depends on the hardware.
Please don't say it does not trap on none because that is not true.
I don't have access to my PPC PEM right now but IIRC, it says some
implementations can trap.

This is one of the reasons why in sysv4.h, there is a define for
STRICT_ALIGNMENT as:
#define STRICT_ALIGNMENT (TARGET_STRICT_ALIGN)

Yes most of the non embedded processors don't trap but does not
mean anything in general.

-- Pinski

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[rguenth at gcc dot gnu dot org]

------- Comment #19 from rguenth at gcc dot gnu dot org  2006-03-17 10:33 -------
*sigh*, seems like I opened a can of worms.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[rguenth at gcc dot gnu dot org]

------- Comment #20 from rguenth at gcc dot gnu dot org  2006-03-17 11:03 -------
For the testcase in comment #6 we fall into the

#ifdef CONSTANT_ALIGNMENT
          else if (CONSTANT_CLASS_P (exp))
            align = CONSTANT_ALIGNMENT (exp, align);
#endif

path and conclude the alignment is 128.

I have yet another patch.


-- 


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[rguenth at gcc dot gnu dot org]

------- Comment #22 from rguenth at gcc dot gnu dot org  2006-03-17 17:39 -------
This should be fixed now.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.2.0


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

[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2006-03-17 17:38 -------
Subject: Bug 26721

Author: rguenth
Date: Fri Mar 17 17:38:51 2006
New Revision: 112177

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112177
Log:
2006-03-17  Richard Guenther  <rguenther@suse.de>

        PR middle-end/26721
        * builtins.c (get_pointer_alignment): For component style references
        adjust alignment to the component type alignment.  Make sure
        to adjust alignment for component access of constants.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c


-- 


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