On 10/31/21 8:13 AM, Daniil Stas wrote:
On Sun, 10 Oct 2021 23:10:20 +0000
Daniil Stas <daniil.s...@posteo.net> wrote:
This option is enabled by default when -Wformat option is enabled. A
user can specify -Wno-format-int-precision to disable emitting
warnings when passing an argument of an incompatible integer type to
a 'd', 'i', 'o', 'u', 'x', or 'X' conversion specifier when it has
the same precision as the expected type.
Signed-off-by: Daniil Stas <daniil.s...@posteo.net>
gcc/c-family/ChangeLog:
* c-format.c (check_format_types): Don't emit warnings when
passing an argument of an incompatible integer type to
a 'd', 'i', 'o', 'u', 'x', or 'X' conversion specifier when
it has the same precision as the expected type if
-Wno-format-int-precision option is specified.
* c.opt: Add -Wformat-int-precision option.
gcc/ChangeLog:
* doc/invoke.texi: Add -Wformat-int-precision option
description.
gcc/testsuite/ChangeLog:
* c-c++-common/Wformat-int-precision-1.c: New test.
* c-c++-common/Wformat-int-precision-2.c: New test.
---
This is an update of patch "c-format: Add -Wformat-same-precision
option [PR80060]". The changes comparing to the first patch version:
- changed the option name to -Wformat-int-precision
- changed the option description as was suggested by Martin
- changed Wformat-int-precision-2.c to used dg-bogus instead of
previous invalid syntax
I also tried to combine the tests into one file with #pragma GCC
diagnostic, but looks like it's not possible. I want to test that
when passing just -Wformat option everything works as before my patch
by default. And then in another test case to check that passing
-Wno-format-int-precision disables the warning. But looks like in GCC
you can't toggle the warnings such as -Wno-format-int-precision
individually but only can disable the general -Wformat option that
will disable all the formatting warnings together, which is not the
proper test.
Hi,
Can anyone review this patch?
Thank you
I can't approve the change but it looks pretty good to me.
The documentation should wrap code symbols like int64_t, long,
or printf in @code{} directives.
I don't think the first test needs to be restricted to just
lp64, although I'd expect it to already be covered by the test
suite. The lp64 selector only tells us that int is 32 bits
and long (and pointer) are 64, but nothing about long long so
I suspect the test might fail on other targets. There's llp64
that's true for 4 byte ints and longs (but few targets match),
and long_neq_int that's true when long is not the same size as
int. So I think the inverse of the latter might be best, with
int and long as arguments. testsuite/lib/target-supports.exp
defines these and others.
It might also be a good idea to add another case to the second
test to exercise arguments with different precision to make
sure -Wformat still triggers for those even with
-Wno-format-int-precision.
The -Wformat warnings are Joseph's domain (CC'd) so either he
or some other C or global reviewer needs to sign off on changes
in this area. (Please ping the patch weekly until you get
a response.)
Thanks
Martin
