llvm dev - Jul 2009 - [LLVMdev] switching to llvm-g++ as the host compiler

IANACE (I Am Not A Configury Expert :-), but I've been asked to  
reconfigure LLVM and LLVM-GCC to build with LLVM-GCC (perhaps more  
accurately, LLVM-G++).

The patches to do this are short.  In the LLVM tree, this suffices; it  
looks for LLVM-GCC first, and if that fails, falls back to GCC:

Index: llvm.test/autoconf/configure.ac
==================================================================---
llvm.test/autoconf/configure.ac     (revision 74729)
+++ llvm.test/autoconf/configure.ac     (working copy)
@@ -601,8 +601,8 @@

  dnl Check for compilation tools
  AC_PROG_CPP
-AC_PROG_CC(gcc)
-AC_PROG_CXX(g++)
+AC_PROG_CC([llvm-gcc gcc])
+AC_PROG_CXX([llvm-g++ g++])

  AC_PROG_NM
  AC_SUBST(NM)


Likewise, in our LLVM-GCC tree, this seems to work for Darwin/x86:

Index: llvm-gcc.test/configure.in
==================================================================---
llvm-gcc.test/configure.in  (revision 74729)
+++ llvm-gcc.test/configure.in  (working copy)
@@ -993,10 +993,10 @@
    # APPLE LOCAL begin dynamic-no-pic
    i[[3456789]]86-*-darwin*)
      host_makefile_frag="config/mh-x86-darwin"
-    # gcc can default to x86_64 code generation, avoid that
+    # llvm-gcc can default to x86_64 code generation, avoid that
      if test "${build}" = "${host}"; then
-      CC="${CC-gcc} -m32"
-      CXX="${CXX-g++} -m32"
+      CC="${CC-llvm-gcc} -m32"
+      CXX="${CXX-llvm-g++} -m32"
      fi
      ;;
    # APPLE LOCAL end dynamic-no-pic


I've done some light testing of these, and I'm convinced they will  
work, at least for those of us on Darwin.  The latter patch is Darwin/ 
x86-specific, and hopefully non-contentious.  I would hope the former  
patch wouldn't break anybody, but I thought I'd ask before applying it.

Of course, I'm omitting the diffs resulting from the re-auto- 
confiscation of both trees.  I was obliged to tweak all the version  
checks in the LLVM file AutoRegen.sh in order to get it to run :-),  
but no errors turned up after my hacking.  (Should AutoRegen.sh be  
updated too?)

Comments invited; if there's a better approach, please share.

stuart

On Mon, Jul 6, 2009 at 3:47 PM, Stuart Hastings<stuart at apple.com>
wrote:
> IANACE (I Am Not A Configury Expert :-), but I've been asked to
> reconfigure LLVM and LLVM-GCC to build with LLVM-GCC (perhaps more
> accurately, LLVM-G++).
>
> The patches to do this are short.  In the LLVM tree, this suffices; it
> looks for LLVM-GCC first, and if that fails, falls back to GCC:
Would it make sense to have configure bootstrap the current sources
instead of using whatever llvm-gcc is installed?
> Of course, I'm omitting the diffs resulting from the re-auto-
> confiscation of both trees.  I was obliged to tweak all the version
> checks in the LLVM file AutoRegen.sh in order to get it to run :-),
> but no errors turned up after my hacking.  (Should AutoRegen.sh be
> updated too?)
I was just asking about this in IRC. I couldn't grok why AutoRegen.sh
wouldn't work on a stock Leopard install. Fixing this would be most
welcome.

deep

On Jul 6, 2009, at 3:47 PM, Stuart Hastings wrote:
> The patches to do this are short.  In the LLVM tree, this suffices; it
> looks for LLVM-GCC first, and if that fails, falls back to GCC
Seems reasonable.

On Mon, Jul 6, 2009 at 3:47 PM, Stuart Hastings<stuart at apple.com>
wrote:
> IANACE (I Am Not A Configury Expert :-), but I've been asked to
> reconfigure LLVM and LLVM-GCC to build with LLVM-GCC (perhaps more
> accurately, LLVM-G++).
The attached patches affect the *tests*, not the actual builds
themselves; is that intentional?

-Eli

Please make sure when we are running the llvm test suite the "native"
executables are still built with gcc (or another compiler) unless it's  
explicitly specified to be llvm-gcc. Thanks.

Evan

On Jul 6, 2009, at 3:47 PM, Stuart Hastings wrote:
> IANACE (I Am Not A Configury Expert :-), but I've been asked to
> reconfigure LLVM and LLVM-GCC to build with LLVM-GCC (perhaps more
> accurately, LLVM-G++).
>
> The patches to do this are short.  In the LLVM tree, this suffices; it
> looks for LLVM-GCC first, and if that fails, falls back to GCC:
>
> Index: llvm.test/autoconf/configure.ac
> ==================================================================> ---
llvm.test/autoconf/configure.ac     (revision 74729)
> +++ llvm.test/autoconf/configure.ac     (working copy)
> @@ -601,8 +601,8 @@
>
>  dnl Check for compilation tools
>  AC_PROG_CPP
> -AC_PROG_CC(gcc)
> -AC_PROG_CXX(g++)
> +AC_PROG_CC([llvm-gcc gcc])
> +AC_PROG_CXX([llvm-g++ g++])
>
>  AC_PROG_NM
>  AC_SUBST(NM)
>
>
> Likewise, in our LLVM-GCC tree, this seems to work for Darwin/x86:
>
> Index: llvm-gcc.test/configure.in
> ==================================================================> ---
llvm-gcc.test/configure.in  (revision 74729)
> +++ llvm-gcc.test/configure.in  (working copy)
> @@ -993,10 +993,10 @@
>    # APPLE LOCAL begin dynamic-no-pic
>    i[[3456789]]86-*-darwin*)
>      host_makefile_frag="config/mh-x86-darwin"
> -    # gcc can default to x86_64 code generation, avoid that
> +    # llvm-gcc can default to x86_64 code generation, avoid that
>      if test "${build}" = "${host}"; then
> -      CC="${CC-gcc} -m32"
> -      CXX="${CXX-g++} -m32"
> +      CC="${CC-llvm-gcc} -m32"
> +      CXX="${CXX-llvm-g++} -m32"
>      fi
>      ;;
>    # APPLE LOCAL end dynamic-no-pic
>
>
> I've done some light testing of these, and I'm convinced they will
> work, at least for those of us on Darwin.  The latter patch is Darwin/
> x86-specific, and hopefully non-contentious.  I would hope the former
> patch wouldn't break anybody, but I thought I'd ask before applying
> it.
>
> Of course, I'm omitting the diffs resulting from the re-auto-
> confiscation of both trees.  I was obliged to tweak all the version
> checks in the LLVM file AutoRegen.sh in order to get it to run :-),
> but no errors turned up after my hacking.  (Should AutoRegen.sh be
> updated too?)
>
> Comments invited; if there's a better approach, please share.
>
> stuart
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Shouldn't it be using the compiler specified by --with-llvmgcc/--with- 
llvmgxx if specified? Normally that just gives a compiler driver for  
the test suite, but it seems appropriate to use here as well, since  
most people won't have llvm-gcc-4.2 built with --program-prefix=llvm-  
unless they do special configuration there as well.

Or maybe llvm-gcc-4.2 should be defaulting to --program-prefix=llvm-  
if --enable-llvm is used?

Shantonu

Sent from my MacBook

On Jul 6, 2009, at 5:34 PM, Evan Cheng wrote:
> Please make sure when we are running the llvm test suite the
"native"
> executables are still built with gcc (or another compiler) unless it's
> explicitly specified to be llvm-gcc. Thanks.
>
> Evan
>
> On Jul 6, 2009, at 3:47 PM, Stuart Hastings wrote:
>
>> IANACE (I Am Not A Configury Expert :-), but I've been asked to
>> reconfigure LLVM and LLVM-GCC to build with LLVM-GCC (perhaps more
>> accurately, LLVM-G++).
>>
>> The patches to do this are short.  In the LLVM tree, this suffices;  
>> it
>> looks for LLVM-GCC first, and if that fails, falls back to GCC:
>>
>> Index: llvm.test/autoconf/configure.ac
>>
==================================================================>> ---
llvm.test/autoconf/configure.ac     (revision 74729)
>> +++ llvm.test/autoconf/configure.ac     (working copy)
>> @@ -601,8 +601,8 @@
>>
>> dnl Check for compilation tools
>> AC_PROG_CPP
>> -AC_PROG_CC(gcc)
>> -AC_PROG_CXX(g++)
>> +AC_PROG_CC([llvm-gcc gcc])
>> +AC_PROG_CXX([llvm-g++ g++])
>>
>> AC_PROG_NM
>> AC_SUBST(NM)
>>
>>
>> Likewise, in our LLVM-GCC tree, this seems to work for Darwin/x86:
>>
>> Index: llvm-gcc.test/configure.in
>>
==================================================================>> ---
llvm-gcc.test/configure.in  (revision 74729)
>> +++ llvm-gcc.test/configure.in  (working copy)
>> @@ -993,10 +993,10 @@
>>   # APPLE LOCAL begin dynamic-no-pic
>>   i[[3456789]]86-*-darwin*)
>>     host_makefile_frag="config/mh-x86-darwin"
>> -    # gcc can default to x86_64 code generation, avoid that
>> +    # llvm-gcc can default to x86_64 code generation, avoid that
>>     if test "${build}" = "${host}"; then
>> -      CC="${CC-gcc} -m32"
>> -      CXX="${CXX-g++} -m32"
>> +      CC="${CC-llvm-gcc} -m32"
>> +      CXX="${CXX-llvm-g++} -m32"
>>     fi
>>     ;;
>>   # APPLE LOCAL end dynamic-no-pic
>>
>>
>> I've done some light testing of these, and I'm convinced they
will
>> work, at least for those of us on Darwin.  The latter patch is  
>> Darwin/
>> x86-specific, and hopefully non-contentious.  I would hope the former
>> patch wouldn't break anybody, but I thought I'd ask before
applying
>> it.
>>
>> Of course, I'm omitting the diffs resulting from the re-auto-
>> confiscation of both trees.  I was obliged to tweak all the version
>> checks in the LLVM file AutoRegen.sh in order to get it to run :-),
>> but no errors turned up after my hacking.  (Should AutoRegen.sh be
>> updated too?)
>>
>> Comments invited; if there's a better approach, please share.
>>
>> stuart
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Mon, Jul 6, 2009 at 3:47 PM, Stuart Hastings<stuart at apple.com>
wrote:

==================================================================> ---
llvm-gcc.test/configure.in  (revision 74729)
> +++ llvm-gcc.test/configure.in  (working copy)
> @@ -993,10 +993,10 @@
>    # APPLE LOCAL begin dynamic-no-pic
>    i[[3456789]]86-*-darwin*)
>      host_makefile_frag="config/mh-x86-darwin"
> -    # gcc can default to x86_64 code generation, avoid that
> +    # llvm-gcc can default to x86_64 code generation, avoid that
>      if test "${build}" = "${host}"; then
> -      CC="${CC-gcc} -m32"
> -      CXX="${CXX-g++} -m32"
> +      CC="${CC-llvm-gcc} -m32"
> +      CXX="${CXX-llvm-g++} -m32"
>      fi
>      ;;
>    # APPLE LOCAL end dynamic-no-pic
>
Stuart,

Here we are making two independent LOCAL changes.
1. use llvm-gcc & llvm-g++, if available
2. Force -m32

Pl. mention both changes explicitly in the comment.
-
Devang

On Tue, Jul 7, 2009 at 11:50 AM, Devang Patel<devang.patel at gmail.com>
wrote:
> On Mon, Jul 6, 2009 at 3:47 PM, Stuart Hastings<stuart at apple.com>
wrote:
>
> ==================================================================>>
--- llvm-gcc.test/configure.in  (revision 74729)
>> +++ llvm-gcc.test/configure.in  (working copy)
>> @@ -993,10 +993,10 @@
>>    # APPLE LOCAL begin dynamic-no-pic
>>    i[[3456789]]86-*-darwin*)
>>      host_makefile_frag="config/mh-x86-darwin"
>> -    # gcc can default to x86_64 code generation, avoid that
>> +    # llvm-gcc can default to x86_64 code generation, avoid that
>>      if test "${build}" = "${host}"; then
>> -      CC="${CC-gcc} -m32"
>> -      CXX="${CXX-g++} -m32"
>> +      CC="${CC-llvm-gcc} -m32"
>> +      CXX="${CXX-llvm-g++} -m32"
>>      fi
>>      ;;
>>    # APPLE LOCAL end dynamic-no-pic
>>
>
> Stuart,
>
> Here we are making two independent LOCAL changes.
> 1. use llvm-gcc & llvm-g++, if available
> 2. Force -m32
>
> Pl. mention both changes explicitly in the comment.
>
Also, we should fall back to a default of "gcc" and "g++" if
LLVM
isn't available.

-bw

On Jul 6, 2009, at 5:24 PM, Eli Friedman wrote:
> On Mon, Jul 6, 2009 at 3:47 PM, Stuart Hastings<stuart at apple.com>
> wrote:
>> IANACE (I Am Not A Configury Expert :-), but I've been asked to
>> reconfigure LLVM and LLVM-GCC to build with LLVM-GCC (perhaps more
>> accurately, LLVM-G++).
>
> The attached patches affect the *tests*, not the actual builds
> themselves; is that intentional?
I'm missing something significant here.  I tried my patch before  
posting it to the list, and I'm pretty sure that LLVM got compiled  
with a previously installed LLVM-GCC.  And the tests I ran seemed  
"normal" too (i.e. the right thing got tested).

Am I misunderstanding you?  Could you be more specific?  What,  
exactly, do you foresee going wrong?

Thank you in advance,

stuart