GDB testsuite: Suppress GCC's colored output

  Newer GCC versions yield colored diagnostic messages by default, which may
be useful when executing GDB interactively from a terminal.  But when run
from a GDB test case, the compiler output is written into gdb.log, where
such escape sequences are usually more inhibiting than helpful to the
evaluation of test results.  So this patch suppresses that.

gdb/testsuite/ChangeLog:

	* lib/gdb.exp (gdb_compile): Suppress GCC's coloring of messages.
---
 gdb/testsuite/lib/gdb.exp | 3 +++
 1 file changed, 3 insertions(+)
  

On 2017-08-02 19:35, Andreas Arnez wrote:
> Newer GCC versions yield colored diagnostic messages by default, which 
> may
> be useful when executing GDB interactively from a terminal.  But when 
> run
> from a GDB test case, the compiler output is written into gdb.log, 
> where
> such escape sequences are usually more inhibiting than helpful to the
> evaluation of test results.  So this patch suppresses that.

That's because you are not using the right viewer :).  Try "less -R 
gdb.log", you should see the rainbow.

> 
> gdb/testsuite/ChangeLog:
> 
> 	* lib/gdb.exp (gdb_compile): Suppress GCC's coloring of messages.
> ---
>  gdb/testsuite/lib/gdb.exp | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index 3d3eaab..9a5c27f 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -3552,6 +3552,9 @@ proc gdb_compile {source dest type options} {
>  	}
>      }
> 
> +    # Stop the compiler from producing colored output.
> +    setenv GCC_COLORS ""
> +
>      set result [target_compile $source $dest $type $options]
> 
>      # Prune uninteresting compiler (and linker) output.

I was wondering why GCC showed colors even though it's not invoked 
"interactively".  Dejagnu uses expect's spawn to spawn processes, 
including the compiler.  spawn allocates a tty for the subprocess, which 
is what GCC checks to determine whether or not to enable colors.

You patch LGTM, but please leave the patch for review for a few days, 
then push it if nobody says anything.

Thanks!

Simon
  

On Wed, Aug 02 2017, Simon Marchi wrote:

> On 2017-08-02 19:35, Andreas Arnez wrote:
>> Newer GCC versions yield colored diagnostic messages by default, which
>> may
>> be useful when executing GDB interactively from a terminal.  But when
>> run
>> from a GDB test case, the compiler output is written into gdb.log, where
>> such escape sequences are usually more inhibiting than helpful to the
>> evaluation of test results.  So this patch suppresses that.
>
> That's because you are not using the right viewer :).  Try "less -R 
> gdb.log", you should see the rainbow.

Right...  That's why I wrote "usually".  Such as when using "grep",
loading the file into an editor, pasting the error message into an
e-Mail, etc.

>
>>
>> gdb/testsuite/ChangeLog:
>>
>> 	* lib/gdb.exp (gdb_compile): Suppress GCC's coloring of messages.
>> ---
>>  gdb/testsuite/lib/gdb.exp | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
>> index 3d3eaab..9a5c27f 100644
>> --- a/gdb/testsuite/lib/gdb.exp
>> +++ b/gdb/testsuite/lib/gdb.exp
>> @@ -3552,6 +3552,9 @@ proc gdb_compile {source dest type options} {
>>  	}
>>      }
>>
>> +    # Stop the compiler from producing colored output.
>> +    setenv GCC_COLORS ""
>> +
>>      set result [target_compile $source $dest $type $options]
>>
>>      # Prune uninteresting compiler (and linker) output.
>
> I was wondering why GCC showed colors even though it's not invoked
> "interactively".  Dejagnu uses expect's spawn to spawn processes,
> including the compiler.  spawn allocates a tty for the subprocess, which
> is what GCC checks to determine whether or not to enable colors.

Right.  If spawn used a pipe instead of a pseudo-tty, then GCC wouldn't
show colors.

> You patch LGTM, but please leave the patch for review for a few days, then
> push it if nobody says anything.

OK.

--
Andreas
  

Andreas Arnez <arnez@linux.vnet.ibm.com> writes:

Hi Andreas,

> +    # Stop the compiler from producing colored output.
> +    setenv GCC_COLORS ""
> +

This doesn't work for remote host.  How about passing option
-fno-color-diagnostics to compiler which supports that option?  Both gcc
(4.9 and later) and clang has this option.
  

On 2017-08-04 13:06, Yao Qi wrote:
> Andreas Arnez <arnez@linux.vnet.ibm.com> writes:
> 
> Hi Andreas,
> 
>> +    # Stop the compiler from producing colored output.
>> +    setenv GCC_COLORS ""
>> +
> 
> This doesn't work for remote host.  How about passing option
> -fno-color-diagnostics to compiler which supports that option?  Both 
> gcc
> (4.9 and later) and clang has this option.

My gcc (5.4) doesn't recognize it:

$ gcc -fno-color-diagnostics test.c
gcc: error: unrecognized command line option ‘-fno-color-diagnostics’

It knows about -fdiagnostics-color=never however, which clang seems to 
recognize as well.  It would be nice however not to restrict the 
compiler version used for testing just for this.  Can we write a small 
proc that checks if the compiler recognizes that flag and only include 
it if it does?

Simon
  

Simon Marchi <simon.marchi@polymtl.ca> writes:

> My gcc (5.4) doesn't recognize it:
>
> $ gcc -fno-color-diagnostics test.c
> gcc: error: unrecognized command line option ‘-fno-color-diagnostics’
>

Ah, sorry.  What I meant is -fdiagnostics-color=never.

> It knows about -fdiagnostics-color=never however, which clang seems to
> recognize as well.  It would be nice however not to restrict the
> compiler version used for testing just for this.  Can we write a small
> proc that checks if the compiler recognizes that flag and only include
> it if it does?

Yes, we can do that, but be careful on the recursive calls here.  We
want to pass -fdiagnostics-color=never to compiler during compilation,
but we need to check whether compiler understands this option or not.
When we test compiler, we may pass -fdiagnostics-color=never to compiler
to try to compile something again to see if compiler understands.