https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=102831
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
Confirmed. It's a failure in what looks like a paranoia test that tries to
verify that the sprintf pass isn't making overly aggressive assumptions about
the width field. The sprintf pass calls get_range_expr() to determine the
range. It runs as part of the strlen pass which still uses EVRP for ranges.
It's strange that the range is different for some targets than others (the IL
is otherwise identical). Since the code is using the same EVRP analyzer as
before I'd expect the GIMPLE statement passed to get_range_expr() to be ignored
and the range to be "global" for the whole function body. I haven't looked
into this in enough detail to understand what's different. As of now this is
just as puzzling to me as the false positive reported in pr102831. I'd expect
converting the strlen pass to use ranger to fix this. I plan to work on it
sometime soon.
