This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, RFC] PR 55403 + 55391
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 20 Nov 2012 16:55:14 +0000
- Subject: Re: [PATCH, RFC] PR 55403 + 55391
- References: <50ABB04E.5070705@redhat.com>
Richard Henderson <rth@redhat.com> writes:
> This assert looks to me like a "can this ever happen" sort of check.
> It quite apparently can.
>
> Although I'm a bit curious about the reasons we got to this point
> in the 55403 instance (unaligned TCmode memory, extracting a TFmode
> value), it's clear that one could intentionally write such a thing,
> rather than have it happen by accident, and that it should work.
>
> The following fills in what appears to be a blank. I assume this
> is the sort of thing you'd have intended?
Sorry, still haven't managed to reproduce this yet -- sparc bootstrap
still in slow progress, will try the alpha --with-long-double-128 thing
when I get home -- but what kind of bitfield memory were we trying to
create in the ICE case? The idea was that "adjust_object" is only ever
true for bitfield adjustments. We should then either be using an
integer or field mode whose size is picked up by:
if (defattrs->size_known_p)
size = defattrs->size;
or a BLKmode whose value is passed in via adjust_bitfield_address_size.
It sounds like I missed a case where the latter was needed.
Richard