On 11/28/13 03:24, Bernd Edlinger wrote:
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.
Well, my point is there's this thread that deals with multiple issues;
the message with the patch itself references prior versions of the patch
and sorting out any discussion that relates strictly to the outstanding
patch is nontrivial.
Hence my request to repost the patch as a new independent thread.
Include the testcase and a reference to any current bugzilla bugs.
jeff
