Hello Bernd, Thanks for your feedback on this :-)
> On 11 Jan 2016, at 17:09, Bernd Schmidt <bschm...@redhat.com> wrote: > > On 01/08/2016 02:23 PM, Olivier Hainque wrote: >> + /* Undefined variable references in specs are harmless if >> + we're running for --help or --version alone, or together. */ >> + spec_undefvar_allowed = >> + (((print_version || print_help_list) >> + && decoded_options_count == 2) >> + || >> + ((print_version && print_help_list) >> + && decoded_options_count == 3)); >> + > > This doesn't follow the formatting rules. Arg, indeed. Revised version attached. > Also, there are a couple of other options that cause gcc to just print > something and exit. Are these affected by missing env vars? Some of these, for sure. For example, a common use case here is to define a default --sysroot. We need this to be set properly for at least --print-search-dirs and --print-prog-name, probably --print-file-name. The print-multi family might be ok. It's heavily based on the presence of other options on the command line, but maybe never depending on argument values. I wasn't ready to bet though and opted for a conservative approach first. The attached patch is doing the same as the previous one, except more explicitly and making it easier to adapt if deemed useful. I could extract the decision code in a separate function if you prefer. Olivier
spec-undef.diff
Description: Binary data
