Re: [patch] m68k: Fix binary compatibility problem with -mno-strict-align. (Take 2)

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Wed, 29 Aug 2007, Kazu Hirata wrote:

> Hi Roman,
> 
> > Looking at this a little closer, I'm not sure why this is related to
> > alignment in first place. Whether a structure is returned in a register
> > should be controlled by -fpcc-struct-return/-freg-struct-return and the
> > DEFAULT_PCC_STRUCT_RETURN value in the config. In
> > function.c:aggregate_value_p there is shortly after the return_in_memory
> > hook the following test:
> > 
> >   if (flag_pcc_struct_return && AGGREGATE_TYPE_P (type))
> >     return 1;
> > 
> > IMO the alignment should have no influence here, so where is this coming
> > from? 
> 
> STRICT_ALIGNMENT affects us in compute_record_mode and
> default_return_in_memory.  (Note that m68k_return_in_memory emulates
> default_return_in_memory with STRICT_ALIGNMENT 1.)
> 
> Given a return type, compute_record_mode computes a return mode.  If
> STRICT_ALIGNMENT is 1, compute_record_mode chooses BLKmode for the type. (See
> the last "if" block in compute_record_mode.)  default_return_in_memory simply
> returns 1 if it sees BLKmode.

I see.
What concerns me here is that this produces incompatibilities for ColdFire 
code between Linux and other targets. It also makes the support for this 
in libffi interesting (e.g. if you ever want Java support for ColdFire).

Since this is a special case I would seriously consider to ignore the 
alignment mode for this in m68k_return_in_memory. Since this is an ABI 
issue there probably should be an option to get the old behaviour.

bye, Roman