On Tue, Nov 27, 2012 at 11:45 PM, Ramana Radhakrishnan
<[email protected]> wrote:
> On Tue, Nov 27, 2012 at 8:22 PM, Richard Sandiford
> <[email protected]> wrote:
>> Ramana Radhakrishnan <[email protected]> writes:
>>>> Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
>>>> Also tested by making sure that there were no changes in assembly
>>>> output for a set of gcc .ii files. On the other hand, the -march=octeon
>>>> output for a set of mips64-linux-gnu gcc .ii files showed the optimisation
>>>> kicking in as hoped.
>>>
>>> This sequence of patches caused a regression in
>>> gcc.target/arm/volatile-bitfields-1.c . I haven't reviewed the patch
>>> stack in great detail yet, but it looks like this sequence of patches
>>> doesn't take the ARM volatile bitfields into account. (193600 is fine,
>>> 193606 is not).
>>
>> Looks like I was wrong to drop the conditions from patch 5.
>> Please could you try the attached?
>
> Fixes volatile-bitfields-1.c but appears to break volatile-bitfields-4.c :( .
Can arm folks please re-implement strict volatile bitfields in terms of
DECL_BIT_FIELD_REPRESENTATIVE as I suggested elsewhere?
Thus, adjust stor-layout.c to compute a proper representative honoring
strict volatile bitfield semantics?
Thanks,
Richard.
> Ramana
>
>>
>> Richard
>>
>>
>> gcc/
>> * expmed.c (adjust_bit_field_mem_for_reg): Add handling of volatile
>> bitfields.
>>
>> Index: gcc/expmed.c
>> ===================================================================
>> --- gcc/expmed.c 2012-11-27 19:09:18.000000000 +0000
>> +++ gcc/expmed.c 2012-11-27 19:09:33.314634741 +0000
>> @@ -372,6 +372,15 @@ adjust_bit_field_mem_for_reg (enum extra
>> bitregion_end, MEM_ALIGN (op0),
>> MEM_VOLATILE_P (op0));
>> enum machine_mode best_mode;
>> + if (MEM_VOLATILE_P (op0) && flag_strict_volatile_bitfields > 0)
>> + {
>> + while (iter.next_mode (&best_mode))
>> + if (GET_MODE_SIZE (best_mode) == MEM_SIZE (op0))
>> + return narrow_bit_field_mem (op0, best_mode, bitsize, bitnum,
>> + new_bitnum);
>> + return NULL_RTX;
>> + }
>> +
>> if (iter.next_mode (&best_mode))
>> {
>> /* We can use a memory in BEST_MODE. See whether this is true for
