[Bug tree-optimization/106679] [13 regression] gcc.dg/tree-prof/cmpsf-1.c fails after r13-2098-g5adfb6540db95d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679 --- Comment #2 from Aldy Hernandez --- Huh. I wonder why this didn't show up in my regression tests. Are these tests not run by default? Either way, I'll take a look. On Thu, Aug 18, 2022, 23:29 pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679 > > Andrew Pinski changed: > >What|Removed |Added > > > Target|powerpc64-linux-gnu,| >|powerpc64le-linux-gnu | >Host|powerpc64-linux-gnu,| >|powerpc64le-linux-gnu | >Last reconfirmed||2022-08-18 > Build|powerpc64-linux-gnu,| >|powerpc64le-linux-gnu | > Ever confirmed|0 |1 > Status|UNCONFIRMED |NEW > > --- Comment #1 from Andrew Pinski --- > Looks like it also fails on x86_64-linux-gnu: > https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599920.html > > -- > You are receiving this mail because: > You are on the CC list for the bug. > >
[Bug tree-optimization/103188] [12 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103188
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at redhat dot com,
||amacleod at redhat dot com
--- Comment #9 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> Caused by g:e82c382971664d6fd138cc36020db4b1a91885c6, the call tree roots at
>
> #666394 0x015f2170 in should_duplicate_loop_header_p (
> header=, loop=0x766aa9f0,
> limit=0x7fffd97c, query=0x3fccb70)
> at /home/rguenther/src/gcc3/gcc/tree-ssa-loop-ch.c:83
> 83&& !entry_loop_condition_is_static (loop, query))
>
> likely ranger is confused by the intermediate IL (from other loops header
> copying), the IL is kept partly not in up-to-date SSA form (because running
> update_ssa is costly so we run it once after doing all header copying in
> a function).
Ughh, yeah. Ranger won't do well with in-flight SSA. I think we can do ok
with minimally changing IL like what evrp does with the substitute and fold
engine, but we expect things quite sane.
When working on this patch I saw the call to gimple_duplicate_sese_region would
increase the number of BBs, which caused problems in the cache and Andrew
fixed. I thought that was it for issues, obviously not.
>
> In this case we applied loop header copying to loop 4 containing loop 5
> which we are now processing.
>
> Not up-to-date SSA form means that while SSA defs are copied, the SSA uses
> in a stmt are still old and _not_ replaced with their current definition.
> There's only so much you can do with such IL, in particular invoking SCEV
> isn't among that.
>
> You can actually check whether a SSA name may be affected by checking
> name_registered_for_update_p. SCEV doesn't do that.
Hmmm, useful.
>
> In the end that means that we'd have to do the ranger analysis before
> actually applying the header copying.
>
> Note that the current place of the
>
> /* Avoid loop header copying when optimizing for size unless we can
> determine that the loop condition is static in the first
> iteration. */
> if (optimize_loop_for_size_p (loop)
> && !loop->force_vectorize
> && !entry_loop_condition_is_static (loop, query))
> {
>
> is off in any case, since we iterate on blocks to copy, instead it should
> be done exactly once per loop. So we can do the "head", up until this
> and the very first should_duplicate_loop_header_p first for each loop,
> recording candidates in a vector and in a second loop process them all,
> not doing the already done entry_loop_condition_is_static.
>
> Let me cook up a patch to do that.
Thanks for fixing this!
[Bug tree-optimization/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906 --- Comment #18 from Defunct account. Do not use. --- > Yes. I guess it would be nice to have a CTOR or so for the case > where the path is really a single edge like in this case. Good idea. Will do.
[Bug middle-end/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at redhat dot com
--- Comment #3 from Aldy Hernandez ---
I'm going to need more specific instructions here.
Looking at the link provided, there's a target of arm-none-linux-gnueabihf
--with-arch=default --with-cpu=cortex-a9 --with-cpu=vfp -march=armv5t... that
has a a red "REGRESSED" column.
I tried to simulate that with a cross --target=arm-none-linux-gnueabihf:
diff --git a/gcc/testsuite/gcc.target/arm/ivopts-4.c
b/gcc/testsuite/gcc.target/arm/ivopts-4.c
index 2e866c01823..cb81d010bb5 100644
--- a/gcc/testsuite/gcc.target/arm/ivopts-4.c
+++ b/gcc/testsuite/gcc.target/arm/ivopts-4.c
@@ -1,5 +1,5 @@
/* { dg-do assemble } */
-/* { dg-options "-Os -fdump-tree-ivopts -save-temps" } */
+/* { dg-options "-Os -fdump-tree-ivopts -save-temps -S -mcpu=cortex-a9
-mfpu=vfp -march=armv5t" } */
extern unsigned int foo (int*) __attribute__((pure));
$ make check-gcc RUNTESTFLAGS=arm.exp=ivopts-4.c
=== gcc Summary ===
# of expected passes4
Can you provide specific flags to pass to cc1 on a cross to
arm-none-linux-gnueabihf in order to reproduce?
[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 --- Comment #12 from Aldy Hernandez --- Thank you for your help on this (and the myriad of other PRs ;-)). I'll submit upstream. On Sat, Oct 23, 2021 at 11:06 AM pinskia at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 > > --- Comment #11 from Andrew Pinski --- > (In reply to Aldy Hernandez from comment #10) > > Created attachment 51656 [details] > > proposed patch 2 > > > > How about this? > > I can confirm the patch works on aarch64-linux-gnu and x86_64-linux-gnu. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug tree-optimization/102794] [12 Regression] missing vrp in evrp dealing with casts and ands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102794 --- Comment #2 from Aldy Hernandez --- I haven't looked at this, but there's a pending patch with more restrictions for loop threading in the presence of loops. Does this help? https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581637.html We really shouldn't be destroying loop info. On Sat, Oct 16, 2021, 07:01 pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102794 > > Andrew Pinski changed: > >What|Removed |Added > > > CC||aldyh at gcc dot gnu.org > > --- Comment #1 from Andrew Pinski --- > Jump threading really messes up the loop here ... > about to thread: path: 4 -> 6, 6 -> 7, 7 -> 3, > just threaded: path: 4 -> 9, 6 -> 7, 7 -> 3, > > I don't know what else to say. Maybe move ethread after evpr? > > Note with -fno-thread-jumps, evpr is able to figure out the induction > variable > goes from [-100, -1] . It does look like jump threading is full on > messing up > how induction variable detection works; we get two a = a +1; statement > after > the jump threading improvements. > Maybe there is another bug about that case already. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > >
[Bug tree-optimization/102703] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2591-g2e96b5f14e402569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703 --- Comment #8 from Aldy Hernandez --- On Wed, Oct 13, 2021, 11:37 pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703 > > --- Comment #7 from Andrew Pinski --- > Because: > if (d_11 > 1) > goto ; [59.00%] > else > goto ; [41.00%] > >[local count: 391808389]: > >[local count: 955630225]: > # iftmp.1_6 = PHI <0(3), 2(4)> > > If the phi node was removed, the original al condition for d_11 > 1 would > be > remove. > As the IL stands, the 3->5 edge has relevant range information. If the IL should be different at this point, there is no way the threader can know this. Aldy
[Bug tree-optimization/102646] large performance changes between 1932e1169a236849f5e7f1cd386da100d9af470f and 9cfb95f9b92326e86e99b50350ebf04fa9cd2477 (probably jump threading)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102646 --- Comment #3 from Aldy Hernandez --- Most if not all the performance changes I've seen so far have been, not due to the jump threader changes, but to the restrictions we've put into place for jump threadable paths. Before, we used to thread paths that destroyed loop form. We are much more cautious now. In theory, the vectorizer should be able to do an even better job with loops preserved longer. That being said, this has been a bit of a moving target, with the thread validity model changing a few times in the past month. A good exercise would be to compare the old and new threaders, with the vectorizer kept constant (whether -fno-tree-vectorize or -ftree-vectorize), but without the loop threading restrictions. That is, with something like this patch: diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c index 32ce1e3af40..1a49cb61ca3 100644 --- a/gcc/tree-ssa-threadupdate.c +++ b/gcc/tree-ssa-threadupdate.c @@ -2853,9 +2853,6 @@ jt_path_registry::register_jump_thread (vec *path) return false; } - if (cancel_invalid_paths (*path)) -return false; - if (dump_file && (dump_flags & TDF_DETAILS)) dump_jump_thread_path (dump_file, *path, true); On Mon, Oct 11, 2021 at 4:59 PM hubicka at kam dot mff.cuni.cz wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102646 > > --- Comment #2 from hubicka at kam dot mff.cuni.cz --- > > I think most of the regressions are fixed, we get even better numbers now. > Because we enabled vectorization. I would say they should still > reproduce with -fno-tree-vectorize, right? > > Honza > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug tree-optimization/102622] [12 Regression] Wrong code with -O3 for skylake-avx512 and icelake-server by r12-3903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622 --- Comment #10 from Aldy Hernandez --- Does :1-1 fail? In which case it's definitely the first thread.
[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605 --- Comment #7 from Aldy Hernandez --- On Wed, Oct 6, 2021 at 10:14 AM rguenther at suse dot de wrote: > Btw, please report cases where -gimple doesn't produce valid GIMPLE FE > inputs (OK, there are known cases with mangled symbol names when > passes create temporaries whose name includes a '.' for example...) Thanks, will do.
[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605
--- Comment #5 from Aldy Hernandez ---
> > BTW, the __MEM_REF output from the dumps does not work in -fgimple either.
> > More errors.
>
> Can you share an example?
This is from gcc.c-torture/execute/961125-1.c compiled with -fgimple:
char * begfield (int tab, char * ptr, char * lim, int sword, int schar);
int __GIMPLE (ssa)
main ()
{
char * lim;
char * s;
char * _1;
__BB(2):
_1 = begfield (58, ":ab", &__MEM ((void *)":ab" + _Literal
(void *) 3), 1, 1);
if (_1 != &__MEM ((void *)":ab" + _Literal (void *) 2))
goto __BB3;
else
goto __BB4;
__BB(3):
abort ();
__BB(4):
exit (0);
}
$ ./cc1 x.c -quiet -fgimple
x.c: In function ‘main’:
x.c:11:55: error: invalid type of ‘__MEM’ operand
11 | _1 = begfield (58, ":ab", &__MEM ((void *)":ab" +
_Literal (void *) 3), 1, 1);
| ^
x.c:11:60: error: expected ‘)’ before ‘+’ token
11 | _1 = begfield (58, ":ab", &__MEM ((void *)":ab" +
_Literal (void *) 3), 1, 1);
|^~
|)
x.c:12:13: error: expected expression before ‘&’ token
12 | if (_1 != &__MEM ((void *)":ab" + _Literal (void *) 2))
| ^
x.c: At top level:
x.c:12:67: error: expected identifier or ‘(’ before ‘)’ token
12 | if (_1 != &__MEM ((void *)":ab" + _Literal (void *) 2))
| ^
x.c:14:3: error: expected identifier or ‘(’ before ‘else’
14 | else
| ^~~~
x.c:17:8: error: expected declaration specifiers or ‘...’ before
numeric constant
17 | __BB(3):
|^
x.c:20:8: error: expected declaration specifiers or ‘...’ before
numeric constant
20 | __BB(4):
|^
x.c:23:1: error: expected identifier or ‘(’ before ‘}’ token
23 | }
| ^
Thanks for improving all this.
[Bug tree-optimization/102546] [12 Regregression] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546 --- Comment #12 from Aldy Hernandez --- Absolutely, but I didn't want to pollute the patch for this PR. Consider the patch to do so pre-approved :-). On Sat, Oct 2, 2021, 00:20 jakub at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546 > > Jakub Jelinek changed: > >What|Removed |Added > > > CC||jakub at gcc dot gnu.org > > --- Comment #11 from Jakub Jelinek --- > Isn't the same thing true also for operator_rshift::op1_range? > I mean, (X >> Y) != 0 implies X != 0. > > -- > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug. > >
[Bug tree-optimization/102542] [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542 --- Comment #7 from Aldy Hernandez --- On Fri, Oct 1, 2021 at 1:46 PM rguenth at gcc dot gnu.org wrote: > > Could I inconvenience you to tweak this function with your insight? It's a > > tiny function, and it seems you're much more qualified to add the > > restriction code. If not, I'm sure I can stumble around it and send it for > > review. > > Something like > > diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c > index dcabfdb30d2..b1b77e91176 100644 Thanks so much for this. I will test it, and incorporate it with some ideas Jeff had suggested. Then I'll post it upstream for review/discussion. BTW, it seems that the code restricting paths should actually live in the loop world...since it's the loop experts who know what is allowed and what is problematic ;-).
[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 --- Comment #21 from Aldy Hernandez --- However, if you care to test a patch, I'd be happy to review it. On Thu, Sep 30, 2021 at 7:49 AM aldot at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 > > Bernhard Reutner-Fischer changed: > >What|Removed |Added > > CC||aldot at gcc dot gnu.org > > --- Comment #19 from Bernhard Reutner-Fischer --- > so as asked in > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580485.html what > about > dominance_info? > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 --- Comment #20 from Aldy Hernandez --- Doesn't make a difference. If the blocks are stale, they need to be reconstructed anyhow. It's preexisting behavior in VRP anyhow. I heard you the first time ;-). On Thu, Sep 30, 2021 at 7:49 AM aldot at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 > > Bernhard Reutner-Fischer changed: > >What|Removed |Added > > CC||aldot at gcc dot gnu.org > > --- Comment #19 from Bernhard Reutner-Fischer --- > so as asked in > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580485.html what > about > dominance_info? > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527 --- Comment #11 from Aldy Hernandez --- This looks mighty suspicious ;-) diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 69a3ab0ea9d..c24c67f8874 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -4408,6 +4408,7 @@ hybrid_threader::~hybrid_threader () delete m_threader; delete m_state; delete m_ranger; + delete m_query; scev_finalize (); loop_optimizer_finalize ();
[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 --- Comment #16 from Aldy Hernandez --- On Wed, Sep 29, 2021 at 10:46 PM dje at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 > > --- Comment #15 from David Edelsohn --- > I annotated execute_vrp_threader() to call getrusage() and print the size of > RSS around each call to threader.thread_jumps(). It consistently is growing, > but not in the threader itself. Was the former VPR Threader intentionally or > implicitly freeing some other data allocated by the compiler that the new > threader is not cleaning up? Huh. Very good insight. :-) diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 69a3ab0ea9d..c24c67f8874 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -4408,6 +4408,7 @@ hybrid_threader::~hybrid_threader () delete m_threader; delete m_state; delete m_ranger; + delete m_query; scev_finalize (); loop_optimizer_finalize ();
[Bug middle-end/101671] pr83510 fails with -Os because threader confuses -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
--- Comment #2 from Aldy Hernandez ---
Yeah, that would be great. Thanks!
On Thu, Jul 29, 2021 at 6:05 PM msebor at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
>
> Martin Sebor changed:
>
>What|Removed |Added
>
> CC||msebor at gcc dot gnu.org
>Last reconfirmed||2021-07-29
>Keywords||diagnostic
> Summary|pr83510 fails because |pr83510 fails with -Os
>|threader confuses |because threader confuses
>|-Warray-bounds |-Warray-bounds
> Ever confirmed|0 |1
> Status|UNCONFIRMED |NEW
>
> --- Comment #1 from Martin Sebor ---
> Confirmed. I've extracted the test case that fails from the bigger test.
> Rather than xfailing the whole test I think it would be better to split out
> just the failing case and/or xfail just that assertion. Unless you expect the
> others to start failing too due to some changes you still have planned?
>
> $ cat a.c && gcc -Os -S -Wall a.c
> extern int f (void);
> extern void sink (unsigned int);
>
> unsigned int a[10];
>
> static unsigned int g (int i, int j)
> {
> if (i == 9)
> return j;
> else if (i == 10)
> return a[i];// no warning here
> return 0;
> }
>
> void test_g (int j)
> {
> for (int i = 0; i < 10; i++)
> {
> if (f ())
> sink (g (i, j));
> }
> }
>
> static unsigned int h (int i, int j)
> {
> switch (i)
> {
> case 9:
> return j;
> case 10:
> return a[i]; // { dg-bogus "-Warray-bounds" }
> }
> return 0;
> }
>
> void test_h (int j)
> {
> for (int i = 0; i < 10; i++)
> {
> if (f ())
> sink (h (i, j));
> }
> }
> In function ‘h’,
> inlined from ‘test_h’ at a.c:41:2:
> a.c:31:15: warning: array subscript 10 is above array bounds of ‘unsigned
> int[10]’ [-Warray-bounds]
>31 | return a[i]; // { dg-bogus "-Warray-bounds" }
> | ~^~~
> a.c: In function ‘test_h’:
> a.c:4:14: note: while referencing ‘a’
> 4 | unsigned int a[10];
> | ^
>
> --
> You are receiving this mail because:
> You reported the bug.
>
[Bug tree-optimization/100787] [12 Regression] Bootstrap failure caused by r12-1077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 --- Comment #7 from Jakub Jelinek --- Perhaps if EVRP is folding debug stmts it could first fold non-debug stmts (and remember if there were any debug stmts) and only fold debug stmts afterwards, either just by using caches and not adding anything to them (if they survive to later passes), or just to make sure that the debug stmts don't affect non-debug folding. --- Comment #8 from Aldy Hernandez --- I'll work on it this weekend. If there's no patch by Monday morning, we can revert the patch while I find a solution. On Fri, May 28, 2021, 19:49 ro at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 > > Rainer Orth changed: > >What|Removed |Added > > > Target|i686|i686, sparc > CC||ro at gcc dot gnu.org > > --- Comment #6 from Rainer Orth --- > It also affects 32-bit sparc (sparc-sun-solaris2.11), maybe other 32-bit > targets, too? Unless a quick fix is coming forward, I suspect it would be > better > to revert the patch instead of keeping bootstrap broken for days. > > -- > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug. > >
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #30 from Aldy Hernandez --- On 5/26/21 3:23 PM, rguenther at suse dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 > > --- Comment #29 from rguenther at suse dot de --- > On Wed, 26 May 2021, amacleod at redhat dot com wrote: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 >> >> --- Comment #28 from Andrew Macleod --- >> (In reply to rguent...@suse.de from comment #27) >>> On Wed, 26 May 2021, aldyh at redhat dot com wrote: >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #26 from Aldy Hernandez --- On Wed, May 26, 2021 at 10:34 AM rguenther at suse dot de wrote: > It's probably too strict for multiple_of_p which is fine with > overflows that preserve modulo behavior. Could you provide an example? >>> >>> Like with DECL_SIZE being D.1234 * 8 as unsigned multiplication >>> and the query whether it's a multiple of 8. Once you have no >>> range for 'D.1234' you will signal overflow (correctly) but >>> even then it's still a mutliple of 8. >> >> Determining whether an arbitrary expression is a multiple of some number is >> not >> really something we can figure out via ranges. Well, that's not quite true. >> If >> we fully fleshed out the operations you care about, things like multiply or >> shift you could get some results. presumably things like multiply by 2,4,8 >> and >> 16.. if we created correct multi-ranges for those, a cast of the high >> precision >> range back to the original precision would yield an identical non-varying >> range. and for non-multiples/unsupported values we'd get varying or something >> not the same as the original value?. This would only work if the original >> value doesn't come out varying.Although if its varying, maybe you dont >> care >> and a match is ok anyway?We could have may_overflow_p also return the >> higher precision range for inspection if its true... > > I guess optimally multiple_of_p would check for each individual > operation it looks at whether the op is transparent for the > modulo query and only if not checks whether there's possible overflow > (where ranges could help). My POC gimple_ranger_wider class can just be overloaded and in range_of_expr, you could just hijack the operations you care about (PLUS_EXPR, MULTIPLY_EXPR, etc) and treat them specially. Just a thought... Aldy
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #26 from Aldy Hernandez --- On Wed, May 26, 2021 at 10:34 AM rguenther at suse dot de wrote: > It's probably too strict for multiple_of_p which is fine with > overflows that preserve modulo behavior. Could you provide an example?
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #20 from Aldy Hernandez --- On Wed, May 19, 2021 at 8:31 AM rguenth at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 > > --- Comment #17 from Richard Biener --- > (In reply to Andrew Macleod from comment #16) > > We could add an expression evaluator that can walk that expression, invoking > > range-ops on each expression, and calling a ranger instance to evaluate a > > range for any ssa_name it finds. > > > > It would bail if there are unknown tree-codes to range-ops. > > Yeah, it would be similar to the existing determine_value_range () function > which does exactly do this (but not using ranger). determine_value_range() has been calling range-ops under the covers for quite a while, so it's half-way there. It would require some minor tweaks: a) Use irange instead of value_range so as to not throw away the higher precision range-ops calculates. b) If we want context-aware ranges, pass it a gimple statement / edge / etc, and a range_query/ranger. Oh yeah, and return a proper range, not this value_range_kind + wide_int + wide_int business (determine_value_range_1 does this already).
[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #10 from Aldy Hernandez ---
> > as well as here:
> >
> > if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
> > {
> > /* We cannot compare overflowed values. */
> > if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
> > return -2;
> >
> > return tree_int_cst_compare (val1, val2);
> > }
>
> VRP uses (used to use) fold_* routines and _specifically_ relies (relied)
> on some TREE_OVERFLOW bits therein. This might be all long history
> but the above is probably because of that.
>
> Btw, IIRC I've made sure to drop TREE_OVERFLOW from constants picked out
> of the IL for VRP purposes (as said, some passes are "confused" about
> existing TREE_OVERFLOW if they rely on TREE_OVERFLOW for their own
> internal processing - which, nowadays should use wide_int).
Ok, let's let sleeping dogs lie then. I'll drop the overflow will
building ranges.
Thanks for the explanation.
I'll commit the following if it passes tests.
Aldy
Drop overflow from constants while building ranges in ranger.
Sometimes overflow flag will leak into the IL. Drop them while
creating ranges.
gcc/ChangeLog:
PR tree-optimization/97721
* gimple-range.cc (get_tree_range): Drop overflow from constants.
gcc/testsuite/ChangeLog:
* gcc.dg/pr97721.c: New test.
diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
index cf979845acf..6d351002830 100644
--- a/gcc/gimple-range.cc
+++ b/gcc/gimple-range.cc
@@ -165,6 +165,8 @@ get_tree_range (irange , tree expr)
switch (TREE_CODE (expr))
{
case INTEGER_CST:
+if (TREE_OVERFLOW_P (expr))
+ expr = drop_tree_overflow (expr);
r.set (expr, expr);
return true;
diff --git a/gcc/testsuite/gcc.dg/pr97721.c b/gcc/testsuite/gcc.dg/pr97721.c
new file mode 100644
index 000..c2a2848ba13
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr97721.c
@@ -0,0 +1,13 @@
+// { dg-do compile }
+// { dg-options "-O -fno-tree-dominator-opts" }
+
+int ot;
+
+void
+z6 (char *tw)
+{
+ while (ot >= 0)
+--ot;
+
+ __builtin_strcpy ([ot], tw);
+}
[Bug tree-optimization/97609] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609 --- Comment #8 from Aldy Hernandez --- Yes. On Thu, Oct 29, 2020, 09:47 marxin at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609 > > Martin Liška changed: > >What|Removed |Added > > > CC||marxin at gcc dot gnu.org > > --- Comment #7 from Martin Liška --- > Can it be closed as fixed? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > >
[Bug tree-optimization/96818] [11 Regression] ICE: in decompose, at wide-int.h:984 at -O since r11-2883
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818 --- Comment #11 from Aldy Hernandez --- Ah...it can be closed. On Wed, Oct 14, 2020, 17:58 jamborm at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818 > > --- Comment #10 from Martin Jambor --- > Is this bug still "WAITING" for something? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug. > >
