[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.

Great! They all look good except one.
The test "for GNU preprocessor" never fails because whether the macro  
exists or not does not influence anything. Before the change the value  
returned from main was the indication if the macro was set or not. I think  
the test can be fixed by letting the compilation fail when __GNUC__ is  
undefined:

diff --git a/src/racket/configure.ac b/src/racket/configure.ac
index 92af108..15b6742 100644
--- a/src/racket/configure.ac
+++ b/src/racket/configure.ac
@@ -801,7 +801,7 @@ AC_COMPILE_IFELSE(
     #ifdef __GNUC__
      return 0;
     #else
-    return 1;
+    if; // should fail on any valid c compiler
     #endif
     }, using_gnu_cpp=yes, using_gnu_cpp=no)
  if test "$using_gnu_cpp" = "yes" ; then


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

You are probably right. We will most likely have to carry gccs default  
i386 burden around until 32bit platforms die out.

Tobias



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