Re: [cft] excise gen_mem_addressof from ia64

[Jim Wilson <wilson at specifixinc dot com>]

On Sat, 2004-07-03 at 20:04, Richard Henderson wrote:
> I've now run this through a test cycle and it passed.  There may be
> better ways to approach this, but for the moment this is in the way
> of other queued patches.  So I've committed it.

No problem, I understand people want to get rid of addressof.  I've been
meaning to look at this, but office problems made it difficult to do
IA-64 work the last few weeks.  If there are problems resulting from
this change, I will try to deal with them.

I've now done a bootstrap and make check with and without the patch, and
there were no regressions.  Unfortunately, I built without Fortran,
because I don't have <gmp.h> installed on the machine.  That is a
problem I missed when tree-ssa got merged to mainline.  I have already
fixed this for next time.

I started to look at the MEMBER_TYPE_FORCES_BLK change you sugested, but
it seems the long double/union support was already broken.  I tried
writing a trivial testcase to test the support, and I got an ICE even
with an unpatched compiler.

union foo {
  long double ld;
} bar;

double
sub (union foo baz)
{
  return baz.ld / 2;
}

This fails because the ABI says the TImode union must be passed in an FP
reg, but FP regs can't hold TImode values.  This is OK because the union
only has 10 bytes of real data (XFmode), and the FP regs can hold XFmode
values, but the compiler doesn't know that.  If I define
MEMBER_TYPE_FORCES_BLK, then the compiler doesn't abort, but it thinks
the union takes up two FP regs which is wrong.  This is because we need
to do a BLKmode copy out of the FP regs, which is done using DImode
because that is the largest integer mode that fits in FP regs, and hence
we copy two FP regs to the stack.

This is so messed up that I am just going to create a bugzilla bug
report, and look at it later.  This is now bug #16364.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com