On Thu, Apr 30, 2009 at 9:08 AM, Collin Winter <[email protected]>wrote:
> Hi Daniel, > > On Wed, Apr 29, 2009 at 7:24 PM, Daniel Dunbar <[email protected]> wrote: > > Hi Colin, > > > > I would definitely like to improve this, but I also think that the > llvm-gcc > > behavior (which clang is just copying) was chosen by design. Poor design, > > perhaps, but I believe the intent was that -emit-llvm simply changes the > > output format, not the functionality. Thus -S -emit-llvm is output in > LLVM > > IR, -c -emit-llvm is output in LLVM bitcode, -emit-llvm alone is an > > executable, but having been compiled with LLVM tools. The problem, of > > course, is when the linker doesn't have LLVM support. > > > > I'd rather not break "compatibility" with llvm-gcc... is there a specific > > reason you wante to change this (why not use "-c"?). If it just comes > down > > to eliminating the current bad user experience, we could augment the tool > > chain to understand whether the system supports LLVM inputs and avoid > trying > > to pass them to the linker and give an error instead. > > My biggest reason for wanting to change this is that clang > -emit-llvm-bc works as expected on Darwin but works differently on > Linux. This recently broke our project's build: testing the change on > our Darwin laptops worked just fine, but broke our Linux-based > buildslaves. We can certainly use -emit-llvm -c going forward, but the > difference between platforms seems like a bug. I'm a little confused, I missed in the original email that you are using "-emit-llvm-bc". This argument isn't understood by clang or llvm-gcc. "emit-llvm-bc" is the low level CC1 argument, but it shouldn't be something the user sees. I am going to augment the tool chains for the time being to have a clue about whether the linker supports LLVM inputs, and refuse to call it if it doesn't. This won't make -emit-llvm work on Linux, but it will at least have a nicer error message. In the long term we would want this to be tied to whether or not the linker has Gold + LTO support. - Daniel Note that currently in clang, -emit-llvm-bc -c doesn't work: > > obj/$ Util/llvm/Debug/bin/clang -ccc-echo -O3 -c -emit-llvm-bc -I. > -IInclude -I../trunk -I../trunk/Include -DPy_BUILD_CORE > ../trunk/Python/llvm_inline_functions.c -o > Python/llvm_inline_functions.bc > "/usr/local/google/collinwinter/us/obj/Util/llvm/Debug/bin/clang-cc" > -triple i386-unknown-linux-gnu -S -disable-free -main-file-name > llvm_inline_functions.c --relocation-model static --disable-fp-elim > --unwind-tables=0 --fmath-errno=1 -DPy_BUILD_CORE -I. -IInclude > -I../trunk -I../trunk/Include -O3 -fdiagnostics-show-option -o > /tmp/cc-X0bB5X.s -x c ../trunk/Python/llvm_inline_functions.c > "/usr/bin/gcc" -O3 -emit-llvm-bc -I. -IInclude -I../trunk > -I../trunk/Include -DPy_BUILD_CORE -c -o > Python/llvm_inline_functions.bc -x assembler /tmp/cc-X0bB5X.s > obj/$ file Python/llvm_inline_functions.bc > Python/llvm_inline_functions.bc: ELF 32-bit LSB relocatable, Intel > 80386, version 1 (SYSV), not stripped > > clang -emit-llvm -c produces the bitcode as expected, though. I'll > change our build steps to use -emit-llvm -c. > > Thanks, > Collin Winter >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
