* [PATCH] c++: fix ICE with sizeof in a template [PR112869] @ 2023-12-05 20:31 Marek Polacek 2023-12-08 17:09 ` Jason Merrill 0 siblings, 1 reply; 8+ messages in thread From: Marek Polacek @ 2023-12-05 20:31 UTC (permalink / raw) To: GCC Patches, Jason Merrill Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This test shows that we cannot clear *walk_subtrees in cp_fold_immediate_r when we're in_immediate_context, because that, as the comment says, affects cp_fold_r as well. Here we had an expression with min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr (int) <<< error >>> >>>) as its sub-expression, and we never evaluated that into min ((long int) bytecount, 4) so the SIZEOF_EXPR leaked into the middle end. (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that one should be OK.) PR c++/112869 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees for unevaluated operands. gcc/testsuite/ChangeLog: * g++.dg/template/sizeof18.C: New test. --- gcc/cp/cp-gimplify.cc | 8 ++------ gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ 2 files changed, 10 insertions(+), 6 deletions(-) create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc index 5abb91bbdd3..46c3eb91853 100644 --- a/gcc/cp/cp-gimplify.cc +++ b/gcc/cp/cp-gimplify.cc @@ -1177,13 +1177,9 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) ? tf_error : tf_none); const tree_code code = TREE_CODE (stmt); - /* No need to look into types or unevaluated operands. - NB: This affects cp_fold_r as well. */ + /* No need to look into types or unevaluated operands. */ if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) - { - *walk_subtrees = 0; - return NULL_TREE; - } + return NULL_TREE; tree decl = NULL_TREE; bool call_p = false; diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C new file mode 100644 index 00000000000..afba9946258 --- /dev/null +++ b/gcc/testsuite/g++.dg/template/sizeof18.C @@ -0,0 +1,8 @@ +// PR c++/112869 +// { dg-do compile } + +void min(long, long); +template <class T> void Binaryread(int &, T, unsigned long); +template <> void Binaryread(int &, float, unsigned long bytecount) { + min(bytecount, sizeof(int)); +} base-commit: 9c3a880feecf81c310b4ade210fbd7004c9aece7 -- 2.43.0 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] c++: fix ICE with sizeof in a template [PR112869] 2023-12-05 20:31 [PATCH] c++: fix ICE with sizeof in a template [PR112869] Marek Polacek @ 2023-12-08 17:09 ` Jason Merrill 2023-12-08 21:15 ` [PATCH v2] " Marek Polacek 0 siblings, 1 reply; 8+ messages in thread From: Jason Merrill @ 2023-12-08 17:09 UTC (permalink / raw) To: Marek Polacek, GCC Patches On 12/5/23 15:31, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > This test shows that we cannot clear *walk_subtrees in > cp_fold_immediate_r when we're in_immediate_context, because that, > as the comment says, affects cp_fold_r as well. Here we had an > expression with > > min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr > (int) <<< error >>> >>>) > > as its sub-expression, and we never evaluated that into > > min ((long int) bytecount, 4) > > so the SIZEOF_EXPR leaked into the middle end. > > (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that > one should be OK.) > > PR c++/112869 > > gcc/cp/ChangeLog: > > * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees > for unevaluated operands. I agree that we want this change for in_immediate_context (), but I don't see why we want it for TYPE_P or unevaluated_p (code) or cp_unevaluated_operand? > gcc/testsuite/ChangeLog: > > * g++.dg/template/sizeof18.C: New test. > --- > gcc/cp/cp-gimplify.cc | 8 ++------ > gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ > 2 files changed, 10 insertions(+), 6 deletions(-) > create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C > > diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc > index 5abb91bbdd3..46c3eb91853 100644 > --- a/gcc/cp/cp-gimplify.cc > +++ b/gcc/cp/cp-gimplify.cc > @@ -1177,13 +1177,9 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) > ? tf_error : tf_none); > const tree_code code = TREE_CODE (stmt); > > - /* No need to look into types or unevaluated operands. > - NB: This affects cp_fold_r as well. */ > + /* No need to look into types or unevaluated operands. */ > if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) > - { > - *walk_subtrees = 0; > - return NULL_TREE; > - } > + return NULL_TREE; > > tree decl = NULL_TREE; > bool call_p = false; > diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C > new file mode 100644 > index 00000000000..afba9946258 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/template/sizeof18.C > @@ -0,0 +1,8 @@ > +// PR c++/112869 > +// { dg-do compile } > + > +void min(long, long); > +template <class T> void Binaryread(int &, T, unsigned long); > +template <> void Binaryread(int &, float, unsigned long bytecount) { > + min(bytecount, sizeof(int)); > +} > > base-commit: 9c3a880feecf81c310b4ade210fbd7004c9aece7 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] c++: fix ICE with sizeof in a template [PR112869] 2023-12-08 17:09 ` Jason Merrill @ 2023-12-08 21:15 ` Marek Polacek 2023-12-09 4:09 ` Jason Merrill 0 siblings, 1 reply; 8+ messages in thread From: Marek Polacek @ 2023-12-08 21:15 UTC (permalink / raw) To: Jason Merrill; +Cc: GCC Patches On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote: > On 12/5/23 15:31, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > This test shows that we cannot clear *walk_subtrees in > > cp_fold_immediate_r when we're in_immediate_context, because that, > > as the comment says, affects cp_fold_r as well. Here we had an > > expression with > > > > min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr > > (int) <<< error >>> >>>) > > > > as its sub-expression, and we never evaluated that into > > > > min ((long int) bytecount, 4) > > > > so the SIZEOF_EXPR leaked into the middle end. > > > > (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that > > one should be OK.) > > > > PR c++/112869 > > > > gcc/cp/ChangeLog: > > > > * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees > > for unevaluated operands. > > I agree that we want this change for in_immediate_context (), but I don't > see why we want it for TYPE_P or unevaluated_p (code) or > cp_unevaluated_operand? No particular reason, just paranoia. How's this? Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This test shows that we cannot clear *walk_subtrees in cp_fold_immediate_r when we're in_immediate_context, because that, as the comment says, affects cp_fold_r as well. Here we had an expression with min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr (int) <<< error >>> >>>) as its sub-expression, and we never evaluated that into min ((long int) bytecount, 4) so the SIZEOF_EXPR leaked into the middle end. (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that one should be OK.) PR c++/112869 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees for in_immediate_context. gcc/testsuite/ChangeLog: * g++.dg/template/sizeof18.C: New test. --- gcc/cp/cp-gimplify.cc | 6 +++++- gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ 2 files changed, 13 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc index 5abb91bbdd3..6af7c787372 100644 --- a/gcc/cp/cp-gimplify.cc +++ b/gcc/cp/cp-gimplify.cc @@ -1179,11 +1179,15 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) /* No need to look into types or unevaluated operands. NB: This affects cp_fold_r as well. */ - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) + if (TYPE_P (stmt) || unevaluated_p (code)) { *walk_subtrees = 0; return NULL_TREE; } + else if (in_immediate_context ()) + /* Don't clear *walk_subtrees here: we still need to walk the subtrees + of SIZEOF_EXPR and similar. */ + return NULL_TREE; tree decl = NULL_TREE; bool call_p = false; diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C new file mode 100644 index 00000000000..afba9946258 --- /dev/null +++ b/gcc/testsuite/g++.dg/template/sizeof18.C @@ -0,0 +1,8 @@ +// PR c++/112869 +// { dg-do compile } + +void min(long, long); +template <class T> void Binaryread(int &, T, unsigned long); +template <> void Binaryread(int &, float, unsigned long bytecount) { + min(bytecount, sizeof(int)); +} base-commit: d468718c9a097aeb8794fb1a2df6db2c1064d7f7 -- 2.43.0 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] c++: fix ICE with sizeof in a template [PR112869] 2023-12-08 21:15 ` [PATCH v2] " Marek Polacek @ 2023-12-09 4:09 ` Jason Merrill 2023-12-12 22:48 ` [PATCH v3] " Marek Polacek 0 siblings, 1 reply; 8+ messages in thread From: Jason Merrill @ 2023-12-09 4:09 UTC (permalink / raw) To: Marek Polacek; +Cc: GCC Patches On 12/8/23 16:15, Marek Polacek wrote: > On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote: >> On 12/5/23 15:31, Marek Polacek wrote: >>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? >>> >>> -- >8 -- >>> This test shows that we cannot clear *walk_subtrees in >>> cp_fold_immediate_r when we're in_immediate_context, because that, >>> as the comment says, affects cp_fold_r as well. Here we had an >>> expression with >>> >>> min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr >>> (int) <<< error >>> >>>) >>> >>> as its sub-expression, and we never evaluated that into >>> >>> min ((long int) bytecount, 4) >>> >>> so the SIZEOF_EXPR leaked into the middle end. >>> >>> (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that >>> one should be OK.) >>> >>> PR c++/112869 >>> >>> gcc/cp/ChangeLog: >>> >>> * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees >>> for unevaluated operands. >> >> I agree that we want this change for in_immediate_context (), but I don't >> see why we want it for TYPE_P or unevaluated_p (code) or >> cp_unevaluated_operand? > > No particular reason, just paranoia. How's this? > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > This test shows that we cannot clear *walk_subtrees in > cp_fold_immediate_r when we're in_immediate_context, because that, > as the comment says, affects cp_fold_r as well. Here we had an > expression with > > min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr > (int) <<< error >>> >>>) > > as its sub-expression, and we never evaluated that into > > min ((long int) bytecount, 4) > > so the SIZEOF_EXPR leaked into the middle end. > > (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that > one should be OK.) > > PR c++/112869 > > gcc/cp/ChangeLog: > > * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees > for in_immediate_context. > > gcc/testsuite/ChangeLog: > > * g++.dg/template/sizeof18.C: New test. > --- > gcc/cp/cp-gimplify.cc | 6 +++++- > gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ > 2 files changed, 13 insertions(+), 1 deletion(-) > create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C > > diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc > index 5abb91bbdd3..6af7c787372 100644 > --- a/gcc/cp/cp-gimplify.cc > +++ b/gcc/cp/cp-gimplify.cc > @@ -1179,11 +1179,15 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) > > /* No need to look into types or unevaluated operands. > NB: This affects cp_fold_r as well. */ > - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) > + if (TYPE_P (stmt) || unevaluated_p (code)) > { > *walk_subtrees = 0; > return NULL_TREE; > } > + else if (in_immediate_context ()) > + /* Don't clear *walk_subtrees here: we still need to walk the subtrees > + of SIZEOF_EXPR and similar. */ > + return NULL_TREE; > > tree decl = NULL_TREE; > bool call_p = false; > diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C > new file mode 100644 > index 00000000000..afba9946258 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/template/sizeof18.C > @@ -0,0 +1,8 @@ > +// PR c++/112869 > +// { dg-do compile } > + > +void min(long, long); > +template <class T> void Binaryread(int &, T, unsigned long); > +template <> void Binaryread(int &, float, unsigned long bytecount) { > + min(bytecount, sizeof(int)); > +} Hmm, actually, why does the above make a difference for this testcase? ... It seems that in_immediate_context always returns true in cp_fold_function because current_binding_level->kind == sk_template_parms. That seems like a problem. Maybe for cp_fold_immediate_r we only want to check cp_unevaluated_operand or DECL_IMMEDIATE_CONTEXT (current_function_decl)? Jason ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v3] c++: fix ICE with sizeof in a template [PR112869] 2023-12-09 4:09 ` Jason Merrill @ 2023-12-12 22:48 ` Marek Polacek 2023-12-13 20:28 ` Jason Merrill 0 siblings, 1 reply; 8+ messages in thread From: Marek Polacek @ 2023-12-12 22:48 UTC (permalink / raw) To: Jason Merrill; +Cc: GCC Patches On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote: > On 12/8/23 16:15, Marek Polacek wrote: > > On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote: > > > On 12/5/23 15:31, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > > > -- >8 -- > > > > This test shows that we cannot clear *walk_subtrees in > > > > cp_fold_immediate_r when we're in_immediate_context, because that, > > > > as the comment says, affects cp_fold_r as well. Here we had an > > > > expression with > > > > > > > > min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr > > > > (int) <<< error >>> >>>) > > > > > > > > as its sub-expression, and we never evaluated that into > > > > > > > > min ((long int) bytecount, 4) > > > > > > > > so the SIZEOF_EXPR leaked into the middle end. > > > > > > > > (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that > > > > one should be OK.) > > > > > > > > PR c++/112869 > > > > > > > > gcc/cp/ChangeLog: > > > > > > > > * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees > > > > for unevaluated operands. > > > > > > I agree that we want this change for in_immediate_context (), but I don't > > > see why we want it for TYPE_P or unevaluated_p (code) or > > > cp_unevaluated_operand? > > > > No particular reason, just paranoia. How's this? > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > This test shows that we cannot clear *walk_subtrees in > > cp_fold_immediate_r when we're in_immediate_context, because that, > > as the comment says, affects cp_fold_r as well. Here we had an > > expression with > > > > min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr > > (int) <<< error >>> >>>) > > > > as its sub-expression, and we never evaluated that into > > > > min ((long int) bytecount, 4) > > > > so the SIZEOF_EXPR leaked into the middle end. > > > > (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that > > one should be OK.) > > > > PR c++/112869 > > > > gcc/cp/ChangeLog: > > > > * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees > > for in_immediate_context. > > > > gcc/testsuite/ChangeLog: > > > > * g++.dg/template/sizeof18.C: New test. > > --- > > gcc/cp/cp-gimplify.cc | 6 +++++- > > gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ > > 2 files changed, 13 insertions(+), 1 deletion(-) > > create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C > > > > diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc > > index 5abb91bbdd3..6af7c787372 100644 > > --- a/gcc/cp/cp-gimplify.cc > > +++ b/gcc/cp/cp-gimplify.cc > > @@ -1179,11 +1179,15 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) > > /* No need to look into types or unevaluated operands. > > NB: This affects cp_fold_r as well. */ > > - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) > > + if (TYPE_P (stmt) || unevaluated_p (code)) > > { > > *walk_subtrees = 0; > > return NULL_TREE; > > } > > + else if (in_immediate_context ()) > > + /* Don't clear *walk_subtrees here: we still need to walk the subtrees > > + of SIZEOF_EXPR and similar. */ > > + return NULL_TREE; > > tree decl = NULL_TREE; > > bool call_p = false; > > diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C > > new file mode 100644 > > index 00000000000..afba9946258 > > --- /dev/null > > +++ b/gcc/testsuite/g++.dg/template/sizeof18.C > > @@ -0,0 +1,8 @@ > > +// PR c++/112869 > > +// { dg-do compile } > > + > > +void min(long, long); > > +template <class T> void Binaryread(int &, T, unsigned long); > > +template <> void Binaryread(int &, float, unsigned long bytecount) { > > + min(bytecount, sizeof(int)); > > +} > > Hmm, actually, why does the above make a difference for this testcase? > > ... > > It seems that in_immediate_context always returns true in cp_fold_function > because current_binding_level->kind == sk_template_parms. That seems like a > problem. Maybe for cp_fold_immediate_r we only want to check > cp_unevaluated_operand or DECL_IMMEDIATE_CONTEXT (current_function_decl)? Yeah, I suppose that could become an issue. How about this, then? Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This test shows that we cannot clear *walk_subtrees in cp_fold_immediate_r when we're in_immediate_context, because that, as the comment says, affects cp_fold_r as well. Here we had an expression with min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr (int) <<< error >>> >>>) as its sub-expression, and we never evaluated that into min ((long int) bytecount, 4) so the SIZEOF_EXPR leaked into the middle end. (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that one should be OK.) PR c++/112869 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees in an unevaluated operand or immediate function. gcc/testsuite/ChangeLog: * g++.dg/template/sizeof18.C: New test. --- gcc/cp/cp-gimplify.cc | 8 +++++++- gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc index c307e1b62db..413ebafbd1a 100644 --- a/gcc/cp/cp-gimplify.cc +++ b/gcc/cp/cp-gimplify.cc @@ -1179,11 +1179,17 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) /* No need to look into types or unevaluated operands. NB: This affects cp_fold_r as well. */ - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) + if (TYPE_P (stmt) || unevaluated_p (code)) { *walk_subtrees = 0; return NULL_TREE; } + else if (cp_unevaluated_operand + || (current_function_decl + && DECL_IMMEDIATE_FUNCTION_P (current_function_decl))) + /* Don't clear *walk_subtrees here: we still need to walk the subtrees + of SIZEOF_EXPR and similar. */ + return NULL_TREE; tree decl = NULL_TREE; bool call_p = false; diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C new file mode 100644 index 00000000000..afba9946258 --- /dev/null +++ b/gcc/testsuite/g++.dg/template/sizeof18.C @@ -0,0 +1,8 @@ +// PR c++/112869 +// { dg-do compile } + +void min(long, long); +template <class T> void Binaryread(int &, T, unsigned long); +template <> void Binaryread(int &, float, unsigned long bytecount) { + min(bytecount, sizeof(int)); +} base-commit: cd7d0b4cf789264cd75ab7df5df232dc58061ed7 -- 2.43.0 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3] c++: fix ICE with sizeof in a template [PR112869] 2023-12-12 22:48 ` [PATCH v3] " Marek Polacek @ 2023-12-13 20:28 ` Jason Merrill 2023-12-14 21:01 ` [PATCH v4] " Marek Polacek 0 siblings, 1 reply; 8+ messages in thread From: Jason Merrill @ 2023-12-13 20:28 UTC (permalink / raw) To: Marek Polacek; +Cc: GCC Patches On 12/12/23 17:48, Marek Polacek wrote: > On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote: >> On 12/8/23 16:15, Marek Polacek wrote: >>> On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote: >>>> On 12/5/23 15:31, Marek Polacek wrote: >>>>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? >>>>> >>>>> -- >8 -- >>>>> This test shows that we cannot clear *walk_subtrees in >>>>> cp_fold_immediate_r when we're in_immediate_context, because that, >>>>> as the comment says, affects cp_fold_r as well. Here we had an >>>>> expression with >>>>> >>>>> min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr >>>>> (int) <<< error >>> >>>) >>>>> >>>>> as its sub-expression, and we never evaluated that into >>>>> >>>>> min ((long int) bytecount, 4) >>>>> >>>>> so the SIZEOF_EXPR leaked into the middle end. >>>>> >>>>> (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that >>>>> one should be OK.) >>>>> >>>>> PR c++/112869 >>>>> >>>>> gcc/cp/ChangeLog: >>>>> >>>>> * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees >>>>> for unevaluated operands. >>>> >>>> I agree that we want this change for in_immediate_context (), but I don't >>>> see why we want it for TYPE_P or unevaluated_p (code) or >>>> cp_unevaluated_operand? >>> >>> No particular reason, just paranoia. How's this? >>> >>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? >>> >>> -- >8 -- >>> This test shows that we cannot clear *walk_subtrees in >>> cp_fold_immediate_r when we're in_immediate_context, because that, >>> as the comment says, affects cp_fold_r as well. Here we had an >>> expression with >>> >>> min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr >>> (int) <<< error >>> >>>) >>> >>> as its sub-expression, and we never evaluated that into >>> >>> min ((long int) bytecount, 4) >>> >>> so the SIZEOF_EXPR leaked into the middle end. >>> >>> (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that >>> one should be OK.) >>> >>> PR c++/112869 >>> >>> gcc/cp/ChangeLog: >>> >>> * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees >>> for in_immediate_context. >>> >>> gcc/testsuite/ChangeLog: >>> >>> * g++.dg/template/sizeof18.C: New test. >>> --- >>> gcc/cp/cp-gimplify.cc | 6 +++++- >>> gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ >>> 2 files changed, 13 insertions(+), 1 deletion(-) >>> create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C >>> >>> diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc >>> index 5abb91bbdd3..6af7c787372 100644 >>> --- a/gcc/cp/cp-gimplify.cc >>> +++ b/gcc/cp/cp-gimplify.cc >>> @@ -1179,11 +1179,15 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) >>> /* No need to look into types or unevaluated operands. >>> NB: This affects cp_fold_r as well. */ >>> - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) >>> + if (TYPE_P (stmt) || unevaluated_p (code)) >>> { >>> *walk_subtrees = 0; >>> return NULL_TREE; >>> } >>> + else if (in_immediate_context ()) >>> + /* Don't clear *walk_subtrees here: we still need to walk the subtrees >>> + of SIZEOF_EXPR and similar. */ >>> + return NULL_TREE; >>> tree decl = NULL_TREE; >>> bool call_p = false; >>> diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C >>> new file mode 100644 >>> index 00000000000..afba9946258 >>> --- /dev/null >>> +++ b/gcc/testsuite/g++.dg/template/sizeof18.C >>> @@ -0,0 +1,8 @@ >>> +// PR c++/112869 >>> +// { dg-do compile } >>> + >>> +void min(long, long); >>> +template <class T> void Binaryread(int &, T, unsigned long); >>> +template <> void Binaryread(int &, float, unsigned long bytecount) { >>> + min(bytecount, sizeof(int)); >>> +} >> >> Hmm, actually, why does the above make a difference for this testcase? >> >> ... >> >> It seems that in_immediate_context always returns true in cp_fold_function >> because current_binding_level->kind == sk_template_parms. That seems like a >> problem. Maybe for cp_fold_immediate_r we only want to check >> cp_unevaluated_operand or DECL_IMMEDIATE_CONTEXT (current_function_decl)? > > Yeah, I suppose that could become an issue. How about this, then? > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > -- >8 -- > This test shows that we cannot clear *walk_subtrees in > cp_fold_immediate_r when we're in_immediate_context, because that, > as the comment says, affects cp_fold_r as well. Here we had an > expression with > > min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr > (int) <<< error >>> >>>) > > as its sub-expression, and we never evaluated that into > > min ((long int) bytecount, 4) > > so the SIZEOF_EXPR leaked into the middle end. > > (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that > one should be OK.) > > PR c++/112869 > > gcc/cp/ChangeLog: > > * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees > in an unevaluated operand or immediate function. > > gcc/testsuite/ChangeLog: > > * g++.dg/template/sizeof18.C: New test. > --- > gcc/cp/cp-gimplify.cc | 8 +++++++- > gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ > 2 files changed, 15 insertions(+), 1 deletion(-) > create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C > > diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc > index c307e1b62db..413ebafbd1a 100644 > --- a/gcc/cp/cp-gimplify.cc > +++ b/gcc/cp/cp-gimplify.cc > @@ -1179,11 +1179,17 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) > > /* No need to look into types or unevaluated operands. > NB: This affects cp_fold_r as well. */ > - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) > + if (TYPE_P (stmt) || unevaluated_p (code)) > { > *walk_subtrees = 0; > return NULL_TREE; > } > + else if (cp_unevaluated_operand > + || (current_function_decl > + && DECL_IMMEDIATE_FUNCTION_P (current_function_decl))) It should still be fine to clear *walk_subtrees in these cases; the problem I was talking about above was that in_immediate_context was returning true for all functions, not just consteval functions. I think the fix is not adding an else, but rather replacing the in_immediate_context call with "unevaluated or consteval cfun". > + /* Don't clear *walk_subtrees here: we still need to walk the subtrees > + of SIZEOF_EXPR and similar. */ We shouldn't need to walk subtrees of SIZEOF_EXPR or other unevaluated operands, they'll all get cp_folded away. The bug was that we weren't calling cp_fold on the SIZEOF_EXPR itself. Jason ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v4] c++: fix ICE with sizeof in a template [PR112869] 2023-12-13 20:28 ` Jason Merrill @ 2023-12-14 21:01 ` Marek Polacek 2023-12-14 21:04 ` Jason Merrill 0 siblings, 1 reply; 8+ messages in thread From: Marek Polacek @ 2023-12-14 21:01 UTC (permalink / raw) To: Jason Merrill; +Cc: GCC Patches On Wed, Dec 13, 2023 at 03:28:38PM -0500, Jason Merrill wrote: > On 12/12/23 17:48, Marek Polacek wrote: > > On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote: > > > On 12/8/23 16:15, Marek Polacek wrote: > > > > On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote: > > > > > On 12/5/23 15:31, Marek Polacek wrote: > > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > > > > > > > -- >8 -- > > > > > > This test shows that we cannot clear *walk_subtrees in > > > > > > cp_fold_immediate_r when we're in_immediate_context, because that, > > > > > > as the comment says, affects cp_fold_r as well. Here we had an > > > > > > expression with > > > > > > > > > > > > min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr > > > > > > (int) <<< error >>> >>>) > > > > > > > > > > > > as its sub-expression, and we never evaluated that into > > > > > > > > > > > > min ((long int) bytecount, 4) > > > > > > > > > > > > so the SIZEOF_EXPR leaked into the middle end. > > > > > > > > > > > > (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that > > > > > > one should be OK.) > > > > > > > > > > > > PR c++/112869 > > > > > > > > > > > > gcc/cp/ChangeLog: > > > > > > > > > > > > * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees > > > > > > for unevaluated operands. > > > > > > > > > > I agree that we want this change for in_immediate_context (), but I don't > > > > > see why we want it for TYPE_P or unevaluated_p (code) or > > > > > cp_unevaluated_operand? > > > > > > > > No particular reason, just paranoia. How's this? > > > > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > > > -- >8 -- > > > > This test shows that we cannot clear *walk_subtrees in > > > > cp_fold_immediate_r when we're in_immediate_context, because that, > > > > as the comment says, affects cp_fold_r as well. Here we had an > > > > expression with > > > > > > > > min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr > > > > (int) <<< error >>> >>>) > > > > > > > > as its sub-expression, and we never evaluated that into > > > > > > > > min ((long int) bytecount, 4) > > > > > > > > so the SIZEOF_EXPR leaked into the middle end. > > > > > > > > (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that > > > > one should be OK.) > > > > > > > > PR c++/112869 > > > > > > > > gcc/cp/ChangeLog: > > > > > > > > * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees > > > > for in_immediate_context. > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > * g++.dg/template/sizeof18.C: New test. > > > > --- > > > > gcc/cp/cp-gimplify.cc | 6 +++++- > > > > gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ > > > > 2 files changed, 13 insertions(+), 1 deletion(-) > > > > create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C > > > > > > > > diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc > > > > index 5abb91bbdd3..6af7c787372 100644 > > > > --- a/gcc/cp/cp-gimplify.cc > > > > +++ b/gcc/cp/cp-gimplify.cc > > > > @@ -1179,11 +1179,15 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) > > > > /* No need to look into types or unevaluated operands. > > > > NB: This affects cp_fold_r as well. */ > > > > - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) > > > > + if (TYPE_P (stmt) || unevaluated_p (code)) > > > > { > > > > *walk_subtrees = 0; > > > > return NULL_TREE; > > > > } > > > > + else if (in_immediate_context ()) > > > > + /* Don't clear *walk_subtrees here: we still need to walk the subtrees > > > > + of SIZEOF_EXPR and similar. */ > > > > + return NULL_TREE; > > > > tree decl = NULL_TREE; > > > > bool call_p = false; > > > > diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C > > > > new file mode 100644 > > > > index 00000000000..afba9946258 > > > > --- /dev/null > > > > +++ b/gcc/testsuite/g++.dg/template/sizeof18.C > > > > @@ -0,0 +1,8 @@ > > > > +// PR c++/112869 > > > > +// { dg-do compile } > > > > + > > > > +void min(long, long); > > > > +template <class T> void Binaryread(int &, T, unsigned long); > > > > +template <> void Binaryread(int &, float, unsigned long bytecount) { > > > > + min(bytecount, sizeof(int)); > > > > +} > > > > > > Hmm, actually, why does the above make a difference for this testcase? > > > > > > ... > > > > > > It seems that in_immediate_context always returns true in cp_fold_function > > > because current_binding_level->kind == sk_template_parms. That seems like a > > > problem. Maybe for cp_fold_immediate_r we only want to check > > > cp_unevaluated_operand or DECL_IMMEDIATE_CONTEXT (current_function_decl)? > > > > Yeah, I suppose that could become an issue. How about this, then? > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > > This test shows that we cannot clear *walk_subtrees in > > cp_fold_immediate_r when we're in_immediate_context, because that, > > as the comment says, affects cp_fold_r as well. Here we had an > > expression with > > > > min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr > > (int) <<< error >>> >>>) > > > > as its sub-expression, and we never evaluated that into > > > > min ((long int) bytecount, 4) > > > > so the SIZEOF_EXPR leaked into the middle end. > > > > (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that > > one should be OK.) > > > > PR c++/112869 > > > > gcc/cp/ChangeLog: > > > > * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees > > in an unevaluated operand or immediate function. > > > > gcc/testsuite/ChangeLog: > > > > * g++.dg/template/sizeof18.C: New test. > > --- > > gcc/cp/cp-gimplify.cc | 8 +++++++- > > gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ > > 2 files changed, 15 insertions(+), 1 deletion(-) > > create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C > > > > diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc > > index c307e1b62db..413ebafbd1a 100644 > > --- a/gcc/cp/cp-gimplify.cc > > +++ b/gcc/cp/cp-gimplify.cc > > @@ -1179,11 +1179,17 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) > > /* No need to look into types or unevaluated operands. > > NB: This affects cp_fold_r as well. */ > > - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) > > + if (TYPE_P (stmt) || unevaluated_p (code)) > > { > > *walk_subtrees = 0; > > return NULL_TREE; > > } > > + else if (cp_unevaluated_operand > > + || (current_function_decl > > + && DECL_IMMEDIATE_FUNCTION_P (current_function_decl))) > > It should still be fine to clear *walk_subtrees in these cases; the problem > I was talking about above was that in_immediate_context was returning true > for all functions, not just consteval functions. > > I think the fix is not adding an else, but rather replacing the > in_immediate_context call with "unevaluated or consteval cfun". Aha, sorry, I misunderstood what you meant. > > + /* Don't clear *walk_subtrees here: we still need to walk the subtrees > > + of SIZEOF_EXPR and similar. */ > > We shouldn't need to walk subtrees of SIZEOF_EXPR or other unevaluated > operands, they'll all get cp_folded away. The bug was that we weren't > calling cp_fold on the SIZEOF_EXPR itself. Yes. I suppose the comment should have read "because of SIZEOF_EXPR". Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This test shows that we cannot clear *walk_subtrees in cp_fold_immediate_r when we're in_immediate_context, because that checks even e.g. sk_template_parms, and, as the comment says, affects cp_fold_r as well. Here we had an expression with min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr (int) <<< error >>> >>>) as its sub-expression, and we never evaluated that into min ((long int) bytecount, 4) so the SIZEOF_EXPR leaked into the middle end. We need to make sure we are calling cp_fold on the SIZEOF_EXPR. PR c++/112869 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold_immediate_r): Check cp_unevaluated_operand and DECL_IMMEDIATE_FUNCTION_P rather than in_immediate_context. gcc/testsuite/ChangeLog: * g++.dg/template/sizeof18.C: New test. --- gcc/cp/cp-gimplify.cc | 8 +++++++- gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc index c307e1b62db..64049f4154e 100644 --- a/gcc/cp/cp-gimplify.cc +++ b/gcc/cp/cp-gimplify.cc @@ -1179,7 +1179,13 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) /* No need to look into types or unevaluated operands. NB: This affects cp_fold_r as well. */ - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) + if (TYPE_P (stmt) + || unevaluated_p (code) + /* We do not use in_immediate_context here because it checks + more than is desirable, e.g., sk_template_parms. */ + || cp_unevaluated_operand + || (current_function_decl + && DECL_IMMEDIATE_FUNCTION_P (current_function_decl))) { *walk_subtrees = 0; return NULL_TREE; diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C new file mode 100644 index 00000000000..afba9946258 --- /dev/null +++ b/gcc/testsuite/g++.dg/template/sizeof18.C @@ -0,0 +1,8 @@ +// PR c++/112869 +// { dg-do compile } + +void min(long, long); +template <class T> void Binaryread(int &, T, unsigned long); +template <> void Binaryread(int &, float, unsigned long bytecount) { + min(bytecount, sizeof(int)); +} base-commit: 83088b331cde0843d65d316e554873ef6d7b6bca -- 2.43.0 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4] c++: fix ICE with sizeof in a template [PR112869] 2023-12-14 21:01 ` [PATCH v4] " Marek Polacek @ 2023-12-14 21:04 ` Jason Merrill 0 siblings, 0 replies; 8+ messages in thread From: Jason Merrill @ 2023-12-14 21:04 UTC (permalink / raw) To: Marek Polacek; +Cc: GCC Patches On 12/14/23 16:01, Marek Polacek wrote: > On Wed, Dec 13, 2023 at 03:28:38PM -0500, Jason Merrill wrote: >> On 12/12/23 17:48, Marek Polacek wrote: >>> On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote: >>>> On 12/8/23 16:15, Marek Polacek wrote: >>>>> On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote: >>>>>> On 12/5/23 15:31, Marek Polacek wrote: >>>>>>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? >>>>>>> >>>>>>> -- >8 -- >>>>>>> This test shows that we cannot clear *walk_subtrees in >>>>>>> cp_fold_immediate_r when we're in_immediate_context, because that, >>>>>>> as the comment says, affects cp_fold_r as well. Here we had an >>>>>>> expression with >>>>>>> >>>>>>> min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr >>>>>>> (int) <<< error >>> >>>) >>>>>>> >>>>>>> as its sub-expression, and we never evaluated that into >>>>>>> >>>>>>> min ((long int) bytecount, 4) >>>>>>> >>>>>>> so the SIZEOF_EXPR leaked into the middle end. >>>>>>> >>>>>>> (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that >>>>>>> one should be OK.) >>>>>>> >>>>>>> PR c++/112869 >>>>>>> >>>>>>> gcc/cp/ChangeLog: >>>>>>> >>>>>>> * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees >>>>>>> for unevaluated operands. >>>>>> >>>>>> I agree that we want this change for in_immediate_context (), but I don't >>>>>> see why we want it for TYPE_P or unevaluated_p (code) or >>>>>> cp_unevaluated_operand? >>>>> >>>>> No particular reason, just paranoia. How's this? >>>>> >>>>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? >>>>> >>>>> -- >8 -- >>>>> This test shows that we cannot clear *walk_subtrees in >>>>> cp_fold_immediate_r when we're in_immediate_context, because that, >>>>> as the comment says, affects cp_fold_r as well. Here we had an >>>>> expression with >>>>> >>>>> min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr >>>>> (int) <<< error >>> >>>) >>>>> >>>>> as its sub-expression, and we never evaluated that into >>>>> >>>>> min ((long int) bytecount, 4) >>>>> >>>>> so the SIZEOF_EXPR leaked into the middle end. >>>>> >>>>> (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that >>>>> one should be OK.) >>>>> >>>>> PR c++/112869 >>>>> >>>>> gcc/cp/ChangeLog: >>>>> >>>>> * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees >>>>> for in_immediate_context. >>>>> >>>>> gcc/testsuite/ChangeLog: >>>>> >>>>> * g++.dg/template/sizeof18.C: New test. >>>>> --- >>>>> gcc/cp/cp-gimplify.cc | 6 +++++- >>>>> gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ >>>>> 2 files changed, 13 insertions(+), 1 deletion(-) >>>>> create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C >>>>> >>>>> diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc >>>>> index 5abb91bbdd3..6af7c787372 100644 >>>>> --- a/gcc/cp/cp-gimplify.cc >>>>> +++ b/gcc/cp/cp-gimplify.cc >>>>> @@ -1179,11 +1179,15 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) >>>>> /* No need to look into types or unevaluated operands. >>>>> NB: This affects cp_fold_r as well. */ >>>>> - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) >>>>> + if (TYPE_P (stmt) || unevaluated_p (code)) >>>>> { >>>>> *walk_subtrees = 0; >>>>> return NULL_TREE; >>>>> } >>>>> + else if (in_immediate_context ()) >>>>> + /* Don't clear *walk_subtrees here: we still need to walk the subtrees >>>>> + of SIZEOF_EXPR and similar. */ >>>>> + return NULL_TREE; >>>>> tree decl = NULL_TREE; >>>>> bool call_p = false; >>>>> diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C >>>>> new file mode 100644 >>>>> index 00000000000..afba9946258 >>>>> --- /dev/null >>>>> +++ b/gcc/testsuite/g++.dg/template/sizeof18.C >>>>> @@ -0,0 +1,8 @@ >>>>> +// PR c++/112869 >>>>> +// { dg-do compile } >>>>> + >>>>> +void min(long, long); >>>>> +template <class T> void Binaryread(int &, T, unsigned long); >>>>> +template <> void Binaryread(int &, float, unsigned long bytecount) { >>>>> + min(bytecount, sizeof(int)); >>>>> +} >>>> >>>> Hmm, actually, why does the above make a difference for this testcase? >>>> >>>> ... >>>> >>>> It seems that in_immediate_context always returns true in cp_fold_function >>>> because current_binding_level->kind == sk_template_parms. That seems like a >>>> problem. Maybe for cp_fold_immediate_r we only want to check >>>> cp_unevaluated_operand or DECL_IMMEDIATE_CONTEXT (current_function_decl)? >>> >>> Yeah, I suppose that could become an issue. How about this, then? >>> >>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? >>> -- >8 -- >>> This test shows that we cannot clear *walk_subtrees in >>> cp_fold_immediate_r when we're in_immediate_context, because that, >>> as the comment says, affects cp_fold_r as well. Here we had an >>> expression with >>> >>> min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr >>> (int) <<< error >>> >>>) >>> >>> as its sub-expression, and we never evaluated that into >>> >>> min ((long int) bytecount, 4) >>> >>> so the SIZEOF_EXPR leaked into the middle end. >>> >>> (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that >>> one should be OK.) >>> >>> PR c++/112869 >>> >>> gcc/cp/ChangeLog: >>> >>> * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees >>> in an unevaluated operand or immediate function. >>> >>> gcc/testsuite/ChangeLog: >>> >>> * g++.dg/template/sizeof18.C: New test. >>> --- >>> gcc/cp/cp-gimplify.cc | 8 +++++++- >>> gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ >>> 2 files changed, 15 insertions(+), 1 deletion(-) >>> create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C >>> >>> diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc >>> index c307e1b62db..413ebafbd1a 100644 >>> --- a/gcc/cp/cp-gimplify.cc >>> +++ b/gcc/cp/cp-gimplify.cc >>> @@ -1179,11 +1179,17 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) >>> /* No need to look into types or unevaluated operands. >>> NB: This affects cp_fold_r as well. */ >>> - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) >>> + if (TYPE_P (stmt) || unevaluated_p (code)) >>> { >>> *walk_subtrees = 0; >>> return NULL_TREE; >>> } >>> + else if (cp_unevaluated_operand >>> + || (current_function_decl >>> + && DECL_IMMEDIATE_FUNCTION_P (current_function_decl))) >> >> It should still be fine to clear *walk_subtrees in these cases; the problem >> I was talking about above was that in_immediate_context was returning true >> for all functions, not just consteval functions. >> >> I think the fix is not adding an else, but rather replacing the >> in_immediate_context call with "unevaluated or consteval cfun". > > Aha, sorry, I misunderstood what you meant. > >>> + /* Don't clear *walk_subtrees here: we still need to walk the subtrees >>> + of SIZEOF_EXPR and similar. */ >> >> We shouldn't need to walk subtrees of SIZEOF_EXPR or other unevaluated >> operands, they'll all get cp_folded away. The bug was that we weren't >> calling cp_fold on the SIZEOF_EXPR itself. > > Yes. I suppose the comment should have read "because of SIZEOF_EXPR". > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK, thanks. > -- >8 -- > This test shows that we cannot clear *walk_subtrees in > cp_fold_immediate_r when we're in_immediate_context, because that > checks even e.g. sk_template_parms, and, as the comment says, affects > cp_fold_r as well. Here we had an expression with > > min ((long int) VIEW_CONVERT_EXPR<long unsigned int>(bytecount), (long int) <<< Unknown tree: sizeof_expr > (int) <<< error >>> >>>) > > as its sub-expression, and we never evaluated that into > > min ((long int) bytecount, 4) > > so the SIZEOF_EXPR leaked into the middle end. We need to make sure > we are calling cp_fold on the SIZEOF_EXPR. > > PR c++/112869 > > gcc/cp/ChangeLog: > > * cp-gimplify.cc (cp_fold_immediate_r): Check cp_unevaluated_operand > and DECL_IMMEDIATE_FUNCTION_P rather than in_immediate_context. > > gcc/testsuite/ChangeLog: > > * g++.dg/template/sizeof18.C: New test. > --- > gcc/cp/cp-gimplify.cc | 8 +++++++- > gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ > 2 files changed, 15 insertions(+), 1 deletion(-) > create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C > > diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc > index c307e1b62db..64049f4154e 100644 > --- a/gcc/cp/cp-gimplify.cc > +++ b/gcc/cp/cp-gimplify.cc > @@ -1179,7 +1179,13 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) > > /* No need to look into types or unevaluated operands. > NB: This affects cp_fold_r as well. */ > - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) > + if (TYPE_P (stmt) > + || unevaluated_p (code) > + /* We do not use in_immediate_context here because it checks > + more than is desirable, e.g., sk_template_parms. */ > + || cp_unevaluated_operand > + || (current_function_decl > + && DECL_IMMEDIATE_FUNCTION_P (current_function_decl))) > { > *walk_subtrees = 0; > return NULL_TREE; > diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C > new file mode 100644 > index 00000000000..afba9946258 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/template/sizeof18.C > @@ -0,0 +1,8 @@ > +// PR c++/112869 > +// { dg-do compile } > + > +void min(long, long); > +template <class T> void Binaryread(int &, T, unsigned long); > +template <> void Binaryread(int &, float, unsigned long bytecount) { > + min(bytecount, sizeof(int)); > +} > > base-commit: 83088b331cde0843d65d316e554873ef6d7b6bca ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-12-14 21:04 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-12-05 20:31 [PATCH] c++: fix ICE with sizeof in a template [PR112869] Marek Polacek 2023-12-08 17:09 ` Jason Merrill 2023-12-08 21:15 ` [PATCH v2] " Marek Polacek 2023-12-09 4:09 ` Jason Merrill 2023-12-12 22:48 ` [PATCH v3] " Marek Polacek 2023-12-13 20:28 ` Jason Merrill 2023-12-14 21:01 ` [PATCH v4] " Marek Polacek 2023-12-14 21:04 ` Jason Merrill
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).