<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
FWIW, I think if the LLVM project will not accept C++17 code soon, then f18 should detect C++17 support and if it's not there, use local implementations. Cray once released a library back when some compilers did not yet support C++11, so I detected if C++11
support existed and used my own implementations when it wasn't present. For some things, it was trivial, for others, really annoying....but it worked. It would be lovely to see f18 in the new LLVM repo sooner than later, but obviously if f18 merges in after
C++14 is allowed, then less work is required to duplicate std:: functionality. It's a tradeoff.<br>
<br>
-Troy
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Chandler Carruth via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Sent:</b> Monday, February 25, 2019 4:45:28 PM<br>
<b>To:</b> Stephen Scalpone<br>
<b>Cc:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] RFC for f18+runtimes in LLVM</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">On Mon, Feb 25, 2019 at 10:06 AM Stephen Scalpone via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
</div>
<div class="x_gmail_quote">
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div lang="EN-US">
<div class="x_gmail-m_-1195941680496066381WordSection1">
<p class="x_MsoNormal"><span style="color:black">* The current f18 code will be committed to the new LLVM subproject. </span><span class="x_gmail-m_-1195941680496066381apple-converted-space" style="color:black"> </span><span style="color:black">The f18 code
is a set of libraries that implements the Fortran compiler.</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Awesome. This is an important aspect of the design of LLVM projects IMO -> they build their functionality primarily as re-usable libraries, and then expose that in useful command line utilities.</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div lang="EN-US">
<div class="x_gmail-m_-1195941680496066381WordSection1">
<p class="x_MsoNormal"><span style="color:black">The f18 compiler source code complies with most of LLVM's coding guidelines; however, the code uses several C++17 features. We've documented our use of C++17 here:</span><br>
</p>
<p class="x_MsoNormal" style="font-variant-caps:normal; text-align:start; word-spacing:0px">
<span style="color:black"> <u></u><u></u></span></p>
<p class="x_MsoNormal" style="font-variant-caps:normal; text-align:start; word-spacing:0px">
<span style="color:black"> <span class="x_gmail-m_-1195941680496066381apple-converted-space"> </span><a href="https://github.com/flang-compiler/f18/blob/master/documentation/C++17.md" target="_blank"><span style="color:rgb(149,79,114)">https://github.com/flang-compiler/f18/blob/master/documentation/C++17.md</span></a><u></u><u></u></span></p>
<p class="x_MsoNormal" style="font-variant-caps:normal; text-align:start; word-spacing:0px">
<span style="color:black"> <u></u><u></u></span></p>
<p class="x_MsoNormal" style="font-variant-caps:normal; text-align:start; word-spacing:0px">
<span style="color:black">In particular, the parse tree and the lowered forms of expressions and variables are defined in terms of C++17<span class="x_gmail-m_-1195941680496066381apple-converted-space"> </span>std::variant. Most of the compiler uses C++17<span class="x_gmail-m_-1195941680496066381apple-converted-space"> </span>std::visit
to walk these data structures.<u></u><u></u></span></p>
<p class="x_MsoNormal" style="font-variant-caps:normal; text-align:start; word-spacing:0px">
<span style="color:black"> <u></u><u></u></span></p>
<p class="x_MsoNormal" style="font-variant-caps:normal; text-align:start; word-spacing:0px">
<span style="color:black">It’s possible to reimplement the most important functionality of<span class="x_gmail-m_-1195941680496066381apple-converted-space"> </span>std:variant<span class="x_gmail-m_-1195941680496066381apple-converted-space"> </span>as a subset
class, say<span class="x_gmail-m_-1195941680496066381apple-converted-space"> </span>llvm:variant; however, variant gets its power from the C++17 features generic lambdas and parameter pack expansion on “using”. <span class="x_gmail-m_-1195941680496066381apple-converted-space"> </span>Without
these C++17 features, use of variant would be impractical.<u></u><u></u></span></p>
<p class="x_MsoNormal" style="font-variant-caps:normal; text-align:start; word-spacing:0px">
<span style="color:black"> <u></u><u></u></span></p>
<p class="x_MsoNormal" style="font-variant-caps:normal; text-align:start; word-spacing:0px">
<span style="color:black">Our thinking when we started was that llvm would adopt C++17 before mid-2020, which lines up with our projected completion date. If we were to adopt C++11 or C++14, we would likely create substitutes for these classes, certainly at
a cost of calendar time and perhaps type safety and notational convenience. One of our principles is to take advantage of the standard library as much as possible, so casual readers will better understand our code and so we avoid the time and bugs associated
with writing class libraries.<u></u><u></u></span></p>
<p class="x_MsoNormal" style="font-variant-caps:normal; text-align:start; word-spacing:0px">
<span style="color:black"> <u></u><u></u></span></p>
<p class="x_MsoNormal" style="font-variant-caps:normal; text-align:start; word-spacing:0px">
<span style="color:black">Our request would be to get a waiver for the C++11 requirement based on the fact that we're skating to where the puck will be. In the meantime, because F18 only exists as a stand-alone program, early adopters would still have a useful
parser and analyzer for Fortran.</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Hold on, either it is a collection of libraries or it is a stand-alone program. It can't really be both?</div>
<div><br>
</div>
<div>Generally, I think the idea that diverging from the rest of the project here is low-cost for a subproject isn't supported by experience with other projects.</div>
<div><br>
</div>
<div>Notably, it has a strong tendancy to create tension. You want some ADT or support library in LLVM to work well with your C++17 code. But it is C++11. Every time this has been done in the past, the result has been that generically useful tools and libraries
get added to the subproject rather than to LLVM as a whole.</div>
<div><br>
</div>
<div>So FWIW, I'd be really opposed to this. Instead, I think that F18 should have rich libraries, and develop them exactly the same way as the rest of LLVM.</div>
<div><br>
</div>
<div>We're getting close to switching to C++14, so maybe due to timing, you could merge F18 when that happens?</div>
<div><br>
</div>
<div>Ultimately, I think you either need to raise the LLVM base language version or lower the F18 one so that they match when merged IMO. Anything else I think will hamper integration with the larger project.</div>
</div>
</div>
</div>
</body>
</html>