[AD] END_OF_FUNCTION problems in gcc 3.4?

[Sven Sandberg <svens@xxxxxxxxxx>]

Hello,
It seems gcc 3.4 includes changes that may break the functionality of 
END_OF_FUNCTION(). From http://gcc.gnu.org/gcc-3.4/changes.html :

----------------------
The new unit-at-a-time compilation scheme has several compatibility issues:

    * The order in which functions, variables, and top-level asm 
statements are emitted may have changed. Code relying on some particular 
ordering needs to be updated. The majority of such top-level asm 
statements can be replaced by section attributes.
----------------------

This "unit-at-a-time compilation scheme" is a new optimization in gcc 
3.4, implied by -funit-at-a-time or -O2.

The END_OF_FUNCTION(func) construct in djgpp relies on a particular 
ordering of functions: it declares a new function (called func_end), and 
then LOCK_FUNCTION(func) locks all code between func and func_end. This 
clearly does not work if func and func_end have been reordered.

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.").

But a bigger problem is that users of Allegro need to address the same 
issue. We could simply add to the documentation of END_OF_FUNCTION() 
that djgpp users should not use -O2 or higher under gcc 3.4 or higher. 
But it's not nice that they have to know about it, especially since 
people may develop under other systems and not see the bug, and in any 
case it may be a hard to find bug.

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?)

/Sven