[racket-dev] Compilation of 5.3.2 fails on some compilers

Thanks for the patch. I've changed more AC_TRY_RUN()s to
AC_COMPILE_IFELSE()s and AC_LINK_IFELSE()s to work better for
cross-compilation, and I'll push that soon.

I don't think I agree about the compare-and-swap test. If the
compiler's default mode on a given machine is i386, then I don't think
the `configure' script or other parts of the Racket build should try to
override that. The choice of architecture should be left up to the user
and system defaults.

At Sat, 2 Feb 2013 01:26:06 +0100, Tobias Hammer wrote:
> Thanks for the detailed explanation. It's a lot clearer now why it's  
> needed.
> 
> But i figured out that the real culprit was cross-compilation in  
> combination with autoconf. autoconfs default rule for test results when  
> running cross-compilation was set to noinline not available, and therefore  
> setting the define to expand to nothing.
> It should be, in this case and for inline too, enough to check for  
> compilation, not for running the test. If the attribute is not supported  
> the compilation should already fail.
> I attached a patch to change these two test and fix a typo. Compilation  
> runs without any errors then.
> 
> While checking for more similar tests i noticed that the test for  
> compare-and-swap is completely screwed up. Even on a modern Core i7 with  
> gcc 4.x it fails with default settings on a 32bit OS. The CAS builtins  
> need at least -march=i686 there to run, otherwise you get undefined symbol  
> errors. That never happens on 64bit OS because gcc knows that every x86-64  
> processor has CAS operations. I think it would be a good choice to set  
> -march when using gcc with 32bit OS, assuming at least a pentium pro  
> processor might be ok nowadays. It must be remain unset for 64bit, or gcc  
> throws errors. Unfortunately my autoconf skills are far too limited to  
> provide a patch.
> 
> Tobias
> 
> 
> 
> On Fri, 01 Feb 2013 19:30:15 +0100, Matthew Flatt <mflatt at cs.utah.edu>  
> wrote:
> 
> > At Fri, 1 Feb 2013 12:23:59 +0100, Tobias Hammer wrote:
> >> i am getting the following error when i try to compile racket-textual  
> >> on a
> >> a version of gcc that does not support the 'noinline' attribute:
> >>
> >> xsrc/place.c: In function 'place_start_proc':
> >> xsrc/place.c:2793: warning: assignment makes pointer from integer  
> >> without
> >> a cast
> >> xsrc/place.c: At top level:
> >> xsrc/place.c:3185: error: conflicting types for
> >> 'place_start_proc_after_stack'
> >> xsrc/place.c:2793: note: previous implicit declaration of
> >> 'place_start_proc_after_stack' was here
> >>
> >> The cause is that the forward declaration of
> >> 'place_start_proc_after_stack' is missing. It was originally there (L  
> >> 95)
> >> but the MZ_DO_NOT_INLINE macro expands to nothing, effectively removing
> >> the declaration.
> >>
> >> The wrapping macro was added in commit 9692765e2 but the commit message
> >> gives no real reason why it is needed. I am a bit worried to revert the
> >> change because i don't know which bug i could reintroduce. What would be
> >> the correct fix to compile 5.3.2?
> >
> > Hopefully, the right fix is to make `MZ_DO_NOT_INLINE(decl)' expand to
> > `decl' if no "no inline" annotation is available.
> >
> > If place_start_proc_after_stack() is inlined at its only use, whcih is
> > in place_start_proc(), then a new place will not register its stack
> > bounds correctly for the implementation of continuations. The
> > implementation of continuations assumes that local variables in
> > place_start_proc_after_stack() are shallower on the stack than
> > variables in place_start_proc(), and inlining can defeat that
> > assumption.
> >
> > If there's no way to say "no inlining" and inlining of that function
> > can still happen, then we'll have to work harder to confuse the C
> > compiler. The same is true for any other use of MZ_DO_NOT_INLINE().