On Fri, Nov 15, 2013 at 1:08 PM, Bernd Edlinger
<bernd.edlin...@hotmail.de> wrote:
>>>
>>> hmm...
>>> the above change is just not aggressive enough.
>>>
>>>
>>> with a slightly changed test case I have now got a
>>> recursion on the extract_fixed_bit_fields on ARM but
>>> interestingly not on powerpc:
>>>
>>> #include <stdlib.h>
>>>
>>> typedef struct {
>>> char pad;
>>> int arr[0];
>>> } __attribute__((packed)) str;
>>>
>>> str *
>>> foo (int* src)
>>> {
>>> str *s = malloc (sizeof (str) + sizeof (int));
>>> *src = s->arr[0];
>>> s->arr[0] = 0x12345678;
>>> return s;
>>> }
>>>
>>> Now I think about reverting that hunk back to what I had in mind initially:
>>>
>>> else if (MEM_P (str_rtx)
>>> && GET_MODE_BITSIZE (GET_MODE (str_rtx)) != 0
>>> && GET_MODE_BITSIZE (GET_MODE (str_rtx)) < GET_MODE_BITSIZE (word_mode)
>>> && bitnum % GET_MODE_BITSIZE (GET_MODE (str_rtx)) + bitsize
>>>> GET_MODE_BITSIZE (GET_MODE (str_rtx)))
>>> /* If the mode of str_rtx is too small or unaligned
>>> fall back to word mode for subsequent logic. */
>>> str_rtx = adjust_address (str_rtx, word_mode, 0);
>>>
>>> this fixes the recursion on the read side too. And it is limited to cases
>>> where the mode does not match the bitnum and bitsize parameters.
>>
>> But that's not conditional on -fstrict-volatile-bitfields and frankly it
>> doesn't
>> make sense to me. Why is the recursion not there for
>> -fno-strict-volatile-bitfields?
>>
>
> the problem here is different, than we thought. Both recursions have been
> observed initially only with volatile accesses and
> -fstrict-volatile-bitfields.
> That's why it looked like the right thing to do. But PR59134 shows clearly
> that both recursions have nothing to do with strict-volatile-bitfields. They
> happen just because the hardware is not always able to access unaligned data
> on one instruction. And the mode in str_rtx is sometimes too restrictive.
>
> Now in this test case, we have s, a packed structure, but malloc retruns a
> BIGGEST_ALIGNMENT. And at -O2 the back-end sees the larger alignment.
> But the mode of str_rtx is QImode, because that is the mode of the struct str.
> This mode is only good for accessing pad, but not for arr[0].
> It does never make sense to access 32 bits in QImode, especially if the memory
> is un-aligned. That is how this hunk resolves the issue.
But then why is the mode QImode in the first place? The access is
definitely of SImode.
Richard.
>> Richard.
>>
>>>
>>> Bernd.
>>>
>>>
>>>>
>>>>> Bernd.
>>>>>
>>>>>> Richard.
>>>>>>
>>>>>>> -Sandra
