Hi,
On Wed, 27 Nov 2013 12:07:16, Jeff Law wrote:
>
> On 11/27/13 05:29, Bernd Edlinger wrote:
>> Hi,
>>
>> ping...
>>
>> this patch still open:
>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02291.html
>>
>> Note: it does, as it is, _not_ depend on the keep_aligning patch.
>> And it would fix some really nasty wrong code generation issues.
> Is there a testcase for this problem?
Yes,
the patch contains two test cases, one for
struct S { V a; V b[0]; } P __attribute__((aligned (1)))
and another for
struct S { V b[1]; } P __attribute__((aligned (1)))
V can be anything that has a movmisalign_optab or is SLOW_UNALIGNED_ACCESS
If V::b is used as flexible array, reading p->b[1] gives garbage.
We tried hard, to fix this in stor-layout.c by not using the mode of V
for struct S, but this created ABI-fallout. So currently the only possible
way to fix it seems to be in expansion, by letting expand_real_1 know that
we need a memory reference, even if it may be unaligned.
>
> My recommendation is to start a separate thread which focuses on this
> issue and only this issue.
>
If there are more questions of general interest, please feel free to start
in a new thread.
> jeff
>
Thanks
Bernd.
