https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
--- Comment #16 from Thomas Schwinge ---
(In reply to rsand...@gcc.gnu.org from comment #13)
> Author: rsandifo
> Date: Thu Feb 1 14:17:07 2018
> New Revision: 257296
>
> URL: https://gcc.gnu.org/viewcvs?rev=257296=gcc=rev
> Log:
> Use range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
--- Comment #14 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Thu Feb 8 15:16:29 2018
New Revision: 257491
URL: https://gcc.gnu.org/viewcvs?rev=257491=gcc=rev
Log:
Use nonzero bits to refine range in split_constant_offset (PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
--- Comment #13 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Thu Feb 1 14:17:07 2018
New Revision: 257296
URL: https://gcc.gnu.org/viewcvs?rev=257296=gcc=rev
Log:
Use range info in split_constant_offset (PR 81635)
This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
--- Comment #12 from rsandifo at gcc dot gnu.org
---
In the end I agree using range info in split_constant_offset is the right way
to go -- sorry for the runaround. Testing a patch for that.
I'll see if that triggers the same predcom problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
--- Comment #11 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #10)
> So, for #c3 testcase on x86_64-linux, I can confirm:
> -bash-4.3$ rm -f pr81635.c.*; /opt/notnfs/gcc-bisect/obj/gcc/cc1.249895
> -quiet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
--- Comment #9 from Aldy Hernandez ---
Author: aldyh
Date: Wed Sep 13 16:14:17 2017
New Revision: 252225
URL: https://gcc.gnu.org/viewcvs?rev=252225=gcc=rev
Log:
Simplify nvptx/slp* test-cases
Use signed loop iteration variable in nvtpx/slp*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
--- Comment #7 from Tom de Vries ---
Author: vries
Date: Tue Aug 1 13:52:14 2017
New Revision: 250778
URL: https://gcc.gnu.org/viewcvs?rev=250778=gcc=rev
Log:
Simplify nvptx/slp* test-cases
Use signed loop iteration variable in nvtpx/slp*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
--- Comment #6 from rsandifo at gcc dot gnu.org
---
Richard predicted that this might happen. I'll see how easy it would
be to get back the SCEV-based analysis (but hopefully at the point
that needs it, rather than in dr_analyze_innermost)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
--- Comment #5 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> Looking at the x86_64 example, the difference between the signed and
> unsigned case happens here in split_constant_offset_1:
Same thing for nvptx.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
--- Comment #4 from Tom de Vries ---
Looking at the x86_64 example, the difference between the signed and unsigned
case happens here in split_constant_offset_1:
...
CASE_CONVERT:
{
/* We must not introduce undefined overflow,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
--- Comment #3 from Tom de Vries ---
(In reply to Richard Biener from comment #2)
> So maybe finally a testcase where that SCEV analysis did sth useful...
>
> x86_64 testcase should be possible with changing the datatype to double?
Yep.
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
Richard Biener changed:
What|Removed |Added
Component|target |tree-optimization
Target
16 matches
Mail list logo
