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

["manu at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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?