Hi Tobias,
Am 21.09.21 um 21:22 schrieb Tobias Burnus:
While the previous patch fixed -Wno-missing-include-dirs and sorted
out some inconsistencies with libcpp warnings, it had two issues:
* Some superfluous warnings were printed, e.g. for
gfortran nonexisting/file.f90
there was a warning about include path "nonexisting" not existing
and twice the error that the "nonexisting/file.f90" could not be
read.
* At least as invoked when build GCC or when running the GCC testsuite,
the passed -B -isystem etc. arguments lead to proper but pointless
diagnostic about 'finclude' or other directories not being found,
causing excess-error FAILS and -Werror build fails.
While the latter could be fixed by adding -Wno-missing-include-dirs,
it still felt like the wrong approach.
I concur.
While the testsuite does run for me, others reported that they do
see missing-include-dirs warnings. Instead of adding a bunch of
-Wno-missing-include-dirs to the test config, I now only warn for
-I and -J by default (similar to previous state) and only do a full
warnings when the user requested passes the -Wmissing-include-dirs
explicitly. The Fortran behavior is now also properly documented
in the manual.
I had actually only looked at my use cases (-I, -J), which worked
as expected.
What I find a bit confusing - from the viewpoint of a user - is the
case of using the preprocessor (-cpp), as one gets e.g.
<built-in>: Warning: ./no/such/dir: No such file or directory
[-Wmissing-include-dirs]
while without -cpp:
f951: Warning: Nonexistent include directory './no/such/dir/'
[-Wmissing-include-dirs]
If you feel like me that the printing "<built-in>" should be
documented, feel free to do so. I failed to find it.
(In some build setups the users do not normally see the actual
command line invoking the compiler, and they have to guess.)
In order to handle the silencing of the diagnostic and to avoid
double output via the Fortran code and libcpp (or rather: gcc/incpath.c),
I had to add some not that clean and obvious diagnostic flags.
I hope they still make sense and are somewhat readable.
OK? Comments?
I think that's good to go. Even better if you have a user-friendly
solution to my above comment.
Thanks for the patch!
Harald
Tobias
PS: There is also some inconsistency whether fprintf stderr and
gfc_error is used. All calls in load_file could be fatal errors
as all exist with an error - and similar issues get different
error messages for no good reason. I have not tried to solve
this issue – but can if deemed reasonable as follow-up patch.
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
Registergericht München, HRB 106955
