[Bug c/65466] New: Unnecessary source line output for "note: each undeclared identifier is reported only once"

[Bug c/65466] New: Unnecessary source line output for "note: each undeclared identifier is reported only once"

[achurch+gcc at achurch dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466

            Bug ID: 65466
           Summary: Unnecessary source line output for "note: each
                    undeclared identifier is reported only once"
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: achurch+gcc at achurch dot org

For the first undeclared identifier found in a source file, GCC outputs an
additional diagnostic, "note: each undeclared identifier is reported only once
for each function it appears in", and then (assuming no
-fno-diagnostics-show-caret) displays the source line and location of the
undeclared identifier.  The note itself is fine, but the source location only
clutters up the output since it was already displayed for the actual warning. 
This is exacerbated if the undeclared identifier was used in a macro, since the
macro expansion is also printed twice (as in the example below).

It seems to me it would make more sense to either suppress the source line
display and macro expansion for the "note: each undeclared..." diagnostic, or
merge that text into the warning text for the first instance of the warning,
perhaps: "'bar' undeclared (first use in this function; each undeclared
identifier is reported only once for each function it appears in)".

$ cat foo.c
#define FOO(x) x
int foo(void) {return FOO(bar);}
$ gcc-4.9.2 -c foo.c
foo.c: In function 'foo':
foo.c:2:27: error: 'bar' undeclared (first use in this function)
 int foo(void) {return FOO(bar);}
                           ^
foo.c:1:16: note: in definition of macro 'FOO'
 #define FOO(x) x
                ^
foo.c:2:27: note: each undeclared identifier is reported only once for each
function it appears in
 int foo(void) {return FOO(bar);}
                           ^
foo.c:1:16: note: in definition of macro 'FOO'
 #define FOO(x) x
                ^

[Bug c/65466] Unnecessary source line output for "note: each undeclared identifier is reported only once"

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote:

> (If I was re-doing that patch again, I will try to overload inform(), because
> inform_with_flags is just too much typing).

Note that diagnostic functions cannot be overloaded in a way that means 
different functions with the same name have the msgid argument in 
different positions, as that breaks exgettext.

[Bug c/65466] Unnecessary source line output for "note: each undeclared identifier is reported only once"

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #2)
> On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote:
> 
> > (If I was re-doing that patch again, I will try to overload inform(), because
> > inform_with_flags is just too much typing).
> 
> Note that diagnostic functions cannot be overloaded in a way that means 
> different functions with the same name have the msgid argument in 
> different positions, as that breaks exgettext.

Ah, yes, I forgot about this. We had this problem already in the Fortran FE.
Can exgettext be fixed to handle overloads eventually? Perhaps someone could
reimplement it as a GCC plugin. That would be a nice GSoC!
>From gcc-bugs-return-480895-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 20 00:00:22 2015
Return-Path: <gcc-bugs-return-480895-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14004 invoked by alias); 20 Mar 2015 00:00:22 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13951 invoked by uid 48); 20 Mar 2015 00:00:19 -0000
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/65481] New: _Pragma GCC dependency broken on powerpc64
Date: Fri, 20 Mar 2015 03:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: msebor at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-65481-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02039.txt.bz2
Content-length: 1802

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65481

            Bug ID: 65481
           Summary: _Pragma GCC dependency broken on powerpc64
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gcc dot gnu.org

The gcc.dg/cpp/_Pragma3.c test is failing on powerpc64 but passes on
powerpc64le.  The following test case demonstrates the same problem that causes
the test failure.  It looks like the timestamp computation is broken on this
target.  GCC 4.8.3 has the same problem.

$ cat t.c && touch t.h && stat t.c t.h && /build/gcc-5.0/gcc/xgcc
-B/build/gcc-5.0/gcc -ansi -pedantic-errors -E -o/dev/null t.c
#define GCC_PRAGMA(x) _Pragma (#x)
GCC_PRAGMA(GCC dependency "t.h")
  File: ‘t.c’
  Size: 68            Blocks: 8          IO Block: 65536  regular file
Device: fd00h/64768d    Inode: 69928678    Links: 1
Access: (0664/-rw-rw-r--)  Uid: (25066/  msebor)   Gid: (25066/  msebor)
Context: unconfined_u:object_r:default_t:s0
Access: 2015-03-19 19:55:32.668667450 -0400
Modify: 2015-03-19 19:54:40.448639710 -0400
Change: 2015-03-19 19:54:40.468639721 -0400
 Birth: -
  File: ‘t.h’
  Size: 0             Blocks: 0          IO Block: 65536  regular empty file
Device: fd00h/64768d    Inode: 69928674    Links: 1
Access: (0664/-rw-rw-r--)  Uid: (25066/  msebor)   Gid: (25066/  msebor)
Context: unconfined_u:object_r:default_t:s0
Access: 2015-03-19 19:56:02.508682213 -0400
Modify: 2015-03-19 19:56:02.508682213 -0400
Change: 2015-03-19 19:56:02.508682213 -0400
 Birth: -
t.c:2:16: warning: current file is older than t.h
 GCC_PRAGMA(GCC dependency "t.h")
                ^
>From gcc-bugs-return-480896-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 20 00:00:37 2015
Return-Path: <gcc-bugs-return-480896-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14810 invoked by alias); 20 Mar 2015 00:00:31 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 14422 invoked by uid 55); 20 Mar 2015 00:00:26 -0000
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/65466] Unnecessary source line output for "note: each undeclared identifier is reported only once"
Date: Fri, 20 Mar 2015 03:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joseph at codesourcery dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65466-4-H7n9lD9LcK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65466-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65466-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02040.txt.bz2
Content-length: 1423

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
> 
> --- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
> (In reply to joseph@codesourcery.com from comment #2)
> > On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote:
> > 
> > > (If I was re-doing that patch again, I will try to overload inform(), because
> > > inform_with_flags is just too much typing).
> > 
> > Note that diagnostic functions cannot be overloaded in a way that means 
> > different functions with the same name have the msgid argument in 
> > different positions, as that breaks exgettext.
> 
> Ah, yes, I forgot about this. We had this problem already in the Fortran FE.
> Can exgettext be fixed to handle overloads eventually? Perhaps someone could
> reimplement it as a GCC plugin. That would be a nice GSoC!

exgettext (which essentially just computes arguments to pass to xgettext 
from GNU gettext) needs to handle sources that are not part of the current 
configuration, including inside disabled #if conditionals.  That is, the 
sources parsed by the compiler compiling any particular build of GCC are 
not the full set of sources that need to be handled to generate gcc.pot.
>From gcc-bugs-return-480897-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 20 00:02:25 2015
Return-Path: <gcc-bugs-return-480897-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17024 invoked by alias); 20 Mar 2015 00:02:25 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16918 invoked by uid 48); 20 Mar 2015 00:02:22 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/65481] _Pragma GCC dependency broken on powerpc64
Date: Fri, 20 Mar 2015 03:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65481-4-BodiDPoTyT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65481-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65481-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02041.txt.bz2
Content-length: 184

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide481

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
contrib/gcc_update --touch is usually used to fix this problem.