https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104787
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
CC| |rguenth at gcc dot gnu.org
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the case is probably similar - without the early folding we go all the
way, transforming
struct FileAccessRef f;
try
{
if (1)
{
return <retval> = 0;
}
}
finally
{
FileAccessRef::~FileAccessRef (&f);
}
__builtin_trap ();
to
D.2402 = 0;
// predicted unlikely by early return (on trees) predictor.
finally_tmp.0 = 0;
FileAccessRef::~FileAccessRef (&f);
if (finally_tmp.0 == 1)
goto <bb 4>; [INV]
else
goto <bb 6>; [INV]
since the return-type diagnostic is before any kind of optimization it
probably diagnoses this by design. Otherwise it would be appropriate
to move the diagnostic to the build_ssa_passes set of diagnostic passes
which could share a common VN run to mark unreachable blocks.
In the end I'm currently not working on the middle-end unreachable code
diagnostic so we can as well revert the frontend change causing all this
fallout ...
