<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
For the Ninja CMake generator, CMake uses an intrusive mechanism for finding the dependencies (through modules) among Fortran files. CMake uses the compiler to preprocess the file and then finds the dependencies and then passes the preprocessed files onto another
invocation of the compiler to compile. This has tripped up a few compilers like Cray, IBM etc which they fixed recently (see links to issues below). The issue does not apply for the Makefile generator since it internally uses a Fortran parser/preprocessor
(makedepf90) to go through the files and find the dependencies. See the following link for more details. An ideal non-intrusive mechanism would have been to ask the compiler to list modules used and modules defined and then build the dependencies from that.<br>
<a href="https://mathstuf.fedorapeople.org/fortran-modules/fortran-modules.html" id="LPlnk493453">https://mathstuf.fedorapeople.org/fortran-modules/fortran-modules.html</a><br>
<a href="https://gitlab.kitware.com/cmake/cmake/-/issues/20697" id="LPlnk">https://gitlab.kitware.com/cmake/cmake/-/issues/20697</a><br>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview_1 _EReadonly_1"><a href="https://gitlab.kitware.com/cmake/cmake/-/issues/20731" id="LPlnk">https://gitlab.kitware.com/cmake/cmake/-/issues/20731</a></div>
<br>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview_2 _EReadonly_1"></div>
I believe in Flang, the preprocessor and prescanner (<a href="https://github.com/llvm/llvm-project/blob/main/flang/docs/Parsing.md#prescanning-and-preprocessing" id="LPlnk">https://github.com/llvm/llvm-project/blob/main/flang/docs/Parsing.md#prescanning-and-preprocessing</a>)
run together to produce a cooked character stream (normalized with no spaces, lowercase etc). I guess prescanner helps the preprocessor to be Fortran aware. In classic flang we have had issues where we had to make the preprocessor aware of Fortran syntax (<a href="https://github.com/flang-compiler/flang/pull/658" id="LPlnk636628">https://github.com/flang-compiler/flang/pull/658</a>). The
cooked character stream is currently the output if we use the -E flag. Due to loss of whitespace etc this is not fixed form anymore. Also, flang would have constructed the provenance information while creating the cooked character stream. A new invocation
of Flang on the cooked character stream will not be able to capture the source provenance information. As Bryan points out (<a href="https://gitlab.kitware.com/cmake/cmake/-/issues/22387#note_986516" id="LPlnk">https://gitlab.kitware.com/cmake/cmake/-/issues/22387#note_986516</a>)
I guess line directives have to be inserted to retain this information. <br>
<br>
Is it possible to retain fixed-form formatting after prescanning? And can we normalize it as the first step in parsing, so that the parser remains unchanged?</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Can line directive information be added to retain source location information? And can this be consumed and interpreted before parsing?<br>
Can CMake use the make generator flow? (The CMake folks have a preference to fix this in the compiler side. <a href="https://gitlab.kitware.com/cmake/cmake/-/issues/22387#note_983394" id="LPlnk">https://gitlab.kitware.com/cmake/cmake/-/issues/22387#note_983394</a>.)
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview_3 _EReadonly_1"></div>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
--Kiran<br>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_1"></div>
<br>
</div>
<div id="appendonsend"></div>
<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> flang-dev <flang-dev-bounces@lists.llvm.org> on behalf of Andrzej Warzynski via flang-dev <flang-dev@lists.llvm.org><br>
<b>Sent:</b> 21 July 2021 11:15<br>
<b>To:</b> flang-dev@lists.llvm.org <flang-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [flang-dev] Flang + CMake</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi everyone,<br>
<br>
We are a bit stuck here. From the discussions so far, it seems that we <br>
may need to make some changes to the preprocessor in order to progress <br>
this. Would someone familiar with the design of the preprocessor be able <br>
to chime in (either here, on Slack, CMake [1] or Bugzilla [2])? That <br>
would be greatly appreciated!<br>
<br>
Lack of CMake integration is already limiting us in terms of _what_ can <br>
be tested. The project will benefit greatly if we manage to get this <br>
introduced soon. And it will make LLVM Flang much more attractive to <br>
end-users.<br>
<br>
Best regards,<br>
-Andrzej<br>
<br>
[1] <a href="https://gitlab.kitware.com/cmake/cmake/-/issues/22387">https://gitlab.kitware.com/cmake/cmake/-/issues/22387</a><br>
[2] <a href="https://bugs.llvm.org/show_bug.cgi?id=50993">https://bugs.llvm.org/show_bug.cgi?id=50993</a><br>
<br>
On 06/07/2021 11:57, Andrzej Warzynski via flang-dev wrote:<br>
> FYI, I've just opened an issue for this: <br>
> <a href="https://gitlab.kitware.com/cmake/cmake/-/issues/22387">https://gitlab.kitware.com/cmake/cmake/-/issues/22387</a><br>
> <br>
> -Andrzej<br>
> <br>
> On 02/07/2021 22:06, Andrzej Warzynski via flang-dev wrote:<br>
>> Hi Tin,<br>
>><br>
>> Thank you for taking a look at this!<br>
>><br>
>> * LLVM Flang - <a href="https://github.com/llvm/llvm-project/tree/main/flang">
https://github.com/llvm/llvm-project/tree/main/flang</a><br>
>> * Classic Flang - <a href="https://github.com/flang-compiler/flang">https://github.com/flang-compiler/flang</a><br>
>><br>
>> IIUC, the existing identification in CMake is for "Classic Flang". We <br>
>> want to preserve it - there will be a lot of developers that rely on <br>
>> it. So for "LLVM Flang", we probably want to add something new rather <br>
>> then modify the existing identification.<br>
>><br>
>> I'm not too concerned about the actual name, but I think that it would <br>
>> be very beneficial if we abandoned the name "Flang" in favour of <br>
>> something that uniquely identifies "Classic Flang" and "LLVM Flang". <br>
>> Otherwise this gets too confusing.<br>
>><br>
>> In my original e-mail I was only referring to "LLVM Flang". It was my <br>
>> incorrect assumption that the existing identification in CMake was <br>
>> introduced for "LLVM Flang". Apologies for that.<br>
>><br>
>> -Andrzej<br>
>><br>
>> On 02/07/2021 18:25, Tin Huynh via flang-dev wrote:<br>
>>> Hi,<br>
>>><br>
>>> I've been asked by Steve to take a look at Flang CMake integration as <br>
>>> I have upstreamed the original flang integration in the past.<br>
>>><br>
>>> I've taken a look and confirm that if we change the predefines that <br>
>>> CMake looks for from upper case __FLANG to __flang__ (and other <br>
>>> similar predefines) cmake will be able to identify and use flang.<br>
>>><br>
>>> The question I want to pose is: what should we name this flang for <br>
>>> cmake identification? There is already an existing flang <br>
>>> identification in CMake that I assume people depend on. So we will <br>
>>> need to duplicate the CMake identification bits for original flang <br>
>>> into a different name. I would like suggestions for what to name it. <br>
>>> (Perhaps llvm-flang?)<br>
>>><br>
>>> I can set up the initial CMake identification for flang and create a <br>
>>> pull request upstream, but going forward someone with more <br>
>>> familiarity with flang's options should maintain it.<br>
>>><br>
>>> Tin<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> flang-dev mailing list<br>
>>> flang-dev@lists.llvm.org<br>
>>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev</a><br>
>>><br>
>> _______________________________________________<br>
>> flang-dev mailing list<br>
>> flang-dev@lists.llvm.org<br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev</a><br>
> _______________________________________________<br>
> flang-dev mailing list<br>
> flang-dev@lists.llvm.org<br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev</a><br>
_______________________________________________<br>
flang-dev mailing list<br>
flang-dev@lists.llvm.org<br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev</a><br>
</div>
</span></font></div>
</body>
</html>