https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534
--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Harald Anlauf from comment #9) > (In reply to Manuel López-Ibáñez from comment #8) > > (In reply to Manuel López-Ibáñez from comment #7) > > > The ideal fix for this would adding a function like: > > > > I forgot about this bug and redid the above from scratch. But this time, I > > actually tested that it works: > > https://gcc.gnu.org/ml/fortran/2014-10/msg00019.html > > Has this patch been applied? An equivalent one has. The remaining problem (I think) is that the warning is given when -I is processed, so the order of -I and -Wno-missing-include-dirs matters. In your example, the order should be correct, but the driver unhelpfully re-orders the command-line as: f951 xxx.f90 -I /no/such/dir -quiet -dumpbase xxx.f90 "-mtune=generic" "-march=x86-64" -auxbase xxx -Wno-missing-include-dirs -fintrinsic-modules-path finclude -o /tmp/ccwz8Va5.s If I invoke f951 manually, it works: f951 -Wno-missing-include-dirs ~/xxx.f90 -I /no/such/dir -Wno-missing-include-dirs However, if I invoke it like this it doesn't work: f951 -Wno-missing-include-dirs ~/xxx.f90 -I /no/such/dir -Wno-missing-include-dirs because prune_options removes duplicated options by keeping the last one. Thus, the fix is either to buffer the arguments to -I and process them after all options have been processed or move just the warning code to such a latter phase. I'm not sure what is simpler. This is what the C/C++ FE does (see incpath.c add_path, which is called when -I is processed and c-opts.c register_include_chains, which is called after options processing and gives the diagnostics). Note that this applies to all warnings given by add_path_to_list, since ideally they should be disabled by "--no-warnings" (aka -w), but currently it depends on the order they are given.
