https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83698
Martin Sebor <msebor at gcc dot gnu.org> 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 <msebor at gcc dot gnu.org> ---
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.
