On Thu, Mar 23, 2023 at 04:35:07PM -0400, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu. Jakub, does this make sense to you? Do we have a
> way of testing for compile-hog regressions?
>
> -- 8< --
>
> The patch for PR91415 fixed -Wsequence-point to treat shifts and ARRAY_REF
> as sequenced in C++17, and COMPONENT_REF as well. But this is unnecessary
> for COMPONENT_REF, since the RHS is just a FIELD_DECL with no actual
> evaluation, and in this testcase handling COMPONENT_REF as sequenced blows
> up fast in a deep inheritance tree.
>
> PR c++/107163
>
> gcc/c-family/ChangeLog:
>
> * c-common.cc (verify_tree): Don't use sequenced handling
> for COMPONENT_REF.
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;
?
As for compile-hog, depends on how long it will take it to compile before
fix/after fix. If before fix can be above the normal timeout on reasonably
fast matchines and after fix can take a few seconds, great, if after fix
would take longer but still not horribly long, one way to do it is
guard the test with run_expensive_tests effective target. Or another way
is have the test smaller in complexity normally and
// { dg-additional-options "-DEXPENSIVE" { target run_expensive_tests } }
and #ifdef EXPENSIVE make it more complex.
Jakub
