[Bug c/61861] New: Incorrect column number for -Wdiscarded-qualifiers

[Bug c/61861] New: Incorrect column number for -Wdiscarded-qualifiers

[chengniansun at gmail dot com]

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

            Bug ID: 61861
           Summary: Incorrect column number for -Wdiscarded-qualifiers
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chengniansun at gmail dot com

It seems that GCC outputs incorrect column number for "__FILE__", but not user
defined macro "T".



$: cat t.c
extern int * f (int*a, char * loc); 

#define T "t.c" 

void g(int *a) {
  f(a, T);        /*column number here is correct*/
  f(a, __FILE__); /*column number here is INCORRECT*/
}
$: 
$: gcc-trunk -Wwrite-strings -c t.c
t.c: In function ‘g’:
t.c:3:11: warning: passing argument 2 of ‘f’ discards ‘const’ qualifier from
pointer target type [-Wdiscarded-qualifiers]
 #define T "t.c" 
           ^
t.c:6:8: note: in expansion of macro ‘T’
   f(a, T);
        ^
t.c:1:14: note: expected ‘char *’ but argument is of type ‘const char *’
 extern int * f (int*a, char * loc); 
              ^
t.c:7:1: warning: passing argument 2 of ‘f’ discards ‘const’ qualifier from
pointer target type [-Wdiscarded-qualifiers]
   f(a, __FILE__);
 ^
t.c:1:14: note: expected ‘char *’ but argument is of type ‘const char *’
 extern int * f (int*a, char * loc); 
              ^
$: 
$: clang-trunk -Wwrite-strings -c t.c
t.c:6:8: warning: passing 'const char [4]' to parameter of type 'char *'
discards qualifiers
      [-Wincompatible-pointer-types-discards-qualifiers]
  f(a, T);
       ^
t.c:3:11: note: expanded from macro 'T'
#define T "t.c" 
          ^~~~~
t.c:1:31: note: passing argument to parameter 'loc' here
extern int * f (int*a, char * loc); 
                              ^
t.c:7:8: warning: passing 'const char [4]' to parameter of type 'char *'
discards qualifiers
      [-Wincompatible-pointer-types-discards-qualifiers]
  f(a, __FILE__);
       ^~~~~~~~
<scratch space>:2:1: note: expanded from here
"t.c"
^~~~~
t.c:1:31: note: passing argument to parameter 'loc' here
extern int * f (int*a, char * loc); 
                              ^
2 warnings generated.
$:
>From gcc-bugs-return-456834-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 21 00:29:41 2014
Return-Path: <gcc-bugs-return-456834-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31202 invoked by alias); 21 Jul 2014 00:29:39 -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 31068 invoked by uid 48); 21 Jul 2014 00:29:35 -0000
From: "chengniansun at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61862] New: No -Wcast-align warning
Date: Mon, 21 Jul 2014 00:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: chengniansun 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-61862-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: 2014-07/txt/msg01425.txt.bz2
Content-length: 773

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

            Bug ID: 61862
           Summary: No -Wcast-align warning
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chengniansun at gmail dot com

GCC does not emit cast-align warning on the following code. Is this expected?


$: cat t.c
int *f(char * c, int n) {
  return (int *)(c + 2);
}



$: clang-trunk -Wcast-align -c t.c
t.c:2:10: warning: cast from 'char *' to 'int *' increases required alignment
from 1 to 4 [-Wcast-align]
  return (int *)(c + 2);
         ^~~~~~~~~~~~~~
1 warning generated.
$: gcc-trunk -Wcast-align -c t.c
$:

[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-07-22
                 CC|                            |mpolacek at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |4.10.0
     Ever confirmed|0                           |1

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Mine.

[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Seems that the location of __FILE__ is generally broken, e.g. on
extern void foo (int i);
void
f (void)
{
  foo (__FILE__);
}
the column info is wrong as well.

[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers

[manu at gcc dot gnu.org]

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

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

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

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Is this something new? Dodji made some changes recently to the location of
built-in tokens.
>From gcc-bugs-return-456954-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 23 10:40:09 2014
Return-Path: <gcc-bugs-return-456954-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2820 invoked by alias); 23 Jul 2014 10:40:09 -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 2786 invoked by uid 48); 23 Jul 2014 10:40:05 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/61886] New: [4.8/4.9/4.10 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
Date: Wed, 23 Jul 2014 10:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: diagnostic, lto, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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 keywords bug_severity priority component assigned_to reporter cc attachments.created
Message-ID: <bug-61886-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: 2014-07/txt/msg01545.txt.bz2
Content-length: 5209

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

            Bug ID: 61886
           Summary: [4.8/4.9/4.10 Regression] LTO breaks fread with
                    _FORTIFY_SOURCE=2
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Keywords: diagnostic, lto, wrong-code
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
                CC: hubicka at gcc dot gnu.org

Created attachment 33176
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33176&action=edit
testcase extracted from cairo test suite

With the attached testcase extracted from the Cairo testsuite (which they build
with -flto ...) you get

> gcc-4.9 create-for-stream.i -O2 -flto -r -nostdlib
In function ‘__fread_alias’,
    inlined from ‘test_surface’ at create-for-stream.c:218:9:
/usr/include/bits/stdio2.h:290:2: warning: call to ‘__fread_chk_warn’ declared
with attribute warning: fread called with bigger size * nmemb than length of
destination buffer
  return __fread_chk (__ptr, __bos0 (__ptr), __size, __n, __stream);
  ^

where we mangle compile-time

  <bb 13>:
  _55 = wc.index;
  _77 = __builtin_constant_p (_55);
  if (_77 == 0)
    goto <bb 15>;
  else
    goto <bb 14>;

  <bb 14>:
  _78 = _55 | 1;
  if (_78 > 4294967295)
    goto <bb 15>;
  else
    goto <bb 16>;

  <bb 15>:
  _79 = __fread_chk (&file_contents, 4096, 1, _55, fp_48);
  goto <bb 19>;

  <bb 16>:
  if (_55 > 4096)
    goto <bb 17>;
  else
    goto <bb 18>;

  <bb 17>:
  _81 = *__fread_chk (&file_contents, 4096, 1, _55, fp_48);
  goto <bb 19>;

  <bb 18>:
  _82 = *fread (&file_contents, 1, _55, fp_48);

  <bb 19>:
  # _83 = PHI <_79(15), _81(17), _82(18)>

into the bogus

  <bb 13>:
  _49 = wc.index;
  _64 = __builtin_constant_p (_49);
  if (_64 == 0)
    goto <bb 15>;
  else
    goto <bb 14>;

  <bb 14>:
  _65 = _49 | 1;
  if (_65 > 4294967295)
    goto <bb 15>;
  else
    goto <bb 16>;

  <bb 15>:
  _66 = __fread_chk_warn (&file_contents, 4096, 1, _49, fp_43);
  goto <bb 19>;

  <bb 16>:
  if (_49 > 4096)
    goto <bb 17>;
  else
    goto <bb 18>;

  <bb 17>:
  _67 = __fread_chk_warn (&file_contents, 4096, 1, _49, fp_43);
  goto <bb 19>;

  <bb 18>:
  _68 = __fread_alias (&file_contents, 1, _49, fp_43);

  <bb 19>:
  # _69 = PHI <_66(15), _67(17), _68(18)>

somehow messing up the aliases game glibc plays:

extern size_t __fread_chk (void *__restrict __ptr, size_t __ptrlen,
                           size_t __size, size_t __n,
                           FILE *__restrict __stream) __wur;
extern size_t __REDIRECT (__fread_alias,
                          (void *__restrict __ptr, size_t __size,
                           size_t __n, FILE *__restrict __stream),
                          fread) __wur;
extern size_t __REDIRECT (__fread_chk_warn,
                          (void *__restrict __ptr, size_t __ptrlen,
                           size_t __size, size_t __n,
                           FILE *__restrict __stream),
                          __fread_chk)
     __wur __warnattr ("fread called with bigger size * nmemb than length "
                       "of destination buffer");

__fortify_function __wur size_t
fread (void *__restrict __ptr, size_t __size, size_t __n,
       FILE *__restrict __stream)
{
  if (__bos0 (__ptr) != (size_t) -1)
    {
      if (!__builtin_constant_p (__size)
          || !__builtin_constant_p (__n)
          || (__size | __n) >= (((size_t) 1) << (8 * sizeof (size_t) / 2)))
        return __fread_chk (__ptr, __bos0 (__ptr), __size, __n, __stream);

      if (__size * __n > __bos0 (__ptr))
        return __fread_chk_warn (__ptr, __bos0 (__ptr), __size, __n, __stream);
    }
  return __fread_alias (__ptr, __size, __n, __stream);
}

Merging nodes for *__fread_chk. Candidates:
*__fread_chk/98 (__fread_chk_warn) @0x7ffff6dc2b80
  Type: function
  Visibility: undef external public
  next sharing asm name: 97
  References:
  Referring:
  Read from file: /tmp/ccu88pge.o
  First run: 0
  Function flags:
  Called by: test_surface/78
  Calls:
__fread_chk/97 (__fread_chk) @0x7ffff6dc2cf0
  Type: function
  Visibility: external public
  previous sharing asm name: 98
  References:
  Referring:
  Read from file: /tmp/ccu88pge.o
  First run: 0
  Function flags:
  Called by: test_surface/78 (0.00 per call)
After resolution:
*__fread_chk/98 (__fread_chk_warn) @0x7ffff6dc2b80
  Type: function
  Visibility: undef external public
  next sharing asm name: 97
  References:
  Referring:
  Read from file: /tmp/ccu88pge.o
  First run: 0
  Function flags:
  Called by: test_surface/78
  Calls:
__fread_chk/97 (__fread_chk) @0x7ffff6dc2cf0
  Type: function
  Visibility: external public
  previous sharing asm name: 98
  References:
  Referring:
  Read from file: /tmp/ccu88pge.o
  First run: 0
  Function flags:
  Called by: test_surface/78 (0.00 per call)
  Calls:

but we obviously shouldn't merge these ...

(I believe we shouldn't drop any aliases at LTO symbol merging time, which
means _not_ merging based on asm-name?)
>From gcc-bugs-return-456955-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 23 10:40:18 2014
Return-Path: <gcc-bugs-return-456955-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3465 invoked by alias); 23 Jul 2014 10:40:17 -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 3337 invoked by uid 48); 23 Jul 2014 10:40:13 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/61886] [4.8/4.9/4.10 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
Date: Wed, 23 Jul 2014 10:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: diagnostic, lto, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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: 4.8.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: target_milestone
Message-ID: <bug-61886-4-AKZCYfnR8D@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61886-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61886-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: 2014-07/txt/msg01546.txt.bz2
Content-length: 294

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.4

[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
It looks like a pretty old issue.  E.g. on
void
foo (void)
{
  __FILE__;
  "foo";
}

4.8 says:
r.c: In function ‘foo’:
r.c:4:1: warning: statement with no effect [-Wunused-value]
   __FILE__;
 ^
r.c:5:3: warning: statement with no effect [-Wunused-value]
   "foo";
   ^

See how that first caret is off.  I have an untested patch that should fix
this.
>From gcc-bugs-return-456962-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 23 11:58:04 2014
Return-Path: <gcc-bugs-return-456962-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17929 invoked by alias); 23 Jul 2014 11:58:03 -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 17323 invoked by uid 48); 23 Jul 2014 11:57:59 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/61886] [4.8/4.9/4.10 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
Date: Wed, 23 Jul 2014 11:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: diagnostic, lto, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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: 4.8.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61886-4-88sByYGCl3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61886-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61886-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: 2014-07/txt/msg01553.txt.bz2
Content-length: 2167

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fails LTO bootstrap with

/abuild/rguenther/obj/./prev-gcc/xg++ -B/abuild/rguenther/obj/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/abuild/rguenther/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/abuild/rguenther/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/abuild/rguenther/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
 -I/abuild/rguenther/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/space/rguenther/src/svn/trunk/libstdc++-v3/libsupc++
-L/abuild/rguenther/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/abuild/rguenther/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc
-o build/genhooks \
            build/genhooks.o build/errors.o .././libiberty/libiberty.a
lto1: internal compiler error: in maybe_add_reference, at symtab.c:613
0x68a129 symtab_node::maybe_add_reference(tree_node*, ipa_ref_use,
gimple_statement_base*)
        /space/rguenther/src/svn/trunk/gcc/symtab.c:613
0x6a16de cgraph_create_virtual_clone(cgraph_node*, vec<cgraph_edge*, va_heap,
vl_ptr>, vec<ipa_replace_map*, va_gc, vl_embed>*, bitmap_head*, char const*)
        /space/rguenther/src/svn/trunk/gcc/cgraphclones.c:582
0x12ca0e5 create_specialized_node
        /space/rguenther/src/svn/trunk/gcc/ipa-cp.c:2802
0x12ce757 decide_whether_version_node
        /space/rguenther/src/svn/trunk/gcc/ipa-cp.c:3556
0x12ce8d3 ipcp_decision_stage
        /space/rguenther/src/svn/trunk/gcc/ipa-cp.c:3668
0x12cef4d ipcp_driver
        /space/rguenther/src/svn/trunk/gcc/ipa-cp.c:3714
0x12cefba execute
        /space/rguenther/src/svn/trunk/gcc/ipa-cp.c:3805

[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Sun Jul 27 17:09:38 2014
New Revision: 213102

URL: https://gcc.gnu.org/viewcvs?rev=213102&root=gcc&view=rev
Log:
    PR c/61861
    * macro.c (builtin_macro): Add location parameter.  Set
    location of builtin macro to the expansion point.
    (enter_macro_context): Pass location to builtin_macro.

    * gcc.dg/pr61861.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr61861.c
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/libcpp/ChangeLog
    trunk/libcpp/macro.c

[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Should be better now.

[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers

[dodji at gcc dot gnu.org]

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

Dodji Seketeli <dodji at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dodji at gcc dot gnu.org
         Resolution|FIXED                       |DUPLICATE

--- Comment #8 from Dodji Seketeli <dodji at gcc dot gnu.org> ---
Hello,

I was on the road when this patch was submitted so I missed it.  Sorry.

It looks too like this issue is related to PR61817.  I even sent a patch for
this at http://comments.gmane.org/gmane.comp.gcc.patches/316794 but then later
you sent your patch and it went in :-)

I think the initial patch I sent solves this issue as well.  Both of our
patches have a something common:  they make builtin_macro() take an additional
parameter that is the location of the expansion point of the built-in macro we
are looking at.

One the differences in handling is that you set the token->src_loc to the
location of the expansion point of the built-in macro; but then normally, the
convention is that that token->src_loc must always be spelling location.  It
must never be a virtual location.  And the issue is that the location of the
expansion point can be a virtual location.  So we should not set token->src_loc
like that, I think.

But do not worry; I'll update the patch, test it, submit it and keep you guys
posted.

Cheers.

*** This bug has been marked as a duplicate of bug 61817 ***