On Thu, Oct 24, 2013 at 02:55:59PM +0200, Bernd Edlinger wrote:
> On Thu, 24 Oct 2013 12:18:43, Richard Biener wrote:
> >
> > On Thu, Oct 24, 2013 at 10:48 AM, Eric Botcazou <ebotca...@adacore.com>
> > wrote:
> >>> I think that is common practice to write array[1]; at the end of the
> >>> structure, and use it as a flexible array. The compute_record_mode has no
> >>> way to decide if that is going to be a flexible array or not.
> >>>
> >>> Sorry Eric, but now I have no other choice than to go back to my previous
> >>> version of part 2:
> >>>
> >>> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00222.html
> >>
> >> Why? Just set BLKmode in this case as well.
> >
> > Works for me if it works ABI-wise (which you say it should unless the
> > backend is buggy). Note that means mode_for_array should unconditionally
> > return BLKmode.
>
> Did you just propose:
But why would we want to penalize the generated code for this?
I mean, if some structure has a flexible array member or something similar
to it that we allow to be used as one, if we pass it as arguments, return
from functions etc., it will not have any bits beyond those and thus it
should be just fine to be passed in registers etc. We can only use those
extra bits if either we allocate them on the heap/stack (malloc, alloca,
...) or as a global or automatic variable with initializer that fills in the
zero sized array or flexible array member (GNU extensions?), but in either
of these cases the DECL_MODE or TYPE_MODE should be irrelevant.
So to me this really sounds like a bug in the expansion, certainly not
stor-layout.
Jakub
