https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #31 from Martin Sebor ---
I believe I understand what both of you are saying and (also) that the cache
behaves correctly. It stores offsets based on the pointer definition
statements. Here's a test that I think reproduces the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #30 from Andrew Macleod ---
(In reply to Martin Sebor from comment #29)
> From memory: At use1 the cache is empty so go and find its definition and
> record the offset at that point, with the pointer addition as the context.
> And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #29 from Martin Sebor ---
>From memory: At use1 the cache is empty so go and find its definition and
record the offset at that point, with the pointer addition as the context. And
at use2 we look up the same offset. So use1 won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #28 from rguenther at suse dot de ---
On Thu, 20 Jan 2022, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
>
> --- Comment #26 from Martin Sebor ---
> (In reply to rguent...@suse.de from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
John David Anglin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #26 from Martin Sebor ---
(In reply to Andrew Macleod from comment #25)
...
> I also don't get the warning anymore on trunk.
>
> Is there still an issue here?
The strlen pass was converted to Ranger in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #25 from Andrew Macleod ---
OK, lets reset.
I run it now, and ranger is indeed being used, so somewhere along the way the
conversion was finished I guess.
so.
looking at the trace, I see:
446 range_of_expr(_2) at stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #24 from Richard Biener ---
Oh, and btw. strlen no longer uses EVRP it seems - it still performs a DOM walk
but is using ranger now (but my guess is still the ptr-query caching is what is
broken - one could try simply bypassing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #23 from rguenther at suse dot de ---
On Wed, 19 Jan 2022, amacleod at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
>
> --- Comment #22 from Andrew Macleod ---
> (In reply to rguent...@suse.de from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #22 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #21)
> On Tue, 18 Jan 2022, amacleod at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
> >
> > --- Comment #20 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #21 from rguenther at suse dot de ---
On Tue, 18 Jan 2022, amacleod at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
>
> --- Comment #20 from Andrew Macleod ---
> I think the anaylsis in comment 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #20 from Andrew Macleod ---
I think the anaylsis in comment 5 and onward needs to be redone since it was
using rangers debug output to see something wrong, but the pass isn't even
using ranger.. It is using EVRP as we determined in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #19 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #18 from Richard Biener ---
The EVRP range_of_expr is not context sensitive and if EVRP is in effect the
EVRP active context is implicitely used, so when you try to ask for a different
context you won't get that contexts result but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #17 from Aldy Hernandez ---
(In reply to Martin Sebor from comment #15)
> accurate than with ranger. I also didn't realize that debug_ranger() didn't
> show me the same ranges I get from a call range_of_expr(). Live and learn I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #16 from Aldy Hernandez ---
> $3 = void
> (gdb) n
> 326 max = wi::to_wide (vr.max ());
> (gdb) p range_type
> $4 = VR_RANGE
> (gdb) p debug_tree(vr.min())
>
> constant 1>
> $5 = void
> (gdb) p debug_tree(vr.max())
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #15 from Martin Sebor ---
The call is made from the strlen pass which still does apparently use EVRP. I
believe Aldy's been moving it away from it (some of his changes are still
pending) as have I, so things are still in flux. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #14 from Andrew Macleod ---
As near as I can tell, you are calling debug_ranger () to see what ranger could
produce. That routine creates a new ranger and populates it, dumps out the
results, kills the ranger and returns.
When I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #13 from Martin Sebor ---
Here's a reduced test case that reproduces the problem with an x86_64-linux GCC
in ILP32 mode:
$ cat pr103121.C && gcc -O2 -S -Wall -m32 pr103121.C
typedef typeof (sizeof 0) size_t;
struct tree_node {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #12 from Martin Sebor ---
Okay, here's my question: when I call range_of_expr (vr, _4, stmt) with stmt
being 'grp_name_37 = __builtin_alloca (_4)' in BB 4, should I not expect the
result to be either VR_VARYING or [0, +INF]?
What I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #11 from Andrew Macleod ---
(In reply to Martin Sebor from comment #10)
> Sorry, I've been having trouble with GDB and so I'm running two GDB sessions
> and I have been mixing output from both of them. I see the warning for the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #10 from Martin Sebor ---
Sorry, I've been having trouble with GDB and so I'm running two GDB sessions
and I have been mixing output from both of them. I see the warning for the
store to *_23 in BB 13, not for BB 12. Here's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #9 from Andrew Macleod ---
(In reply to Martin Sebor from comment #8)
> The [1, 1] range comes from a call to qry->range_of_expr (vr, exp, stmt) in
> in get_size_range() in pointer-query.cc:
>
> (gdb)
> #7 0x0192c0df in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #8 from Martin Sebor ---
The [1, 1] range comes from a call to qry->range_of_expr (vr, exp, stmt) in in
get_size_range() in pointer-query.cc:
(gdb) p debug(gimple_bb(stmt))
[local count: 118111600]:
_4 = _1 + 1;
grp_name_37 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
Martin Sebor changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
Martin Sebor changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #4 from John David Anglin ---
Created attachment 51748
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51748=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #2 from dave.anglin at bell dot net ---
On 2021-11-08 4:24 a.m., rguenth at gcc dot gnu.org wrote:
> David, can you try adding
> -fno-tree-vectorize to the command line to see if that silences the
> diagnostic?
It does not silence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #1 from Richard Biener ---
grp_name = XALLOCAVEC (char, IDENTIFIER_LENGTH (complete_name) + 1);
so the array is at least of size 1. David, can you try adding
-fno-tree-vectorize to the command line to see if that silences the
31 matches
Mail list logo
