Hi, > On 7 Oct 2026, at 9:02 am, Iain Sandoe <[email protected]> wrote: > > The initial solution proposed and landed for 126811 was to avoid calling > tsubst on constructors (motivated by a similar scheme used for constructor > elements). The intent was to avoid recursing into these where they have > NSDMIs (or other content that contains expressions that tsubst does not > expect). The concern at the time was that to handle an arbitrary set of > such conditions in tsubst would be open-ended and hard to prove complete. > > However, the solution landed has just pushed that problem onto constexpr > handling and resulted in a number of reported regressions. Rather than > trying to fix these issues in constexpr, a rework of the patch for the > original (126811) problem deals with the cases in which tsubst is expected > to be visited by expressions already lowered. > > One specific expected case is when tsubst is called with NULL_TREE args > and is used explicitly to rewrite the tree. We also handle cases now > where the constructor tree contains a mixture of sub-trees that still > require substitution. > > In the final analysis the penalty for doing this in tsubst is small - > firstly the current set of excluded trees are (presumably) never reached > in current code (an absence of reports). The case that is reached is > actually guarded by 'checking' and therefore only enabled for trunk. We > can also short-circuit for the special case that the substitution is called > with null args - so that the original concern about complexity in tsubst > turned out to be somewhat unfounded. > > The patch reverts the change previously applied for 126811 so that we do > not reopen that regression at the same time. The combination of gating > on checking and that the current reporting conditions are not reached > should make this reasonable for fixing the 126811 regression on open > branches. > > My original testsuite additions were augmented with the assistance of an > LLM given the guidance that we should intend comprehensive coverage, > therefore they are partially LLM-generated. > > PR c++/126811 > PR c++/127395 > PR c++/127439 > PR c++/127573 > > gcc/cp/ChangeLog: > > * pt.cc (tsubst_expr): Allow for CONSTRUCTORS that may have a > mixture of lowered and to-be-substituted sub-trees. > * typeck2.cc (store_init_value): Revert the gating of tsubst > for CONSTRUCTOR trees.
Ping? This is affecting PyTorch builds with master as I posted in https://gcc.gnu.org/pipermail/gcc-patches/2026-October/735041.html Thanks, Kugan
