Bug 91599 - GCC does not say where warning is happening
Summary: GCC does not say where warning is happening
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 10.0
: P3 normal
Target Milestone: 10.0
Assignee: Martin Sebor
URL:
Keywords: diagnostic, patch
Depends on:
Blocks: Wstringop-overflow
  Show dependency treegraph
 
Reported: 2019-08-29 21:51 UTC by Steve Ellcey
Modified: 2019-08-30 17:50 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2019-08-29 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Ellcey 2019-08-29 21:51:06 UTC
When compiling the following source file, GCC gives a warning.  The warning notes that the declaration is on line 2 but it does not say what line the actual write is on (line 12).  This message started showing up with Martin Sebor's patch for PR c++/83431 though I don't know if he added it or if he just made it show up in places where it wasn't happening before.

% cat x.c
struct charseq {
   unsigned char bytes[0];
};
struct locale_ctype_t {
   struct charseq *mboutdigits[10];
};
void ctype_finish (struct locale_ctype_t *ctype)
{
   long unsigned int cnt;
   for (cnt = 0; cnt < 20; ++cnt) {
                static struct charseq replace[2];
                replace[0].bytes[1] = '\0';
                ctype->mboutdigits[cnt] = &replace[0];
   }
}


% install/bin/gcc -O2 -c x.c
x.c: In function ‘ctype_finish’:
cc1: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
x.c:2:18: note: destination object declared here
    2 |    unsigned char bytes[0];
      |


It would be nice if the warning said the write was on line 12 as well as saying that the declaration is on line 2.  This test case is cutdown from code in glibc where the code doing the write was less easy to find.
Comment 1 Martin Sebor 2019-08-29 23:07:49 UTC
Confirmed.  gimple_location(stmt) returns zero for the statement but EXPR_LOCATION(lhs) has the right location so it can be used as a fallback.  Unfortunately, that alone isn't enough.  The %G directive in the warning_at(loc, "%G...", stmt) call seems to insist on using the stmt location in preference to loc even when it's invalid/unknown, and so the warning still doesn't point in the right place.  I could hack around it at the call site but a better fix is in the warning machinery.  (Ideally, of course, every statement would have location and this wouldn't be a problem at all. But what fun would that be?)
Comment 2 Martin Sebor 2019-08-30 02:01:24 UTC
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02025.html
Comment 3 Martin Sebor 2019-08-30 17:49:48 UTC
Author: msebor
Date: Fri Aug 30 17:49:17 2019
New Revision: 275211

URL: https://gcc.gnu.org/viewcvs?rev=275211&root=gcc&view=rev
Log:
PR middle-end/91599 - GCC does not say where warning is happening

gcc/ChangeLog:

	PR middle-end/91599
	* tree-ssa-strlen.c (handle_store): Use a fallback location if
	the statement doesn't have one.
	* gimple-pretty-print.c (percent_G_format): Same.

gcc/testsuite/ChangeLog:

	PR middle-end/91599
	* gcc.dg/Wstringop-overflow-16.c: New test.


Added:
    trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-16.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gimple-pretty-print.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-strlen.c
Comment 4 Martin Sebor 2019-08-30 17:50:04 UTC
Committed in r275211.