------- 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.
