On Wed, 20 Jan 2021, Nathan Sidwell wrote: > On 1/19/21 6:27 PM, Joseph Myers wrote: > > On Tue, 19 Jan 2021, Nathan Sidwell wrote: > > > > > Joseph, > > > I was relying on this patch on the modules branch, but didn't realize the > > > implications when merging and thought it was just a cleanup. I'm not sure > > > why > > > the driver wants to check here, rather than leave it to the compiler. > > > Seems > > > optimizing for failure? The only difference I can think is that the > > > diagnostic > > > might mention the driver name, rather than say (cc1plus), but that's a > > > different problem that I've also reported. > > > > What do the error messages look like, before and after this patch, for the > > various cases? (Response file missing; file handled by e.g. cc1plus > > missing; file handled by the linker missing.) > > here are some experiments:
Thanks. Mentioning cc1plus is a pre-existing issue that applies in general to diagnostics coming from cc1plus and not associated with a given source file (as I said in <https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534846.html>, I think such diagnostics ought to mention the program the user called, i.e. the driver, and not mention cc1plus at all unless the user really called it manually without the driver). Given that, the interesting cases are the ones where an error becomes a warning. > Unspecified non-existent file: > OLD: > 1)devvm293:292>g++ -c nothing > g++: error: nothing: No such file or directory > g++: fatal error: no input files > compilation terminated. > > NEW: > (1)devvm293:293>./xg++ -B./ -c nothing > xg++: warning: nothing: linker input file unused because linking not done This seems analogous to e.g. not detecting syntax errors when using -E, or not detecting that a file #included inside #if 0 doesn't exist: the requested processing doesn't involve doing anything with the file "nothing" so it seems appropriate for its absence not to be treated as an error. > Unspecified non-existent response file: > OLD: > (1)devvm293:282>g++ -c @nothing > g++: error: nothing: No such file or directory > g++: fatal error: no input files > compilation terminated. > > NEW: > (1)devvm293:284>./xg++ -B./ -c @nothing > xg++: warning: @nothing: linker input file unused because linking not done This is less clear, in that one might suppose "nothing" is meant to be a file listing C++ sources to compile, so should be processed and should result in an error for its absence. However, this particular place in the driver handling OPT_SPECIAL_input_file doesn't seem like the right place for such an error. Either the correct handling of response files is that the @file argument is silently kept as-is and so the warning after your patch is correct, or the correct handling of response files is that there should be an error if such a file cannot be found (and so users with filenames starting @ must reference them e.g. as ./@file.cc) and expandargv should have some way to report that error. Leaving it to OPT_SPECIAL_input_file as in the driver at present would mean such an error doesn't occur when @file, unexpanded, appears to be an option argument rather than an input file. -- Joseph S. Myers jos...@codesourcery.com
