<div dir="ltr"><div>I had to leave the call early so I don't know whether the topics below were addressed.  Hopefully my comments below are useful.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 18, 2021 at 12:37 PM Perry-Holby, Alexis via flang-dev <<a href="mailto:flang-dev@lists.llvm.org">flang-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="word-wrap:break-word">
<div class="gmail-m_-6701601470573158150WordSection1">
<p class="MsoNormal"> <br></p><p class="MsoNormal"><u></u></p>
<p class="MsoNormal"><u>OTHER TOPICS<u></u><u></u></u></p>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_-6701601470573158150MsoListParagraphCxSpFirst" style="margin-left:0in">
Driver can make an executable now!<u></u><u></u>
<ul style="margin-top:0in" type="circle">
<li class="gmail-m_-6701601470573158150MsoListParagraphCxSpMiddle" style="margin-left:0in">Is now a good time to switch name from flang-new to flang?<br></li></ul></li></ul></div></div></blockquote><div>This it sounds like a good idea to me.  On a possibly related note, at what point in the process does an end user have the experience of installing flang and producing an executable file with something like "flang hello_world.f90"?  And when will the end user be able to install flang via common package managers?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="word-wrap:break-word"><div class="gmail-m_-6701601470573158150WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_-6701601470573158150MsoListParagraphCxSpMiddle" style="margin-left:0in">
Two different ways to approach continued development: keep chasing standards or make a high-quality F95 compiler with optimizations and such?</li></ul></div></div></blockquote><div>The utility of a compiler only becomes non-zero once the compiler supports the standards a code uses.  Every project I lead uses Fortran 2018.  Also, any support for Fortran 2018 parallel features might improve  performance more than optimizing Fortran 95 serial features.   For example, any time spent on optimizing the Fortran 95 FOR ALL statement would be better spent offloading DO CONCURRENT to GPUs -- especially given that the Fortran 2018 standard officially declares FOR ALL to be obsolescent. Fortran 2018 also deletes some features so you probably don't want to optimize any of those.</div><div><br></div><div>Progressing through the standards chronologically also means missing some attractive low-hanging fruit.  For example, supporting the Fortran 2018 collective subroutines is much easier than supporting Fortran 2008 coarrays. I've worked on several production applications for which the collective subroutines provide all of the parallel communication needs even with no coarrays anywhere in the codes.  <br></div><div><br></div><div>If the decision is to focus on Fortran 2003 next, will patches for more recent standards be accepted?</div><div><br></div><div>Damian</div></div></div>