[cfe-dev] changing -save-temps to keep bitcode?

[Reid Kleckner]

It's all visible with -### on a system with gcc installed. Previously we
would invoke gcc to do the compilation for .f files, and with this change
we would try to invoke clang. I haven't dug further than this.

Before:

$ clang -c t.f -###
clang version 3.6.0 (trunk 224546) (llvm/trunk 224542)
Target: x86_64-unknown-linux-gnu
Thread model: posix
 "/usr/bin/gcc" "-S" "-m64" "-o" "/tmp/t-22d130.s" "-x" "f95" "t.f"
 "/usr/local/google/home/rnk/llvm/build/bin/clang-3.6" "-cc1as"
"-triple" "x86_64-unknown-linux-gnu" "-filetype" "obj"
"-main-file-name" "t.f" "-target-cpu" "x86-64" "-mrelax-all" "-o"
"t.o" "/tmp/t-22d130.s"


After:

$ clang -c t.f -###
clang version 3.6.0 (trunk 224546) (llvm/trunk 224542)
Target: x86_64-unknown-linux-gnu
Thread model: posix
 "/usr/local/google/home/rnk/llvm/build/bin/clang-3.6" "-cc1"
"-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-mrelax-all"
"-disable-free" "-main-file-name" "t.f" "-mrelocation-model" "static"
"-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno"
"-masm-verbose" "-mconstructor-aliases" "-munwind-tables"
"-fuse-init-array" "-target-cpu" "x86-64" "-dwarf-column-info"
"-coverage-file" "/usr/local/google/home/rnk/llvm/tools/clang/t.f"
"-resource-dir"
"/usr/local/google/home/rnk/llvm/build/bin/../lib/clang/3.6.0"
"-fdebug-compilation-dir"
"/usr/local/google/home/rnk/llvm/tools/clang" "-ferror-limit" "19"
"-fmessage-length" "190" "-mstackrealign" "-fobjc-runtime=gcc"
"-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "t.o" "-x"
"f95" "t.f"


On Thu, Dec 18, 2014 at 4:05 PM, Bob Wilson <bob.wilson at apple.com> wrote:
>
> Do you have any details on how it broke? If I can see the symptom, I might
> be able to guess at the cause.
>
> On Dec 18, 2014, at 3:10 PM, Reid Kleckner <rnk at google.com> wrote:
>
> I had to revert this patch in r224546, as it broke compilation of fortran
> files with gcc through the clang driver. It's easy to observe the change in
> behavior with -###, but I think you need to be on a system where clang
> thinks there is a valid gcc installation that can handle fortran. I was
> unable to observe the behavior change on Windows, for example, so I doubt
> it will be observable on Mac OS X without some fiddling. Let me know if you
> need help reproducing the situation.
>
> On Mon, Dec 15, 2014 at 4:19 PM, Bob Wilson <bob.wilson at apple.com> wrote:
>>
>>
>> On Dec 15, 2014, at 3:06 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>
>>
>> On Mon, Dec 15, 2014 at 3:00 PM, Diego Novillo <dnovillo at google.com>
>> wrote:
>>>
>>>
>>> On Dec 15, 2014 5:23 PM, "David Blaikie" <dblaikie at gmail.com> wrote:
>>> >
>>> >
>>> >
>>> > On Mon, Dec 15, 2014 at 1:09 PM, Diego Novillo <dnovillo at google.com>
>>> wrote:
>>> >>
>>> >> On 12/15/14 15:10, Joerg Sonnenberger wrote:
>>> >>>
>>> >>> On Mon, Dec 15, 2014 at 11:26:43AM -0800, Bob Wilson wrote:
>>> >>>>
>>> >>>> Does anyone have interest in this or objections to it?
>>> >>>
>>> >>>
>>> >>> Yes, please. Especially if it captures the bitcode *before* any of
>>> the
>>> >>> optimisations hit.
>>> >>
>>> >>
>>> >> Agreed. On several occasions, I've found myself wondering how I can
>>> generate bitcode exactly as it leaves the parser, before any early cleanups
>>> and such.
>>> >
>>> >
>>> > -mllvm -disable-llvm-optzns
>>> >
>>> > will produce the IR straight out of Clang's CodeGen. Skipping things
>>> like the AlwaysInliner and AddDiscriminator pass, etc.
>>> >
>>>
>>> Yes. Of course, i know that.
>>>
>> Ah, sorry - wasn't sure if you knew that particular one. I always forget
>> it/have to look it up whenever I want to do that.
>>
>>> The point is that easier is better.
>>>
>> Sure enough - well, point to Bob, then: consider doing this kind of IR,
>> rather than the usual -emit-llvm IR, to get something closer to the
>> original/pure generated IR.
>>
>>
>> Sounds good. I agree that will be even more useful. Steven Wu has already
>> written a patch to do something similar, so I’ll see if I get that done
>> soon.
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141218/149ae602/attachment.html>