[Bug fortran/102145] TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145 --- Comment #2 from ripero84 at gmail dot com --- 1) The gfortran manual has its own entries for -pedantic and -pedantic-errors: -Wpedantic -pedantic Issue warnings for uses of extensions to Fortran. -pedantic also applies to C-language constructs where they occur in GNU Fortran source files, such as use of \e in a character constant within a directive like "#include". Valid Fortran programs should compile properly with or without this option. However, without this option, certain GNU extensions and traditional Fortran features are supported as well. With this option, many of them are rejected. Some users try to use -pedantic to check programs for conformance. They soon find that it does not do quite what they want---it finds some nonstandard practices, but not all. However, improvements to GNU Fortran in this area are welcome. This should be used in conjunction with -std=f95, -std=f2003, -std=f2008 or -std=f2018. -pedantic-errors Like -pedantic, except that errors are produced rather than warnings. The first lines of each description are quite clear about -pedantic issuing warnings and -pedantic-errors issuing errors instead of warnings, in what sounds like a very reasonable strategy. But then the second paragraph of -pedantic says that many (unspecified) non-standard features will be rejected. 2) This answers part of my issue: the behaviour is indeed documented, just in a way that has proved confusing to me. It think that a more accurate description would start with: -pedantic: Issue warnings for some uses of extensions to Fortran, raise otherwise warnings to errors for others. Not all extensions will raise warnings or errors. which sounds bad. 3) If this is the intended behaviour I can propose some tweaks to the documentation, but as I said first I would like to have a confirmation (ideally by the person who set up the interaction between -pedantic and -fallow-argument-mismatch) that this is really intended behaviour, not accidental. 4) Apologies for not going into the C discussion, my C is limited, and to start with I don't understand the "warnings demanded by strict ISO C" statement: ISO/IEC 9899:2017, Annex I (informative) "Common warnings" says that "An implementation may generate warnings in many situations, none of which are specified as part of this International Standard", so I don't really know what the "demanded warnings" are. Thank you for your help.
[Bug fortran/102145] New: TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145 Bug ID: 102145 Summary: TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ripero84 at gmail dot com Target Milestone: --- In the presence of -pedantic, -fallow-argument-mismatch fails to degrade the mismatch errors to warnings: $ cat pedt.f90 MODULE M IMPLICIT NONE EXTERNAL :: X CONTAINS SUBROUTINE S(A) COMPLEX :: A(*) CALL X(A) END SUBROUTINE T(A) REAL :: A(*) CALL X(A) END END $ gfortran pedt.f90 -c -o pedt.o -fallow-argument-mismatch # Expected warning pedt.f90:8:11: 8 | CALL X(A) | 1 .. 13 | CALL X(A) | 2 Warning: Type mismatch between actual argument at (1) and actual argument at (2) (COMPLEX(4)/REAL(4)). $ gfortran pedt.f90 -c -o pedt.o -fallow-argument-mismatch -pedantic # Unexpected error pedt.f90:8:11: 8 | CALL X(A) | 1 .. 13 | CALL X(A) | 2 Error: Type mismatch between actual argument at (1) and actual argument at (2) (COMPLEX(4)/REAL(4)). This is: - undocumented; and - unexpected, since it effectively means that by adding -pedantic to a compilation line that already contains -fallow-argument-mismatch, mismatch warnings are upgraded to errors, despite -pedantic is only supposed to issue warnings. It seems that GCC developers have known for years that -pedantic may change warnings to errors in the absence of error-raising flags (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929#c9), but it is still unclear to me whether this is undocumented or wrong behaviour. Note that there is evidence that -fallow-argument-mismatch is actually being processed: if the compiler finds multiple mismatches involving a given argument, it succeeds in only reporting one of them (as an error, not as the expected warning). I am seeking clarification about whether this is a bug (the combination of -pedantic -fallow-argument-mismatch flags should work differently / be forbidden), a documentation bug (in which case I would appreciate an explanation of the logic behind this, and an update to the documentation), or both, and I would be grateful for the fix(/es). I am aware that -fallow-argument-mismatch is a hack that should be avoided, but since users still need it, its behaviour and documentation should be at least consistent. Note that this issue has already been reported by some Fortran codes: https://github.com/cp2k/cp2k/issues/1019, https://gitlab.com/siesta-project/siesta/-/issues/130 . This seems to affect all versions of gfortran since GCC 10. It would be nice if any updates related to this were ported to the 10.x branch. Thank you for your help.
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 --- Comment #11 from ripero84 at gmail dot com --- Thank you very much for the information and your help.
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 ripero84 at gmail dot com changed: What|Removed |Added CC||ripero84 at gmail dot com --- Comment #9 from ripero84 at gmail dot com --- Steve, is this a GCC bug or a FreeBSD bug (or if it is something else, what side does this belong to)? Other OSs seem to be able to compile gfortran with these modules for these architectures, see, e.g., https://packages.ubuntu.com/focal/arm64/gfortran-10/filelist and https://packages.ubuntu.com/focal/ppc64el/gfortran-10/filelist). And they seem to have been able to do so since the introduction of the three Fortran IEEE intrinsic modules in GCC 5 (https://packages.ubuntu.com/bionic/amd64/gfortran-5/filelist and https://packages.ubuntu.com/bionic/ppc64el/gfortran-5/filelist). Therefore, some kind of solution must exist for this - and probably has been there for over half a decade. (Apologies for not being able to provide a better insight from the Ubuntu sources.) Thank you.
