[Bug c++/55252] New: Caret diagnostic doesn't show useful location when macro clashes with name in system header

[Bug c++/55252] New: Caret diagnostic doesn't show useful location when macro clashes with name in system header

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

             Bug #: 55252
           Summary: Caret diagnostic doesn't show useful location when
                    macro clashes with name in system header
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: redi@gcc.gnu.org


(preprocessed source doesn't show the error due to the system_header pragma)


$ cat test.cc
#define bar 1
#include "header.h"
$ cat header.h
#pragma GCC system_header
int bar = 0;
$ g++ test.cc
test.cc:1:13: error: expected unqualified-id before numeric constant
 #define bar 1
             ^

This is no help because it doesn't point you to the line in header.h that
clashes with 'bar'

Without the system_header pragma you get

test.cc:1:13: error: expected unqualified-id before numeric constant
 #define bar 1
             ^
header.h:2:5: note: in expansion of macro 'bar'
 int bar = 0;
     ^

Which at least shows both locations, although the first diagnostic is still
confusing ... are the two locations backwards?  The "expected unqualified-id
before numeric constant" should point to "int bar = 0;"

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-11-09 18:08:40 UTC ---
clang++ gets this right, printing the same thing with or without the
system_header pragma, and swapping the locations of the error and the note:

In file included from test.cc:2:
./header.h:1:5: error: expected unqualified-id
int bar = 0;
    ^
test.cc:1:13: note: expanded from macro 'bar'
#define bar 1
            ^
1 error generated.


This makes much more sense.

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-11-09
                 CC|                            |dodji at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-11-09 21:02:20 UTC ---
I think this his how the macro expansion was designed to work: It shows the
location of the token that triggered the error. I also agree that the clang way
makes more sense in this case.

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-11-10 22:58:16 UTC ---
Hum, I am not sure why the macro unwinder avoids unwinding if the macro comes
from a system-header. If a warning message comes from a system-header, then it
should have been suppressed earlier and never reach the macro unwinder.
Otherwise, we already have emitted the diagnostic, so the macro unwinder just
provides more context.

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-11-10 23:10:32 UTC ---
On the other hand, let's consider:

pr55252.c:
#define bar 256
#include "pr55252.h"

pr55252.h:
#pragma GCC system_header
signed char foo = bar;

In this case, I would expect the warning to be suppressed (as it is with
-ftrack-macro-expansion=0). However, since the warning is actually given in the
C file, it is emitted. I am getting more and more convinced that expanding to
spelling point might not be the best (I think Paolo Bonzini raised this issue
at the time...). On the other hand, this is a very contrived testcase. I
wouldn't expect in normal code that the expansion point to be in a
system-header and the spelling point in a non-system-header.

Dodji, what do you think?

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-11-10 23:20:36 UTC ---
(In reply to comment #4)
> On the other hand, this is a very contrived testcase. I
> wouldn't expect in normal code that the expansion point to be in a
> system-header and the spelling point in a non-system-header.

It's not that contrived, here's a more realistic example:

  #define fixed 1
  #include <iostream>
  int main() { }

This gives a very unhelpful error:

t.cc:1:15: error: expected unqualified-id before numeric constant
 #define fixed 1
               ^
t.cc:1:15: error: expected unqualified-id before numeric constant
 #define fixed 1
               ^
t.cc:1:15: error: expected initializer before numeric constant

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[dodji at seketeli dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

--- Comment #6 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-11-19 16:17:20 UTC ---
> I think this his how the macro expansion was designed to work: It
> shows the location of the token that triggered the error.

Yes.  And there are cases where the GCC way seems to make more sense;
for instance:
$ cat -n test.c
     1    #define OPERATE(OPRD1, OPRT, OPRD2) \
     2      OPRD1 OPRT OPRD2;
     3    
     4    #define SHIFTL(A,B) \
     5      OPERATE (A,<<,B)
     6    
     7    #define MULT(A) \
     8      SHIFTL (A,1)
     9    
    10    void
    11    g ()
    12    {
    13      MULT (1.0);// 1.0 << 1; <-- so this is an error.
    14    }
$ 

With GCC:

./test.c: In function ‘g’:
./test.c:5:14: error: invalid operands to binary << (have ‘double’ and ‘int’)
   OPERATE (A,<<,B)
              ^
./test.c:2:9: note: in definition of macro ‘OPERATE’
   OPRD1 OPRT OPRD2;
         ^
./test.c:8:3: note: in expansion of macro ‘SHIFTL’
   SHIFTL (A,1)
   ^
./test.c:13:3: note: in expansion of macro ‘MULT’
   MULT (1.0);// 1.0 << 1; <-- so this is an error.
   ^
$

With Clang:

test.c:13:3: error: invalid operands to binary expression ('double' and 'int')
  MULT (1.0);// 1.0 << 1; <-- so this is an error.
  ^~~~~~~~~~
test.c:8:3: note: expanded from macro 'MULT'
  SHIFTL (A,1)
  ^
test.c:5:14: note: expanded from macro 'SHIFTL'
  OPERATE (A,<<,B)
             ^
test.c:2:9: note: expanded from macro 'OPERATE'
  OPRD1 OPRT OPRD2;
  ~~~~~ ^    ~~~~~
1 error generated.
$

So, at line 13.3, I think it doesn't make sense to talk about a binary
expression (which is related to the '<<' operator).

So yes, we chose to first point to the token on which the error
appeared, and then print the context of the macro expansion all the way
to the expansion point.

Now I am not sure what the best approach should be.

> I also agree that the clang way makes more sense in this case.

Indeed.

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[dodji at seketeli dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

--- Comment #7 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-11-19 16:34:11 UTC ---
"manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> a écrit:

> On the other hand, let's consider:
> pr55252.c:
>
> #define bar 256
> #include "pr55252.h"
>
> pr55252.h:
>
> #pragma GCC system_header
> signed char foo = bar;
>
>
>
> In this case, I would expect the warning to be suppressed (as it is with
>
> -ftrack-macro-expansion=0). However, since the warning is actually
> given in the C file, it is emitted. I am getting more and more
> convinced that expanding to spelling point might not be the best (I
> think Paolo Bonzini raised this issue at the time...).

I am thinking that a way to really handle this correctly is to have the
concept of the location of the "current expression", which the current
token belongs to.

In this case, we are emitting the warning on the token 'bar' (which is
spelled in the C file), while the relevant expression (the variable
declaration) is in a header file.

The diagnostics machinery should be able to say "is the current
expression in a header file?", and act appropriately.

Would that make sense in the grand scheme of things?

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-11-19 16:50:34 UTC ---
(In reply to comment #7)
> Would that make sense in the grand scheme of things?

The idea seems good. It would also handle comment #4 testcase. However, I am
not sure how you would implement this.

A different issue is why the macro unwinder cares about system-headers? See
comment #3.

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[dodji at seketeli dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

--- Comment #9 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-11-19 17:05:57 UTC ---
"manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> a écrit:

> Hum, I am not sure why the macro unwinder avoids unwinding if the
> macro comes from a system-header. If a warning message comes from a
> system-header, then it should have been suppressed earlier and never
> reach the macro unwinder.  Otherwise, we already have emitted the
> diagnostic, so the macro unwinder just provides more context.

Yeah. I agree this is weird.

There are cases where the spelling location is in normal main file, but
some locations in its macro expansion context are e.g, for built-in
tokens.  In that case we can get ugly diagnostic prefixes like:

  <built-in>:0:0: warning: conversion to 'float' alters 'int' constant value

This is what the commit r186970 tries to fix.  Please read the commit
log (that contains useful information about the context of the bug,
besides the ChangeLog that we like to put in there) of that revision to
understand why we are skipping each locus that comes from a system
header too.

I guess a way to handle this is to 

    1/ make the macro unwinder call
    linemap_unwind_to_first_non_reserved_loc at the beginning of the
    unwind process and start unwinding from there

    2/  during the rest of the unwind process, dismiss reserved
    locations only.  Not those coming from system headers.

Would this make sense?

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[dodji at seketeli dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

--- Comment #10 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-11-19 17:18:00 UTC ---
"manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> a écrit:

> The idea seems good. It would also handle comment #4 testcase.

Yeah, and I think it would be a step in the direction of printing ranges
for expressions.  I know you and I share a (not so) secret dream of
seeing taht in GCC one day.  :-)

> However, I am not sure how you would implement this.

That is the real issue, I guess.

I suspect this could be like opening a can of worms.  In G++, I guess
I'd start with updating the hypothetical 'current expression' variable
in cp_parser_expression.  But then we need to handle tentative parsing.
That is, if we are in a tentative parse, save the new 'current
expression' on the side, and really save it when the parse is
committed.

And pray for the fall-outs to not be in the order of dozens.  :-)

> different issue is why the macro unwinder cares about system-headers? See
> comment #3.

Right, I have replied to that in an earlier comment.

Thanks.

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michael at talamasca dot ocis.net

--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
*** Bug 58953 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-433268-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 01 15:30:54 2013
Return-Path: <gcc-bugs-return-433268-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15552 invoked by alias); 1 Nov 2013 15:30:53 -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 15447 invoked by uid 48); 1 Nov 2013 15:30:50 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/58953] Unhelpful error message in conflict between enum and #define
Date: Fri, 01 Nov 2013 15:30: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.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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_status cc resolution
Message-ID: <bug-58953-4-yHC0kETesn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58953-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58953-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: 2013-11/txt/msg00045.txt.bz2
Content-length: 624

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58953

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |manu at gcc dot gnu.org
         Resolution|---                         |DUPLICATE

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Macro unwinder known issue.

*** This bug has been marked as a duplicate of bug 55252 ***
>From gcc-bugs-return-433270-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 01 15:34:48 2013
Return-Path: <gcc-bugs-return-433270-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18386 invoked by alias); 1 Nov 2013 15:34:48 -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 18355 invoked by uid 48); 1 Nov 2013 15:34:45 -0000
From: "sshannin at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/58948] c++0x support for enums in namespaces
Date: Fri, 01 Nov 2013 15:34: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.6.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: sshannin at gmail dot com
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-58948-4-oYBVXVq4WT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58948-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58948-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: 2013-11/txt/msg00047.txt.bz2
Content-length: 309

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX948

--- Comment #2 from sshannin at gmail dot com ---
Ahh, good call. I forgot that it would parse like that.

I wonder if there's any way to declare it such that the namespaces/types are
unambiguous that will parse correctly in both the c++11 and c++03 modes.

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252

--- Comment #12 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
PR52962 is another case where it would make more sense to give the error on the
macro expansion location rather than on the macro definition.
>From gcc-bugs-return-433292-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 01 21:40:28 2013
Return-Path: <gcc-bugs-return-433292-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28138 invoked by alias); 1 Nov 2013 21:40:28 -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 27951 invoked by uid 48); 1 Nov 2013 21:40:24 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/43736] Invalid uninitialized variable warning at -O3 -Wall
Date: Fri, 01 Nov 2013 21:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.4.3
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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_status cc resolution
Message-ID: <bug-43736-4-vY0mu12YcZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-43736-4@http.gcc.gnu.org/bugzilla/>
References: <bug-43736-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: 2013-11/txt/msg00069.txt.bz2
Content-length: 561

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43736

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |manu at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
This seems to be fixed on 4.9.
>From gcc-bugs-return-433293-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 01 21:45:19 2013
Return-Path: <gcc-bugs-return-433293-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1193 invoked by alias); 1 Nov 2013 21:45:18 -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 1167 invoked by uid 48); 1 Nov 2013 21:45:15 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/44781] unjustified warning about uninitialized variable
Date: Fri, 01 Nov 2013 21:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.6.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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_status cc resolution
Message-ID: <bug-44781-4-7IdHPod1jt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-44781-4@http.gcc.gnu.org/bugzilla/>
References: <bug-44781-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: 2013-11/txt/msg00070.txt.bz2
Content-length: 617

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44781

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |manu at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
It seems fixed since 4.6 and the testcase is too large to be useful for the
testsuite.
>From gcc-bugs-return-433294-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 01 21:46:59 2013
Return-Path: <gcc-bugs-return-433294-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2661 invoked by alias); 1 Nov 2013 21:46:59 -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 2594 invoked by uid 55); 1 Nov 2013 21:46:56 -0000
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/48326] Target attribute leaks from function pointers
Date: Fri, 01 Nov 2013 21:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.6.0
X-Bugzilla-Keywords: wrong-code
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-48326-4-soMXv1uvZZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-48326-4@http.gcc.gnu.org/bugzilla/>
References: <bug-48326-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: 2013-11/txt/msg00071.txt.bz2
Content-length: 800

http://gcc.gnu.org/bugzilla/show_bug.cgi?idH326

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 1 Nov 2013, michael at talamasca dot ocis.net wrote:

> Do I have to file a separate bug report in order to fix the problem that
> current GCC releases can't be expected to bootstrap up if the starting compiler
> is GCC 4.7.0 (among several other problem releases) and the host hardware is
> ix86 with no cmov?

Please do.  Such a bug report would be a request for libcpp to work around
known buggy bootstrap compilers, which is completely separate from the
present report about the actual bug in those compilers.  (Or test and send
to gcc-patches a patch with the change you suggest; a one-line fix like
that doesn't need a copyright assignment.)

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[tromey at gcc dot gnu.org]

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

Tom Tromey <tromey at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu.org

--- Comment #14 from Tom Tromey <tromey at gcc dot gnu.org> ---
*** Bug 61165 has been marked as a duplicate of this bug. ***

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[tromey at gcc dot gnu.org]

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

--- Comment #15 from Tom Tromey <tromey at gcc dot gnu.org> ---
*** Bug 61803 has been marked as a duplicate of this bug. ***

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[tromey at gcc dot gnu.org]

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

--- Comment #16 from Tom Tromey <tromey at gcc dot gnu.org> ---
I've tripped across this enough that I've actually filed dups twice now.

I think it would be best to change the ordering here.
That is, the initial error ought to generally be the
location of the outermost expansion.  Then, the remaining
notes ought to delineate the macro expansions.

While it is true that this will yield a sub-optimal result in some
cases, I think that it will have better results in the preponderance
of cases.  That is, there's no way to be perfect here but gcc could be more
useful.

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[manu at gcc dot gnu.org]

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

--- Comment #18 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #17)
> It would be less of a pain if -Wsystem-headers caused both locations to be
> printed, but it doesn't, so sometimes the only option is to dump the
> preprocessed source without line markers and then compile that to get two
> locations, then map the location in the preprocessed source back to a line
> in the original source.

You could try with this:

Index: tree-diagnostic.c
===================================================================
--- tree-diagnostic.c   (revision 220306)
+++ tree-diagnostic.c   (working copy)
@@ -197,12 +197,14 @@ maybe_unwind_expanded_macro_loc (diagnos
           within a system header.  */
         const struct line_map *m = NULL;
         source_location l =
           linemap_resolve_location (line_table, resolved_def_loc,
                                     LRK_SPELLING_LOCATION,  &m);
-        if (l < RESERVED_LOCATION_COUNT || LINEMAP_SYSP (m))
-          continue;
+        if (l < RESERVED_LOCATION_COUNT)
+         continue;
+       if (LINEMAP_SYSP (m) && !context->dc_warn_system_headers)
+         continue;

        /* We need to print the context of the macro definition only
           when the locus of the first displayed diagnostic (displayed
           before this trace) was inside the definition of the
           macro.  */

.. but I still not see why we need to skip system-headers at all. The comment
in the original patch (r186970)

I am then using that facility in the diagnostics printing module and
in the macro unwinder to avoid printing diagnostics lines that refer
to the locations for built-ins or more generally for reserved
locations.  Note that when I start the dance of skipping a built-in
location I also skip locations that are in system headers, because it
turned out that a lot of those built-ins are actually used in system
headers (e.g, "#define INT_MAX __INT_MAX__" where __INT_MAX__ is a
built-in).

suggests that we do not want to give a note for the #define, but it seems a
small price to pay for getting the other cases right.
>From gcc-bugs-return-475725-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Feb 01 20:35:46 2015
Return-Path: <gcc-bugs-return-475725-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15539 invoked by alias); 1 Feb 2015 20:35:46 -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 15493 invoked by uid 48); 1 Feb 2015 20:35:43 -0000
From: "max at cert dot cx" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/61601] C++11 regex resource exhaustion
Date: Sun, 01 Feb 2015 20:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: max at cert dot cx
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-61601-4-8zpdB2tW4Z@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61601-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61601-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-02/txt/msg00058.txt.bz2
Content-length: 206

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

--- Comment #6 from Maksymilian Arciemowicz <max at cert dot cx> ---

> Do you have any other testcases?

for trunk? maybe you have to use ::regex_match

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[dodji at gcc dot gnu.org]

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

--- Comment #19 from Dodji Seketeli <dodji at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #16)
> I've tripped across this enough that I've actually filed dups twice now.
> 
> I think it would be best to change the ordering here.
> That is, the initial error ought to generally be the
> location of the outermost expansion.  Then, the remaining
> notes ought to delineate the macro expansions.
> 
> While it is true that this will yield a sub-optimal result in some
> cases, I think that it will have better results in the preponderance
> of cases.  That is, there's no way to be perfect here but gcc could be more
> useful.


I am starting to think the same here.  In the unwinding, it seems less
surprising to start from the code the user has the most chance to have written
herself, that is, the code at the point of expansion of the outermost macro,
rather than the point where the offending token was spelled -- which can be
hidden anywhere.

If everyone agrees, then I am okay to change the unwinding direction for the
next stage 1.

Manuel, Jonathan, what do you think?