This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/82084] [5/6/7/8 Regression] ICE: constructing wstring with -O3
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 04 Sep 2017 10:12:41 +0000
- Subject: [Bug c++/82084] [5/6/7/8 Regression] ICE: constructing wstring with -O3
- Auto-submitted: auto-generated
- References: <bug-82084-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82084
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> The STRING_CST isn't handled by native_encode_string which is why it fails:
>
> static int
> native_encode_string (const_tree expr, unsigned char *ptr, int len, int off)
> {
> tree type = TREE_TYPE (expr);
> HOST_WIDE_INT total_bytes;
>
> if (TREE_CODE (type) != ARRAY_TYPE
> || TREE_CODE (TREE_TYPE (type)) != INTEGER_TYPE
> || (GET_MODE_BITSIZE (SCALAR_INT_TYPE_MODE (TREE_TYPE (type)))
> != BITS_PER_UNIT)
> || !tree_fits_shwi_p (TYPE_SIZE_UNIT (type)))
> return 0;
>
> not sure why it only handles byte-sized literals, possibly endianess
> related.
>
> Going to handle those like fixed-point support (build a tree int and
> encode that...).
I think the reason for not handling non-char strings is similar to why we don't
have wide printf/scanf format string handling etc., that there are no agreed
upon accessor for the elements of those strings. See
https://gcc.gnu.org/ml/gcc-patches/2001-12/msg01579.html and PR38308 and
PR20110.
I think the vectorizer should verify if the constant can be successfully folded
and punt if not, then whether we actually add support for the
wchar_t/uchar16_t/uchar32_t strings or not can be independent of that.