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

[Tobias Hammer]

Thanks for the detailed explanation. It's a lot clearer now why it's needed.

Tobias

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. On Fri, 01 Feb 2013 19:30:15 +0100, Matthew Flatt <mfl...@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':

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

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?

xsrc/place.c:2793: warning: assignment makes pointer from integer without 'place_start_proc_after_stack' is missing. It was originally there (L 95)

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

configure.ac.patch
Description: Binary data

_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev