https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #9)
> It might be possible for some. I'm not sure how successful it would be for
> others. The thread_jumps pass runs four times and moving the warn_restrict
> pass before its first instance results in dozens of regressions. This
> particular instance of the warning goes away if the warn_restrict pass is
> moved before the second to last threads_jump pass, but that still causes
> regressions. Moving the pass just before the last threads_jump pass doesn't
> help.
Either we need to mark some way all the stmts involved in jump threading and
ignore warning on those by the late warning passes (setting gimple_no_warning_p
on those might be too big hammer, but we have one padding bit close to
no_warning, so use that for gimple_jump_threaded_p), or the late warning passes
need to be moved before the first jump threading and have infrastructure
improvement that they are able to figure stuff out better (say on demand VRP,
strlen if needed, etc.) and after that just turn UB statements into
__builtin_unreachable or __builtin_trap or whatever based on what the user
chooses.
I guess the main problem is that we have some jump threading already before the
(non-early) inlining.
As I said multiple times in the past, the problem with jump threading is that
it tends to create statements, just because it sees some often related
comparison somewhere else, those statements can be specialized for constants or
ranges that actually never occur in the program at runtime, but in many cases
no optimization can figure that out. It is a significant difference if the
user writes strncpy (, , -1U) vs. when it appears through jump threading like
in this example.
