Richard Sandiford writes:
> Iain Sandoe writes:
>> On 17 Nov 2011, at 09:25, Andreas Krebbel wrote:
>>> On 11/17/2011 03:44 AM, David Edelsohn wrote:
Andreas,
This patch seems to have introduced a failure for all of the
gcc.dg-struct-layout tests on AIX.
gcc.dg-struc
> Ah, so in the BLKmode case, VALUE can still be a nonzero const_int?
Yes, I'd think so.
> What are the justification rules in that case? Naively, I'd have
> expected a store of (const_int 1) into a BLKmode field to set one
> of the bits to 1, but it sounds from the above like it depends on
> en
Eric Botcazou writes:
>> If so, it seems odd that we're using a property of STR_RTX to determine
>> the interpretation/justification of VALUE. That is, we're using
>> FIELDMODE before, rather than after:
>>
>> /* This is the mode we must force value to, so that there will be
>> enough subwo
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325#c4
>
> value was (subreg:DI (reg:TI 70) 8)
Not the original VALUE though, since it is 12-byte wide.
--
Eric Botcazou
> It's the interpretation and mode of VALUE that I'm worried about.
> Doesn't FIELDMODE describe STR_RTX (the stored bitfield) instead?
Yes, FIELDMODE is the mode of the target field.
> If so, it seems odd that we're using a property of STR_RTX to determine
> the interpretation/justification of V
> Being in stage 3 shouldn't stop us trying to fix bugs in the compiler:
> we're not in the final run-up to a release yet (that could still be five
> months away if history is anything to go by). It should just be a
> clamp-down on major new functionality.
But Richard's proposed change wasn't rea
On 21/11/11 08:02, Eric Botcazou wrote:
> This seems to be a little risky for stage 3 though.
Being in stage 3 shouldn't stop us trying to fix bugs in the compiler:
we're not in the final run-up to a release yet (that could still be five
months away if history is anything to go by). It should jus
On 11/23/2011 03:47 PM, Richard Sandiford wrote:
> Since Andreas was fixing C++ bugs, I assume the same situation occurs there.
> What does it look like in a C++ context?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325#c4
value was (subreg:DI (reg:TI 70) 8)
and fieldmode == BLKmode
-Andreas-
Eric Botcazou writes:
>> OK, I see how the two are different now, but I still don't get why the
>> current version is right. If we say words are 16 bits for simplicity,
>> and we're storing VALUE == 0x0001_2345 into a 3-byte BLKmode bitfield,
>> surely we want to store 0x01_2345 rather than 0x00_
> OK, I see how the two are different now, but I still don't get why the
> current version is right. If we say words are 16 bits for simplicity,
> and we're storing VALUE == 0x0001_2345 into a 3-byte BLKmode bitfield,
> surely we want to store 0x01_2345 rather than 0x00_0123?
Why? If you want th
Eric Botcazou writes:
>> What's the main potential problem you see? The backwards condition:
>>
>> (fieldmode == BLKmode ? BYTES_BIG_ENDIAN : WORDS_BIG_ENDIAN)
>>
>> should apply the same bit-for-bit mapping between source and target
>> as the patch applies.
>
> Not if the objects don't have
> What's the main potential problem you see? The backwards condition:
>
> (fieldmode == BLKmode ? BYTES_BIG_ENDIAN : WORDS_BIG_ENDIAN)
>
> should apply the same bit-for-bit mapping between source and target
> as the patch applies.
Not if the objects don't have the same size. In Ada we have B
Eric Botcazou writes:
>> Yeah, I don't think constants are any different here. One fix might be
>> to use simplify_expand_binop instead of extract_bit_field, as per the
>> patch below. The patch also restricts the shifting to forward walks,
>> as discussed in the PR trail.
>
> This looks fine to
> Yeah, I don't think constants are any different here. One fix might be
> to use simplify_expand_binop instead of extract_bit_field, as per the
> patch below. The patch also restricts the shifting to forward walks,
> as discussed in the PR trail.
This looks fine to me, please apply (with a few
Iain Sandoe writes:
> On 17 Nov 2011, at 09:25, Andreas Krebbel wrote:
>> On 11/17/2011 03:44 AM, David Edelsohn wrote:
>>> Andreas,
>>>
>>> This patch seems to have introduced a failure for all of the
>>> gcc.dg-struct-layout tests on AIX.
>>>
>>> gcc.dg-struct-layout-1/t001_test.h:8:1: internal
On 17 Nov 2011, at 09:25, Andreas Krebbel wrote:
On 11/17/2011 03:44 AM, David Edelsohn wrote:
Andreas,
This patch seems to have introduced a failure for all of the
gcc.dg-struct-layout tests on AIX.
gcc.dg-struct-layout-1/t001_test.h:8:1: internal compiler error: in
int_mode_for_mode, at st
On 11/17/2011 03:44 AM, David Edelsohn wrote:
> Andreas,
>
> This patch seems to have introduced a failure for all of the
> gcc.dg-struct-layout tests on AIX.
>
> gcc.dg-struct-layout-1/t001_test.h:8:1: internal compiler error: in
> int_mode_for_mode, at stor-layout.c:424
>
> After your change,
Andreas,
This patch seems to have introduced a failure for all of the
gcc.dg-struct-layout tests on AIX.
gcc.dg-struct-layout-1/t001_test.h:8:1: internal compiler error: in
int_mode_for_mode, at stor-layout.c:424
After your change, int_mode_for_mode now is passed VOIDmode because
the rtx is a CO
Hi,
starting with r177691 store_bit_field is used for source operands
which cannot be covered exactly with word mode chunks. So far
store_bit_field does not seem to handle that correctly. With the
attached patch extract_bit_field is used for the remaining bits of the
source on big endian targets
19 matches
Mail list logo
