https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090
--- Comment #5 from Aldy Hernandez ---
[from the POC patch]
It seems that every missed thread (due to inability of the threader,
or due to cost restraints) is a potential false positive for the
uninit code. Perhaps what we need is a way to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090
--- Comment #4 from Aldy Hernandez ---
Created attachment 51913
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51913=edit
proof of concept to reduce uninit warnings with the path solver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78993
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100047
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97108
Aldy Hernandez changed:
What|Removed |Added
Depends on||101912
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
--- Comment #3 from Aldy Hernandez ---
> && !(leapcnt == 0
>|| (prevcorr < corr
>? corr == prevcorr + 1
>: (corr == prevcorr
> || corr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 61112, which changed state.
Bug 61112 Summary: Simple example triggers false-positive -Wmaybe-uninitialized
warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #5 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #4)
> Created attachment 51908 [details]
> untested patch
>
> Like this. It fixes the problem at least for -O2.
For -O1 y'all are on your own because there are no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
--- Comment #5 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Aldy Hernandez from comment #3)
> > The warning on the above IL seems legit.
> >
> > x_5 is initialized from b$i_11 when b & 1 == 0, but the read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #4 from Aldy Hernandez ---
Created attachment 51908
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51908=edit
untested patch
Like this. It fixes the problem at least for -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 99756, which changed state.
Bug 99756 Summary: bogus -Wmaybe-uninitialized with a use conditional that's a
subset of a defining conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99756
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99756
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103484
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
--- Comment #10 from Aldy Hernandez ---
*** Bug 103461 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103461
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #30 from Aldy Hernandez ---
(In reply to Jan Hubicka from comment #28)
> Bit unrelated but shows that threader seems bit expensive on other builds
> too.
> Getting stats from cc1plus LTO-link with -flto-partition=one it seems that
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Aldy Hernandez changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103486
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
--- Comment #10 from Aldy Hernandez ---
Created attachment 51896
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51896=edit
untested patch
The threading slowdown here is due to the ssa_global_cache temporary. It
doesn't look like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
--- Comment #9 from Aldy Hernandez ---
There's definitely something in the threader, but I'm not sure it's the cause
of all the regression.
For the record, I've reproduced on ppc64le with a spec .cfg file having:
OPTIMIZE= -O2 -flto=100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #2)
> So range-op.cc eventually wants to look at 'cfun' which of course is a
> non-go in IPA context.
>
> void
> operator_div::wi_fold (irange , tree type,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103388
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
--- Comment #7 from Aldy Hernandez ---
*** Bug 103388 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103388
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103359
--- Comment #8 from Aldy Hernandez ---
For the record, I'm using:
gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC)
as a proxy for gcc11.
And I'm using the *.fre1 dump to see what evrp sees on entry.
Perhaps there's something going on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103359
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #21 from Aldy Hernandez ---
One last comment.
A smaller hammer than -fno-unsafe-math-optimizations may be
-fno-finite-math-only which allows for the problematic NAN behavior in
Perl_do_ncmp. Allowing for the inlining, but not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #21 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #20)
> Your c#19 was a bit hard to follow. But you hit the key issue.
Ughh sorry. I'm running on fumes here :-).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #20 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #19)
> Ughh, I was nerd sniped. Couldn't let it go ;-).
>
> The problem is this construct in Perl_do_ncmp:
>
> if (lnv < rnv)
> return -1;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #19 from Aldy Hernandez ---
Ughh, I was nerd sniped. Couldn't let it go ;-).
The problem is this construct in Perl_do_ncmp:
if (lnv < rnv)
return -1;
if (lnv > rnv)
return 1;
if (lnv == rnv)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 103088, which changed state.
Bug 103088 Summary: [12 regression] 500.perlbench from spec 2017 fails since
r12-4698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #13 from Aldy Hernandez ---
(In reply to Tamar Christina from comment #11)
> Historically it has always only been for the test dataset with the problem
> Aldy encountered before with the signed zeros. See
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #7 from Aldy Hernandez ---
Could someone post the relevant configury bits used for the ppc64le case.
For example, I have:
OPTIMIZE= -O3 -m64 -mcpu=power9 -ffast-math -funroll-loops -fpeel-loops
-fvect-cost-model -mpopcntd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #19 from Aldy Hernandez ---
This looks like a target or RTL problem.
The .optimized dumps between x86-64 and bfin-elf look the same for:
-O2 -fno-tree-vrp -fno-tree-vectorize -fno-thread-jumps -fno-ivopts
-fno-tree-pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2021-11-17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #17 from Aldy Hernandez ---
The .s files on my cross versus the AWS instance or not even remotely the same:
--- j.s 2021-11-17 14:13:19.979883609 -0500
+++ j.s.bad 2021-11-17 14:13:12.083828127 -0500
@@ -5,79 +5,78 @@
.global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #16 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #15)
> Re: c#13. You were so close :-) Add "-msim" to your command line. THat's
> one of the things the baseboards file does for you when you run things under
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #4 from Aldy Hernandez ---
Is this still an issue with the latest trunk? There have been a few changes in
this space (phi ordering, loop header copying, etc).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #13 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #11)
> Aldy, I could also set up a cross toolchain, ready for debugging in an AWS
> instance if that would be helpful.
Ok, I give up.
I configured and installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
Aldy Hernandez changed:
What|Removed |Added
Target|aarch64-none-elf|aarch64-none-elf, bfin-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #12 from Aldy Hernandez ---
(In reply to Tamar Christina from comment #9)
> (In reply to Aldy Hernandez from comment #8)
> > (In reply to Tamar Christina from comment #7)
> > > Just a note, in our case the error seems to cause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #8 from Aldy Hernandez ---
(In reply to Tamar Christina from comment #7)
> Just a note, in our case the error seems to cause stage2 build to fail.
Please file a PR for it and indicate the architecture. This PR is for a
pr80974.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #5 from Aldy Hernandez ---
FWIW, the *.ch2 dump on both x86-64 and bfin-elf are identical.
This is unlikely to help, but...
In *.ivopts we start seeing differences in the IL:
[local count: 60236916]:
e = 1;
+ ivtmp.29_7 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #4 from Aldy Hernandez ---
It's been a LONG time since I had to do a sim build, so please bear with me.
I have combined tree with gcc, binutils-gdb, dejagnu, newlib-cygwin:
~/src/combined/configure --target=bfin-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
--- Comment #6 from Aldy Hernandez ---
This looks like a class of problems we could easily get if we wanted. The
pattern is:
PREHEADER
|
|
V
HEADER --> LOOPEXIT
|
|
V
SUCC
| \
| \
DEAD \
| /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
--- Comment #5 from Aldy Hernandez ---
*** Bug 103280 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103280
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #18 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #17)
> iftmp.2373_1515 is defined earlier as:
> iftmp.2373_1515 = code_1387(D) != 181 ? ctx_1386 : outer_ctx_1389;
> so the transformation by dom3? from
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103254
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103257
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207
--- Comment #6 from Aldy Hernandez ---
Created attachment 51796
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51796=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207
--- Comment #5 from Aldy Hernandez ---
(In reply to Richard Biener from comment #4)
> Sure. (OVF) in the IL are meaningless, we do try to prune them but it still
> happens that they appear.
Ughh, you've mentioned this before. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101941
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 103229, which changed state.
Bug 103229 Summary: gcc/gimple-range-cache.cc:654:10: runtime error: null
pointer passed as argument 1, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103229
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103231
--- Comment #8 from Aldy Hernandez ---
Created attachment 51789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51789=edit
similar problem on aarch64 kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103231
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103229
--- Comment #2 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #1)
> Untested, but if someone wants to test and commit, feel free.
Nevermind, I'll pass it through the gauntlet and commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103219
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2021-11-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103229
--- Comment #1 from Aldy Hernandez ---
Untested, but if someone wants to test and commit, feel free.
diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
index a63e20e7e49..b347edeb474 100644
--- a/gcc/gimple-range-cache.cc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103222
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103222
--- Comment #3 from Aldy Hernandez ---
Created attachment 51783
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51783=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103222
Aldy Hernandez changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #2 from Aldy Hernandez
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207
--- Comment #3 from Aldy Hernandez ---
That is, is the overflowed 0 allowed in the switch's case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202
--- Comment #9 from Aldy Hernandez ---
Created attachment 51780
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51780=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #11 from Aldy Hernandez ---
Created attachment 51778
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51778=edit
preprocessed source to reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #10 from Aldy Hernandez ---
The guard seems to be removed by the vrp2 pass, not by jump threading.
a.ii.195t.vrp2:Folding predicate iftmp.2373_1515 != 0B to 1
For some bizarre reason, ranger thinks iftmp.2373_1515 is nonzero and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #8 from Aldy Hernandez ---
Note that I've disabled all the thread full passes and the problem persists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #6 from Aldy Hernandez ---
Hmm, all these threads look correct. Following are my steps for verification.
In a stage2 compiler I do:
$ rm -f gimplify.o
$ make cc1 CXXFLAGS="-O2 -fdisable-tree-threadfull2 -fdisable-tree-threadfull1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #4 from Aldy Hernandez ---
I can reproduce on a stage2 compiler. I've narrowed it down to:
-O2 -fdisable-tree-threadfull2 -fdisable-tree-threadfull1
-fdisable-tree-thread2 -fdisable-tree-thread1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202
--- Comment #7 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #6)
> Not looking at this yet, but disabling jump threading from all passes (dom
> included) makes the problem go away:
>
> $ ./xgcc -B./ a.c -w -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202
--- Comment #6 from Aldy Hernandez ---
Not looking at this yet, but disabling jump threading from all passes (dom
included) makes the problem go away:
$ ./xgcc -B./ a.c -w -O2 -fno-thread-jumps && ./a.out
element 1
element 2
element 3
...so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #3 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #1)
> Seems to have started with r12-4790-g4b3a325f07acebf47e82de227ce1d5ba62f5bcae
Huh. I wonder what happened. I never saw these regressions in my testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #21 from Aldy Hernandez ---
Should be fixed. Can someone verify the object size on arm is as expected?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
--- Comment #8 from Aldy Hernandez ---
https://en.cppreference.com/w/cpp/language/eval_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
--- Comment #6 from Aldy Hernandez ---
(In reply to Martin Sebor from comment #5)
> Great! With the strlen conversion to ranger
> (g:6b8b959675a3e14cfdd2145bd62e4260eb193765) the test now fails on x86_64 as
> well:
I didn't see any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892
--- Comment #6 from Aldy Hernandez ---
(In reply to Martin Liška from comment #5)
> Fixed on master with r12-4790-g4b3a325f07acebf4.
Wadayaknow...I fixed it and didn't even know it :)
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892
Aldy Hernandez changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #19 from Aldy Hernandez ---
Created attachment 51757
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51757=edit
proposed patch in testing
Patch depends on some shuffling in the path solver to make way for non-threader
clients.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #16 from Aldy Hernandez ---
(In reply to rguent...@suse.de from comment #15)
> On Wed, 10 Nov 2021, aldyh at gcc dot gnu.org wrote:
> > @@ -60,6 +63,24 @@ should_duplicate_loop_header_p (basic_block header, class
> > loop *loop,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
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())
>
401 - 500 of 740 matches
Mail list logo
