On Tue, 2015-11-24 at 13:43 +0100, Bernd Schmidt wrote: > On 11/23/2015 07:26 PM, David Malcolm wrote: > > > > In theory we could attempt to try to handle this kind of thing by > > looking at the macro expansions, and to print something like: > > > > 13 TEST_EQ (fmin); > > ^~~~ > > 6 if ((long)FUNC##l(xl,xl) != (long)xl) \ > > ~~~~~~~~ > > > > or whatnot, but that strikes me as error-prone at this stage. > > Could I ask you to spend some time looking at what would be involved at > fixing it this way? In the end (assuming it doesn't prove to be a simple > fix) we will probably go with your original patch for gcc-6, but it > really goes against the grain to paper over a bug like this.
I've been looking into this. The first issue we run into is that, currently, when we pass location_t values into rich_location, it expands them immediately and stores the result, which is thus throwing away any information on virtual macro locations. The first patch in the attached kit fixes that, storing location_t values (aka source_location) within rich_location, delaying their expansion until inside diagnostic_show_locus. Doing so also simplifies the code. In writing the above patch I noticed now muddled the terminology has become (range vs location), so the second patch in the kit rewords things; I believe it makes the code much clearer. The third patch in the kit is the earlier workaround for the bug; as before it degrades diagnostic-printing to just print a caret for the awkward cases, rather than attempting to print a range. This should mean that we fallback to the gcc 5 behavior for these cases. I've also added some new test cases based on duplicates filed against the bug; they show a variety of interesting patterns that would have to be handled if we were to use the 1st patch to fix things "properly". I've added some TODO comments to the testcases to describe my thoughts on how a proper fix might print them. I've successfully bootstrapped®rtested the combination of the patch kit on x86_64-pc-linux-gnu; adds 17 PASS results to gcc.sum. OK for trunk for gcc 6? (as 3 separate commits, assuming they individually bootstrap®rtest) Thanks Dave
