On Mon, Oct 21, 2013 at 2:46 AM, Fabian Cenedese <Cenedese@xxxxxxxx> wrote: > > I'll have to side with the OP here. We also use code that relies on the order > of the toplevel items so we need to use the no-reorder flag, no problem there. > So I was eagerly reading this thread to find other ways to achieve the same > result (there don't seem to be, that's okay). > > However reading the documentation I find it hard to see any other meaning > than that "there are attributes that do the same as -fno-toplevel-reorder". If > there aren't any attributes for this precise case then what's this sentence > doing in the -fno-toplevel-reorder section? Well, OK. I just committed a patch to add "when possible," so the sentence now reads "For new code, it is better to use attributes when possible." > I think these approaches where one could use attributes to influence > the ordering should be mentioned here and also where it's not possible. > Otherwise people might start looking for these attributes that don't > exist (at least 2 people now :) I don't know how to enumerate the cases because I don't know what people use -fno-toplevel-reorder for. I continue to believe that it is always possible to rework your code using attributes. For the OP's case a struct plus #define macros would have addressed the case, until the code was very unusual. Ian
