<div dir="ltr"><div>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.</div><div><br></div>Before:<div><pre style="color:rgb(0,0,0)">$ 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"</pre></div><div><br></div><div>After:</div><div><pre style="color:rgb(0,0,0)">$ 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"</pre></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 18, 2014 at 4:05 PM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Do you have any details on how it broke? If I can see the symptom, I might be able to guess at the cause.<div><div class="h5"><div><br><div><blockquote type="cite"><div>On Dec 18, 2014, at 3:10 PM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:</div><br><div><div dir="ltr">I had to revert this patch in <span>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.</span></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 4:19 PM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Dec 15, 2014, at 3:06 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Dec 15, 2014 at 3:00 PM, Diego Novillo <span dir="ltr"><<a href="mailto:dnovillo@google.com" target="_blank">dnovillo@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><p dir="ltr"><br>
On Dec 15, 2014 5:23 PM, "David Blaikie" <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Dec 15, 2014 at 1:09 PM, Diego Novillo <<a href="mailto:dnovillo@google.com" target="_blank">dnovillo@google.com</a>> wrote:<br>
>><br>
>> On 12/15/14 15:10, Joerg Sonnenberger wrote:<br>
>>><br>
>>> On Mon, Dec 15, 2014 at 11:26:43AM -0800, Bob Wilson wrote:<br>
>>>><br>
>>>> Does anyone have interest in this or objections to it?<br>
>>><br>
>>><br>
>>> Yes, please. Especially if it captures the bitcode *before* any of the<br>
>>> optimisations hit.<br>
>><br>
>><br>
>> 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.<br>
><br>
><br>
> -mllvm -disable-llvm-optzns<br>
><br>
> will produce the IR straight out of Clang's CodeGen. Skipping things like the AlwaysInliner and AddDiscriminator pass, etc.<br>
>  </p>
</span><p dir="ltr">Yes. Of course, i know that. </p></blockquote></div></div><div>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. </div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">The point is that easier is better.<br></p></blockquote></span><div>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.<br></div></div></div></div></div></blockquote></div><br><div>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.</div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div></div>