Bug #340: 1.9/trunk does not work when compiled with llvm-gcc4 2.3 (gcc 4.2.1)

• Status: Third Party's Issue
• Assignee: ko1 (Koichi Sasada)
• Target version: 3.0
• ruby -v: -

[roberto (Ollivier Robert)]

=begin
Ive tried llvm-gcc4 (http://www.llvm.org/) on both FreeBSD 7.0 & MacOS X 10.4 and both shows the same behaviour. When configured with llvm-gcc as compiler, everything compiles fine but the first time miniruby is run (see below), it is spinning away, eating CPU circles and had to be killed with -9.

./miniruby -I../lib -I.ext/common -I./- -r../ext/purelib.rb ../enc/make_encdb.rb ../enc encdb.h.new

Using built-in specs.
Target: x86_64-portbld-freebsd7.0
Configured with: ./../configure --enable-llvm=/usr/local --enable-languages=c,c++ --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-prefix=llvm- --libdir=/usr/local/lib/llvm-gcc-2.3 --with-gxx-include-dir=/usr/local/lib/llvm-gcc-2.3/include/c++ --libexecdir=/usr/local/lib/llvm-gcc-2.3 --infodir=/usr/local/llvm-gcc --disable-shared --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/llvm-gcc x86_64-portbld-freebsd7.0
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5555) (LLVM build)

BTW the configure script has a problem (I can open another ticket if you want) in that even if I specify CFLAGS="-O -pipe", the generated Makefile ends up with CFLAGS set to "-O -pipe -O2 -g"...
=end

[roberto (Ollivier Robert)]

=begin
1.8.6-P110 compiles fine BTW:

...
compiling win32ole
compiling zlib
llvm-gcc-4.2 -I. -I../.. -I../../.. -I../../../ext/zlib -DHAVE_ZLIB_H -DOS_CODE=OS_UNIX -fno-common -O -pipe -pipe -fno-common -c ../../../ext/zlib/zlib.c
cc -dynamic -bundle -undefined suppress -flat_namespace -o ../../.ext/i686-darwin8.11.1/zlib.bundle zlib.o -L"." -L"../.." -L. -lz -lpthread -ldl -lobjc
making ruby
llvm-gcc-4.2 -O -pipe -pipe -fno-common -DRUBY_EXPORT -L. main.o -lruby-static -lpthread -ldl -lobjc -o ruby
1440 [9:24] roberto@roberto-al:ruby-1.8.6-p110/build> make test
test succeeded

=end

[ko1 (Koichi Sasada)]

• Assignee set to ko1 (Koichi Sasada)

=begin

=end

[ko1 (Koichi Sasada)]

• Priority changed from Normal to 3

=begin

=end

[yugui (Yuki Sonoda)]

• Target version set to 3.0

=begin
Ruby currently does not support llvm-gcc, but in the future ....
=end

[roberto (Ollivier Robert)]

• File Picture_1.png Picture_1.png added

=begin
I posted some more data on ruby-talk. What I don't see is in which way is it so different that a llvm-compiled binary would spin and not the 1.8 one. I understand that there is a world between the two ruby with respect to bytecode, VM and all that but why just using a different compiler break? Is the 1.9 code so tied to gcc-specific features/code?
=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:19041] [Bug #340] 1.9/trunk does not work when compiled with llvm-gcc4 2.3 (gcc 4.2.1)"
on Tue, 30 Sep 2008 20:43:48 +0900, Ollivier Robert [e-mail] writes:

|I posted some more data on ruby-talk. What I don't see is in which way is it so different that a llvm-compiled binary would spin and not the 1.8 one. I understand that there is a world between the two ruby with respect to bytecode, VM and all that but why just using a different compiler break? Is the 1.9 code so tied to gcc-specific features/code?

Perhaps we've just hit slightest incompatibility between compilers. I
know llvm-gcc is a great piece of code, but still there could be bugs
or incompatibility. YARV is a VERY complex code for compilers.

						matz.

=end

[ash.gti (john harrison)]

=begin
I was able to get Ruby 1.9.1 RC2 to compile and run if I set:

#define RUBY_SETJMP(env) setjmp(env)
#define RUBY_LONGJMP(env,val) longjmp(env,val)

I don't know exactly why, but the llvm-gcc doesn't do __builtin_longjmp and __builtin_setjmp properly, but if you have it use just setjmp and longjmp it seems to compile. It passed most of the tests.

Btw, I am using OS X 10.5.6; llvm from mac ports:

Target: i686-apple-darwin9
Configured with: /var/tmp/llvmgcc42/llvmgcc42-2039~2/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/Developer/usr/llvm-gcc-4.2/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-gxx-include-dir=/usr/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --enable-llvm=/Developer/usr/local --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5555) (LLVM build 2039)

=end

[roberto (Ollivier Robert)]

• File Picture_3.png Picture_3.png added

=begin
Just trying to compile trunk-after-1.9.1 (#22011) using llvm-gcc-4.2 (aka llvm-2.4). miniruby still spins unless configure is given the "--with-setjmp-type=setjmp" parameter. Seems to be running fine compiled like this. Interestingly enough, when I first compiled it w/o the option, the call graph from "Instrument.app" is different from the previous one.
=end

[marcandre (Marc-Andre Lafortune)]

• Category set to build
• ruby -v set to -

=begin

=end

[mame (Yusuke Endoh)]

• Status changed from Open to Third Party's Issue

=begin
Hi,

The issue looks like a fault of llvm-gcc.

I set this ticket as Third Party's issue.
Please report to llvm-gcc community.

BTW, where is the sense in compiling with llvm-gcc to normal
object file?

--
Yusuke Endoh [e-mail]
=end

[jonforums (Jon Forums)]

=begin

BTW, where is the sense in compiling with llvm-gcc to normal object file?

You may find this LLVM intro (PDF) helpful in answering your question

http://llvm.org/pubs/2008-10-04-ACAT-LLVM-Intro.pdf

Jon
=end

[mame (Yusuke Endoh)]

=begin
2010/4/22 Jon Forums [e-mail]:

BTW, where is the sense in compiling with llvm-gcc to normal object file?

You may find this LLVM intro (PDF) helpful in answering your question

http://llvm.org/pubs/2008-10-04-ACAT-LLVM-Intro.pdf

I understand the worth of LLVM.
But this ticket is not about compiling into LLVM bytecode, but
compiling into normal object file with llvm-gcc, isn't it?
I think it has no sense but debugging llvm-gcc.

--
Yusuke Endoh [e-mail]

=end

[jonforums (Jon Forums)]

=begin

I understand the worth of LLVM.
But this ticket is not about compiling into LLVM bytecode, but
compiling into normal object file with llvm-gcc, isn't it?

My understanding of the issue is similar to yours; whether llvm-gcc can be used to compile Ruby into normal object files.

My impression (perhaps incorrect) was also that the ticket's concern was whether the build environment could be made to allow the use of llvm-gcc as a compiler.

FWIW, my current interest is in using llvm-gcc to build Ruby to take advantage of the following:

• LLVM optimizer - LLVM replaces GCC's optimizer and code generator (execution time, compile time, generated code size)
• safe to mix and match .o files between GCC and LLVM-gcc compilers
• safe to call into other libraries build by other compilers

Whether the above turn out to be true, I'm still investigating. However I've had good results so far as I try using the MinGW port of llvm-gcc (as a compiler) for building gvim and Python extensions on Windows and as time permits, I plan to test more with Ruby. As such, I'm also interested in Ruby and Ruby's build system being able to use llvm-gcc as a compiler.

If I misunderstood the ticket's real issue, pardon the noise.

Jon

p.s. - fyi, there are other build issues I've found when using llvm-gcc such as ensuring binutils windres calls the correct compiler when handling Windows resource files, such as adding something like the following to rules:

$(WINDRES) --preprocessor="$(CC) -E -xc" -DRC_INVOKED

p.p.s - If you get a chance and haven't done so already, take a look at the "LLVM as a C and C++ compiler" section of the above mentioned PDF for some SPEC 2000 results.
=end

[jonforums (Jon Forums)]

=begin
forgot a link to other more recent llvm-gcc/clang vs. gcc 4.x comparisons

http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1
=end

[mame (Yusuke Endoh)]

=begin
Hi,

2010/4/22 Jon Forums [e-mail]:

p.p.s - If you get a chance and haven't done so already, take a look at the "LLVM as a C and C++ compiler" section of the above mentioned PDF for some SPEC 2000 results.

Ah, very sorry. I didn't know llvm-gcc uses its own code generator for
even normal object code.

Ruby deeply uses setjmp/longjmp and many non-guraranteed feature of C89.
So it would be very tough test for llvm-gcc :-)

BTW, according to OP, build seems to success with --with-setjmp-type=setjmp.
I'm curious how fast ruby runs.

--
Yusuke Endoh [e-mail]

=end

[jonforums (Jon Forums)]

=begin

BTW, according to OP, build seems to success with --with-setjmp-type=setjmp.

Good point; it appears that it closes the specific issue. Anyone who feels strongly about build mods needed for llvm-gcc/clang can always open up a new feature request :)

Thanks for the background info.

Jon
=end