On Thu, Oct 24, 2013 at 3:13 PM, Jakub Jelinek <ja...@redhat.com> wrote: > 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.
Sure, that was what I was saying all along ... but still, if we want to fix it in stor-layout.c then we have to fix it for all cases there, not just the zero-size array case (which I showed is not the only relevant case). Richard. > Jakub
