On Tue, Mar 6, 2018 at 12:42 AM, Alexandre Oliva wrote:
> On Mar 2, 2018, Jason Merrill wrote:
>
>> On Fri, Mar 2, 2018 at 2:57 AM, Alexandre Oliva wrote:
>>> + gcc_assert (TREE_CODE (type) == REFERENCE_TYPE);
>>> + init = fold (convert (type, integer_zero_node));
>
>> Maybe build_zer
On Mar 2, 2018, Jason Merrill wrote:
>> + gcc_assert (TREE_CODE (type) == REFERENCE_TYPE);
>> + init = fold (convert (type, integer_zero_node));
> Maybe build_zero_cst?
> OK either way.
Here's what I'm installing:
[PR c++/84593] ice on braced init
On Mar 2, 2018, Jason Merrill wrote:
> On Fri, Mar 2, 2018 at 2:57 AM, Alexandre Oliva wrote:
>> + gcc_assert (TREE_CODE (type) == REFERENCE_TYPE);
>> + init = fold (convert (type, integer_zero_node));
> Maybe build_zero_cst?
Sure.
I wonder, is there any reason to not change any o
l for a reference.
>
> Like this? Regstrapped on i686- and x86_64-linux-gnu.
>
> [PR c++/84593] ice on braced init with uninit ref field
>
> If an initializer expr is to be NULL in a ctor initializer list, we
> ICE in picflag_from_initializer and elsewhere.
>
> If we'r
ther. When there
> isn't an NSDMI to worry about, we zero-initialize the reference, and
> it seems reasonable to continue doing that, by fixing
> build_zero_init_1 to return something non-null for a reference.
Like this? Regstrapped on i686- and x86_64-linux-gnu.
[PR c++/84593] ice o
On Wed, Feb 28, 2018 at 7:08 AM, Alexandre Oliva wrote:
> Don't allow the initializer expr to be NULL in a ctor initializer
> list, make it error_marker_node instead.
I don't want error_mark_nodes in a CONSTRUCTOR, either. When there
isn't an NSDMI to worry about, we zero-initialize the referenc
Don't allow the initializer expr to be NULL in a ctor initializer
list, make it error_marker_node instead.
Regstrapped on x86_64- and i686-linux-gnu. Ok to install?
for gcc/cp/ChangeLog
PR c++/84593
* typeck2.c (process_init_constructor_record): Set NULL next
to error_m
