[Bug c++/18384] [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer...
------- Additional Comments From mark at codesourcery dot com 2004-12-27 20:19 -------
Subject: Re: [3.3/3.4/4.0 Regression] ICE on zero-length array
with empty initializer...
jakub at gcc dot gnu dot org wrote:
> ------- Additional Comments From jakub at gcc dot gnu dot org 2004-12-27 20:15 -------
> Created an attachment (id=7831)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7831&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7831&action=view)
> New patch
>
> Regarding max_index, I have removed the if (!TYPE_IS_TYPESIZE (max_index))
> gcc_unreachable (); part. I still think it is useful to first check for
> host_integerp (, 1), as that's the common case and we don't need to create
> any new trees in that case.
Agreed.
> As for designated_index, this differs between 3.3 and 3.4+ it seems.
> With GCC 3.3, reshape_init_array can see arbitrary trees in TREE_PURPOSE (),
> checking of these happens afterwards, not before reshape_init. So I think we
> certainly want a host_integerp (, 1) there, that will ensure it is an
> INTEGER_CST and not negative. In GCC 3.4 and HEAD, it seems the new parser
> doesn't parse
> [4] = X nor [4] X style array designated initializers at all, so we IMHO either
> can do what will be done in GCC 3.3 too, or remove the designated_index
> handling
> altoghether and replace with gcc_assert (!TREE_PURPOSE (element_init)).
3.3 is up to Gaby. For 3.4/mainline, let's do as you suggest and just
add the assertion. We'll fix it when (if?) we add that extension back
to G++. (It was removed because it basically didn't work.)
Patch OK.
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Reply to: