public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Build failure due to format-truncation
@ 2021-06-13 17:48 José Rui Faustino de Sousa
  2021-06-16 16:53 ` Martin Sebor
  0 siblings, 1 reply; 9+ messages in thread
From: José Rui Faustino de Sousa @ 2021-06-13 17:48 UTC (permalink / raw)
  To: gcc


Hi All!

While building I started to get this error:

../../gcc-master/gcc/opts.c: In function ‘void 
print_filtered_help(unsigned int, unsigned int, unsigned int, unsigned 
int, gcc_options*, unsigned int)’:
../../gcc-master/gcc/opts.c:1497:26: error: ‘  ’ directive output may be 
truncated writing 2 bytes into a region of size between 1 and 256 
[-Werror=format-truncation=]
  1497 |                       "%s  %s", help, _(use_diagnosed_msg));
       |                          ^~
../../gcc-master/gcc/opts.c:1496:22: note: ‘snprintf’ output 3 or more 
bytes (assuming 258) into a destination of size 256
  1496 |             snprintf (new_help, sizeof new_help,
       |             ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
  1497 |                       "%s  %s", help, _(use_diagnosed_msg));
       |                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors

My guess is that it is due to the use of the flag "-fstrict-overflow"

I am not complaining or saying that this is a bug, but the whole code 
compiles fine with this flag except for this single instance...

Thank you very much.

Best regards,
José Rui


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Build failure due to format-truncation
  2021-06-13 17:48 Build failure due to format-truncation José Rui Faustino de Sousa
@ 2021-06-16 16:53 ` Martin Sebor
  2021-06-16 17:21   ` José Rui Faustino de Sousa
  0 siblings, 1 reply; 9+ messages in thread
From: Martin Sebor @ 2021-06-16 16:53 UTC (permalink / raw)
  To: José Rui Faustino de Sousa, gcc

On 6/13/21 11:48 AM, José Rui Faustino de Sousa via Gcc wrote:
> 
> Hi All!
> 
> While building I started to get this error:
> 
> ../../gcc-master/gcc/opts.c: In function ‘void 
> print_filtered_help(unsigned int, unsigned int, unsigned int, unsigned 
> int, gcc_options*, unsigned int)’:
> ../../gcc-master/gcc/opts.c:1497:26: error: ‘  ’ directive output may be 
> truncated writing 2 bytes into a region of size between 1 and 256 
> [-Werror=format-truncation=]
>   1497 |                       "%s  %s", help, _(use_diagnosed_msg));
>        |                          ^~
> ../../gcc-master/gcc/opts.c:1496:22: note: ‘snprintf’ output 3 or more 
> bytes (assuming 258) into a destination of size 256
>   1496 |             snprintf (new_help, sizeof new_help,
>        |             ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
>   1497 |                       "%s  %s", help, _(use_diagnosed_msg));
>        |                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1plus: all warnings being treated as errors
> 
> My guess is that it is due to the use of the flag "-fstrict-overflow"
> 
> I am not complaining or saying that this is a bug, but the whole code 
> compiles fine with this flag except for this single instance...

-fstrict-overflow isn't related to the warning or to sprintf (it
controls whether signed integer overflow is considered undefined).

The warning above tells you that if help points to a string that's
255 characters long the snprintf output will be truncated.  This
warning is only issued at level 2 (-Wformat-truncation=2) which
points out more instances of possible truncation than the more
conservative level 1.

Martin

> 
> Thank you very much.
> 
> Best regards,
> José Rui
> 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Build failure due to format-truncation
  2021-06-16 16:53 ` Martin Sebor
@ 2021-06-16 17:21   ` José Rui Faustino de Sousa
  2021-06-16 20:37     ` Martin Sebor
  0 siblings, 1 reply; 9+ messages in thread
From: José Rui Faustino de Sousa @ 2021-06-16 17:21 UTC (permalink / raw)
  To: Martin Sebor, gcc

On 16/06/21 16:53, Martin Sebor wrote:
> -fstrict-overflow isn't related to the warning or to sprintf (it
> controls whether signed integer overflow is considered undefined).
> 
> The warning above tells you that if help points to a string that's
> 255 characters long the snprintf output will be truncated.  This
> warning is only issued at level 2 (-Wformat-truncation=2) which
> points out more instances of possible truncation than the more
> conservative level 1.
> 

These are the flags I use to build gcc:

-O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
-fno-omit-frame-pointer -fstrict-overflow -fstack-check

I have been using these flags for more than a year now, it just started 
failing recently.

Maybe this is due to some other, deeper, issue?

Thank you very much.

Best regards,
José Rui

P.S.- from config.log:

   $ ../gcc-local/configure --prefix=/opt/gcc/gcc-local --enable-debug 
--enable-checking --enable-valgrind-annotations --disable-multilib 
CFLAGS= -O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
-fno-omit-frame-pointer -fstrict-overflow -fstack-check   CXXFLAGS= -O0 
-g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments -fno-omit-frame-pointer 
-fstrict-overflow -fstack-check   --enable-languages=c,c++,fortran,lto 
--no-create --no-recursion


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Build failure due to format-truncation
  2021-06-16 17:21   ` José Rui Faustino de Sousa
@ 2021-06-16 20:37     ` Martin Sebor
  2021-06-17  0:26       ` José Rui Faustino de Sousa
  0 siblings, 1 reply; 9+ messages in thread
From: Martin Sebor @ 2021-06-16 20:37 UTC (permalink / raw)
  To: José Rui Faustino de Sousa, gcc

On 6/16/21 11:21 AM, José Rui Faustino de Sousa wrote:
> On 16/06/21 16:53, Martin Sebor wrote:
>> -fstrict-overflow isn't related to the warning or to sprintf (it
>> controls whether signed integer overflow is considered undefined).
>>
>> The warning above tells you that if help points to a string that's
>> 255 characters long the snprintf output will be truncated.  This
>> warning is only issued at level 2 (-Wformat-truncation=2) which
>> points out more instances of possible truncation than the more
>> conservative level 1.
>>
> 
> These are the flags I use to build gcc:
> 
> -O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
> -fno-omit-frame-pointer -fstrict-overflow -fstack-check
> 
> I have been using these flags for more than a year now, it just started 
> failing recently.
> 
> Maybe this is due to some other, deeper, issue?

The early sprintf warning pass has been moved recently to run after
the IL has been converted to the SSA form which lets it follow more
logic.  But because few optimizations have been done on the IL at
that point it also results in different warnings than when it runs
later.  In this case, the difference is that the pass now sees a PHI
where before it saw a VAR_DECL and the logic between the two is just
different enough that it makes a difference to the heuristics used
to enable vs disable it.  I don't really think the warning is doing
anything wrong, it just works with limited view of the code at -O0.
Perhaps it might be worth turning off the "maybe" kind of warnings
when optimization is disabled to reduce noise.  Here's a test case
that shows another difference between GCC 11 and trunk (although
this one warns consistently with -O0 and -O2 as well so that's
an improvement):

   char a[7], d[8], *p;

   void f (int i)
   {
     const char *s = i ? a : p;
     __builtin_snprintf (d, sizeof d, "%s x", s);   // trunk warns
   }

Martin

> 
> Thank you very much.
> 
> Best regards,
> José Rui
> 
> P.S.- from config.log:
> 
>    $ ../gcc-local/configure --prefix=/opt/gcc/gcc-local --enable-debug 
> --enable-checking --enable-valgrind-annotations --disable-multilib 
> CFLAGS= -O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
> -fno-omit-frame-pointer -fstrict-overflow -fstack-check   CXXFLAGS= -O0 
> -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments -fno-omit-frame-pointer 
> -fstrict-overflow -fstack-check   --enable-languages=c,c++,fortran,lto 
> --no-create --no-recursion
> 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Build failure due to format-truncation
  2021-06-16 20:37     ` Martin Sebor
@ 2021-06-17  0:26       ` José Rui Faustino de Sousa
  2021-06-17 20:51         ` Martin Sebor
  0 siblings, 1 reply; 9+ messages in thread
From: José Rui Faustino de Sousa @ 2021-06-17  0:26 UTC (permalink / raw)
  To: Martin Sebor, gcc

On 16/06/21 20:37, Martin Sebor wrote:
> I don't really think the warning is doing
> anything wrong
> 

I completely agree. I am not complaining about the warning, I am 
complaining that there is code in gcc which raises this warning and 
breaks the build.

I was assuming that this was being triggered by some option that I was 
using but, on further investigation, the -Wformat-truncation flag is 
being set by -Wall which AFAICT is set by the build process itself...

So this is starting to look like something that really should be 
fixed... What bugs me is why it seems that I was the only one who noticed...

Thank you very much.

Best regards,
José Rui



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Build failure due to format-truncation
  2021-06-17  0:26       ` José Rui Faustino de Sousa
@ 2021-06-17 20:51         ` Martin Sebor
  2021-06-17 23:04           ` José Rui Faustino de Sousa
  0 siblings, 1 reply; 9+ messages in thread
From: Martin Sebor @ 2021-06-17 20:51 UTC (permalink / raw)
  To: José Rui Faustino de Sousa, gcc

On 6/16/21 6:26 PM, José Rui Faustino de Sousa wrote:
> On 16/06/21 20:37, Martin Sebor wrote:
>> I don't really think the warning is doing
>> anything wrong
>>
> 
> I completely agree. I am not complaining about the warning, I am 
> complaining that there is code in gcc which raises this warning and 
> breaks the build.
> 
> I was assuming that this was being triggered by some option that I was 
> using but, on further investigation, the -Wformat-truncation flag is 
> being set by -Wall which AFAICT is set by the build process itself...

Correct.

> 
> So this is starting to look like something that really should be 
> fixed... What bugs me is why it seems that I was the only one who 
> noticed...

What stage does this happens in, and if stage 1, what is the system 
compiler?  You need GCC 12 to reproduce it and as far as I can see
it needs -O0 (or -Og or -Os).  That seems like a unique setup.  If
this is stage 1 it doesn't use -Werror so warnings shouldn't keep
the build from succeeding.  If some later stage and you're using
any unusual options (like -Og or -Os) then that would also be
unusual.  Otherwise I'll need more info to understand what's going
on.

Martin

> 
> Thank you very much.
> 
> Best regards,
> José Rui
> 
> 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Build failure due to format-truncation
  2021-06-17 20:51         ` Martin Sebor
@ 2021-06-17 23:04           ` José Rui Faustino de Sousa
  2021-06-18  0:05             ` Martin Sebor
  0 siblings, 1 reply; 9+ messages in thread
From: José Rui Faustino de Sousa @ 2021-06-17 23:04 UTC (permalink / raw)
  To: Martin Sebor, gcc

On 17/06/21 20:51, Martin Sebor wrote:
> What stage does this happens in, and if stage 1, what is the system 
> compiler? 
 >

I am not sure if this happens also in the earlier stages, I would have 
to do a complete rebuild and that would take some time.

I have built gcc using an altered "opts.c" so that it compiles without 
problems. After that replacing the file with the original one generates 
the error. So this is happening at the later stages of compilation.

> You need GCC 12 to reproduce it and as far as I can see
> it needs -O0 (or -Og or -Os). 
 >

No problems with 11, 10 or 9, with the same flags.

> That seems like a unique setup.  If
> this is stage 1 it doesn't use -Werror so warnings shouldn't keep
> the build from succeeding.  If some later stage and you're using
> any unusual options (like -Og or -Os) then that would also be
> unusual.  Otherwise I'll need more info to understand what's going
> on.
> 

This is the full command issued by make:

/home/jrfsousa/Work/gcc/build-master/./prev-gcc/xg++ 
-B/home/jrfsousa/Work/gcc/build-master/./prev-gcc/ 
-B/opt/gcc/gcc-master/x86_64-pc-linux-gnu/bin/ -nostdinc++ 
-B/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs 
-B/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
 
-I/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu 
 
-I/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
  -I/home/jrfsousa/Work/gcc/gcc-master/libstdc++-v3/libsupc++ 
-L/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs 
-L/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
  -fno-PIE -c   -O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
-fno-omit-frame-pointer -fstrict-overflow -fstack-check   -fchecking=1 
-DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W 
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag 
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc-master/gcc -I../../gcc-master/gcc/. 
-I../../gcc-master/gcc/../include 
-I../../gcc-master/gcc/../libcpp/include 
-I../../gcc-master/gcc/../libcody 
-I/home/jrfsousa/Work/gcc/build-master/./gmp 
-I/home/jrfsousa/Work/gcc/gcc-master/gmp 
-I/home/jrfsousa/Work/gcc/build-master/./mpfr/src 
-I/home/jrfsousa/Work/gcc/gcc-master/mpfr/src 
-I/home/jrfsousa/Work/gcc/gcc-master/mpc/src 
-I../../gcc-master/gcc/../libdecnumber 
-I../../gcc-master/gcc/../libdecnumber/bid -I../libdecnumber 
-I../../gcc-master/gcc/../libbacktrace 
-I/home/jrfsousa/Work/gcc/build-master/./isl/include 
-I/home/jrfsousa/Work/gcc/gcc-master/isl/include  -o opts.o -MT opts.o 
-MMD -MP -MF ./.deps/opts.TPo ../../gcc-master/gcc/opts.c

Applying the command by hand still fails, with or without the flags I 
used (-O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
-fno-omit-frame-pointer -fstrict-overflow -fstack-check), after removing 
"-Wall" the compilation succeeds without problems.

Thank you very much.

Best regards,
José Rui


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Build failure due to format-truncation
  2021-06-17 23:04           ` José Rui Faustino de Sousa
@ 2021-06-18  0:05             ` Martin Sebor
  2021-06-20 10:33               ` José Rui Faustino de Sousa
  0 siblings, 1 reply; 9+ messages in thread
From: Martin Sebor @ 2021-06-18  0:05 UTC (permalink / raw)
  To: José Rui Faustino de Sousa, gcc

On 6/17/21 5:04 PM, José Rui Faustino de Sousa wrote:
> On 17/06/21 20:51, Martin Sebor wrote:
>> What stage does this happens in, and if stage 1, what is the system 
>> compiler? 
>  >
> 
> I am not sure if this happens also in the earlier stages, I would have 
> to do a complete rebuild and that would take some time.
> 
> I have built gcc using an altered "opts.c" so that it compiles without 
> problems. After that replacing the file with the original one generates 
> the error. So this is happening at the later stages of compilation.
> 
>> You need GCC 12 to reproduce it and as far as I can see
>> it needs -O0 (or -Og or -Os). 
>  >
> 
> No problems with 11, 10 or 9, with the same flags.
> 
>> That seems like a unique setup.  If
>> this is stage 1 it doesn't use -Werror so warnings shouldn't keep
>> the build from succeeding.  If some later stage and you're using
>> any unusual options (like -Og or -Os) then that would also be
>> unusual.  Otherwise I'll need more info to understand what's going
>> on.
>>
> 
> This is the full command issued by make:
> 
> /home/jrfsousa/Work/gcc/build-master/./prev-gcc/xg++ 
> -B/home/jrfsousa/Work/gcc/build-master/./prev-gcc/ 
> -B/opt/gcc/gcc-master/x86_64-pc-linux-gnu/bin/ -nostdinc++ 
> -B/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs 
> -B/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
> 
> -I/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu 
> 
> -I/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
>   -I/home/jrfsousa/Work/gcc/gcc-master/libstdc++-v3/libsupc++ 
> -L/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs 
> -L/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
>   -fno-PIE -c   -O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
                   ^^^

Right, with -O0 we understand why it happens.  So you must have set
CXXFLAGS to -O0 (you might have said that and I forgot; if so, sorry
if I sent you on a wild goose chase). That's also the unusual part
and why others haven't run into it.  Normally stage 2 and later build
with -O2 or higher.

Does that make sense?

Martin


> -fno-omit-frame-pointer -fstrict-overflow -fstack-check   -fchecking=1 
> -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W 
> -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag 
> -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
> -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
> -DHAVE_CONFIG_H -I. -I. -I../../gcc-master/gcc -I../../gcc-master/gcc/. 
> -I../../gcc-master/gcc/../include 
> -I../../gcc-master/gcc/../libcpp/include 
> -I../../gcc-master/gcc/../libcody 
> -I/home/jrfsousa/Work/gcc/build-master/./gmp 
> -I/home/jrfsousa/Work/gcc/gcc-master/gmp 
> -I/home/jrfsousa/Work/gcc/build-master/./mpfr/src 
> -I/home/jrfsousa/Work/gcc/gcc-master/mpfr/src 
> -I/home/jrfsousa/Work/gcc/gcc-master/mpc/src 
> -I../../gcc-master/gcc/../libdecnumber 
> -I../../gcc-master/gcc/../libdecnumber/bid -I../libdecnumber 
> -I../../gcc-master/gcc/../libbacktrace 
> -I/home/jrfsousa/Work/gcc/build-master/./isl/include 
> -I/home/jrfsousa/Work/gcc/gcc-master/isl/include  -o opts.o -MT opts.o 
> -MMD -MP -MF ./.deps/opts.TPo ../../gcc-master/gcc/opts.c
> 
> Applying the command by hand still fails, with or without the flags I 
> used (-O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
> -fno-omit-frame-pointer -fstrict-overflow -fstack-check), after removing 
> "-Wall" the compilation succeeds without problems.
> 
> Thank you very much.
> 
> Best regards,
> José Rui
> 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Build failure due to format-truncation
  2021-06-18  0:05             ` Martin Sebor
@ 2021-06-20 10:33               ` José Rui Faustino de Sousa
  0 siblings, 0 replies; 9+ messages in thread
From: José Rui Faustino de Sousa @ 2021-06-20 10:33 UTC (permalink / raw)
  To: Martin Sebor, gcc

On 18/06/21 00:05, Martin Sebor wrote:
> Right, with -O0 we understand why it happens.
> 

I think I have found a minimal way to reproduce the build failure:

make BOOT_CFLAGS="-O0" bootstrap

No environment variables set.

Setting CFLAGS, CXXFLAGS or both does not seem to have any effect.

Additionally at -O1 I found:

../../gcc-xtra/gcc/gimplify.c: In function ‘gimplify_status 
gimplify_omp_loop(tree_node**, gimple**)’:
../../gcc-xtra/gcc/gimplify.c:12975:17: error: ‘last’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
12975 |                 if (pass != last)
       |                 ^~
cc1plus: all warnings being treated as errors

And finally at -O2 there were no problems.

It would have been interesting to try other options, but the build takes 
an enormous amount of time...

Thank you very much.

Best regards,
José Rui


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-06-20 10:33 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-13 17:48 Build failure due to format-truncation José Rui Faustino de Sousa
2021-06-16 16:53 ` Martin Sebor
2021-06-16 17:21   ` José Rui Faustino de Sousa
2021-06-16 20:37     ` Martin Sebor
2021-06-17  0:26       ` José Rui Faustino de Sousa
2021-06-17 20:51         ` Martin Sebor
2021-06-17 23:04           ` José Rui Faustino de Sousa
2021-06-18  0:05             ` Martin Sebor
2021-06-20 10:33               ` José Rui Faustino de Sousa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).