Bug #340

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

Added by Ollivier Robert almost 6 years ago. Updated almost 3 years ago.

[ruby-core:17883]
Status:Third Party's Issue
Priority:Low
Assignee:Koichi Sasada
Category:build
Target version:Next Major
ruby -v:- Backport:

Description

=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: x8664-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

Picture_1.png - Picture of the call stack. (111 KB) Ollivier Robert, 09/30/2008 08:44 PM

Picture_3.png - Call graph (174 KB) Ollivier Robert, 02/03/2009 10:50 PM

History

#1 Updated by Ollivier Robert over 5 years ago

=begin
1.8.6-P110 compiles fine BTW:

...
compiling win32ole
compiling zlib
llvm-gcc-4.2 -I. -I../.. -I../../.. -I../../../ext/zlib -DHAVEZLIBH -DOSCODE=OSUNIX -fno-common -O -pipe -pipe -fno-common -c ../../../ext/zlib/zlib.c
cc -dynamic -bundle -undefined suppress -flatnamespace -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 roberto@roberto-al:ruby-1.8.6-p110/build> make test
test succeeded

=end

#2 Updated by Koichi Sasada over 5 years ago

  • Assignee set to Koichi Sasada

=begin

=end

#3 Updated by Koichi Sasada over 5 years ago

  • Priority changed from Normal to Low

=begin

=end

#4 Updated by Yuki Sonoda over 5 years ago

  • Target version set to Next Major

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

#5 Updated by Ollivier Robert over 5 years ago

=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

#6 Updated by Yukihiro Matsumoto over 5 years ago

=begin
Hi,

In message "Re: [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 redmine@ruby-lang.org 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

#7 Updated by john harrison about 5 years ago

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

#define RUBYSETJMP(env) setjmp(env)
#define RUBY
LONGJMP(env,val) longjmp(env,val)

I don't know exactly why, but the llvm-gcc doesn't do _builtinlongjmp and _builtinsetjmp 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

#8 Updated by Ollivier Robert about 5 years ago

=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

#9 Updated by Marc-Andre Lafortune over 4 years ago

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

=begin

=end

#10 Updated by Yusuke Endoh about 4 years ago

  • 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 mame@tsg.ne.jp
=end

#11 Updated by Jon Forums about 4 years ago

=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

#12 Updated by Yusuke Endoh about 4 years ago

=begin
2010/4/22 Jon Forums redmine@ruby-lang.org:

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 mame@tsg.ne.jp

=end

#13 Updated by Jon Forums about 4 years ago

=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

#14 Updated by Jon Forums about 4 years ago

=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

#15 Updated by Yusuke Endoh about 4 years ago

=begin
Hi,

2010/4/22 Jon Forums redmine@ruby-lang.org:

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 mame@tsg.ne.jp

=end

#16 Updated by Jon Forums about 4 years ago

=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

Also available in: Atom PDF