https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94344
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393
Alan Modra changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94369
--- Comment #3 from Martin Jambor ---
I did not save the reported number of samples but from the raw sample
numbers and percentage points it seems so:
(562770/0.4013)/(518450/0.3953) = 1.069
Nevertheless, I did save separately obtained perf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94402
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94402
--- Comment #1 from Martin Liška ---
Created attachment 48144
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48144=edit
vect-8.f90.161t.vect dump file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94402
--- Comment #3 from Martin Liška ---
Or scan for vectorized 22-23 loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389
--- Comment #3 from Segher Boessenkool ---
The C frontend dumps nothing for -fdump-lang-all, but the C++ frontend
shows (in .002l.raw) that the ?: is optimised to just a constant zero
there, already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94401
Richard Biener changed:
What|Removed |Added
Target||aarch64
Version|unknown
Hi.
I would like to XFAIL the mentioned test-case. It fails
for quite some time and it has PR created.
Ready to be installed?
Thanks,
Martin
gcc/testsuite/ChangeLog:
2020-03-30 Martin Liska
PR rtl-optimization/87716
* gcc.target/i386/pr57193.c: XFAIL a test-case.
---
Hi Jakub:
Thanks for your correction, I read the doc for the aligned attribute
again[1], it's minimum alignment not restricted alignment, I thought
it should honor to the alignment attribute, Richard Biener
suggested[2] should put an assertion here to make sure never decrease
alignment here, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393
--- Comment #1 from Alan Modra ---
Created attachment 48146
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48146=edit
teach gcc more two insn sequences for constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94402
--- Comment #4 from rguenther at suse dot de ---
On Mon, 30 Mar 2020, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94402
>
> --- Comment #3 from Martin Liška ---
> Or scan for vectorized 22-23 loops?
Works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386
--- Comment #6 from Bill Seurer ---
git g:3fb7f2fbd5f109786922deb5af8fd8dd594a7ba6, r10-7443
make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/pr93600_1.f90
# of expected passes3
git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94412
Bug ID: 94412
Summary: wrong code with -fsanitize=undefined and vectors
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90283
--- Comment #5 from Martin Jambor ---
The numbers from this year are:
- on Intel Cascade Lake server CPU the regression disappeared, if
there ever was one, I don't have Skylake numbers this year.
- On AMD Zen1 CPU, the measured regression is
Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't
expect null indexes for a constructor:
/* ??? Here's to hoping the front end fills in all of the indices,
so we don't have to figure out what's missing ourselves. */
gcc_assert (purpose);
The indexes
On 3/30/20 3:58 PM, Patrick Palka wrote:
On Thu, 26 Mar 2020, Jason Merrill wrote:
On 3/22/20 9:21 PM, Patrick Palka wrote:
This patch relaxes an assertion in tsubst_default_argument that exposes a
latent
bug in how we substitute an array type into a cv-qualified wildcard function
parameter
On 3/29/20 6:42 AM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs, because the FE when processing the statement
expression changes the .VEC_CONVERT internal fn CALL_EXPR into .PHI call.
That is because the internal fn call is recorded in the base.u.ifn
field, which overlaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94406
--- Comment #4 from Martin Jambor ---
For the record, on AMD Zen2 at least, SPEC 2006 410.bwaves also runs
about 12% faster with --param vect-epilogues-nomask=0 (and otherwise
with -Ofast -march=native -mtune=native).
On Thu, 26 Mar 2020, Jason Merrill wrote:
> On 3/22/20 9:21 PM, Patrick Palka wrote:
> > This patch relaxes an assertion in tsubst_default_argument that exposes a
> > latent
> > bug in how we substitute an array type into a cv-qualified wildcard function
> > parameter type. Concretely, the
On Mon, 30 Mar 2020, Patrick Palka wrote:
> On Thu, 26 Mar 2020, Jason Merrill wrote:
>
> > On 3/22/20 9:21 PM, Patrick Palka wrote:
> > > This patch relaxes an assertion in tsubst_default_argument that exposes a
> > > latent
> > > bug in how we substitute an array type into a cv-qualified
On Sat, Mar 28, 2020 at 12:37 PM Steve Kargl
wrote:
>
> On Sat, Mar 28, 2020 at 08:10:38AM +0100, Tobias Burnus wrote:
> > Two remarks:
> >
> > * As the file trigd_lib.inc is shared between libgfortran
> > and gcc/fortran, I wonder whether it should be placed
> > under include/ (under the GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to David Malcolm from comment #6)
> If you have a huge workload, one possible workaround would be to disable
> range tracking, perhaps tweaking line_table->default_range_bits, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90151
--- Comment #1 from Martin Jambor ---
This year's numbers:
- on AMD Zen1, we are still 7.2% worse than GCC 7
- on AMD Zen2, the reegression is 4.6%
- in Intel Cascade Lake server CPU, it is 5.4%
This is all -O2, so perhaps not that important
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94412
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94275
John David Anglin changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411
Bug ID: 94411
Summary: E0.d not supported
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94410
--- Comment #2 from Martin Jambor ---
For the record, SPEC 2006 453.povray is similarly affected, the commit
makes it run 26% slower.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #16 from H.J. Lu ---
(In reply to Yuxuan Shui from comment #15)
> Your code is going to dereference the value stored in the ABS symbol as an
> address (e.g. if the symbol has value 10, your code will access (*(char
> *)10), barring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386
--- Comment #7 from Tobias Burnus ---
(In reply to Bill Seurer from comment #6)
> These were both clean builds run on a powerpc64 power8 LE machine.
I can confirm this on x86-64-gnu-linux; if I use the current trunk and undo
this commit, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94412
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94413
Bug ID: 94413
Summary: auto-vectorization of isfinite raises FP exception
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Hi Fritz,
On 3/30/20 10:20 PM, Fritz Reese via Fortran wrote:
* All included files need dependency; I do not quickly
see whether that' the case.
If one looks at the build, the dependency is automatically
obtained and tracked in …/.deps/*.Po in the build directory.
Hence, no action needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94385
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1cb1986cb596336e688c079b821205ec212a46a3
commit r10-7464-g1cb1986cb596336e688c079b821205ec212a46a3
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94385
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94412
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
On Tue, 2020-03-24 at 10:50 +0100, Jakub Jelinek wrote:
> On Mon, Mar 23, 2020 at 06:00:06PM -0600, Jeff Law via Gcc-patches wrote:
> > +/* Return true if CODE is valid for comparisons of mode MODE, false
> > + otherwise.
> > +
> > + It is always safe to return false, even if the code was
The resolution of CWG issue 1321 clarified that when deciding whether two
expressions involving template parameters are equivalent, two dependent
function calls where the function is named with an unqualified-id are
considered to be equivalent if the name is the same, even if unqualified
lookup
201 - 238 of 238 matches
Mail list logo
