[MLton-user] experimental release 20051109

[Matthew Fluet]

> As another data point, I get errors with time profiling with gcc 4.0.1 on 
> x86-linux with -codegen c:
>
> [fluet@localhost temp]$ mlton-stable -verbose 1 -profile time -codegen c 
> -keep g -keep o z.sml
> MLton MLTONVERSION (built Sat Nov 12 16:56:13 2005 on localhost.localdomain)
> MLton starting
>   Compile SML starting
>      pre codegen starting
>      pre codegen finished in 1.92 + 1.02 (35% GC)
>      C code gen starting
>      C code gen finished in 0.02 + 0.00 (0% GC)
>   Compile SML finished in 1.94 + 1.02 (34% GC)
>   Compile C and Assemble starting
>      gcc -std=gnu99 -c -I/home/fluet/mlton/mlton-stable/build/lib/include \
>          -O1 -fno-strict-aliasing -fomit-frame-pointer -w -m32 \
>          -mtune=opteron -o z.1.o z.1.c
> z.1.c:162: error: 'MLtonProfile0 aliased to undefined symbol MLtonProfile0_internal'
> z.1.c:163: error: 'MLtonProfile1 aliased to undefined symbol MLtonProfile1_internal'
> ...

Looking through the gcc documents, I see the following description for the 
alias attribute for gcc 3.4.4:

`alias ("TARGET")'
      The `alias' attribute causes the declaration to be emitted as an
      alias for another symbol, which must be specified.  For instance,

           void __f () { /* Do something. */; }
           void f () __attribute__ ((weak, alias ("__f")));

      declares `f' to be a weak alias for `__f'.  In C++, the mangled
      name for the target must be used.

      Not all target machines support this attribute.

The description for the alias attribute for gcc 4.0.1 is:

`alias ("TARGET")'
      The `alias' attribute causes the declaration to be emitted as an
      alias for another symbol, which must be specified.  For instance,

           void __f () { /* Do something. */; }
           void f () __attribute__ ((weak, alias ("__f")));

      declares `f' to be a weak alias for `__f'.  In C++, the mangled
      name for the target must be used.  It is an error if `__f' is not
      defined in the same translation unit.

      Not all target machines support this attribute.


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.

If I use the __APPLE_CC__ macros for DeclareProfileLabel and ProfileLabel, 
then I can reproduce John's errors:

[fluet@localhost temp]$ mlton-stable -verbose 1 -profile time -codegen c -keep g -keep o z.sml
MLton MLTONVERSION (built Sat Nov 12 16:56:13 2005 on 
localhost.localdomain)
MLton starting
    Compile SML starting
       pre codegen starting
       pre codegen finished in 1.97 + 0.98 (33% GC)
       C code gen starting
       C code gen finished in 0.02 + 0.00 (0% GC)
    Compile SML finished in 1.99 + 0.98 (33% GC)
    Compile C and Assemble starting
       gcc -std=gnu99 -c -I/home/fluet/mlton/mlton-stable/build/lib/include \
           -O1 -fno-strict-aliasing -fomit-frame-pointer -w -m32 \
           -mtune=opteron -o z.1.o z.1.c
/tmp/ccCIrOFk.s: Assembler messages:
/tmp/ccCIrOFk.s:515: Error: symbol `_MLtonProfile96' is already defined
/tmp/ccCIrOFk.s:661: Error: symbol `_MLtonProfile83' is already defined
/tmp/ccCIrOFk.s:697: Error: symbol `_MLtonProfile81' is already defined
...

I note that this is a subset, but not all of the profile labels.  Like 
John, these errors go away with -00 option.  They also go away with 
-fno-inline option, which was my guess as to how gcc was duplicating code.