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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
