Re: [PR c/52952] More precise locations within format strings

2015-05-20 Thread Jeff Law
On 05/20/2015 10:08 AM, Manuel López-Ibáñez wrote: I don't particularly like file scoped "offset_is_invalid" variable. It appears that it's only set within check_format_arg, but it's used from a variety of other locations via location_from_offset. Given the current structure of the code, alte

Re: [PR c/52952] More precise locations within format strings

2015-05-20 Thread Manuel López-Ibáñez
On 20 May 2015 at 15:33, Jeff Law wrote: > So if I'm understanding the situation correctly, with this new version > behaviour for non-concatenated tokens is preserved which was the only > behaviour regression in the prior patch, right? The new version will also handle most escape sequences correc

Re: [PR c/52952] More precise locations within format strings

2015-05-20 Thread Jeff Law
On 05/20/2015 02:15 AM, Manuel López-Ibáñez wrote: This is a new version of the patch submitted here: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00663.html but handling (some) escape sequences. I could not figure out a way to re-use the code from libcpp for this, thus I implemented a simple

[PR c/52952] More precise locations within format strings

2015-05-20 Thread Manuel López-Ibáñez
This is a new version of the patch submitted here: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00663.html but handling (some) escape sequences. I could not figure out a way to re-use the code from libcpp for this, thus I implemented a simple function that given a string and offset in bytes, it

Re: [PR c/52952] More precise locations within format strings

2014-11-17 Thread Dodji Seketeli
Jeff Law writes: > OK, let's go ahead and make that official. Please update MAINTAINERS ;-) I have just added a line for myself as a maintainer for the line map sub system in the MAINTAINERS file. Thanks! -- Dodji

Re: [PR c/52952] More precise locations within format strings

2014-11-13 Thread Jeff Law
On 11/10/14 02:57, Dodji Seketeli wrote: FWIW, I am willing to help with the line map sub-system, of course. Thank you for your confidence. OK, let's go ahead and make that official. Please update MAINTAINERS ;-) jeff

Re: [PR c/52952] More precise locations within format strings

2014-11-13 Thread Manuel López-Ibáñez
On 12 November 2014 15:54, Manuel López-Ibáñez wrote: > On 12 November 2014 15:38, Marek Polacek wrote: >> On Wed, Nov 12, 2014 at 03:35:06PM +0100, Manuel López-Ibáñez wrote: >>> > ../../libcpp/line-map.c:667:65: error: suggest braces around empty body >>> > in an 'if' statement [-Werror=empty-

Re: [PR c/52952] More precise locations within format strings

2014-11-12 Thread Manuel López-Ibáñez
On 13 November 2014 03:07, Mike Stump wrote: > On Nov 12, 2014, at 3:52 PM, Manuel López-Ibáñez > wrote: >> On 12 November 2014 22:41, Jakub Jelinek wrote: >>> I think we had discussions on this topic, the important thing is that we >>> don't want to generate different warnings based on whether

Re: [PR c/52952] More precise locations within format strings

2014-11-12 Thread Mike Stump
On Nov 12, 2014, at 3:52 PM, Manuel López-Ibáñez wrote: > On 12 November 2014 22:41, Jakub Jelinek wrote: >> I think we had discussions on this topic, the important thing is that we >> don't want to generate different warnings based on whether -save-temps has >> been used, there could be just com

Re: [PR c/52952] More precise locations within format strings

2014-11-12 Thread Manuel López-Ibáñez
On 12 November 2014 22:41, Jakub Jelinek wrote: > I think we had discussions on this topic, the important thing is that we > don't want to generate different warnings based on whether -save-temps has > been used, there could be just comment in between ) and ; etc. How can --save-temps influence w

Re: [PR c/52952] More precise locations within format strings

2014-11-12 Thread Jakub Jelinek
On Wed, Nov 12, 2014 at 01:24:18PM -0800, Mike Stump wrote: > On Nov 12, 2014, at 7:04 AM, Manuel López-Ibáñez > wrote: > > And I think GCC is wrong to wan here. The point of the Wempty-body > > warning is to catch things like: > > > > if(a); > > return 2; > > return 3; > > > > However, > > >

Re: [PR c/52952] More precise locations within format strings

2014-11-12 Thread Mike Stump
On Nov 12, 2014, at 7:04 AM, Manuel López-Ibáñez wrote: > And I think GCC is wrong to wan here. The point of the Wempty-body > warning is to catch things like: > > if(a); > return 2; > return 3; > > However, > > if(a) > ; > return 2; In the olden days, we didn’t have enough information to do

Re: [PR c/52952] More precise locations within format strings

2014-11-12 Thread Manuel López-Ibáñez
On 12 November 2014 15:54, Manuel López-Ibáñez wrote: > On 12 November 2014 15:38, Marek Polacek wrote: >> On Wed, Nov 12, 2014 at 03:35:06PM +0100, Manuel López-Ibáñez wrote: >>> > ../../libcpp/line-map.c:667:65: error: suggest braces around empty body >>> > in an 'if' statement [-Werror=empty-

Re: [PR c/52952] More precise locations within format strings

2014-11-12 Thread Manuel López-Ibáñez
On 12 November 2014 15:38, Marek Polacek wrote: > On Wed, Nov 12, 2014 at 03:35:06PM +0100, Manuel López-Ibáñez wrote: >> > ../../libcpp/line-map.c:667:65: error: suggest braces around empty body in >> > an 'if' statement [-Werror=empty-body] >> >> I just (r217418) bootstrapped this code and it d

Re: [PR c/52952] More precise locations within format strings

2014-11-12 Thread Marek Polacek
On Wed, Nov 12, 2014 at 03:35:06PM +0100, Manuel López-Ibáñez wrote: > > ../../libcpp/line-map.c:667:65: error: suggest braces around empty body in > > an 'if' statement [-Werror=empty-body] > > I just (r217418) bootstrapped this code and it did not produce this > error (or warning). Could you g

Re: [PR c/52952] More precise locations within format strings

2014-11-12 Thread Andreas Schwab
See libcpp/include/line-map.h:589. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

Re: [PR c/52952] More precise locations within format strings

2014-11-12 Thread Manuel López-Ibáñez
On 12 November 2014 15:24, Andreas Schwab wrote: > Manuel López-Ibáñez writes: > >> Index: libcpp/line-map.c >> === >> --- libcpp/line-map.c (revision 217191) >> +++ libcpp/line-map.c (working copy) >> @@ -631,10 +631,54 @@ linemap_p

Re: [PR c/52952] More precise locations within format strings

2014-11-12 Thread Andreas Schwab
Manuel López-Ibáñez writes: > Index: libcpp/line-map.c > === > --- libcpp/line-map.c (revision 217191) > +++ libcpp/line-map.c (working copy) > @@ -631,10 +631,54 @@ linemap_position_for_line_and_column (co > + ((line - ORDIN

Re: [PR c/52952] More precise locations within format strings

2014-11-11 Thread Dodji Seketeli
Joseph Myers writes: [...] >> Neither Per nor Tom are active in GCC anymore. If the FE maintainers >> do not feel comfortable reviewing line-map changes, could you nominate >> Dodji as line-map maintainer if he is willing to accept it? I think he >> is currently the person that understands that

Re: [PR c/52952] More precise locations within format strings

2014-11-11 Thread Jason Merrill
On 11/10/2014 01:49 PM, Joseph Myers wrote: Then, do you mean that line-map falls under the reach of the diagnostics maintainer? I agree, but Dodji himself does not seem to be sure about this: I think we should consider it to be covered by diagnostics maintainers. That makes sense. Jason

Re: [PR c/52952] More precise locations within format strings

2014-11-10 Thread Joseph Myers
On Sat, 8 Nov 2014, Manuel López-Ibáñez wrote: > On 7 November 2014 22:39, Joseph Myers wrote: > >> Neither Per nor Tom are active in GCC anymore. If the FE maintainers > >> do not feel comfortable reviewing line-map changes, could you nominate > >> Dodji as line-map maintainer if he is willing t

Re: [PR c/52952] More precise locations within format strings

2014-11-09 Thread Jeff Law
On 11/08/14 02:20, Manuel López-Ibáñez wrote: On 7 November 2014 22:39, Joseph Myers wrote: Neither Per nor Tom are active in GCC anymore. If the FE maintainers do not feel comfortable reviewing line-map changes, could you nominate Dodji as line-map maintainer if he is willing to accept it? I t

Re: [PR c/52952] More precise locations within format strings

2014-11-08 Thread Manuel López-Ibáñez
On 7 November 2014 22:39, Joseph Myers wrote: >> Neither Per nor Tom are active in GCC anymore. If the FE maintainers >> do not feel comfortable reviewing line-map changes, could you nominate >> Dodji as line-map maintainer if he is willing to accept it? I think he >> is currently the person that

Re: [PR c/52952] More precise locations within format strings

2014-11-07 Thread Joseph Myers
On Fri, 7 Nov 2014, Manuel López-Ibáñez wrote: > Maybe I can open the file and re-parse the string to find the right > column. Of course, this will not work when reading stdin, but in that > case the behavior will be the same as currently. It will also allow me > to gracefully degrade in the case

Re: [PR c/52952] More precise locations within format strings

2014-11-07 Thread Manuel López-Ibáñez
On 7 November 2014 18:57, Joseph Myers wrote: > On Fri, 7 Nov 2014, Manuel López-Ibáñez wrote: > >> This patch allows format warnings to point within the format string >> for simple strings. There are a few limitations: >> >> * It does not handle 'const char *' because the location of the >> initi

Re: [PR c/52952] More precise locations within format strings

2014-11-07 Thread Joseph Myers
On Fri, 7 Nov 2014, Manuel López-Ibáñez wrote: > This patch allows format warnings to point within the format string > for simple strings. There are a few limitations: > > * It does not handle 'const char *' because the location of the > initializer is not available. The result is the same before

[PR c/52952] More precise locations within format strings

2014-11-07 Thread Manuel López-Ibáñez
This patch allows format warnings to point within the format string for simple strings. There are a few limitations: * It does not handle 'const char *' because the location of the initializer is not available. The result is the same before and after this patch. * It does not handle non-concatena