[Bug tree-optimization/96058] ICE in c_getstr at gcc/fold-const.c:15475

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.