This is the mail archive of the
mailing list for the GCC project.
Re: Need help debugging likely g++ preprocessor bug
- From: Mike Gulick <mike dot gulick at mathworks dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: gcc-help <gcc-help at gcc dot gnu dot org>
- Date: Sun, 26 Nov 2017 21:39:41 -0500
- Subject: Re: Need help debugging likely g++ preprocessor bug
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mike dot Gulick at mathworks dot com;
- References: <email@example.com> <CAH6eHdQbsJ6+vQZAT-3A8WvPAq7jQ1qo+RKYsqkad=u=pU=Byw@mail.gmail.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 11/23/2017 07:33 AM, Jonathan Wakely wrote:
> On 22 Nov 2017 11:41 p.m., "Mike Gulick" wrote:
>> I have tried looking at this in gdb for quite a few days, but I haven't found
>> any definitive answers. The one possible clue is that I have noticed that the
>> source_location numbers in use are close to LINE_MAP_MAX_LOCATION_WITH_COLS
>> (0x60000000). E.g. I am seeing source locations in the debugger of 1610043911
>> (0x5FF75207). In other examples, I am seeing source locations just over this
>> I would greatly appreciate suggestions for debugging this issue further. I have
>> been looking at it for over a week and am hitting a bit of a wall.
> Are there any odd characters in the headers, specifically
> carriage-returns (i.e. DOS line-endings) or maybe some Unicode space
> characters that aren't whitespace in ASCII?
There may be, but unfortunately this doesn't look to be relevant. See my next
> It's certainly possible you've hit some edge case and the linemap is
> being corrupted. If you add the -v option to your gcc commands you'll
> see the cc1plus command that's being run, and then you can run that
> command under valgrind to see if there are any errors shown.
> Alternatively, rebuild GCC after configuring it with the
> --enable-checking=valgrind option, which will build GCC with valgrind
> debugging built-in. That build of GCC will run very slowly, but using
> it on your source code will check for any uninitialized reads/writes
> or other memory bugs that could be the cause of what you're seeing.
Thanks for the suggestion. I did initially try creating a valgrind build of gcc
7.2 and ran it under valgrind as documented in the gcc wiki, but it did not
report any issues.
I still haven't had any success trying to track down the source of the issue in
the debugger. However I did have success in creating a simple reproduction
case. This bug *is* dependent on crossing over LINE_MAP_MAX_LOCATION_WITH_COLS,
so the reproducer includes a simple gcc plugin that sets the line map's
highest_location field before the preprocessor runs. I have created bug 83173
and have attached the reproduction source code to that bug.