[RFC][PATCH] PR preprocessor/83173: Additional check before decrementing highest_location

Mike Gulick mgulick@mathworks.com
Wed Jan 24 05:17:00 GMT 2018



On 01/14/2018 12:16 PM, Mike Gulick wrote:
> On 01/12/2018 06:16 PM, David Malcolm wrote:
[snip]
>>
>> I was going to suggest renaming your new test to e.g.
>>   location-overflow-test-pr83173.c
>> so that it matches the glob in those comments, but given that you refer
>> to the testname in dg-final directives, please update the line-map.h
>> comments to refer to e.g. "all of testcases in gcc.dg/plugin that use
>> location_overflow_plugin.c.", or somesuch wording.
>>
> 
> If I'm going to modify location_overflow_plugin.c and reuse it for this PR, then
> it would make sense to rename the test and its accompanying helper files to your
> suggested naming as well.  The dg-final regexes will likely continue to work.
> 

I've attached an new version of the test patch that updates
location_overflow_plugin.c to use PLUGIN_PRAGMAS, and updates the test filenames
to be more consistent with the existing location-overflow-test-* tests.

[snip]

>>
>> If I'm reading your description in the PR right, this test case covers
>> the
>>   loc > LINE_MAP_MAX_LOCATION_WITH_COLS
>> case, but not the:
>>   loc <= LINE_MAP_MAX_LOCATION_WITH_COLS
>> case.
>>
>> Can the latter be done by re-using the testcase, but with a different
>> (or no) plugin argument?
>>
> 
> I haven't really poked too hard to try to find if there is any corruption of the
> line map occurring when loc <= LINE_MAP_MAX_LOCATION_WITH_COLS.  It is just a
> suspicion given the fact that this code is still decrementing
> line_table->highest_location in that case.  I would imagine this may result in
> corruption of the column number or range rather than the file name and line
> number.
>

I haven't been able to find any clear bugs in the gcc output when loc <=
LINE_MAP_MAX_LOCATION_WITH_COLS, but I'm not quite sure how this behavior, if
indeed incorrect, would manifest itself.  The original bug is only visible
(AFAIK) when running gcc with -E, as it results in incorrect file names and line
numbers in the preprocessed output.  If the file name and line number are
correct in this output (as they would be when loc <=
LINE_MAP_MAX_LOCATION_WITH_COLS), then everything will be fine when the .i file
is read back in.  I'm not sure if/how this bug can trigger any incorrect
behavior when not using -E (or -no-integrated-cpp).  Still, it does seem to me
that even when loc <= LINE_MAP_MAX_LOCATION_WITH_COLS, _cpp_stack_include() is
doing the wrong thing by decrementing pfile->line_table->highest_location when
CPP_INCREMENT_LINE was not called from _cpp_lex_direct().  I will think about
this a little more, and would value any insight you can offer.  There is some
more information about the details of what goes wrong in these functions in the
original bug report.

Thanks,
Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2-0001-PR-preprocessor-83173-New-test.patch
Type: text/x-patch
Size: 5591 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20180124/feea1d0e/attachment.bin>


More information about the Gcc-patches mailing list