https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112965
--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
In c-parser.cc's consider_macro:
1843 pretty_printer pp;
1844 pp_string (&pp, (const char *) tok.val.str.text);
1845 pp_newline (&pp);
1846 cpp_push_buffer (parse_in,
1847 (const unsigned char *) pp_formatted_text (&pp),
1848 strlen (pp_formatted_text (&pp)),
1849 0);
(gdb) p pp_formatted_text (&pp)
$10 = 0x5782360 "3\n"
(gdb) p (size_t)strlen(pp_formatted_text (&pp))
$11 = 2
So we have an aligned buffer, but it's only 2 bytes long aka 3 bytes in size
i.e.:
['3', '\n', '\0']
Looking at lex.cc's search_line_sse42:
424 uintptr_t si = (uintptr_t)s;
425 uintptr_t index;
426
427 /* Check for unaligned input. */
428 if (si & 15)
429 {
430 v16qi sv;
431
432 if (__builtin_expect (end - s < 16, 0)
433 && __builtin_expect ((si & 0xfff) > 0xff0, 0))
434 {
435 /* There are less than 16 bytes left in the buffer, and less
436 than 16 bytes left on the page. Reading 16 bytes at this
437 point might generate a spurious page fault. Defer to the
438 SSE2 implementation, which already handles alignment. */
439 return search_line_sse2 (s, end);
440 }
we skip the block starting at line 429, since it's aligned:
(gdb) p ((uintptr_t)s) & 15
$14 = 0
but the length is so short that we presumably don't want to read 16 bytes at a
time:
(gdb) p end - s
$15 = 2
Not sure if this is a false positive, or a bug in search_line_sse42 when
dealing with very short aligned buffers.
