https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95803
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Blocks| |83819
Last reconfirmed| |2020-06-22
CC| |msebor at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
The first case is due to failing to handle POINTER_PLUS expressions in
maybe_set_strlen_range() in tree-ssa-strlen.c. The second case is folded into
(i <= 3 ? i : 0) very early on by fold_builtin_strlen().
There is no consistency in how GCC responds to instances of undefined behavior.
Some are folded away and replaced by constants, others are intentionally made
to expand into library calls. The referenced meta-bug tracks a number of such
cases.
We've been talking for years now about implementing a policy where the decision
how to respond is left up to the user. The three common responses that were
discussed at GNU Cauldron in Manchester are to:
1) fold/eliminate/replace it with a safer alternative
2) replace with __builtin_trap
3) replace with __builtin_unreachable
All three with a warning. I've been working on improvements in this area and
with my WIP patches to the detection of past the end reads GCC prints:
pr95803.c: In function ‘f’:
pr95803.c:8:12: warning: ‘__builtin_strlen’ reading 1 or more bytes from a
region of size 0 [-Wstringop-overread]
8 | return __builtin_strlen(s) > 3;
| ^~~~~~~~~~~~~~~~~~~
I expect to submit the patch for review soon (maybe even this week). I support
folding this and similar code to a no-op provided it still triggers a warning.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations
