On Fri, Mar 24, 2023 at 06:11:44PM -0400, Jason Merrill wrote: > > When we touch this for COMPONENT_REF, shouldn't we then handle it as > > unary given that the second operand is FIELD_DECL and third/fourth > > will likely be NULL and even if not, aren't user expressions that should be > > inspected? > > So, instead of doing this do: > > case COMPONENT_REF: > > x = TREE_OPERAND (x, 0); > > writer = 0; > > goto restart; > > ? > > Is clearing 'writer' what we want, since an access to COMPONENT_REF is an > access to (a subobject of) its op0?
I've just mindlessly copied the unary op case. writer is set for pre/post increments and lhs of MODIFY_EXPR, and it is true that VIEW_CONVERT_EXPR doesn't clear it, but e.g. ARRAY_REF clears it for all operands. > Currently with the fix it takes <1s while gcc12 takes ~80s. Perfect. > PR c++/107163 > > gcc/c-family/ChangeLog: > > * c-common.cc (verify_tree): Don't use sequenced handling > for COMPONENT_REF. > > gcc/testsuite/ChangeLog: > > * g++.dg/template/recurse5.C: New test. LGTM, thanks. Maybe the testcase would be better as warn/Wsequence-point-5.C, dunno. Jakub