<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 1/8/20 7:52 PM, Eric Christopher via llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:CALehDX4VKsJNS4e4USLcrydbnwqp5Qg3VY8KndfMrpnQcnWnCQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jan 8, 2020 at 5:42 PM Joerg Sonnenberger via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
On Wed, Jan 08, 2020 at 05:35:44PM -0800, Eric Christopher via llvm-dev wrote:<br>
> As far as the current use in the clang driver: Honestly I don't think you<br>
> should be using the clang driver and had I seen I probably wouldn't have<br>
> accepted those patches either. I think it would be better off to turn parts<br>
> of the driver you might need into a separable library rather than include<br>
> fortran support into a "c based languages" driver and will probably try to<br>
> dig up that patch set and comment.<br>
<br>
I disagree on this part quite a bit. First of all, there is quite a bit<br>
code in the wild that expects at least basic support in the "gcc"<br>
frontend for handling Fortran. Additionally, there is a very significant<br>
overlap in the platform handling and little Fortran specific logic<br>
assuming that we don't end up with hundreds of tuning options in the<br>
frontend. That was the biggest concern for me with the first flang<br>
patches to the clang driver: insane amount of fine-tuning flags and<br>
magic number mappings.<br>
<br>
</blockquote>
<div><br>
</div>
<div>This is an absolutely fair response, but I think the answer there is making a lot of the clang driver a library and not having clang support fortran compilation.</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>First, I completely agree that we should have a "frontend driver" library in LLVM. There are lots of frontends that need to know how to call the linker and make a executable program, shared library, etc., and we should have some reusable infrastructure for
that.</p>
<p>In this case, however, Fortran is somewhat of a special case for historical reasons. To emulate gcc, our driver needs to know how to invoke a Fortran compiler. Considering that, especially considering our long-standing support for being a driver for gfortran
for this reason, and the other similarities in the compilation models, having this in Clang seems reasonable to me. The reality is that, in terms of toolchains, the triple of C/C++/Fortran go together for a significant set of programming environments, and
there has long been a coupling at this driver level (at large).<br>
</p>
<p> -Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CALehDX4VKsJNS4e4USLcrydbnwqp5Qg3VY8KndfMrpnQcnWnCQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>-eric </div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>