https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117158
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-12 branch has been updated by Simon Martin <simar...@gcc.gnu.org>: https://gcc.gnu.org/g:5fdd38d576c20d5a337b5c7d14108981d0751434 commit r12-10804-g5fdd38d576c20d5a337b5c7d14108981d0751434 Author: Simon Martin <si...@nasilyan.com> Date: Tue Nov 5 10:07:42 2024 +0100 c++: Defer -fstrong-eval-order processing to template instantiation time [PR117158] Since r10-3793-g1a37b6d9a7e57c, we ICE upon the following valid code with -std=c++17 and above === cut here === struct Base { unsigned int *intarray; }; template <typename T> struct Sub : public Base { bool Get(int i) { return (Base::intarray[++i] == 0); } }; === cut here === The problem is that from c++17 on, we use -fstrong-eval-order and need to wrap the array access expression into a SAVE_EXPR. We do so at template declaration time, and end up calling contains_placeholder_p with a SCOPE_REF, that it does not handle well. This patch fixes this by deferring the wrapping into SAVE_EXPR to instantiation time for templates, when the SCOPE_REF will have been turned into a COMPONENT_REF. PR c++/117158 gcc/cp/ChangeLog: * typeck.cc (cp_build_array_ref): Only wrap array expression into a SAVE_EXPR at template instantiation time. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/eval-order13.C: New test. * g++.dg/parse/crash77.C: New test. (cherry picked from commit b1d92aeb8583c8d1491c97703680c5fb88ed1fe4)
