[MLton-user] experimental release 20051109

[Matthew Fluet]

>> Note that it is now an error if the alias symbol is not defined in the same 
>> translation unit.  We define the profile label with inline assembly, which 
>> apparently is not accepted as a definition of the label:
>> 
>> #define ProfileLabel(l)                                 \
>>        __asm__ __volatile__ (#l "_internal:" : : )
>> 
>> 
>> Unfortunately, I now see that we don't follow these definition when 
>> __APPLE_CC__ is defined (which is presumably the case on MacOSX), so this 
>> may be a separate  gcc 4.0.1 incompatibility.

Looking through the SVN logs, I see that __APPLE_CC__ got different 
implementations of DeclareProfileLabel/ProfileLabel because "Darwin's gcc 
didn't like the __attribute__ magic that I used to create profile labels 
in C".  Since the ProfileLabel macro is simply inline assembly in all both 
Darwin and other platforms, I assume the problem arose with the 
DeclareProfileLabel macro and the alias attribute.

> With regards to our declaration/definition of profile labels, an option is to 
> change
>
> #define DeclareProfileLabel(l)                                  \
>        void l() __attribute__ ((alias (#l "_internal")))
>
> to
>
> #define DeclareProfileLabel(l)                                  \
>        extern void l () asm (#l "_internal")
>
> which has essentially the same effect: the uses of the profile labels in C 
> code, (namely, to populate the sourceLabels array) will appear in the 
> assembly with the "_internal" suffix.  The advantage of the asm label 
> approach is that we can label it extern and gcc won't look for it in the 
> current compilation unit.

As this change appears to be necessary for gcc 4.0.1 on other platforms, 
perhaps the asm label approach is supported by gcc 3.4 on Darwin, in which 
case we could unify the macros again.