On Wed, 10 Apr 2024, Jakub Jelinek wrote: > On Wed, Apr 10, 2024 at 06:43:02PM +0200, Richard Biener wrote: > > The following fixes a mismatch in COMPOUND_EXPR handling in > > tsubst_expr vs tsubst_stmt where the latter allows a stmt in > > operand zero but the former doesn't. This makes a difference > > for the case at hand because when the COMPOUND_EXPR is wrapped > > inside an ANNOTATE_EXPR it gets handled by tsubst_expr and when > > not, tsubst_stmt successfully handles it and the contained > > DECL_EXPR in operand zero. > > > > The following makes handling of COMPOUND_EXPR in tsubst_expr > > consistent with that of tsubst_stmt for the operand that doesn't > > specify the result and thus the reason we choose either or the > > other for substing. > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK? > > > > Thanks, > > Richard. > > > > PR c++/114409 > > gcc/cp/ > > * pt.cc (tsubst_expr): Recurse to COMPOUND_EXPR operand > > zero using tsubst_stmt, when that returns NULL return > > the subst operand one, mimicing what tsubst_stmt does. > > > > gcc/testsuite/ > > * g++.dg/pr114409.C: New testcase. > > I've posted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409#c16 > for this already and Jason agreed to that version, so I just have to test it > tonight: > https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649165.html
Ah, I saw the bugzilla patches and wanted this version to be sent because I think the COMPOUND_EXPR inconsistency is odd. So Jason, please still have a look, not necessarily because of the bug which can be fixed in multiple ways but because of that COMPOUND_EXPR handling oddity (there are already some cases in tsubst_expr that explicitly recurse with tsubst_stmt). Richard. -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
