[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

["joel at oarcorp dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From joel at oarcorp dot com  2004-11-03 22:56 -------
Subject: Re:  M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

schwab at suse dot de wrote:
> ------- Additional Comments From schwab at suse dot de  2004-11-03 22:25 -------
> On the m68k the biggest alignment has traditionally only been 2 bytes 
> (inherited from the Sun compiler, AFAIK), and it's only overridden on NetBSD 
> (and previously on some configurations that are removed now) or when using 
> -malign-int.  So unless you change that (which of course changes the ABI) 
> you'll continue to get unaligned long words somewhere. 

Then I think the m68060 breaks that rule by not supporting a number of
m68040 integer and FP instructions.  They provide software to handle
traps for unimplemented instructions but for performance reasons it is
best to avoid generating them in the first place.  This is similar to
how the 68040's reduced FP capabilities relative to the 68881/2 was handled.

http://www.freescale.com/files/product/doc/MC68060AR_D.pdf

(hand-typed .. sorry) describes the differences between a 68040 and 
68040.  On page 5, it specifically mentions that the CAS and CAS2
"Unlike the MC68040, the MC68060 supports the CAS instruction with 
misaligned operands, and all CAS2 variants, only via software emulation."

Table 7 on page 11, gives a full list of unimplemented integer
instructions.

Off the cuff, one possible solution is that _Atomic_word does not
have a required alignment.  I know it is possible to force alignment
on a variable. Can the same be done with a type?  T

Or is the solution to do as Andreas suggests and turn on the -malign-int
option by default on the MC68060?

I wouldn't think that making the alignment 4 bytes on the MC68060 target
would be a huge impact since those should be relatively large memory
targets board configurations anyway.

--joel


-- 


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