On Mon, Feb 08, 2016 at 02:38:17PM +0100, Tom de Vries wrote:
> hmm, indeed removing the 'Driver' flag from the fdiagnostics-color= entry in
> common.opt breaks the functioning of fdiagnostics-color= in the gcc driver.
>
> This patch leaves the 'Driver' flag alone, and instead explicitly allows
> fdiagnostics-color= in lto_write_options.
>
> Is this approach ok?
Doesn't that mean storing -fdiagnostics-color= into the LTO option section and
then using whatever was recorded from the first TU that recorded anything?
That doesn't look right for such diagnostics options either.
I mean, if I
$ gcc -fdiagnostics-color=always -c -flto a.c
on another terminal
$ gcc -fdiagnostics-color=never -c -flto b.c
on yet another terminal
$ gcc -flto -o a a.o b.o
then I'd expect the default setting for -fdiagnostics-color= for all
diagnostics while linking/LTO optimizing it, and for say
$ gcc -fdiagnostics-color=always -flto -o a a.o b.o
to have it always colorized, similarly for never.
IMHO we should just honor what has been specified on the linker command
line if anything. So, the question is, is -fdiagnostics-color=never passed
in the testsuite just to the compilation and not to linking (that would be
IMHO a testsuite bug), or is it passed on the linking command line, but not
passed through to lto1?
> Handle -fdiagnostics-color in lto
>
> 2016-02-08 Tom de Vries <t...@codesourcery.com>
>
> PR lto/69707
> * lto-opts.c (lto_write_options): Allow fdiagnostics-color.
> * lto-wrapper.c (merge_and_complain, append_compiler_options): Handle
> OPT_fdiagnostics_color_.
>
> * testsuite/libgomp.oacc-c-c++-common/parallel-dims-2.c: New test.
Jakub
