<div class="gmail_quote">On Thu, Apr 30, 2009 at 9:08 AM, Collin Winter <span dir="ltr"><<a href="mailto:collinwinter@google.com">collinwinter@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Daniel,<br>
<div class="im"><br>
On Wed, Apr 29, 2009 at 7:24 PM, Daniel Dunbar <<a href="mailto:daniel@zuster.org">daniel@zuster.org</a>> wrote:<br>
> Hi Colin,<br>
><br>
> I would definitely like to improve this, but I also think that the llvm-gcc<br>
> behavior (which clang is just copying) was chosen by design. Poor design,<br>
> perhaps, but I believe the intent was that -emit-llvm simply changes the<br>
> output format, not the functionality. Thus -S -emit-llvm is output in LLVM<br>
> IR, -c -emit-llvm is output in LLVM bitcode, -emit-llvm alone is an<br>
> executable, but having been compiled with LLVM tools. The problem, of<br>
> course, is when the linker doesn't have LLVM support.<br>
><br>
> I'd rather not break "compatibility" with llvm-gcc... is there a specific<br>
> reason you wante to change this (why not use "-c"?). If it just comes down<br>
> to eliminating the current bad user experience, we could augment the tool<br>
> chain to understand whether the system supports LLVM inputs and avoid trying<br>
> to pass them to the linker and give an error instead.<br>
<br>
</div>My biggest reason for wanting to change this is that clang<br>
-emit-llvm-bc works as expected on Darwin but works differently on<br>
Linux. This recently broke our project's build: testing the change on<br>
our Darwin laptops worked just fine, but broke our Linux-based<br>
buildslaves. We can certainly use -emit-llvm -c going forward, but the<br>
difference between platforms seems like a bug.</blockquote><div><br>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.<br>
<br>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.<br>
<br> - Daniel<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Note that currently in clang, -emit-llvm-bc -c doesn't work:<br>
<br>
obj/$ Util/llvm/Debug/bin/clang -ccc-echo -O3 -c -emit-llvm-bc  -I.<br>
<div class="im">-IInclude -I../trunk -I../trunk/Include   -DPy_BUILD_CORE<br>
../trunk/Python/llvm_inline_functions.c -o<br>
Python/llvm_inline_functions.bc<br>
</div> "/usr/local/google/collinwinter/us/obj/Util/llvm/Debug/bin/clang-cc"<br>
<div class="im">-triple i386-unknown-linux-gnu -S -disable-free -main-file-name<br>
llvm_inline_functions.c --relocation-model static --disable-fp-elim<br>
--unwind-tables=0 --fmath-errno=1 -DPy_BUILD_CORE -I. -IInclude<br>
-I../trunk -I../trunk/Include -O3 -fdiagnostics-show-option -o<br>
</div>/tmp/cc-X0bB5X.s -x c ../trunk/Python/llvm_inline_functions.c<br>
<div class="im"> "/usr/bin/gcc" -O3 -emit-llvm-bc -I. -IInclude -I../trunk<br>
-I../trunk/Include -DPy_BUILD_CORE -c -o<br>
</div>Python/llvm_inline_functions.bc -x assembler /tmp/cc-X0bB5X.s<br>
obj/$ file Python/llvm_inline_functions.bc<br>
Python/llvm_inline_functions.bc: ELF 32-bit LSB relocatable, Intel<br>
80386, version 1 (SYSV), not stripped<br>
<br>
clang -emit-llvm -c produces the bitcode as expected, though. I'll<br>
change our build steps to use -emit-llvm -c.<br>
<br>
Thanks,<br>
<font color="#888888">Collin Winter<br>
</font></blockquote></div><br>