Re: [PATCH] Fix ICE caused by a missing check for DECL_LANG_SPECIFIC

[Jason Merrill <jason@redhat.com>]

On Fri, Mar 2, 2018 at 8:25 AM, Matthew Fortune <mfortune@gmail.com> wrote:
> Jason Merrill <jason@redhat.com> writes:
>> On Thu, Mar 1, 2018 at 7:02 AM, Matthew Fortune <mfortune@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > It seems we have had a bug for some time that causes an ICE and
>> prevents the
>> > MIPS16 library builds from completing but is likely unrelated to
>> MIPS16.
>> > The problem is when we call target_reinit and library functions get
>> created
>> > as shown in the call stack at the end of this message. The first
>> builtin
>> > that triggers the problem happens to be one of the MIPS16 helpers but
>> I
>> > don't think there is anything unique about it. The issue appeared
>> after some
>> > refactoring work in r253600 where code testing DECL_CLASS_SCOPE_P and
>> > DECL_FRIEND_P was previously guarded by a check for
>> DECL_LANG_SPECIFIC but
>> > not after.
>> >
>> > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00604.html
>> >
>> > I don’t know if this is the correct solution or whether we need to
>> change the
>> > way builtins are initialised in the MIPS backend but I suspect this
>> fix
>> > is the right way to go.
>> >
>> > Cc: Jason as author of the original change.
>> >
>> > Thanks,
>> > Matthew
>> >
>> > gcc/cp/
>> >         * pt.c (type_dependent_expression_p): Add missing check for
>> >         DECL_LANG_SPECIFIC.
>> > ---
>> >  gcc/cp/pt.c | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
>> > index 7345119..c88304f 100644
>> > --- a/gcc/cp/pt.c
>> > +++ b/gcc/cp/pt.c
>> > @@ -24635,6 +24635,7 @@ type_dependent_expression_p (tree expression)
>> >       type-dependent.  Checking this is important for functions with
>> auto return
>> >       type, which looks like a dependent type.  */
>> >    if (TREE_CODE (expression) == FUNCTION_DECL
>> > +      && DECL_LANG_SPECIFIC (expression)
>> >        && !(DECL_CLASS_SCOPE_P (expression)
>> >            && dependent_type_p (DECL_CONTEXT (expression)))
>> >        && !(DECL_FRIEND_P (expression)
>>
>> I think we want to go into this block when DECL_LANG_SPECIFIC is NULL.
>> Does this also fix the issue for you?
>
> Thanks. Yes, this fixes it too. I wasn't sure which of the accessors were
> dependent on DECL_LANG_SPECIFIC so ended up with a sledgehammer.

Applied.

Jason