Re: Variable order and location within the section - optimization level dependent

[Ian Lance Taylor <iant@google.com>]

On Mon, Oct 21, 2013 at 2:46 AM, Fabian Cenedese <Cenedese@indel.ch> 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