https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96058
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #6)
> Am I misreading it? What's mem_size?
Yes. See Martin L.'s comment, it is 10.1 release, so the line numbers are
slightly different from trunk or current 10 branch.
Obviously the two tree_to_uhwi calls guarded with tree_fits_uhwi_p can't be it,
but it is the third one.
tree eltype = TREE_TYPE (TREE_TYPE (src));
/* Support only properly NUL-terminated single byte strings. */
if (tree_to_uhwi (TYPE_SIZE_UNIT (eltype)) != 1)
return NULL;
And see #c5 on what it happens.
The string_constant code added in g:14b7950f126f doesn't try to verify that
chartype is some character or even integral type, nor whether it is a complete
type.
It actually doesn't seem correct even for wchar_t/char16_t/char32_t etc.,
because initsize is size in bytes. Nothing tries to verify tree_fits_uhwi_p
(initsize) and calls build_string_literal with the chartype and initsize
converted to uhwi.
Now, if initsize is HOST_WIDE_INT_M1U, it will do something different, and even
if not, build_string_literal assumes that the string has type chartype[size],
so whenever chartype is not a byte type, but 2/4/8 byte integer, the string
literal will have size that is twice/4/8 times larger type than desired.
