Re: [AD] END_OF_FUNCTION problems in gcc 3.4?

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> I guess this could be fixed in Allegro's source files, by using -O1
> instead of -O2 on all files using LOCK_FUNCTION() (the gcc changelog
> says "As a temporary workaround, -fno-unit-at-a-time can be used, but
> this scheme may not be supported by future releases of GCC.").

-O2 -fno-unit-at-a-time would probably be better.  And note that, once
-fno-unit-at-a-time is removed, -O1 will do unit-at-a-time compilation too.

> Does anyone know more about this optimization? I mean, maybe in this
> particular case func and func_end will not be rearranged, or maybe there
> is some better way to guarantee that they will not be rearranged. (E.g.,
> the same changelog says that functions are topologically sorted with
> respect to the call graph. If this is the only rule by which functions
> are rearranged, there is no need to reorder func and func_end since none
> of them calls the other, but can we be sure?)

I happen to have studied a little the sorting algorithm used in the
callgraph code of GCC and I can say one thing for sure: it already changed
between the 3.4.x releases and the future 3.5.0 release.  So I don't think
you can rely on any ordering between top-level objects.  In particular, the
ordering might depend on the leaf-iness of 'func'.

--
Eric Botcazou