| Message ID | 27fd01d3b155$2bd767f0$838637d0$@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | Fix ICE caused by a missing check for DECL_LANG_SPECIFIC | expand |
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? diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index e07d77bb87e..f67080fc279 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -24641,7 +24641,8 @@ type_dependent_expression_p (tree expression) if (TREE_CODE (expression) == FUNCTION_DECL && !(DECL_CLASS_SCOPE_P (expression) && dependent_type_p (DECL_CONTEXT (expression))) - && !(DECL_FRIEND_P (expression) + && !(DECL_LANG_SPECIFIC (expression) + && DECL_FRIEND_P (expression) && (!DECL_FRIEND_CONTEXT (expression) || dependent_type_p (DECL_FRIEND_CONTEXT (expression)))) && !DECL_LOCAL_FUNCTION_P (expression))
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. Matthew
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
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)