[Bug c/52952] New: Wformat location info is bad (wrong column number)

[Bug c/52952] New: Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

             Bug #: 52952
           Summary: Wformat location info is bad (wrong column number)
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: manu@gcc.gnu.org


#include <stdio.h>
void f() {
   printf("%.*d");
}

$ gcc-4.8 -fsyntax-only  -Wformat format-strings.c
format-strings.c: In function 'f':
format-strings.c:3:4: warning: field precision specifier '.*' expects a
matching 'int' argument [-Wformat]
    printf("%.*d");
    ^
format-strings.c:3:4: warning: format '%d' expects a matching 'int' argument
[-Wformat]
    printf("%.*d");
    ^

$ clang-3.1 -fsyntax-only format-strings.c
format-strings.c:3:14: warning: '.*' specified field precision is missing a
matching 'int' argument
   printf("%.*d");
           ~~^~

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-04-12
     Ever Confirmed|0                           |1

[Bug c/52952] Wformat location info is bad (wrong column number)

[steven at gcc dot gnu.org]

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

--- Comment #2 from Steven Bosscher <steven at gcc dot gnu.org> 2012-05-17 21:19:28 UTC ---
To fix this properly, the input location should be tracked for the format
string. The location of the format string as argument to printf is available in 
c-family/c-format.c:check_format_info() but there is no location information
for the characters within the string. The location for every character in the
format string should be recorded to pin-point the right line/column (think e.g.
for a broken long line).

[Bug c/52952] Wformat location info is bad (wrong column number)

[steven at gcc dot gnu.org]

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

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

--- Comment #1 from Steven Bosscher <steven at gcc dot gnu.org> 2012-05-17 21:04:56 UTC ---
extern int printf (__const char *__restrict __format, ...);
void f(void) {
    printf("%.*d");
}

[Bug c/52952] Wformat location info is bad (wrong column number)

[steven at gcc dot gnu.org]

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

--- Comment #3 from Steven Bosscher <steven at gcc dot gnu.org> 2012-05-21 23:15:31 UTC ---
What does clang report for this:

#include <stdio.h>
void f() {
   printf(
"%."
"*d");
}

?

[Bug c/52952] Wformat location info is bad (wrong column number)

[steven at gcc dot gnu.org]

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

--- Comment #4 from Steven Bosscher <steven at gcc dot gnu.org> 2012-05-21 23:21:04 UTC ---
Created attachment 27466
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27466
Pass around the location of the format string

First, admittedly rather lame, attempt at some improvement. With this patch,
the warning now points to the format string, at least:

$ cat pr525952.c 
extern int printf (__const char *__restrict __format, ...);
void f(void) {
    printf(
   "%."
"*d");
}
$ ./cc1 -quiet -Wformat pr525952.c 
pr525952.c: In function ‘f’:
pr525952.c:4:4: warning: field precision specifier ‘.*’ expects a matching
‘int’ argument [-Wformat]
    "%."
    ^
pr525952.c:4:4: warning: format ‘%d’ expects a matching ‘int’ argument
[-Wformat]

Handling broken-up format lines is rather more difficult.  Not sure how to
tackle that.

[Bug c/52952] Wformat location info is bad (wrong column number)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-05-22 08:29:08 UTC ---
The format string could be even something like
   void f() {
         __builtin_printf(
            u8R"abcd(%.)abcd"
               "*d");
                  }
So, the question is, if we have a way to find from the source_location on the
ADDR_EXPR around STRING_CST the original non-concatenated tokens, and given
index into the (possibly) translated STRING_CST redo the lexing of those
tokens, looking at which byte in the source tokens maps to that offset in the
STRING_CST.

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-05-22 09:54:29 UTC ---
(In reply to comment #3)
> What does clang report for this:
> 
> #include <stdio.h>
> void f() {
>    printf(
> "%."
> "*d");
> }
> 
> ?

/tmp/webcompile/_2090_0.c:5:2: warning: '.*' specified field precision is
missing a matching 'int' argument
"*d");
~^~
1 warning generated.

They have an awesome online demo: http://llvm.org/demo/

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-05-22 10:55:49 UTC ---
(In reply to comment #5)
> The format string could be even something like
>    void f() {
>          __builtin_printf(
>             u8R"abcd(%.)abcd"
>                "*d");
>                   }
> So, the question is, if we have a way to find from the source_location on the
> ADDR_EXPR around STRING_CST the original non-concatenated tokens, and given
> index into the (possibly) translated STRING_CST redo the lexing of those
> tokens, looking at which byte in the source tokens maps to that offset in the
> STRING_CST.

Is it possible to re-preprocess some tokens only? Do the line-maps keep track
of the locations of the tokens which make up a single string? If not, we would
need to create new source locations on-the-fly. Is this possible at all?

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-05-22 11:04:41 UTC ---
(In reply to comment #3)
> What does clang report for this:
> 
> #include <stdio.h>
> void f() {
>    printf(
> "%."
> "*d");
> }
> 
> ?

An even more interesting example is this:

#define FORMAT ".*d"
#include <stdio.h>
void f() {
   printf(
"%"
FORMAT);
}

for which Clang prints:

/tmp/webcompile/_17428_0.c:6:1: warning: '.*' specified field precision is
missing a matching 'int' argument
FORMAT);
^
/tmp/webcompile/_17428_0.c:1:18: note: expanded from:
#define FORMAT ".*d"
                 ^
1 warning generated.

So either one keeps track of all source locations of all "interesting"
characters within strings, which sounds infeasible. Or one needs to
re-preprocess the format string, creating new locations on-the-fly. Dodji, is
this possible?

[Bug c/52952] Wformat location info is bad (wrong column number)

[dodji at seketeli dot org]

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

--- Comment #9 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-05-24 18:38:40 UTC ---
"manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> a écrit:

> So either one keeps track of all source locations of all "interesting"
> characters within strings, which sounds infeasible. Or one needs to
> re-preprocess the format string, creating new locations on-the-fly. Dodji, is
> this possible?

With the current infrastructure, I fear we cannot re-process the format
string *after* the initial pre-processing phase is done, to create new
locations that we'd a in the line maps.

However, briefly looking at the source code, we might be able to pull
this whole shebang off, in a way.

I am thinking that in gcc/c-family/c-format.c:check_format_info_main, we
can arrange for the instance of format_kind_info (that is the result of
parsing the format string) to carry the virtual location  of the
beginning of the format string *and* the offset of the relevant
character we might want to warn about.

Then, later the routines that trigger the warning by analyzing the instance of
format_kind_info could be passed the relevant location for the beginning
of the of the format string as well as the byte offset of the relevant
character I talked about above.  At warning type, it could re-construct
the exact column where of that relevant character, with its byte offset
and the virtual location of the beginning of the format string.

Does that make sense?

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-05-24 19:05:26 UTC ---
(In reply to comment #9)
> "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> a écrit:
> 
> > So either one keeps track of all source locations of all "interesting"
> > characters within strings, which sounds infeasible. Or one needs to
> > re-preprocess the format string, creating new locations on-the-fly. Dodji, is
> > this possible?
> 
> With the current infrastructure, I fear we cannot re-process the format
> string *after* the initial pre-processing phase is done, to create new
> locations that we'd a in the line maps.

Could you elaborate on the reasons for this? Is it impossible to create new
locations on the fly? 

As a brute-force approach, we at least should be able to re-preproces the whole
file, no? Could we do this by invoking libcpp directly rather than calling a
command? 

> Does that make sense?

This implies that the diagnostics code would need to handle a byte offset, no? 

And I am not sure this will handle well the case of split strings and macro
expansion, like Clang does.

[Bug c/52952] Wformat location info is bad (wrong column number)

[dodji at seketeli dot org]

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

--- Comment #11 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-05-24 20:30:10 UTC ---
"manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> a écrit:

>> With the current infrastructure, I fear we cannot re-process the format
>> string *after* the initial pre-processing phase is done, to create new
>> locations that we'd a in the line maps.
>
> Could you elaborate on the reasons for this? Is it impossible to create new
> locations on the fly? 

Not really, no.  It is not practical to insert new locations inside an
existing location map because that would imply to update (modify) all
the maps that come after the one you have modified.  Also, that would
invalidate all the locations that have been encoded by the maps that you
would have updated.

Basically, the current encoding of the map requires that a new location
encoding in a map must always be the last location of that map.  You
cannot insert a location in the "middle" of an existing map.

> As a brute-force approach, we at least should be able to re-preproces the whole
> file, no?

I guess that would take re-processing the whole compilation unit,
starting from the location map that you have changed.  And, just handling
locations wouldn't be enough, we'd need to basically re-tokenize the
files that are re-processed, because the locations are primarily carried
by instances of cpp_token, and we need the locations of these tokens to
be updated.

That doesn't seem practical.

> Could we do this by invoking libcpp directly rather than calling a
> command?

Yes, even though it wouldn't be practical, in my opinion.

>
>> Does that make sense?
>
> This implies that the diagnostics code would need to handle a byte
> offset, no?

Yes, probably.

> And I am not sure this will handle well the case of split strings and macro
> expansion, like Clang does.

Yeah.  Which makes me think that maybe we might want to introduce a new
way to represent string literal tokens in libcpp, that keeps the
underlying raw format.  There would be a character oriented iterator API
for that string literal representation.  And that iterator API could
provide its user with the file/line/column information for the current
character.  And one could pass any such iterator to some of the
diagnostic routines.

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #12 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-05-25 14:09:00 UTC ---
> 
> Basically, the current encoding of the map requires that a new location
> encoding in a map must always be the last location of that map.  You
> cannot insert a location in the "middle" of an existing map.

Just continuing with the thought-experiment... would it be possible to
duplicate the current line-table, then start re-encoding locations from the
last location before the interesting character, and simply stop when the
interesting character is reached? Then switch line-tables on the fly before
giving the diagnostic, and switch back to the original line-table after it.

I guess Clang has a different encoding for source locations, because it seems
they are generating new location indexes on the fly.

> I guess that would take re-processing the whole compilation unit,
> starting from the location map that you have changed.  And, just handling
> locations wouldn't be enough, we'd need to basically re-tokenize the
> files that are re-processed, because the locations are primarily carried
> by instances of cpp_token, and we need the locations of these tokens to
> be updated.
> 
> That doesn't seem practical.

Practical because of complexity, ugliness or computation time?


> > And I am not sure this will handle well the case of split strings and macro
> > expansion, like Clang does.
> 
> Yeah.  Which makes me think that maybe we might want to introduce a new
> way to represent string literal tokens in libcpp, that keeps the
> underlying raw format.  There would be a character oriented iterator API
> for that string literal representation.  And that iterator API could
> provide its user with the file/line/column information for the current
> character.  And one could pass any such iterator to some of the
> diagnostic routines.

This sounds interesting, but I still do not understand how it can handle macro
expansions. Could you elaborate?

[Bug c/52952] Wformat location info is bad (wrong column number)

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-05-25 14:17:41 UTC ---
I guess the C/C++ FEs could for non-trivial string literals put into a hash
table mapping from locus_t (of ADDR_EXPR around STRING_CST) to the first cpp
token for that string, then the diagnostic code could go from there.
Trivial string literal above would be a string literal that doesn't have any
prefixes (L/u/u8/U and variants with R), isn't contatenated from several parts
and didn't need to be translated.  So, printf ("%.*d"); (the common case)
wouldn't have to be recorded, while printf (R"<<<(%)>>>" "." R"(*)" "d"); would
need that.  For "trivial" string literals you'd just shift the locus by the
offset, for non-trivial look up the tokens and process them again, looking at
where the corresponding byte would appear to come from.

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

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

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

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-06-04 11:18:46 UTC ---
(In reply to comment #13)
> I guess the C/C++ FEs could for non-trivial string literals put into a hash
> table mapping from locus_t (of ADDR_EXPR around STRING_CST) to the first cpp
> token for that string, then the diagnostic code could go from there.

Where is the best place to store this hash table? And you say the C/C++ FEs,
but it seems to me this would need to be done in libcpp, no?

> Trivial string literal above would be a string literal that doesn't have any
> prefixes (L/u/u8/U and variants with R), isn't contatenated from several parts
> and didn't need to be translated.  So, printf ("%.*d"); (the common case)
> wouldn't have to be recorded, while printf (R"<<<(%)>>>" "." R"(*)" "d"); would
> need that.  For "trivial" string literals you'd just shift the locus by the
> offset, for non-trivial look up the tokens and process them again, looking at
> where the corresponding byte would appear to come from.

What do you mean by "process them again"? Once we have a mapping of location_t
to individual token, the only thing to be done is look inside the string for
the relevant character, no?

Well, this seems to require several big parts:

First, handle locations + offsets in diagnostics. Perhaps we need new
warning_at_offset(location, offset, ...) functions? Or should we encode the
offset in location_t somehow? If an offset parameter is passed explicitly, the
diagnostics code would require a lot of changes to pass the offset around. Not
sure what is the best way to implement this and avoid massive changes.

Second, building the hash table discussed above. Where should it be built?
Where should it be stored? 

Third, location+offset to expanded_location code. This is the part that will
use the above hash table and reprocess the tokens. Exactly how it will work is
not entirely clear to me.

Fourth, use the new infrastructure in Wformat warnings and other places that
inspect strings. Perhaps the offset could also be re-used to implement ranges,
but the diagnostics code would need to handle them differently when used for
ranges and when used to specify a location within a string.

I added Tom Tromey to the CC, perhaps he has some ideas about how to implement
this.

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #15 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-03-30 12:32:08 UTC ---
(In reply to comment #13)
> I guess the C/C++ FEs could for non-trivial string literals put into a hash
> table mapping from locus_t (of ADDR_EXPR around STRING_CST) to the first cpp
> token for that string, then the diagnostic code could go from there.
> Trivial string literal above would be a string literal that doesn't have any
> prefixes (L/u/u8/U and variants with R), isn't contatenated from several parts
> and didn't need to be translated.  So, printf ("%.*d"); (the common case)
> wouldn't have to be recorded, while printf (R"<<<(%)>>>" "." R"(*)" "d"); would
> need that.  For "trivial" string literals you'd just shift the locus by the
> offset, for non-trivial look up the tokens and process them again, looking at
> where the corresponding byte would appear to come from.

Jakub, I am trying to implement this idea, but I am not sure I got the
hash_table right. It looks overly complicated to me. Could you take a look?
>From gcc-bugs-return-418810-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Mar 30 12:33:04 2013
Return-Path: <gcc-bugs-return-418810-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14077 invoked by alias); 30 Mar 2013 12:33:04 -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 13962 invoked by uid 48); 30 Mar 2013 12:32:57 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/52952] Wformat location info is bad (wrong column number)
Date: Sat, 30 Mar 2013 12:33: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-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-52952-4-RkyS6a6tTm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SW-Source: 2013-03/txt/msg02251.txt.bz2
Content-length: 266


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

--- Comment #16 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-03-30 12:32:57 UTC ---
Created attachment 29753
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29753
loc_token_hash
>From gcc-bugs-return-418811-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Mar 30 12:40:31 2013
Return-Path: <gcc-bugs-return-418811-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15842 invoked by alias); 30 Mar 2013 12:40: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 15808 invoked by uid 48); 30 Mar 2013 12:40:25 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/52952] Wformat location info is bad (wrong column number)
Date: Sat, 30 Mar 2013 12:40: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-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: CC
Message-ID: <bug-52952-4-12Jh7VF4JK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SW-Source: 2013-03/txt/msg02252.txt.bz2
Content-length: 1155


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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joseph at codesourcery dot
                   |                            |com

--- Comment #17 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-03-30 12:40:24 UTC ---
BTW, I have a patch based on Steven's one that is almost working and for simple
strings handles a location+offset. However, there are several issues:

* Cases like:

1: const str[] = "something %d";
2: printf(str);

will report a location at 2 plus offset of %d, not nice.

* I didn't transform the most obscure format warnings. Some of them have no
easy location at hand and others I simply don't know what we want to point at.

* It would be extremely nice to update the testsuite to check the locations are
correct. This is unfortunately a lot of boring work, so if I cannot get help to
do this, I hope it is not a pre-condition for approval.
>From gcc-bugs-return-418812-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Mar 30 12:54:19 2013
Return-Path: <gcc-bugs-return-418812-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24126 invoked by alias); 30 Mar 2013 12:54:19 -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 23698 invoked by uid 55); 30 Mar 2013 12:54:13 -0000
From: "stevenb.gcc at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/52952] Wformat location info is bad (wrong column number)
Date: Sat, 30 Mar 2013 12:54: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-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: stevenb.gcc at gmail 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-Changed-Fields:
Message-ID: <bug-52952-4-3eGFT5pYmw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-03/txt/msg02253.txt.bz2
Content-length: 480


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

--- Comment #18 from stevenb.gcc at gmail dot com <stevenb.gcc at gmail dot com> 2013-03-30 12:54:12 UTC ---
> * It would be extremely nice to update the testsuite to check the locations are
> correct. This is unfortunately a lot of boring work, so if I cannot get help to
> do this, I hope it is not a pre-condition for approval.

You mean for existing test cases? I will help with that, just say
what/where/when ;-)

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #19 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-03-30 13:26:19 UTC ---
Unfortunately, there are some stuff like this:

 <addr_expr 0x7ffff708f680
    type <pointer_type 0x7ffff7094690
        type <array_type 0x7ffff7094540 type <integer_type 0x7ffff6ef3dc8 char>
            BLK
            size <integer_cst 0x7ffff708f540 constant 280>
            unit size <integer_cst 0x7ffff708f620 constant 35>
            align 8 symtab 0 alias set -1 canonical type 0x7ffff7094540 domain
<integer_type 0x7ffff70943f0>
            pointer_to_this <pointer_type 0x7ffff7094690>>
        unsigned DI
        size <integer_cst 0x7ffff6ecddc0 constant 64>
        unit size <integer_cst 0x7ffff6ecdde0 constant 8>
        align 64 symtab 0 alias set -1 canonical type 0x7ffff7094690>
    readonly constant
    arg 0 <string_cst 0x7ffff7059038 type <array_type 0x7ffff7094540>
        readonly constant static "%s:%d: %s: Assertion '%s' failed.\012\000">>

so we cannot assert that the format_expr has no unknown location.
>From gcc-bugs-return-418814-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Mar 30 14:45:59 2013
Return-Path: <gcc-bugs-return-418814-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26259 invoked by alias); 30 Mar 2013 14:45: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 26203 invoked by uid 48); 30 Mar 2013 14:45:47 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/49791] [4.6/4.7/4.8/4.9 Regression] Formatted namelist reads fails with: Cannot match namelist object
Date: Sat, 30 Mar 2013 14:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: jvdelisle at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.6.4
X-Bugzilla-Changed-Fields: CC
Message-ID: <bug-49791-4-0G7jgnseLG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-49791-4@http.gcc.gnu.org/bugzilla/>
References: <bug-49791-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-03/txt/msg02255.txt.bz2
Content-length: 637


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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #26 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-03-30 14:45:45 UTC ---
(In reply to comment #25)
> Lets close this one and carry forward on PR56660.

PR56660 is about comment 19.

The other issue, comment 18, has been fixed meanwhile. (By one of the recent
4.9 patches; GCC 4.8.0 fails.)

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #20 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-03-30 15:02:11 UTC ---
(In reply to comment #18)
> > * It would be extremely nice to update the testsuite to check the locations are
> > correct. This is unfortunately a lot of boring work, so if I cannot get help to
> > do this, I hope it is not a pre-condition for approval.
> 
> You mean for existing test cases? I will help with that, just say
> what/where/when ;-)

I personally think that it would be better to spend our extremely limited human
resources on adding more explicit locations and offsets to the various warnings
and checking that they are correct. This can be done by running with my current
patch the following:

make check-gcc RUNTESTFLAGS='format.exp=*.c
--target_board="unix/-fdiagnostics-show-caret"'

and checking if the output is what one would expect.

If later we regress, then we could update/add testcases.
>From gcc-bugs-return-418820-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Mar 30 15:03:22 2013
Return-Path: <gcc-bugs-return-418820-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5155 invoked by alias); 30 Mar 2013 15:03:21 -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 5114 invoked by uid 48); 30 Mar 2013 15:03:15 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/52952] Wformat location info is bad (wrong column number)
Date: Sat, 30 Mar 2013 15:03: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-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-52952-4-f6ociYHSJ7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SW-Source: 2013-03/txt/msg02261.txt.bz2
Content-length: 352


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

--- Comment #21 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-03-30 15:03:14 UTC ---
Created attachment 29755
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29755
add locations and offsets to format warnings

My current patch, untested except for a few testcases.
>From gcc-bugs-return-418821-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Mar 30 18:42:52 2013
Return-Path: <gcc-bugs-return-418821-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15610 invoked by alias); 30 Mar 2013 18:42:52 -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 15567 invoked by uid 48); 30 Mar 2013 18:42:46 -0000
From: "madawilliams at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks
Date: Sat, 30 Mar 2013 18:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: madawilliams at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: burnus at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.6.4
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56735-4-OSP0wzrC7P@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56735-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56735-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-03/txt/msg02262.txt.bz2
Content-length: 683


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

--- Comment #9 from Adam Williams <madawilliams at gmail dot com> 2013-03-30 18:42:44 UTC ---
This is great. I look forward to testing when I get a chance to build from the
latest dev branch. I understand what you mean with the "?", however they are
being used in a completely non-standard way in the legacy code in question.
They are actually being used as a marker in some formatted text which is kept
at the top of a namelist file and read in separately. I will see if we can
alter this, but unfortunately it is not my decision and backwards compatibility
will need to be considered.

Cheers for all your help/work

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #22 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-01 14:17:45 UTC ---
(In reply to comment #13)
> and didn't need to be translated.  So, printf ("%.*d"); (the common case)
> wouldn't have to be recorded, while printf (R"<<<(%)>>>" "." R"(*)" "d"); would

BTW, your testcase does not work for me and confuses GCC:

/home/manuel/loc_offset.c:7:21: error: unterminated raw string
   __builtin_printf (R"<<<(%)>>>" R"(*d)" );
                     ^
/home/manuel/loc_offset.c:7:3: error: expected expression at end of input
   __builtin_printf (R"<<<(%)>>>" R"(*d)" );
   ^
/home/manuel/loc_offset.c:7:3: error: expected declaration or statement at end
of input

It is also very unclear to me how to re-process such a token stream in order to
find out the real location+offset.

A further issue is that for:

#define FORMAT ".*d"
#include <stdio.h>
void f() {
   printf(
"%"
FORMAT);
}

the token representing "%" is overriden when we call cpp_get_token next time:

@@ -1003,10 +1004,13 @@ lex_string (const cpp_token *tok, tree *
      concatenation.  It is 'true' if we have seen an '@' before the
      current string, and 'false' if not.  We must see exactly one or
      zero '@' before each string.  */
   bool objc_at_sign_was_seen = false;

+  // This token is overwritten! How can that happen?
+  const cpp_token *prev_tok = tok;
+
  retry:
   tok = cpp_get_token (parse_in);
   switch (tok->type)
     {
     case CPP_PADDING:

so prev_tok above may or may not change by the call of cpp_get_token.
>From gcc-bugs-return-418861-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 01 14:20:26 2013
Return-Path: <gcc-bugs-return-418861-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1876 invoked by alias); 1 Apr 2013 14:20: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 1791 invoked by uid 48); 1 Apr 2013 14:20:17 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/52952] Wformat location info is bad (wrong column number)
Date: Mon, 01 Apr 2013 14:20: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-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: Attachment #29753 is obsolete Attachment #29755 is obsolete
Message-ID: <bug-52952-4-uSR1QSKS9n@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg00006.txt.bz2
Content-length: 846


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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #29753|0                           |1
        is obsolete|                            |
  Attachment #29755|0                           |1
        is obsolete|                            |

--- Comment #23 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-01 14:20:16 UTC ---
Created attachment 29765
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29765
add locations and offsets to format warnings + loc_token hash

This patch works perfect for simple sequences of plain strings and when the
whole format string comes from a macro expansion.
>From gcc-bugs-return-418862-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 01 14:32:42 2013
Return-Path: <gcc-bugs-return-418862-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10729 invoked by alias); 1 Apr 2013 14:32:42 -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 10654 invoked by uid 48); 1 Apr 2013 14:32:29 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/52952] Wformat location info is bad (wrong column number)
Date: Mon, 01 Apr 2013 14:32: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-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle 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-Changed-Fields:
Message-ID: <bug-52952-4-ZymIQYkmQE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg00007.txt.bz2
Content-length: 233


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

--- Comment #24 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-04-01 14:32:27 UTC ---
(Nit: careful with the GCC coding style, eg, open curly bracket on a new line)

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #25 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-05 22:02:26 UTC ---
I am currently stuck on the three problems I described above and I cannot
figure out a way to fix any of them:

* How to reprocess tokens that need to be translated/have prefixes.

* The issue that the current token may get modified when we call cpp_get_token
next time (I could store the full token, but that seems a bit waste of memory).

* Cases like:

1: const str[] = "something %d";
2: printf(str);

where we don't have (or I cannot find) the location of "something %d".

Any ideas? 

I am also not sure if I implemented correctly the hash_table. 

Another possibility is to make the offset work only with simple strings, if
there is something strange, simply set the offset to zero. It is a poor
solution, but it is better than nothing.
>From gcc-bugs-return-419365-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 05 22:02:52 2013
Return-Path: <gcc-bugs-return-419365-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19693 invoked by alias); 5 Apr 2013 22:02:51 -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 19682 invoked by uid 89); 5 Apr 2013 22:02:51 -0000
X-Spam-SWARE-Status: No, score=4.3 required=5.0 tests=AXB_XMAILER_MIMEOLE_OL_22B61,BAYES_99,FSL_HELO_BARE_IP_2,KHOP_RCVD_UNTRUST,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_HI,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD autolearn=no version=3.3.1
Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 05 Apr 2013 22:02:49 +0000
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53246)	by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)	(Exim 4.71)	(envelope-from <fred@fatherleo.com>)	id 1UOEib-00040a-Ta	for bug-gcc@gnu.org; Fri, 05 Apr 2013 18:02:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)	(envelope-from <fred@fatherleo.com>)	id 1UOEiS-00020X-Gn	for bug-gcc@gnu.org; Fri, 05 Apr 2013 18:02:45 -0400
X-Spam-Report: 	*  0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL	*      [219.85.4.5 listed in xbl.fsfblacklists]	*  1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT	*      [219.85.4.5 listed in bb.barracudacentral.org]	*  1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net	*      [Blocked - see <http://www.spamcop.net/bl.shtml?219.85.4.5>]	*  0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address	*      [219.85.4.5 listed in dnsbl.sorbs.net]	*  2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL	*      [219.85.4.5 listed in psbl.surriel.com]	*  3.5 RCVD_IN_MSPIKE_BL RBL: RCVD_IN_MSPIKE_BL	*      [219.85.4.5 listed in bl.mailspike.net]	*  3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL	*      [219.85.4.5 listed in zen.spamhaus.org]	*  1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL,	*      https://senderscore.org/blacklistlookup/	*      [219.85.4.5 listed in bl.score.senderscore.com]	*  3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%	*      [score: 1.0000]	*  1.1 FSL_HELO_BARE_IP_2 FSL_HELO_BARE_IP_2	*  2.3 FSL_HELO_BARE_IP_1 FSL_HELO_BARE_IP_1	*  0.4 STOX_REPLY_TYPE STOX_REPLY_TYPE	*  2.5 RECEIVED_FROM_WINDOWS_HOST RECEIVED_FROM_WINDOWS_HOST	*  1.2 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO	*  4.1 AXB_XMAILER_MIMEOLE_OL_22B61 AXB_XMAILER_MIMEOLE_OL_22B61	*  0.8 RDNS_NONE Delivered to internal network by a host with no rDNS	*  1.8 STOX_REPLY_TYPE_WITHOUT_QUOTES STOX_REPLY_TYPE_WITHOUT_QUOTES
Received: from [219.85.4.5] (port053 helo!9.85.4.5)	by eggs.gnu.org with smtp (Exim 4.71)	(envelope-from <fred@fatherleo.com>)	id 1UOEiR-000204-VT	for bug-gcc@gnu.org; Fri, 05 Apr 2013 18:02:36 -0400
Received: from unknown (HELO 9x8ry) ([127.205.33.153])	by 219.85.4.5 with ESMTP; Sat, 6 Apr 2013 05:42:08 +0800
Message-ID: <000601ce3246$17cf8aa0$7fcd2199@Gilbertg14xo489x8ry>
From: "Rachel Burnett" <fred@fatherleo.com>
To: <bug-gcc@gnu.org>
Subject: Business opportunity
Date: Fri, 05 Apr 2013 22:02:00 -0000
MIME-Version: 1.0
Content-Type: text/plain;	format=flowed;	charset="windows-1250";	reply-type=original
Content-Transfer-Encoding: 7bit
X-detected-operating-system: by eggs.gnu.org: Windows XP
X-Received-From: 219.85.4.5
X-SW-Source: 2013-04/txt/msg00510.txt.bz2
Content-length: 113

Our site is the home to discuss potential scams and good business
opportunities. Welcome: http://realscam.com/

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4979 bytes --]

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

--- Comment #27 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #25)
> * Cases like:
> 
> 1: const str[] = "something %d";
> 2: printf(str);

Note that clang is able to handle this:

manuel@gcc10:~$ clang -Wformat  format.c
format.c:4:19: warning: more '%' conversions than data arguments [-Wformat]
 __builtin_printf(str);
                  ^~~
format.c:3:33: note: format string is defined here
 const char str[] = "something %d";
                               ~^
>From gcc-bugs-return-457818-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 05 18:52:49 2014
Return-Path: <gcc-bugs-return-457818-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17272 invoked by alias); 5 Aug 2014 18:52: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 17193 invoked by uid 48); 5 Aug 2014 18:52:44 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/52952] Wformat location info is bad (wrong column number)
Date: Tue, 05 Aug 2014 18:52: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: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
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-52952-4-nxiEsDT558@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52952-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-08/txt/msg00315.txt.bz2
Content-length: 230

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

--- Comment #28 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Testcase:

void foo(void)
{
  char str[] = "something %d";
 __builtin_printf(str);

}
>From gcc-bugs-return-457819-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 05 19:27:00 2014
Return-Path: <gcc-bugs-return-457819-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18550 invoked by alias); 5 Aug 2014 19:26: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 18518 invoked by uid 48); 5 Aug 2014 19:26:54 -0000
From: "d.g.gorbachev at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/62026] New: [4.9/4.10 Regression] Crash in lto_get_decl_name_mapping
Date: Tue, 05 Aug 2014 19:26: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.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: d.g.gorbachev 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 attachments.created
Message-ID: <bug-62026-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-08/txt/msg00316.txt.bz2
Content-length: 598

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

            Bug ID: 62026
           Summary: [4.9/4.10 Regression] Crash in
                    lto_get_decl_name_mapping
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: d.g.gorbachev at gmail dot com

Created attachment 33250
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3250&actioníit
Testcase

Compile this testcase with `-O3 -flto -shared -nostdlib'.

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #29 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Author: manu
Date: Tue Aug 19 02:02:09 2014
New Revision: 214129

URL: https://gcc.gnu.org/viewcvs?rev=214129&root=gcc&view=rev
Log:
gcc/c-family/ChangeLog:

2014-08-19  Manuel López-Ibáñez  <manu@gcc.gnu.org>
        Steven Bosscher  <steven@gcc.gnu.org>

    PR c/52952
    * c-format.c: Add extra_arg_loc and format_string_loc to struct
    format_check_results.
    (check_function_format): Use true and add comment for boolean
    argument.
    (finish_dollar_format_checking): Use explicit location when warning.
    (check_format_info): Likewise.
    (check_format_arg): Set extra_arg_loc and format_string_loc.
    (check_format_info_main): Use explicit location when warning.
    (check_format_types): Pass explicit location.
    (format_type_warning): Likewise.

gcc/testsuite/ChangeLog:

2014-08-19  Manuel López-Ibáñez  <manu@gcc.gnu.org>
        Steven Bosscher  <steven@gcc.gnu.org>

    PR c/52952
    * gcc.dg/redecl-4.c: Add column markers.
    * gcc.dg/format/bitfld-1.c: Likewise.
    * gcc.dg/format/attr-2.c: Likewise.
    * gcc.dg/format/attr-6.c: Likewise.
    * gcc.dg/format/array-1.c: Likewise.
    * gcc.dg/format/attr-7.c: Likewise.
    * gcc.dg/format/asm_fprintf-1.c: Likewise.
    * gcc.dg/format/attr-4.c: Likewise.
    * gcc.dg/format/branch-1.c: Likewise.
    * gcc.dg/format/c90-printf-1.c: Likewise.


Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-format.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/format/array-1.c
    trunk/gcc/testsuite/gcc.dg/format/asm_fprintf-1.c
    trunk/gcc/testsuite/gcc.dg/format/attr-2.c
    trunk/gcc/testsuite/gcc.dg/format/attr-4.c
    trunk/gcc/testsuite/gcc.dg/format/attr-6.c
    trunk/gcc/testsuite/gcc.dg/format/attr-7.c
    trunk/gcc/testsuite/gcc.dg/format/bitfld-1.c
    trunk/gcc/testsuite/gcc.dg/format/branch-1.c
    trunk/gcc/testsuite/gcc.dg/format/c90-printf-1.c
    trunk/gcc/testsuite/gcc.dg/redecl-4.c
>From gcc-bugs-return-458748-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 19 02:12:38 2014
Return-Path: <gcc-bugs-return-458748-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28959 invoked by alias); 19 Aug 2014 02:12:36 -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 25645 invoked by uid 48); 19 Aug 2014 02:11:03 -0000
From: "amker at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/62178] [AArch64] Performance regression on matrix matrix multiply due to r211211
Date: Tue, 19 Aug 2014 02:12: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amker 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-62178-4-MpxbJ4nZSg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62178-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62178-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-08/txt/msg01245.txt.bz2
Content-length: 241

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

--- Comment #2 from amker at gcc dot gnu.org ---
Yes, the patch changes addressing modes choosing and further changes ivopts's
decision.  I shall take this one if you are ok.

Thanks,
bin

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #27466|0                           |1
        is obsolete|                            |

--- Comment #30 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Created attachment 33647
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33647&action=edit
create locations from loc + offset

This variant works for simple strings. However, it cannot handle even simple
macros:

format.c:1:18: warning: format ‘%d’ expects a matching ‘int’ argument
[-Wformat=]
 #define FORMAT "%d"
                  ^
format.c:8:24: warning: format ‘%d’ expects a matching ‘int’ argument
[-Wformat=]
    __builtin_printf("a" FORMAT);
                        ^

whereas Clang can:

format.c:7:20: warning: more '%' conversions than data arguments [-Wformat]
  __builtin_printf(FORMAT);
                   ^
format.c:1:18: note: expanded from macro 'FORMAT'
#define FORMAT "%d"
                ~^
format.c:8:25: warning: more '%' conversions than data arguments [-Wformat]
   __builtin_printf("a" FORMAT);
                        ^
format.c:1:18: note: expanded from macro 'FORMAT'
#define FORMAT "%d"
                ~^
>From gcc-bugs-return-463283-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Oct 04 23:41:30 2014
Return-Path: <gcc-bugs-return-463283-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13988 invoked by alias); 4 Oct 2014 23:41:30 -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 13944 invoked by uid 48); 4 Oct 2014 23:41:26 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/52952] Wformat location info is bad (wrong column number)
Date: Sat, 04 Oct 2014 23:41: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: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
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-52952-4-97Ywtm5rxx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52952-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-10/txt/msg00304.txt.bz2
Content-length: 905

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

--- Comment #31 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #30)
> Created attachment 33647 [details]
> create locations from loc + offset
> 
> This variant works for simple strings. However, it cannot handle even simple
> macros:

In addition, there is the issue that GCC does not track the location of
initializers. Thus, I had to explicitly disable the offset computation in case
of VAR_DECL.

Clang by comparison perfectly handles this case:

format.c:11:21: warning: more '%' conversions than data arguments [-Wformat]
   __builtin_printf(a);
                    ^
format.c:5:18: note: format string is defined here
const char a[] = FORMAT;
                 ^
format.c:1:18: note: expanded from macro 'FORMAT'
#define FORMAT "%d"
                ~^
>From gcc-bugs-return-463284-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Oct 04 23:44:15 2014
Return-Path: <gcc-bugs-return-463284-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15121 invoked by alias); 4 Oct 2014 23:44:15 -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 15055 invoked by uid 48); 4 Oct 2014 23:44:11 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran
Date: Sat, 04 Oct 2014 23:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
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-55534-4-fSIjvql7FX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55534-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55534-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-10/txt/msg00305.txt.bz2
Content-length: 421

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

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #7)
> The ideal fix for this would adding a function like:

I forgot about this bug and redid the above from scratch. But this time, I
actually tested that it works:
https://gcc.gnu.org/ml/fortran/2014-10/msg00019.html
>From gcc-bugs-return-463285-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Oct 05 02:38:59 2014
Return-Path: <gcc-bugs-return-463285-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25037 invoked by alias); 5 Oct 2014 02:38:57 -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 24954 invoked by uid 55); 5 Oct 2014 02:38:48 -0000
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/62026] [4.9/5 Regression] Crash in lto_get_decl_name_mapping
Date: Sun, 05 Oct 2014 02:38: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.2
X-Bugzilla-Keywords: ice-on-valid-code, lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62026-4-slEStVK0mV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62026-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62026-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-10/txt/msg00306.txt.bz2
Content-length: 724

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

--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Sun Oct  5 02:37:31 2014
New Revision: 215894

URL: https://gcc.gnu.org/viewcvs?rev!5894&root=gcc&view=rev
Log:

    PR lto/62026
    * g++.dg/lto/pr62026.C: New testcase.
    * lto-streamer-out.c (lto_output): Handle thunks correctly.
    * cgraphclones.c (duplicate_thunk_for_node): Get thunk's arguments.

Added:
    branches/gcc-4_9-branch/gcc/testsuite/g++.dg/lto/pr62026.C
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/cgraphclones.c
    branches/gcc-4_9-branch/gcc/lto-streamer-out.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33647|0                           |1
        is obsolete|                            |

--- Comment #32 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Created attachment 33648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33648&action=edit
dynamically create locations from loc + offset
>From gcc-bugs-return-463298-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Oct 05 13:23:05 2014
Return-Path: <gcc-bugs-return-463298-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16013 invoked by alias); 5 Oct 2014 13:23:04 -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 15965 invoked by uid 48); 5 Oct 2014 13:23:01 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/52952] Wformat location info is bad (wrong column number)
Date: Sun, 05 Oct 2014 13:23: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: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
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-52952-4-b9ZjGl2E5V@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52952-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-10/txt/msg00319.txt.bz2
Content-length: 2005

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

--- Comment #33 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #32)
> Created attachment 33648 [details]
> dynamically create locations from loc + offset

This version is able to handle macros:

format.c: In function ‘foo’:
format.c:5:18: warning: format ‘%d’ expects a matching ‘int’ argument
[-Wformat=]
 #define FORMAT "%d"
                  ^
format.c:9:20: note: in definition of macro ‘FORMAT3’
 #define FORMAT3(x) x
                    ^
format.c:21:29: note: in expansion of macro ‘FORMAT’
   __builtin_printf(FORMAT3 (FORMAT));
                             ^
format.c:23:31: warning: format ‘%d’ expects a matching ‘int’ argument
[-Wformat=]
   __builtin_printf(FORMAT3 ("%d"));
                               ^
format.c:9:20: note: in definition of macro ‘FORMAT3’
 #define FORMAT3(x) x
                    ^
format.c:5:18: warning: format ‘%d’ expects a matching ‘int’ argument
[-Wformat=]
 #define FORMAT "%d"
                  ^
format.c:28:20: note: in expansion of macro ‘FORMAT’
   __builtin_printf(FORMAT);
                    ^

The approach followed is based on reserving space for one token in every macro
map. If this is expensive, the alternative could be to reserve the virtual
location for the additional token, but not reserve the memory until the virtual
location is requested. The code assumes that the new location is immediately
used, otherwise a subsequent location may overwrite it. The problem is that the
virtual locations of macro maps are consecutive, thus we cannot simply
dynamically create virtual locations without reserving some of them in advance.


Perhaps this is good enough for a first commit? 

Dodji, what do you think?
>From gcc-bugs-return-463299-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Oct 05 13:39:43 2014
Return-Path: <gcc-bugs-return-463299-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6487 invoked by alias); 5 Oct 2014 13:39:43 -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 6435 invoked by uid 48); 5 Oct 2014 13:39:39 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/52952] Wformat location info is bad (wrong column number)
Date: Sun, 05 Oct 2014 13:39: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: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
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-52952-4-QRpiI20Z3g@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52952-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-10/txt/msg00320.txt.bz2
Content-length: 1032

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

--- Comment #34 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #27)
> (In reply to Manuel López-Ibáñez from comment #25)
> > * Cases like:
> > 
> > 1: const str[] = "something %d";
> > 2: printf(str);
> 
> Note that clang is able to handle this:
> 
> manuel@gcc10:~$ clang -Wformat  format.c
> format.c:4:19: warning: more '%' conversions than data arguments [-Wformat]
>  __builtin_printf(str);
>                   ^~~
> format.c:3:33: note: format string is defined here
>  const char str[] = "something %d";
>                                ~^

Note to myself:

Supporting this requires tracking the location of the initializer. Perhaps we
could track this explicitly in var_decl. Or by adding an expression around the
initializer.

Then, we would need to pass the additional location to the point of warning_at,
so we can print the note when appropriate.
>From gcc-bugs-return-463300-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Oct 05 13:45:11 2014
Return-Path: <gcc-bugs-return-463300-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10584 invoked by alias); 5 Oct 2014 13:45:07 -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 10487 invoked by uid 48); 5 Oct 2014 13:45:01 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/52952] Wformat location info is bad (wrong column number)
Date: Sun, 05 Oct 2014 13:45: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: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
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-52952-4-hirlD5brsu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52952-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-10/txt/msg00321.txt.bz2
Content-length: 1411

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

--- Comment #35 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #13)
> I guess the C/C++ FEs could for non-trivial string literals put into a hash
> table mapping from locus_t (of ADDR_EXPR around STRING_CST) to the first cpp
> token for that string, then the diagnostic code could go from there.
> Trivial string literal above would be a string literal that doesn't have any
> prefixes (L/u/u8/U and variants with R), isn't contatenated from several
> parts
> and didn't need to be translated.  So, printf ("%.*d"); (the common case)
> wouldn't have to be recorded, while printf (R"<<<(%)>>>" "." R"(*)" "d");
> would need that.  For "trivial" string literals you'd just shift the locus
> by the offset, for non-trivial look up the tokens and process them again,
> looking at where the corresponding byte would appear to come from.

Perhaps we could use ADHOC_LOCATIONS to implement this? That is, for
multi-string/prefixed string constants, the adhoc data could contain the
additional location. Then, on-the-fly offset locations could be generated by
looking at each piece, if the offset is longer than the piece, then try the
next piece and adjust the offset for the characters already seen in previous
pieces. Simple strings will not have any adhoc data, so they will work as
usual.
>From gcc-bugs-return-463301-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Oct 05 15:15:44 2014
Return-Path: <gcc-bugs-return-463301-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17424 invoked by alias); 5 Oct 2014 15:15:44 -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 17398 invoked by uid 48); 5 Oct 2014 15:15:40 -0000
From: "vincenzo.innocente at cern dot ch" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/56829] Feature request: "generic" builtin to support control flow in vectorized code ("movemask", "vec_any/all_*")
Date: Sun, 05 Oct 2014 15:15: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.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: vincenzo.innocente at cern dot ch
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-56829-4-x5AvpAQnWR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56829-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56829-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-10/txt/msg00322.txt.bz2
Content-length: 240

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

--- Comment #2 from vincenzo Innocente <vincenzo.innocente at cern dot ch> ---
just to add the OpenCL syntax and "doc"
https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/any.html

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #36 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Latest patch: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00663.html

Joseph pointed out that it does not handle escape sequences. The only solution
I can think of is to open the file and re-parse the string. However, it doesn't
seem trivial to re-use libcpp to parse a string given as a char *. Any ideas
how to achieve this or a better alternative?

Escape sequences are too common to ignore in a first implementation.
>From gcc-bugs-return-466057-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 08 16:50:41 2014
Return-Path: <gcc-bugs-return-466057-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 776 invoked by alias); 8 Nov 2014 16:50:41 -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 745 invoked by uid 48); 8 Nov 2014 16:50:37 -0000
From: "thopre01 at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/63761] [5 Regression] error: gimple_bb (stmt) is set to a wrong basic block
Date: Sat, 08 Nov 2014 16:50: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: thopre01 at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: thopre01 at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63761-4-bF2PbssOV9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63761-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63761-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-11/txt/msg00529.txt.bz2
Content-length: 300

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

--- Comment #3 from thopre01 at gcc dot gnu.org ---
I got a local patch that makes this code compile without error and I can build
gcc with this patch. I'm now going to run the testsuite, add some more comments
and try to make a reduced testcase.

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #37 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to dodji@seketeli.org from comment #9)
> "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> a écrit:
> 
> > So either one keeps track of all source locations of all "interesting"
> > characters within strings, which sounds infeasible. Or one needs to
> > re-preprocess the format string, creating new locations on-the-fly. Dodji, is
> > this possible?
> 
> With the current infrastructure, I fear we cannot re-process the format
> string *after* the initial pre-processing phase is done, to create new
> locations that we'd a in the line maps.

I'm thinking whether we cannot simply add a new RENAME map on the fly just
before emitting an error. We could even replace the source_location of the
string with this new map starting location.
>From gcc-bugs-return-482030-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 27 14:52:59 2015
Return-Path: <gcc-bugs-return-482030-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 80776 invoked by alias); 27 Mar 2015 14:52: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 80726 invoked by uid 55); 27 Mar 2015 14:52:54 -0000
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/65588] [5 Regression] lto1: internal compiler error: Segmentation fault
Date: Fri, 27 Mar 2015 15:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at ucw dot cz
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65588-4-xfpTuDCwVC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65588-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65588-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/msg03174.txt.bz2
Content-length: 1493

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

--- Comment #6 from Jan Hubicka <hubicka at ucw dot cz> ---
Hi,
this patch fixes the partitioner and also avoids assemble_undefined_decl to be
called
on hard registers and value exprs.  I am not sure how the reduced testcase
could work,
since I think the bug needs partitioning to reproduce. So I would welcome if
someone
can reproduce the reduced one could test that it is indeed fixed.

Index: varpool.c
==================================================================--- varpool.c    (revision 221725)
+++ varpool.c    (working copy)
@@ -737,7 +737,9 @@ symbol_table::output_variables (void)
   timevar_push (TV_VAROUT);

   FOR_EACH_VARIABLE (node)
-    if (!node->definition)
+    if (!node->definition
+    && !DECL_HAS_VALUE_EXPR_P (node->decl)
+     && !DECL_HARD_REGISTER (node->decl))
       assemble_undefined_decl (node->decl);
   FOR_EACH_DEFINED_VARIABLE (node)
     {
Index: symtab.c
==================================================================--- symtab.c    (revision 221725)
+++ symtab.c    (working copy)
@@ -1684,6 +1689,8 @@ symtab_node::get_partitioning_class (voi
          objects that can not be duplicated across partitions.  */
       if (DECL_IN_CONSTANT_POOL (decl))
     return SYMBOL_DUPLICATE;
+      if (DECL_HARD_REGISTER (decl))
+    return SYMBOL_DUPLICATE;
       gcc_checking_assert (vnode->definition);
     }
   /* Functions that are cloned may stay in callgraph even if they are unused.

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2012-04-12 00:00:00         |2015-9-8

--- Comment #40 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Unreviewed patch that increases precision in some cases:
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01373.html
>From gcc-bugs-return-496640-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 08 15:08:54 2015
Return-Path: <gcc-bugs-return-496640-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21455 invoked by alias); 8 Sep 2015 15:08:54 -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 21408 invoked by uid 48); 8 Sep 2015 15:08:50 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67499] c++ template/overload diagnostic compression
Date: Tue, 08 Sep 2015 15:08: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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: cc
Message-ID: <bug-67499-4-smlcsYcaFa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67499-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67499-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-09/txt/msg00618.txt.bz2
Content-length: 433

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
-Wfatal-errors is always an option.