On 05/02/2017 02:13 PM, Simon Sobisch wrote:
I'm responding here as it was "opened" in this list directly.
You were right, adding -fno-diagnostics-color doesn't show anything
empty, changing it to -fdiagnostics-color bring the nice colors in - and
the spaces instead of the code (yes, I've copied it directly from the
terminal).

I'm on the following machine:

hostname = mymachine-trisquel
uname -m = x86_64
uname -r = 3.13.0-116-lowlatency
uname -s = Linux
uname -v = #163+7.0trisquel2 SMP PREEMPT Thu Apr 6 13:16:46 UTC 2017

I've just got the latest revision 247521 from branch-gcc-7 and did a
recompile (this time using the GCC 7 that was previously built) and the
issue stays.

I've just placed the output into a vim stdin pipe and can see the source
+ its control attributes:

make 2>&1 | vim - -R -c 'set filetype=nomodified nomodifiable nonu'

^[[01m^[[K../../../cobc/typeck.c:1064:2:^[[m^[[K ^[[01;36m^[[Knote:
^[[m^[[K'^[[01m^[[Ksnprintf^[[m^[[K' output between 17 and 63 bytes into
a destination of size 17
  ^[[01;36m^[[Ksnprintf (buff, (size_t)17,
"%02d/%02d/%02d%02d%c%02d%c%02d",^M^[[m^[[K

^[[01;36m^[[K^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^[[m^[[K
 ^[[01;36m^[[K  current_compile_time.day_of_month,^M^[[m^[[K
   ^[[01;36m^[[K~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^[[m^[[K
 ^[[01;36m^[[K  current_compile_time.month,^M^[[m^[[K
   ^[[01;36m^[[K~~~~~~~~~~~~~~~~~~~~~~~~~~~~^[[m^[[K
 ^[[01;36m^[[K  current_compile_time.year % 100,^M^[[m^[[K
   ^[[01;36m^[[K~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^[[m^[[K
 ^[[01;36m^[[K  current_compile_time.hour, '.',^M^[[m^[[K
   ^[[01;36m^[[K~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^[[m^[[K
 ^[[01;36m^[[K  current_compile_time.minute, '.',^M^[[m^[[K
   ^[[01;36m^[[K~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^[[m^[[K
 ^[[01;36m^[[K  current_compile_time.second)^[[m^[[K;^M
   ^[[01;36m^[[K~~~~~~~~~~~~~~~~~~~~~~~~~~~~^[[m^[[K

The main question is: is this a GCC problem or a Trisquel problem?
If it is the later is there any option for GCC to recognize this problem?

From the above it looks like GCC does output the text suggesting
that the problem is not in it, but the GCC colorization is not my
area of expertise (I just wrote the -Wformat-truncation warning).
It's strange to me that you can see the tildes but not the plain
text. I would suggest to try a different terminal.  Otherwise,
post your question to gcc-help where people who know more about
these things than me can help you.

Martin


Simon
Am 02.05.2017 um 01:29 schrieb Martin Sebor:
On 05/01/2017 01:39 PM, Simon Sobisch wrote:
Hi,

I've just got GCC7 (build from svn worked like a charm, even if it
took hours but I was warned) and like the new warnings and hints very
much.

When compiling GnuCOBOL from vcs (sources on mount, therefore the long
path) I got one warning with multiple and very long tilde lines.

/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c: In
function 'cb_build_registers':
/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c:1064:30:
warning: 'snprintf' output may be truncated before the last format
character [-Wformat-truncation=]
  snprintf (buff, (size_t)17, "%02d/%02d/%02d%02d%c%02d%c%02d",
                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c:1064:2: note:
'snprintf' output between 17 and 63 bytes into a destination of size 17

  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   current_compile_time.second);
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It looks like the source in the lines between are missing (the number
of tildes is correct).
The source reads:

    snprintf (buff, (size_t)17, "%02d/%02d/%02d%02d%c%02d%c%02d",
        current_compile_time.day_of_month,
        current_compile_time.month,
        current_compile_time.year % 100,
        current_compile_time.hour, '.',
        current_compile_time.minute, '.',
        current_compile_time.second);

Hmm, that's quite odd.  I'm not able to reproduce this "effect"
and I have never seen anything like it.  My first thought was
that it could be a problem with the terminal you are using (try
compiling with -fno-diagnostics-color to see if it improves)
but since you presumably copied the error message above from
the terminal that's probably not going to help.  If it doesn't,
can you please create a new bug and attach to it a preprocessing
translation unit (compile the source file with -E and save the
output)?  Also include the full set of command line options you
invoked the compiler with when you got the "invisible" message.

[...}

Martin

Reply via email to