https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779
--- Comment #21 from Christopher Albert <albert at tugraz dot at> --- I reran this on clean trunk and also did a clean trunk bisection. Current trunk: - upstream/master at a0d6c3f23cc (2026-03-19) - clean build configured with --enable-valgrind-annotations Results on that clean trunk build: - entry_4.f90 with -O1 -fdefault-integer-8: compiles and runs cleanly - mixed-result reducer from comment #13 with -O1 -fdefault-integer-8: compiles cleanly - direct valgrind on f951 for both of the above: 0 errors from 0 contexts So the remaining memcheck noise is not a current trunk ENTRY regression. It comes from running valgrind on a compiler build without valgrind annotations enabled. I then ran a clean bisection on trunk history with a fresh build at every step. The first good commit for the visible ICE is: 694613a7f9adfa9c87e733adc63839c8801f2b5c expand: Fix up ICE on VCE from _Complex types to _BitInt [PR117458] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=694613a7f9adfa9c87e733adc63839c8801f2b5c Direct confirmation: - parent 600cab162c561c3061317c998972b0ed1b681d5b still ICEs from a fresh build - 694613a7f9ad compiles both reproducers cleanly from a fresh build This is not the recent Fortran ENTRY fix for PR95338. The old PR84779 crash stack goes through: gen_lowpart_general -> extract_bit_field -> expand_expr_real_1 -> expand_return which matches the middle-end fix in PR117458 exactly. Related bug: PR117458 - ICE: in gen_lowpart_general, at rtlhooks.cc:63 when reinterpreting _Complex float as _BitInt(33) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117458 So PR84779 appears to have been fixed upstream indirectly by the generic middle-end PR117458 fix, while the remaining direct-f951 valgrind warnings are a separate sparse-set / build-configuration issue.
