[MLton] Sparc+linux

[Wesley W. Terpstra]

On Sun, Dec 19, 2004 at 10:39:44PM -0500, Matthew Fluet wrote:
> 
> > On Mon, Dec 20, 2004 at 02:08:45AM +0100, Wesley W. Terpstra wrote:
> > > On Sun, Dec 19, 2004 at 04:05:51PM -0500, Matthew Fluet wrote:
> > > > > Done. I've attached the build log for hello.sml:
> > > > > val _ = print "Hello world\n"
> > > >
> > > > MLton raised in 35.56 + 6.68 (16% GC)
> > > > shrinker raised unhandled exception: Subscript
> > > > 	Shrink.shrinkFunction.anon.incLabelMeaning ssa/shrink.fun 249.7
> >
> > Bug squashed.
> > It was a problem with compile options again, just like the other.
> 
> Could you elaborate?  When the bug manifests itself relatively well into a
> compile, it can sometimes point to some unwarrented assumption in the
> compiler.  A genuine "you can't do that on this architecture" bug usually
> just crashes when the program starts running.

To fix the the broken options that the mlton script was using for sparc, 
I copied options from the glibc. What I screwed up is that I copied
'-fstrict-aliasing' and overlooked that there was no 'no'.

'strict-aliasing' means that the compiler can assume that the code follows
C's aliasing rules. I already knew that MLton tosses these rules out the
window, but somehow got confused.

The regressions all worked, but probably b/c there was not enough code to
trip over gcc's optimization. Anyways, the generated C code does not follow
the aliasing rules of C, so that is certainly a bug too. 

I think a good goal for the c-codegen would be to replace '-w' with 
'-Wall -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings' and
solve all of the resulting warnings...

-- 
Wesley W. Terpstra