https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79210
--- Comment #9 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Origin of the garbage location_t value:
During macro expansion, temporary tokens (via _cpp_temp_token) use the location
of the last lexed token as their location, so identifying the origin of the
bogus location_t value requires some tracing back through a series of temporary
tokens. The easier way to do it was to put an assertion into
linemap_position_for_column to detect where the bogus value is generated:
diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index cf7c110..021059c 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -195,6 +195,11 @@ get_combined_adhoc_loc (struct line_maps *set,
{
source_location packed = locus | col_diff;
set->num_optimized_ranges++;
+
+ /* What leads to this bogus value? */
+ if (0)
+ linemap_assert (packed != 229843);
+
return packed;
}
}
The bogus location_t value arises when a cpp_token for the CPP_NAME
"lpfc_peer_port_login" is generated, due to:
#define LPFC_VPORT_ATTR_R(name, desc) \
unsigned int lpfc_##name;\
^~~~~
first part
LPFC_VPORT_ATTR_R(peer_port_login,
^~~~~~~~~~~~~~~
second part
and there isn't a way of representing this split location as a location_t.
In fact, it generates an entirely bogus location for the token:
line_table: entering: void paste_all_tokens(cpp_reader*, const cpp_token*)
line_table: entering: bool paste_tokens(cpp_reader*, source_location, const
cpp_token**, const cpp_token*)
line_table: *plhs: lpfc_
../../src/pr79210-via-attachment.c:13:14: note: 209764
unsigned int lpfc_##name;\
^~~~~
line_table: rhs: peer_port_login
../../src/pr79210-via-attachment.c:16:19: note: 222222
LPFC_VPORT_ATTR_R(peer_port_login,
^~~~~~~~~~~~~~~
line_table: entering: cpp_token* _cpp_lex_direct(cpp_reader*)
line_table: entering: source_location
linemap_position_for_column(line_maps*, unsigned int)
line_table: to_column: 1
line_table: returning: 229824
../../src/pr79210-via-attachment.c:18:1: note: 229824
"other.");
^
line_table: exiting: source_location
linemap_position_for_column(line_maps*, unsigned int)
line_table: entering: source_location
linemap_position_for_column(line_maps*, unsigned int)
line_table: to_column: 20
line_table: returning: 230432
../../src/pr79210-via-attachment.c:18:20: note: 230432
"other.");
^
line_table: exiting: source_location
linemap_position_for_column(line_maps*, unsigned int)
paste_tokens takes a pair of tokens, combines the text into a temporary buffer,
and calls _cpp_lex_direct on that temporary buffer.
Hence the start and finish locations for the resulting pasted token is insane:
it takes the line information from the last parsed line in the line table, and
uses the buffer length for the column number.
Subsequent temporary tokens (including the stringified name) "inherit" this
bogus location.
