https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67076
Jürgen Reuter changed:
What|Removed |Added
CC||dominiq at lps dot ens.fr,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466
--- Comment #21 from Marc Glisse ---
(In reply to Daniel Elliott from comment #20)
> still clang is 1.64x faster. had a look at the assembly. My limited
> understanding makes me think that the ucomiss is not fully vectorized and
> the clang one i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81837
--- Comment #10 from Paolo Carlini ---
In my opinion we should *always* set it when closing bugs: many, many, users
complain that isn't always clear which is the first release where a bug is
fixed. Actually, we should also spend more time on keep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67076
--- Comment #5 from janus at gcc dot gnu.org ---
I also see it working with gfortran 7.2 and OpenCoarrays 1.9.1 (as packaged in
Ubuntu 17.10).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466
--- Comment #22 from Daniel Elliott ---
(In reply to Marc Glisse from comment #21)
> (In reply to Daniel Elliott from comment #20)
> > still clang is 1.64x faster. had a look at the assembly. My limited
> > understanding makes me think that the u
Hello,
#include
int main(void)
{
char buf[10];
return snprintf(buf, 0, "string");
}
GCC simplifies it to
main:
mov eax, 6
ret
but 0 is correct I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85381
Tom de Vries changed:
What|Removed |Added
Keywords||openacc
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
--- Comment #8 from Alexander Monakov ---
Unfortunately the above doesn't fully address the issue, as schedulers and
other passes still have no idea that DF makes those assumptions and will allow
reordering of asms:
register int r asm("ebx");
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85423
Andrey Belevantsev changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |abel at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85490
Bug ID: 85490
Summary: Missing STAGE4_CFLAGS in bootstrap-cet.mk
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
--- Comment #5 from Dominique d'Humieres ---
It seems to work with 7.3.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67076
Dominique d'Humieres changed:
What|Removed |Added
CC|dominiq at lps dot ens.fr |
--- Comment #6 from Domin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85491
Bug ID: 85491
Summary: [8 Regression] scimark LU Decomposition test 15%
slower than GCC 7, 30% slower than peak
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85491
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #36 from David Brown ---
(In reply to Martin Sebor from comment #34)
> I think in the use case below:
>
>struct { int i; char buf[4]; } s, r;
>*(float *)s.buf = 1.;
>r = s;
>
> the aggregate copy has to be viewed as a r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #37 from David Brown ---
(In reply to Martin Sebor from comment #35)
> Here are the proposed changes:
>
> Pointer Provenance:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2219.htm#proposed-technical-
> corrigendum
>
> Trap Rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
--- Comment #6 from Zaak ---
Thanks, I'll check it out.
On Sat, Apr 21, 2018 at 8:20 AM dominiq at lps dot ens.fr <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
>
> --- Comment #5 from Dominique d'Humiere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85220
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
Bitterblue changed:
What|Removed |Added
CC||cantabile.desu at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85485
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85485
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67076
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #17 from Andrew Pinski ---
I think some of this is due to SLOW_BYTE_ACCESS being set to 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71636
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52345
--- Comment #4 from Andrew Pinski ---
The generic rule is:
original 3 expressions;
(((int)b) | i) == 0 -> (b == 0) & (i == 0) -> ~b & (i == 0)
(4 expressions; maybe 3 if b is a comparison and single use)
(((int)b) | i) != 0 -> (b != 0) | (i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32648
--- Comment #4 from Andrew Pinski ---
For ARM64 we get:
f1:
ubfxx1, x0, 5, 1
ubfxx0, x0, 3, 1
eor w0, w1, w0
ret
f2:
eor w0, w0, w0, lsl 2
ubfxx0, x0, 5, 1
ret
Which mi
26 matches
Mail list logo
