[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Unfortunately the #c15 patch regressed:
+FAIL: g++.dg/opt/pr80032.C  -std=gnu++11 (test for excess errors)
+FAIL: g++.dg/opt/pr80032.C  -std=gnu++14 (test for excess errors)
+FAIL: g++.dg/opt/pr80032.C  -std=gnu++17 (test for excess errors)
+FAIL: g++.dg/opt/pr80032.C  -std=gnu++20 (test for excess errors)
+FAIL: g++.dg/opt/pr80032.C  -std=gnu++2b (test for excess errors)
+FAIL: g++.dg/opt/stack2.C  -std=gnu++11 (test for excess errors)
+FAIL: g++.dg/opt/stack2.C  -std=gnu++14 (test for excess errors)
+FAIL: g++.dg/opt/stack2.C  -std=gnu++17 (test for excess errors)
+FAIL: g++.dg/opt/stack2.C  -std=gnu++20 (test for excess errors)
+FAIL: g++.dg/opt/stack2.C  -std=gnu++2b (test for excess errors)
+FAIL: g++.dg/opt/stack2.C  -std=gnu++98 (test for excess errors)
E.g. on stack2.C, the problem is that needs_to_live_in_memory (temp) is false
before TARGET_EXPR_INITIAL is gimplified, so we don't add a clobber at all in
that case with the first patch and so the stack sharing doesn't happen.
This patch is a new attempt, do the TARGET_EXPR_INITIAL gimplification first,
but into a temporary sequence, then push the cleanups (in the order CLOBBER
first (in the end last), then asan poisioning, then TARGET_EXPR_CLEANUP,
which means the opposite order later on, so first some destructors etc., then
poisioning and finally a clobber).