[clang] [flang] [flang] Align `-x f95[-cpp-input]` language modes with `gfortran` (PR #127986)
Iñaki Amatria Barral via cfe-commits
cfe-commits at lists.llvm.org
Fri Mar 7 01:54:31 PST 2025
inaki-amatria wrote:
> Sorry, maybe I'm still getting a bit confused now 😅. I think in
>
> https://github.com/llvm/llvm-project/blob/dddfd77f653d7e88965b647e9bc38827cae8bf8a/clang/lib/Driver/Types.cpp#L300
> we are still getting things the wrong way around, even with this patch? If we want to match gfortran, all the lower case files should have type `TY_Fortran` and all the upper case ones should have `TY_PP_Fortran`, I think? Does it not have any actual difference to the observable behaviour to have that the way around?
>
> R.e. `.i` I think we've explicitly decided in the past that processing files that were preprocessed by a different compiler is not something we need/want to support; Fortran preprocessors are odd, and another compiler's preprocessor may output code that their compiler would accept but that is not standard, regardless of what we do here. Furthermore, the flang preprocessor _always_ runs, there's really no benefit to manually doing a preprocess step yourself even with `flang -E`. Essentially passing a `.i` file to `flang -fc1` is something that should really _only_ be being done by `flang -save-temps`, because it doesn't really have a meaning otherwise.
>
> The PR description does appear to show some erroneous behaviour; if `flang -Werror -x f95 foo.f90` does assume fixed form then that's incorrect. I thought we were assuming fixed-form based only on whether _both_ `.i` is the file extension _and_ we were in `flang -fc1`, neither should be the case with that command. That's definitely a bug if it's the case, but the bug isn't that `flang -fc1` wants to assume that `.i` means fixed form.
>
> Sorry for my overly long comments on this, I'm just trying to share all the context as I understand it 😄. Thanks for your patience!
Apologies for the delayed response, DavidTruby. We took some time to evaluate how best to approach the problem and ensure clarity. Given the discussion, I will close this PR and open a new one with only the necessary changes and a revised description to keep the focus on the key points.
Thanks for your time and for sharing all this context, it is really helpful! And sorry for any confusion along the way.
https://github.com/llvm/llvm-project/pull/127986
More information about the cfe-commits
mailing list