[MLton-user] experimental release 20051109

[Matthew Fluet]

> I tried compiling with -codegen c -profile time using the following
> two versions of {Declare,}ProfileLabel on my Linux machine with gcc
> 3.3.5.
>
> ----------------------------------------------------------------------
> #define DeclareProfileLabel(l)                  \
>        void l()
> #define ProfileLabel(l)                                         \
>        __asm__ __volatile__ (".globl _" #l "\n_" #l ":" : : )
> ----------------------------------------------------------------------
> #define DeclareProfileLabel(l)                                  \
> 	extern void l () asm (#l "_internal")
> #define ProfileLabel(l)                                 \
>        __asm__ __volatile__ (#l "_internal:" : : )
> ----------------------------------------------------------------------
>
> Both of them failed, when trying to run the executable, with
>
>  Max profile label is 0 -- something is wrong.
>
> Am I doing something wrong?

I don't think so, but now that I think about it, I don't know if I 
actually tried running the executables last night.  I'll try these 
variations with gcc 4.0.1 tonight.

> Since MLton's time profiling works with gcc 2.9x and 3.x, which are
> the most common gcc's around, and {Declare,}ProfileLabel is very
> tricky and dependent on gcc version and platform, I'm reluctant to
> change them just before the release.  Also, since gcc 4.x has a new
> requirement for aliasing and requires -fno-tree-ch to work (even with
> new definitions of {Declare,}ProfileLabel), it seems to me like the
> right solution for this release is to not change anything for all
> existing platform/gcc combinations, and to only introduce new
> behaviors when we encounter gcc 4.0.

Well, we're going to fairly rapidly encounter them.  I believe that MacOSX 
ships with (or at least updates to) gcc 4.0, so we need to handle that 
platform correctly.  And many linux distros are starting to ship with it. 
So, it's going to be an issue.

> So, I propose the following two changes
>
> 1. We put tests in main.fun to add -fno-tree-ch if
>    (a) we're using gcc 4.x, and
>    (b) time profiling is on, and
>    (c) the C codegen is being used
>
> 2. Put an #ifdef in c-chunk.h that uses the extern void definition
>    of DeclareProfileLabel if gcc version is 4.x (assuming someone has
>    verified that that works with gcc 4.x).

That seems fair.

> Alternatively, we could change nothing, and simply document the
> -fno-tree-ch solution, since, at least for now, the current definition
> of {Declare,}ProfileLabel works with that (unless I've
> misunderstood).

Well, the current definition of {Declare,}ProfileLabel doesn't work with 
gcc 4 on non-Apple archs with the C codegen (i.e., the default behavior on 
Solaris).  Now, I don't know the prevelance of gcc 4.0 on that 
architecture.

So, I think we need change #2 even if we just document the -fno-tree-ch 
solution.