https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732
--- Comment #7 from Jeffrey A. Law ---
Given that both DOM and strlen are already dom walker based, getting better
range information in them is going to be easy. The former is actually part of
the motivation behind the refactoring work.
We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732
--- Comment #6 from Jakub Jelinek ---
For this exact testcase anywhere in between ldist and strlen pass, so e.g. in
dom or strlen passes. Though it would need to be something that handles what
vrp handles with ASSERT_EXPRs.
Yet another option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732
--- Comment #3 from Peter Cordes ---
(In reply to Marc Glisse from comment #2)
> If you use size_t consistently (for size and i), then the resulting code is
> a call to calloc.
Ah interesting.
With a compile-time constant size and -O3 we get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732
--- Comment #2 from Marc Glisse ---
If you use size_t consistently (for size and i), then the resulting code is a
call to calloc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732
--- Comment #1 from Marc Glisse ---
We do recognize the memset early enough. What we fail to recognize is that the
size argument to malloc is the same as the length of the memset:
_1 = (long unsigned int) size_8(D);
_2 = _1 * 4;
p_11 =
