This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR c++/84593] ice on braced init with uninit ref field
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 06 Mar 2018 02:42:36 -0300
- Subject: Re: [PR c++/84593] ice on braced init with uninit ref field
- Authentication-results: sourceware.org; auth=none
- References: <orbmg9pb95.fsf@lxoliva.fsfla.org> <CADzB+2n-9O4WFpoDz=6ZbOEE=GyE6P+xkKThcY+XMaeoLJrNyA@mail.gmail.com> <ork1uux63f.fsf@lxoliva.fsfla.org> <CADzB+2mKBW0ZCS2NKoQE+8exW+EKYWM5GesZrajaJnNRJe_+uA@mail.gmail.com>
On Mar 2, 2018, Jason Merrill <jason@redhat.com> wrote:
> On Fri, Mar 2, 2018 at 2:57 AM, Alexandre Oliva <aoliva@redhat.com> 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 of these to use
build_zero_cst, too?
else if (TYPE_PTR_OR_PTRMEM_P (type))
init = fold (convert (type, nullptr_node));
else if (SCALAR_TYPE_P (type))
init = fold (convert (type, integer_zero_node));
I suppose pointers to members might need an explicit conversion, which
build_zero_cst might fallback to if it doesn't consider them aggregate
types. As for scalar types, are there any C++-specific scalar types
that build_zero_cst wouldn't know how to deal with? Anyway, it's
probably not the time to change these, if it doesn't fix a regression.
Just curious.
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer