https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #5 from pthaugen at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #4)
>
> Can you git bisect this to find the offending commit?
Yes, I was going to start that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #1 from pthaugen at gcc dot gnu.org ---
Note this only happens on a BE system, compiles fine on LE.
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, segher at kernel dot
crashing.org
Target Milestone: ---
Host: powerpc64
Target: powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99685
pthaugen at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99685
pthaugen at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
Target Milestone: ---
Host: powerpc64le-linux-gnu
Target: powerpc64le-linux-gnu
Build: powerpc64le-linux-gnu
pthaugen@pike
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407
pthaugen at gcc dot gnu.org changed:
What|Removed |Added
CC||pthaugen at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68212
--- Comment #9 from pthaugen at gcc dot gnu.org ---
The problem can be seen in the loop2_unroll dump:
pthaugen@pike:~/temp/pr68212$ grep "Invalid sum of" simple.c.272r.loop2_unroll
;; Invalid sum of incoming counts 285685646 (estimat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68212
pthaugen at gcc dot gnu.org changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65010
pthaugen at gcc dot gnu.org changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #34 from pthaugen at gcc dot gnu.org ---
(In reply to pthaugen from comment #33)
>
> I tried the patch on a Power9 system. Execution time went from 371 seconds
> to 291.
Which I should have included is in line, or even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #33 from pthaugen at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #32)
> Created attachment 52102 [details]
> Alternative patch
>
> This patch is a squash of several ira tweaks that together recov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103734
pthaugen at gcc dot gnu.org changed:
What|Removed |Added
CC||pthaugen at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743
--- Comment #2 from pthaugen at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #1)
> Pat, does the patch from Alan you're working to get committed help with this
> test case?
No, it just loads the constant slightl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #21 from pthaugen at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #20)
> With g:r12-5872-gf157c5362b4844f7676cae2aba81a4cf75bd68d5 we should no
> longer need -fno-inline-functions-called-once
Yes, I see that now w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #19 from pthaugen at gcc dot gnu.org ---
I tried -fno-inline-functions-called-once and the patches on a Power9 system.
Following are the run times and spill counts (grep -c Spilling
exchange2.fppized.f90.298r.ira). Interesting that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
pthaugen at gcc dot gnu.org changed:
What|Removed |Added
CC||pthaugen at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96825
--- Comment #6 from pthaugen at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> I believe there have been improvements recently - can you re-assess the
> magnitude of the problem? The corresponding ARM PR got re-targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99133
pthaugen at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99133
pthaugen at gcc dot gnu.org changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, hubicka at gcc dot gnu.org,
segher at gcc dot gnu.org, seurer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439
pthaugen at gcc dot gnu.org changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
pthaugen at gcc dot gnu.org changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84369
--- Comment #7 from pthaugen at gcc dot gnu.org ---
Author: pthaugen
Date: Fri Apr 19 17:14:57 2019
New Revision: 270461
URL: https://gcc.gnu.org/viewcvs?rev=270461&root=gcc&view=rev
Log:
Backport from mainline:
2019-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84369
--- Comment #5 from pthaugen at gcc dot gnu.org ---
Author: pthaugen
Date: Tue Apr 16 15:58:02 2019
New Revision: 270394
URL: https://gcc.gnu.org/viewcvs?rev=270394&root=gcc&view=rev
Log:
PR target/84369
* config/rs6000/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89154
--- Comment #3 from Pat Haugen ---
(In reply to Segher Boessenkool from comment #1)
> The new version needs to save r4 because it reuses the reg for storing r7+r8.
> And we still don't wrap CR separately, sigh.
Yes, and similar for r3 since it's
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, rguenth at gcc dot gnu.org,
segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #21 from Pat Haugen ---
> Knowing what inline decision matters for VPR, I can try to fix it too.
Gathering some perf data, the hot functions for various revisions are as
follows. All other functions report < 0.5% of execution time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #19 from Pat Haugen ---
(In reply to Jan Hubicka from comment #18)
> which makes it to be inlined. Does it solve the perofmrance problem for both
> benchmarks?
Looking at our nightly spec runs, the bzip2 degradation has indeed been c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #16 from Pat Haugen ---
>
> Do you observe the same slowdown if you restore either of the params to
> the value before the r257582 change?
>
--param max-inline-insns-auto=40 results in the same degradation.
--param inline-min-spee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77698
--- Comment #7 from Pat Haugen ---
I also see the loop now being aligned when I apply your patch.
srdi 10,10,2
mtctr 10
.p2align 4,,15
.L6:
ld 9,0(11)
ld 8,0(4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77698
Pat Haugen changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, jakub at gcc dot gnu.org,
rsandifo at gcc dot gnu.org, segher at gcc dot gnu.org
||pthaugen at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Pat Haugen ---
Was really a library difference, with newer glibc no longer declaring __strdup.
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86612
--- Comment #2 from Pat Haugen ---
Author: pthaugen
Date: Thu Jul 26 20:47:37 2018
New Revision: 263021
URL: https://gcc.gnu.org/viewcvs?rev=263021&root=gcc&view=rev
Log:
PR target/86612
* gcc.target/powerpc/pr58673-2.c: Call str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86612
--- Comment #1 from Pat Haugen ---
Author: pthaugen
Date: Thu Jul 26 20:41:25 2018
New Revision: 263020
URL: https://gcc.gnu.org/viewcvs?rev=263020&root=gcc&view=rev
Log:
PR target/86612
* gcc.target/powerpc/pr58673-2.c: Call str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489
Pat Haugen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489
--- Comment #5 from Pat Haugen ---
(In reply to kugan from comment #3)
> index f6fa2f7..fbdf838 100644
> --- a/gcc/tree-ssa-loop-niter.c
> +++ b/gcc/tree-ssa-loop-niter.c
> @@ -2555,6 +2555,7 @@ number_of_iterations_popcount (loop_p loop, edge ex
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, kugan at gcc dot gnu.org,
segher at gcc dot gnu.org, wschmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
--- Comment #13 from Pat Haugen ---
Author: pthaugen
Date: Mon May 21 16:41:09 2018
New Revision: 260477
URL: https://gcc.gnu.org/viewcvs?rev=260477&root=gcc&view=rev
Log:
PR target/85698
* gcc.target/powerpc/vec-setup-be-long.c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
--- Comment #12 from Pat Haugen ---
Author: pthaugen
Date: Mon May 21 16:34:44 2018
New Revision: 260476
URL: https://gcc.gnu.org/viewcvs?rev=260476&root=gcc&view=rev
Log:
PR target/85698
* config/rs6000/rs6000.c (rs6000_output_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
--- Comment #11 from Pat Haugen ---
Author: pthaugen
Date: Mon May 21 16:23:20 2018
New Revision: 260475
URL: https://gcc.gnu.org/viewcvs?rev=260475&root=gcc&view=rev
Log:
PR target/85698
* config/rs6000/rs6000.c (rs6000_output_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
Pat Haugen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
--- Comment #9 from Pat Haugen ---
Author: pthaugen
Date: Thu May 17 16:19:16 2018
New Revision: 260329
URL: https://gcc.gnu.org/viewcvs?rev=260329&root=gcc&view=rev
Log:
PR target/85698
* config/rs6000/rs6000.c (rs6000_output_mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
--- Comment #7 from Pat Haugen ---
So the problem is that we're generating a stxvw4x insn to write to memory,
which corrupts the contents due to both endian behavior and element size (since
we're dealing with halfword/uint16_t elements).
Value i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
--- Comment #6 from Pat Haugen ---
(In reply to Richard Biener from comment #4)
> I can see what the patch does to this testcase on x86_64 - it enables BB
> vectorization of the first two loops after runrolling. I don't see anything
> suspicious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
--- Comment #5 from Pat Haugen ---
(In reply to Richard Biener from comment #4)
>
> Can you claify whether test, ref or train inputs fail for you? I tried
> AVX256, AVX128 and plain old SSE sofar without any issue but ref takes some
> time...
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
--- Comment #3 from Pat Haugen ---
(In reply to Richard Biener from comment #2)
>
> Can you help me with isolating this to a single function inside that file?
> Maybe try sticking __attribute__((optimize("no-tree-vectorize"))) on some
> function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
--- Comment #1 from Pat Haugen ---
Looks like benchmark fails when x264_src/common/dct.c is compiled with r257581.
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, segher at kernel dot
crashing.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Host: powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85600
Pat Haugen changed:
What|Removed |Added
Known to work||8.0
Summary|CPU2006 471.omnetpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85600
--- Comment #2 from Pat Haugen ---
(In reply to Andrew Pinski from comment #1)
> Does adding -fno-lifetime-dse help? This could be a bug in the omnetpp
> sources ...
Nope, still fails.
471.omnetpp: copy 0 non-zero return code (exit code=1, sig
++
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
Target Milestone: ---
Benchmark is failing at runtime, emitting following message at the end before
exiting with rc=1.
** Event #0 T=0.000 ( 0.00s)
Messages: created: 77472
** Event
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737
--- Comment #20 from Pat Haugen ---
(In reply to Richard Biener from comment #18)
> Fixed (hopefully).
Yes, mgrid performance is back. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737
Pat Haugen changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737
--- Comment #14 from Pat Haugen ---
Created attachment 43928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43928&action=edit
r256888 pcom dump
So the difference appears to be occurring in predictive commoning. In the
ipa-cp clone, resid.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #7 from Pat Haugen ---
Created attachment 43901
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43901&action=edit
inline dump
Prior attachment was r257581 dump. This is r257582 dump.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #6 from Pat Haugen ---
Created attachment 43900
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43900&action=edit
inline dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #5 from Pat Haugen ---
A little more detail. 48t.fnsplit splits mainGtU() into 2 functions:
mainGtU(): which contains a few early exit tests and then a call to
mainGtU.part.0()
mainGtU.part.0(): contains the remainder of mainGtU(),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #3 from Pat Haugen ---
(In reply to Jan Hubicka from comment #1)
> Pat, can you try to figure out what value of min-speedup is neeed to recover
> from this regression?
Using r257582, either of the following options restores the behav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #2 from Pat Haugen ---
(In reply to Pat Haugen from comment #0)
>
> Very initial look at profile of bzip2 shows degradation is contained to
> mainSort(), which showed a 54% increase in run cycles. Appears one of the
> calls to mainGt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665
--- Comment #18 from Pat Haugen ---
(In reply to Richard Biener from comment #17)
> Pat, please open a new bug for the regression caused by the fix.
Done, pr85103.
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, hubicka at gcc dot gnu.org,
marxin at gcc dot gnu.org, segher at kernel dot
crashing.org,
wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83497
Pat Haugen changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737
--- Comment #10 from Pat Haugen ---
(In reply to Pat Haugen from comment #9)
> (pr83497, which I'm still digging on). Ignoring output miscompare and just
> timing the two versions built with -fno-tree-vectorize, I see that the
> performance is s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737
--- Comment #9 from Pat Haugen ---
(In reply to Martin Jambor from comment #7)
> Do I understand it correctly that you suspect that the new IPA-CP
> clone that is created from r256888 on is harmful? In that case, you
> want to test that by tryin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737
--- Comment #5 from Pat Haugen ---
Created attachment 43601
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43601&action=edit
ipa-cp dump (r256887)
(In reply to Martin Liška from comment #4)
> Thank you, may I please ask you for the IPA CP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737
--- Comment #3 from Pat Haugen ---
(In reply to Martin Liška from comment #1)
> Isn't that dup of 84149? Can you please tweak --param ipa-cp-eval-threshold
> to value to 200, 300, 400? Can you please attach -fdump-ipa-cp-details file?
I tried th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737
--- Comment #2 from Pat Haugen ---
Created attachment 43589
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43589&action=edit
ipa-cp dump
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, marxin at gcc dot gnu.org,
segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530
Pat Haugen changed:
What|Removed |Added
Summary|[8 Regression] ICE in |[7/8 Regression] ICE in
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530
--- Comment #9 from Pat Haugen ---
(In reply to Andrey Belevantsev from comment #8)
> I will take a look. The ICE is within the code that models the scheduling
> loop in order to get the proper insn ticks and everything for later MD
> processing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530
--- Comment #7 from Pat Haugen ---
Assuming this is a latent selective scheduling bug since I can reproduce with
r243865 by adding -fsched-pressure --param sched-pressure-algorithm=2.
Looking...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83497
--- Comment #4 from Pat Haugen ---
(In reply to Pat Haugen from comment #0)
> mgrid started failing (output miscompare) with r254730. The following
> options demonstrate the failure "-O3 -mcpu=power6 -ffast-math".
Incomplete option set, -m32 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83497
--- Comment #3 from Pat Haugen ---
(In reply to Richard Biener from comment #2)
>
> As far as I see the miscompare is -0.8 vs. 0.18 so it doesn't look like a
> precision issue to me. Does it only happen for power6 / bigendian?
>
Yes, the fail
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, hubicka at gcc dot gnu.org,
rguenth at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201
--- Comment #18 from Pat Haugen ---
(In reply to Martin Liška from comment #16)
> (In reply to Richard Biener from comment #15)
> > SWAPINIT should end up with swaptype_long == 1 I think and swaptype_int == 1
> > for the cases in question. Enfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201
--- Comment #6 from Pat Haugen ---
So I did a bisect of trunk during the GCC 7 development timeframe
(r235035-r247017) and it pointed to r236878 as the point where the failure
started.
+++ gcc/ChangeLog (revision 236878)
@@ -1,3 +1,9 @@
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201
--- Comment #5 from Pat Haugen ---
Current FSF 6 branch works fine, so I have some bisect points. Will comment
further as I find out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81303
--- Comment #15 from Pat Haugen ---
Just confirming that the changes have eliminated the bwaves degradation on
PowerPC that started with r249919.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201
--- Comment #2 from Pat Haugen ---
(In reply to Pat Haugen from comment #0)
>
> It appears to work fine with r254943. I'll start a bisect and post results.
My bisect showed that r254946 was where it started failing on trunk. And yes,
it fails w
: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, hubicka at gcc dot gnu.org,
marxin at gcc dot gnu.org, segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81953
--- Comment #4 from Pat Haugen ---
(In reply to Richard Biener from comment #3)
> The interesting part is also why RTL scheduling doesn't rectify things
> here?
If you're referring to -fsched-pressure, I believe the answer is that those
algorit
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje.gcc at gmail dot com, wschmidt at gcc dot gnu.org
Target Milestone: ---
Host: powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81340
Pat Haugen changed:
What|Removed |Added
CC||mliska at suse dot cz
--- Comment #1 from P
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, wschmidt at gcc dot gnu.org
Target Milestone: ---
Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597
--- Comment #16 from Pat Haugen ---
(In reply to Dmitry Babokin from comment #14)
> Original test case still fails with compiler switches that I've originally
> reported (-fsanitize=undefined).
Is your failure fixed with r248325?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79801
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597
--- Comment #12 from Pat Haugen ---
(In reply to Martin Liška from comment #11)
> Created attachment 41375 [details]
> Patch candidate v2
>
> Can you please test this version? It moves e from 10^6 to 10^5.
That patch works for both the benchmar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597
--- Comment #9 from Pat Haugen ---
(In reply to Martin Liška from comment #8)
>
> Can you please provide a test-case? Or can you dump the sreal values via
> .to_double() ? That can be also hint for us to fix that properly.
I'm trying to reduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80602
--- Comment #7 from Pat Haugen ---
(In reply to Thomas Koenig from comment #6)
> I just committed r248074 which I suspect is the same problem
> (the fix for PR 80765).
>
> If you could just upgrade to the most recent trunk (only
> need to upgrad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80602
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597
--- Comment #7 from Pat Haugen ---
(In reply to Pat Haugen from comment #6)
>
> I just ran into the same ICE and the proposed patch fixes the problem.
Unfortunately the patch introduces the same ICE on another benchmark that used
to build just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80705
--- Comment #1 from Pat Haugen ---
I should have noted that the dumps I was looking at were slp1 and lim4.
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, wschmidt at gcc dot gnu.org
Target Milestone: ---
Host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80357
--- Comment #7 from Pat Haugen ---
(In reply to Bill Schmidt from comment #6)
> That revision enabled -fsched-pressure by default, so it may have been
> latent with -fsched-pressure before then.
Yes, this is a latent bug in the "model" sched-pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80107
Pat Haugen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 371 matches
Mail list logo
