[LLVMdev] Just got bitten by accidentally using the wrong gcc

[Joachim Durchholz]

Am Freitag, den 21.03.2008, 06:56 -0700 schrieb Shantonu Sen:
> I recommend you don't parse version strings. In fact I switch the  
> check to use AC_COMPILE precisely for the reason that gcc --version is  
> totally unreliable and vendor specific. For example, what's the  
> regular expression that tells you what the GCC version is:
> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5470)  
> (Aspen 5470.3)

Rrright. -v isn't very helpful; I'd have thought it would.

Alternatives would be
  gcc -dumpversion
or __GNUC__, __GNUC_MINOR__, and __GNUC_PATCHLEVEL__ from inside a C
program. (I just checked, __GNUC_PATCHLEVEL is documented to be
available since 3.0, -dumpversion since 3.0.4 or possibly earlier.)

> Per the rest of this thread, you can't even be sure that gcc 4.x.y on  
> one linux distribution is compile the same as on another.

Sure. OTOH one could issue warnings instead of errors in those
situations that are difficult to diagnose exactly. Here's some
pseudocode, take a look at what's happening for 3.3.3 (which assumes
that we can identify cygwin but not SuSE 9.1):

-- snip --
  switch gcc-version
  1.*, 2.*)
    error "gcc before version 3.0 has several problems in the STL
      that effectively prevent it from compiling LLVM. Please upgrade
      to a newer gcc."
  3.2.2, 3.2.3)
    error "gcc 3.2.2 and 3.2.3 fail to compile LLVM with a bogus
      template error. Please upgrade to a newer gcc."
  3.3.3)
    if arch = cygwin then
      error "gcc 3.3.3 on Cygwin does not work. Please upgrade to a
      newer gcc."
    else
      warning "The version of GCC 3.3.3 shipped with SuSE 9.1 (and
        possibly others) does not compile LLVM correctly (it appears
        that exception handling is broken in some cases). Please
        download the FSF 3.3.3 or upgrade to a newer version of GCC."
  3.4.0)
    if arch = x86 then
      error "gcc 3.4.0 for x86 miscompiles portions of the code
        generator, causing an infinite loop in the llvm-gcc build when
        built with optimizations enabled (i.e. a release build). Please
        upgrade to a newer gcc."
  3.4.2)
    if arch = x86 then
      warning "gcc 3.4.2 for x86 miscompiles portions of the code
        generator, causing an infinite loop in the llvm-gcc build when
        built with full optimizations enabled (i.e. a release build).
        The workaround is to use -O2 instead of -O3 as optimization
        level, which has been set."
      activate OPTIMIZE_OPTION=-O2
  3.4.4)
    if arch = arm then
      warning "gcc 3.4.4 for ARM (CodeSourcery ARM 2005q3-2) miscompiles
        LLVM when building with full optimizations enabled.
        The workaround is to use -O1 instead of -O3 as optimization
        level, which has been set."
      activate OPTIMIZE_OPTION=-O1
  4.0.0)
    if arch = ia64 then
      error "gcc 4.0.0 for ia-64 miscompiles LLVM. Please upgrade to a
        newer version of gcc."
  4.1.1)
    error "gcc 4.1.1 fails to build LLVM with template concept check
      errors compiling some files.
      Please update to a newer version of gcc."
  4.1.2)
    warning "gcc 4.1.1 on OpenSuSE segfaults during libstdc++ build.
      Please update to a newer version of gcc if this is OpenSuSE."

  if arch = x86_64 && gcc-version = 3.4.* then
    error "gcc 3.4 for x86_64 miscompiles portions of LLVM. Please
      upgrade to a newer gcc."

  if Xcode 2.3 then
    warning "Xcode 2.3 crashes when compiling LLVM with full
      optimizations enabled.
      The workaround is to use -O1 instead of -O2 as optimization
      level, which has been set."
    activate OPTIMIZE_OPTION=-O2
-- snip --

I'm not sure how to best identify binutils. Assuming their version is in
binutils-version, we could do:

-- snip --
  switch binutils-version
  2.16.*)
    warning "Some 2.16.X versions of the ld linker will produce very
      long warning messages complaining that some ".gnu.linkonce.t.*"
      symbol was defined in a discarded section. You can safely ignore
      these messages as they are erroneous and the linkage is correct."
  2.17.*)
    warning "Binutils 2.17 contains a bug which causes huge link times
      (minutes instead of seconds) when building LLVM.
      Please upgrade to binutils 2.17.50.0.4 or later."
-- snip --


> If there are  
> test cases that you'd like to embed directly into the configure script  
> that will crash the compiler, that's probably worth doing up front.

Can't say anything for or against that. It's not the problem I was
having.

> For the "gcc miscompiles llvm" bugs, can we rely on anything other  
> than the testsuite?

These things cannot be tested before llvm is compiled, at which point
you're ready to run the test suite anyway.

Regards,
jo