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

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Fri Feb 1 13:30:15 EST 2013

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

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().

Posted on the dev mailing list.