[Bug tree-optimization/83698] bogus offset in -Wrestrict messages for strcat of unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83698 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- (In reply to Markus Trippelsdorf from comment #0) Hey, Markus is back!
[Bug tree-optimization/83698] bogus offset in -Wrestrict messages for strcat of unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83698 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed in r257676.
[Bug tree-optimization/83698] bogus offset in -Wrestrict messages for strcat of unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83698 --- Comment #3 from Martin Sebor --- Author: msebor Date: Wed Feb 14 23:22:15 2018 New Revision: 257676 URL: https://gcc.gnu.org/viewcvs?rev=257676=gcc=rev Log: PR tree-optimization/83698 - bogus offset in -Wrestrict messages for strcat of unknown strings gcc/ChangeLog: PR tree-optimization/83698 * gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): For arrays constrain the offset range to their bounds. (builtin_access::strcat_overlap): Adjust the bounds of overlap offset. (builtin_access::overlap): Avoid setting the size of overlap if it's already been set. (maybe_diag_overlap): Also consider arrays when deciding what values of offsets to include in diagnostics. gcc/testsuite/ChangeLog: PR tree-optimization/83698 * gcc.dg/Wrestrict-7.c: New test. * c-c++-common/Wrestrict.c: Adjust expected values for strcat. * gcc.target/i386/chkp-stropt-17.c: Same. Added: trunk/gcc/testsuite/gcc.dg/Wrestrict-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-warn-restrict.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Wrestrict.c trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-17.c
[Bug tree-optimization/83698] bogus offset in -Wrestrict messages for strcat of unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83698 Martin Sebor changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01488.html
[Bug tree-optimization/83698] bogus offset in -Wrestrict messages for strcat of unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83698
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-05
Component|c |tree-optimization
Summary|[8 Regression] -Wrestrict |bogus offset in -Wrestrict
|oddities|messages for strcat of
||unknown strings
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed, though I don't consider it a regression. Here's a test case for the
bogus strcat offset:
$ cat b.c && gcc -O2 -S -Wall b.c
extern char* strcat (char*, const char*);
extern char d[];
void f (unsigned i)
{
strcat (d + 36, d + 20);
}
b.c: In function ‘f’:
b.c:7:3: warning: ‘strcat’ accessing 0 or more bytes at offsets 36 and 20 may
overlap 1 byte at offset [36, -9223372036854775773] [-Wrestrict]
The weird looking upper bound of the offset range is due to converting a very
large offset_int value that the pass computes offsets and sizes in to
HOST_WIDE_INT for printing. This conversion is necessary because GCC's pretty
printer has no formatting directive for any of the wide int flavors. There are
likely other issues like this one that will disappear once the pretty printer
is enhanced to format wide ints and the conversions removed from -Wrestrict
code. I'll try to find the time to fix this one for GCC 8.
I also tend to agree with the comment about the redundancy. I considered
avoiding it when I wrote the code but decided it wasn't worthwhile. To help
you appreciate the challenges in producing meaningful messages from the
-Wrestrict pass (and others like it) I invite you to look at the code in the
maybe_diag_overlap function in gimple-ssa-warn-restrict.c and consider the
different forms of warnings it already issues. Avoiding the redundancy would
nearly double the number of messages the function issues, from 20 to 40. That
said, I am interested in making the messages more useful and informative so if
you have suggestions for how to rephrase them without unduly growing their
number or losing detail I'd love to hear them. Until some good ideas surface I
don't expect to make a change here.
PS Even to the author of a feature it's not terribly helpful to just paste a
random warning message without a test case. I know the numbers in some of the
warnings could be improved so a report without one doesn't tell me anything
new.
