https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> >For coremark, this is not only harmful to performance, but also code size.
>
>
> Bad, very bad benchmark
Coremark only handles very very small data sets b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
--- Comment #1 from Andrew Pinski ---
>For coremark, this is not only harmful to performance, but also code size.
Bad, very bad benchmark
SPEC CPU is closer to real code but still bad benchmarks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
Mel Chen changed:
What|Removed |Added
CC||bina2374 at gmail dot com
--- Comment #27 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
Bug ID: 94092
Summary: Code size and performance degradations after
-ftree-loop-distribute-patterns was enabled at -O[2s]+
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781
--- Comment #2 from vfdff ---
I test a more simple testcase, and find the arg_5(D) already get the expected
range, but the _2 = 1 << arg_9 is unexpected.
unsigned int foo (unsigned int arg)
{
unsigned int C03FE = 4;
if (arg + 1 < 4) //
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94091
Bug ID: 94091
Summary: Erroneous __builtin_memcpy warning for character
assignment
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94086
alex_lop at walla dot com changed:
What|Removed |Added
CC||alex_lop at walla dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94089
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94090
Bug ID: 94090
Summary: ICE on mismatched interface
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675
Jan Kratochvil changed:
What|Removed |Added
Version|4.8.2 |9.2.1
--- Comment #6 from Jan Kratochvi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94059
John Paul Adrian Glaubitz changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94066
--- Comment #5 from Patrick Palka ---
Also if we add an explicitly defaulted constructor "U() = default;" to U in the
original test case, then
using GCC 9 /w -std=c++17 we get:
94066.C:16:25: in ‘constexpr’ expansion of ‘foo((&*this))’
94066.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94066
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94089
Bug ID: 94089
Summary: fixincludes of breaks gcc after
glibc-2.31 upgrade
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93729
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |10.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94011
--- Comment #2 from Arseny Solokha ---
I see similar ICE when compiling gcc/testsuite/g++.old-deja/g++.eh/ptrmem1.C
even w/ -fanalyzer alone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94082
--- Comment #2 from Deniz Bahadir ---
Here is a link to Stack Overflow where I originally asked a question about this
behavior: https://stackoverflow.com/q/60572199/3115457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94082
--- Comment #1 from Deniz Bahadir ---
Not: As due to the sourceware/gcc move it seems my original bug-report comment
got lost, I am here re-posting it.
Reading P0202 (wg21.link/p0202) (which made it into C++20) it sounds as if
`__builtin_memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94088
Bug ID: 94088
Summary: [10 Regression] ICE: in extract_insn, at recog.c:2294
(error: unrecognizable insn), or ICE: in
elimination_costs_in_insn, at reload1.c:3538
Product: g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #4 from Carlos O'Ryan ---
(In reply to Andrew Pinski from comment #1)
> >The bug is *not* present on on Fedora:31 where the compiler reports:
>
> I doubt it is version based but rather based on what the CPU you are running
> on.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #5 from Carlos O'Ryan ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > >The bug is *not* present on on Fedora:31 where the compiler reports:
> >
> > I doubt it is version based but rat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #3 from Andrew Pinski ---
https://software.intel.com/sites/default/files/managed/98/4a/DRNG_Software_Implementation_Guide_2.1.pdf
5.3.1 Retry Recommendations
...
If only one thread is calling RDSEED infrequently, it is very unlikely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #1 from Andrew Pinski ---
>The bug is *not* present on on Fedora:31 where the compiler reports:
I doubt it is version based but rather based on what the CPU you are running
on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> >The bug is *not* present on on Fedora:31 where the compiler reports:
>
> I doubt it is version based but rather based on what the CPU you are running
> on.
I M
25 matches
Mail list logo
