This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] Fix ICE in potential_constant_expression_1 (PR c++/83918)
- From: Jason Merrill <jason at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Nathan Sidwell <nathan at acm dot org>, David Malcolm <dmalcolm at redhat dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 22 Jan 2018 21:42:21 -0500
- Subject: Re: [C++ PATCH] Fix ICE in potential_constant_expression_1 (PR c++/83918)
- Authentication-results: sourceware.org; auth=none
- References: <20180118231315.GM2063@tucnak> <CADzB+2k5W6i+Pqjo1cCAbQQF9oJT8dChdWTLzwGc-UPjxTF=GA@mail.gmail.com> <20180122231449.GO2063@tucnak>
On Mon, Jan 22, 2018 at 6:14 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Jan 22, 2018 at 04:49:34PM -0500, Jason Merrill wrote:
>> On Thu, Jan 18, 2018 at 6:13 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > Before location wrappers were introduced, the potential_constant_expression_1
>> > assumption that a VIEW_CONVERT_EXPR must have non-NULL type was right,
>> > if it is a type dependent reinterpret cast, it would be
>> > REINTERPRET_CAST_EXPR instead.
>> >
>> > Location wrappers around decls can have NULL type, if the decl they wrap
>> > also has NULL type.
>>
>> Hmm, why would a decl have NULL type? Are we wrapping a CONST_DECL in
>> VIEW_CONVERT_EXPR? They should get NON_LVALUE_EXPR, since they aren't
>> lvalues (except the objc++ ones that have TREE_STATIC set).
>
> So, do you want following instead, if it passes bootstrap/regtest?
Looks good.
Jason