<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Mar 1, 2019, at 5:12 AM, Petr Penzin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""><div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><blockquote type="cite" class=""><p class="MsoNormal" style="caret-color: rgb(0, 0,
0);font-variant-caps: normal;orphans:
auto;text-align:start;widows: auto;-webkit-text-size-adjust:
auto;-webkit-text-stroke-width: 0px;word-spacing:0px"><span style="" class="">At this point, we have documented and
implemented a healthy subset of the compiler for symbol
tables and scoping, name resolution, USE statements and
module files, constant representation, constant folding and
much of declaration, label and expression semantics. The
parser handles all of Fortran 2018 and OpenMP 4.5 and
implements a Fortran-aware preprocessor. The Fortran control
flow graph (CFG) is in review now. We continue to update
other documentation, such as the style guide and runtime
descriptor design.</span></p>
<span style="" class=""></span></blockquote>
Currently it looks like only the parser is <i class="">partially</i>
implemented in f18, there is no code generator (via LLVM or
otherwise) and, obviously, no object output. For that reason and
due to the condition of its test suite it is impossible to
reliably assess the state of Fortran 18 support (thought it does
look like a fair amount of effort went into it). State of OpenMP
support actually got me a bit puzzled, more on that below.<br class=""><div class=""><br class="webkit-block-placeholder"></div><p class="">As I understand the announcement, f18 is intended to be used or
merged with Flang sources at some point, but that still does not
explain how it would integrate with LLVM, since Flang does not
seem invoke LLVM directly either (it used to produce LLVM IR as
text files). Because of this, it is likely that its code generator
component would have to be written from scratch. It is also
unclear if and how it would provide the library API which has been
announced.<br class="">
</p><p class="">A bit about the test suite -- I looked at the Fortran
(regression) part of it (as opposed to unit tests, which hopefully
are a relatively simple affair). Maybe nitpicking, but despite
"handles all of OpenMP 4.5" statement in the announcement there
seem to be only two </p></div></div></blockquote><br class=""></div><div>I haven’t looked at f18 at all, but if this is true, it wouldn’t be concerning to me. There is a lot of work at the parser level that can be developed and tested without code generation at all - all semantic analysis, error message generation, sub-dialect support, etc all require a significant amount of work in the parser. This is all generally useful for tooling, even without codegen.</div><div><br class=""></div><div>That said, codegen would obviously be great to see, and my understanding is that the f18 community is committed to building that.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>