https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94627
--- Comment #2 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:4c994586cbd40a33f223aaaf90887afe97208543
commit r10-8409-g4c994586cbd40a33f223aaaf90887afe97208543
Author: Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94627
--- Comment #3 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:e4490e7771e4df28427cca5e113afe58a7fff8d5
commit r9-8713-ge4490e7771e4df28427cca5e113afe58a7fff8d5
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94627
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95282
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:161fb9dfc886afb70dcfb45a51571df5e3fce9eb
commit r10-8410-g161fb9dfc886afb70dcfb45a51571df5e3fce9eb
Author: Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95282
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952
--- Comment #9 from Mikael Pettersson ---
(In reply to Peter Bergner from comment #7)
> I've tried many 32-bit builds, but cannot reproduce the error. I tried with
> top of the releases/gcc-8 branch, using releases/gcc-8 branch at commit
> 09f22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-07-01
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #6 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #5)
> But it is r31 already before
> shrink-wrapping -- we need some renaming / copying of registers (like
> in Peter's code) to get rid of it. In an example like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #7 from Peter Bergner ---
(In reply to Peter Bergner from comment #6)
> There is ira.c:split_live_ranges_for_shrink_wrap(). I'll have a look to see
> why it's not catching this test case.
So it looks like it only splits pseudos tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #8 from Peter Bergner ---
Interesting, if I rewrite the test case so that foo is a parameter and not a
global var, then we get the code we want:
extern void slowpath(int *);
int
test (int *val, int foo)
{
int ret = foo;
if (__b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #9 from Peter Bergner ---
(In reply to Peter Bergner from comment #8)
> At first, I thought that split_live_ranges_for_shrink_wrap() split this
> nicely, but what I found is that IRA assigned a volatile register to a
> pseudo that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95940
--- Comment #7 from Hans-Peter Nilsson ---
(In reply to Eric Botcazou from comment #6)
> > From the look of it, something is already miscompiled.
>
> No, not at all, it's just warnings turned into errors.
Not obvious, but I see from the comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
--- Comment #6 from G. Steinmetz ---
And reducing especially the directives :
$ cat z1.f90
program p
!$omp target data map(tofrom:n,r)
!$omp target teams reduction(+:r)
!$omp distribute parallel do simd collapse(2)
do i = 1, 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96022
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96023
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95706
Richard Biener changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95584
--- Comment #2 from CVS Commits ---
The master branch has been updated by Mark Eggleston
:
https://gcc.gnu.org/g:8f8ea4a47f3ab0b44b2bbf1c77db6111325d4841
commit r11-1777-g8f8ea4a47f3ab0b44b2bbf1c77db6111325d4841
Author: Mark Eggleston
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
--- Comment #6 from martin.schlipf at damnthespam dot com ---
Sorry, if that has not been clear enough. I already know how to work around
this issue. You can simply check the error flag [if (ierr /= 0) return].
What I do not understand is why gfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92002
Eric Botcazou changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #14 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95940
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #16 from Sergei Trofimovich ---
If I looks at bad-bug.c.190t.dse3 I see 'self' and 'other' refer to the same
.MEM_10 memory location in 'basic block 5'. I think it should not, 'basic block
4' jumps into bb5 only when self != other. Do
101 - 127 of 127 matches
Mail list logo
