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

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