[clang] [flang] [flang] Preserve fixed form in fc1 -x value (PR #117563)

[Andrzej Warzyński via cfe-commits]

banach-space wrote:

> However, -save-temps doesn't appear to work for me at all.

You need to add -fno-integrated-as. This is a known limitation:

* [save-temps.f90](https://github.com/llvm/llvm-project/blob/main/flang/test/Driver/save-temps.f90)

>It feels wrong that -save-temps runs the preprocessor separately anyway for flang. There's no "temp" generated by the flang preprocessor as preprocessing is not a separate step to parsing.

`-save-temps` "approximates" the actual compilation flow. This behavior is consistent with Clang, where preprocessing, assembling, etc., are split into separate steps. The need for `-fno-integrated-as` is a side effect of this: `-save-temps` modifies the invocation to run the assembler as a standalone step, but Flang doesn't yet support the "integrated" assembler that Clang uses by default.

> We don't appear to need to do this for compatibility with gfortran either because gfortran doesn't appear to save a preprocessed file with -save-temps (at least on my system). 

That's correct. However, LLVM Flang generally follows Clang in the absence of explicit direction from GFortran. This ensures consistent behavior between `clang` and `flang`, which is the case here.

> Even if we do chose to have -save-temps save a preprocessed file for some reason, I think .i is the wrong extension as that's usually used for C/C++ preprocessed files.

Agreed, .i is typically associated with C/C++. However, Flang uses .i for historical reasons. If .i isn't ideal, what alternative would you suggest for Fortran preprocessed files?

>>banach-space: Is that the only solution?
>
>No. I initially looked at modifying [Flang::ConstructJob](https://github.com/llvm/llvm-project/blob/65c36179be68dda0d1cc5d7e5c5b312a6b52cc0e/clang/lib/Driver/ToolChains/Flang.cpp#L709) to add -ffixed-form to the compilation command. But I found myself having to walk back through the compilation graph to get the original filename extension so I could determine if it was fixed or free.
>
>It worked, but seemed brittle. It does have the benefit of being more surgical.
>
>Another solution I considered, was propagating the fixed vs free information in some way other than the type. I didn't go down this path because it seemed more natural to consider it part of the type.
>
>FWIW, I don't have strong feelings here. I'm happy to implement the fix however you all think is best.

@macurtis-amd, thanks for the detailed explanation. The approach you're suggesting seems the most natural, provided we can guarantee or agree on the following:

* Fixed-form → `flang -E` → fixed-form.
* Free-form → `flang -E` → free-form.

Alternatively, we could simplify by requiring that `flang -E` always produces free-form output. Would that be acceptable to everyone?

https://github.com/llvm/llvm-project/pull/117563