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
On Mar 2, 2018, Jason Merrill <ja...@redhat.com> 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 bra
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,
ing
>> 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 on braced init with uninit ref field
>
> If an initializer expr is to be NULL in a ctor initializer list, we
> ICE in p
or_mark_nodes in a CONSTRUCTOR, either. 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-l
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
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