https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94418
Bug ID: 94418
Summary: Please make reverse_iterator nothrow constructible
when possible
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375
--- Comment #4 from Hongtao.liu ---
(In reply to Martin Jambor from comment #3)
> (In reply to Hongtao.liu from comment #1)
> > Try -mprefer-vector-width=128,256-bit vectorization is not helpful for 548
> > according to our experience.
>
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94401
--- Comment #5 from Kewen Lin ---
Created attachment 48150
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48150=edit
untested patch
This can fix the REG failures on aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94418
--- Comment #1 from Rafael Avila de Espindola ---
For what it is worth, libc++ implements this. Given
static_assert(std::is_nothrow_copy_constructible_v::reverse_iterator>);
With libstdc++:
$ clang -S test3.cc -std=c++17
test3.cc:3:1: error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990
Andrew D'Addesio changed:
What|Removed |Added
CC||modchipv12 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411
--- Comment #2 from Bill Long ---
Thanks for the quick reply. Is there a predicted release date for 10.1?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394
--- Comment #5 from ammy.yi ---
(In reply to Martin Liška from comment #4)
> (In reply to ammy.yi from comment #3)
> > Actually, there is some random kernel panic here.
> >
> > The following steps may reproduce this issue:
> >
> > 1. Enable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307
--- Comment #5 from Kees Cook ---
Hi! I recently learned that Clang has -fsanitizer-minimal-runtime that is very
close to what I was expecting to use:
https://bugs.llvm.org/show_bug.cgi?id=45295
That is close to what you're already suggesting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411
--- Comment #3 from Steve Kargl ---
On Tue, Mar 31, 2020 at 04:47:04AM +, longb at cray dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411
>
> --- Comment #2 from Bill Long ---
> Thanks for the quick reply. Is there a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420
Bug ID: 94420
Summary: ICE error: insn does not satisfy its constraints
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94401
Kewen Lin changed:
What|Removed |Added
CC||segher at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94419
Bug ID: 94419
Summary: accepting wrong programs because compiler error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94417
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375
--- Comment #5 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #4)
> (In reply to Martin Jambor from comment #3)
> > (In reply to Hongtao.liu from comment #1)
> > > Try -mprefer-vector-width=128,256-bit vectorization is not helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94417
H.J. Lu changed:
What|Removed |Added
Summary|-fcf-protection |-fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #23 from Fangrui Song ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Yuxuan Shui from comment #17)
> > Sorry, I am here to report a bug, not to find a workaround for my use case.
>
> I gave you the correct usage for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94415
Bug ID: 94415
Summary: Implement DR 2237: Can a template-id name a
constructor?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94415
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94416
Bug ID: 94416
Summary: passing a restricted pointer to a function can be
assumed not to modify an accessed object
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389
--- Comment #7 from Segher Boessenkool ---
(In reply to felix from comment #6)
> I don’t mind the transformation being applied.
That is not what I said. I said the **language frontend** should not
do this. A language frontend should give an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93573
--- Comment #7 from joseph at codesourcery dot com ---
Passing a variable-size struct or union by value to a non-nested function
seems very questionable (the function couldn't be declared with a matching
prototype), but perhaps that doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #17 from Yuxuan Shui ---
(In reply to H.J. Lu from comment #16)
> (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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #20 from Yuxuan Shui ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Yuxuan Shui from comment #17)
> > Sorry, I am here to report a bug, not to find a workaround for my use case.
>
> I gave you the correct usage for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #18 from Andrew Pinski ---
(In reply to Yuxuan Shui from comment #17)
> Sorry, I am here to report a bug, not to find a workaround for my use case.
I gave you the correct usage for your use case. If you don't like it is not my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Yuxuan Shui changed:
What|Removed |Added
Resolution|WORKSFORME |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93431
--- Comment #2 from John David Anglin ---
Does this test need -fcommon option?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392
--- Comment #3 from joseph at codesourcery dot com ---
I'm not sure the existing infinite loop removal is valid for any C
standard version. The C (C11 and later) rule against infinite loops only
applies when the loop is written as an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94417
Bug ID: 94417
Summary: -fcf-protection -mcmodel=large is broken
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Yuxuan Shui changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #22 from Yuxuan Shui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90711
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:5830f753559f25a5dabcc3507bffa611c6b575a6
commit r10-7465-g5830f753559f25a5dabcc3507bffa611c6b575a6
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94408
--- Comment #3 from michalak at ucar dot edu ---
Thank you, I've verified that removing the interface definitions works for this
test program and provides a workaround for the original code from which this
example was pulled. I'm not sure that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962
S. Davis Herring changed:
What|Removed |Added
CC||herring at lanl dot gov
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94414
Bug ID: 94414
Summary: only `--` gives constexpr
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364
--- Comment #1 from Richard Biener ---
Huh, looks like this is the (patched by us) memory copying done in spec_qsort?
I wonder if you can re-measure with our patching undone but then with
-fno-strict-aliasing (though I think that only was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
--- Comment #9 from fdlbxtqi ---
https://github.com/microsoft/WSL/issues/3898
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #11 from Yuxuan Shui ---
(In reply to Andrew Pinski from comment #8)
> Also it is wrong for a person to assume a normal C variable could be
> SHN_ABS; that is the bug here. It is a bug in the user code.
> I showed up to fix it by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
--- Comment #3 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #2)
> But the ICE happens because the result from the function at transform time
> does not match that at analysis time.
>
> Richard?
Looks like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94400
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394
--- Comment #3 from ammy.yi ---
Actually, there is some random kernel panic here.
The following steps may reproduce this issue:
1. Enable gcov in kconfig
2. build kernel and boot to system
3. Do following load/unload modules steps
modprobe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375
Richard Biener changed:
What|Removed |Added
Blocks||53947
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397
Martin Liška changed:
What|Removed |Added
Known to fail||10.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87528
--- Comment #8 from Martin Jambor ---
Do I understand correctly that this is fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368
Jakub Jelinek changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368
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=94392
Richard Biener changed:
What|Removed |Added
Summary|Infinite loops are |[10 Regression] Infinite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
Bug ID: 94398
Summary: ICE: in vectorizable_load, at tree-vect-stmts.c:9173
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
Richard Biener changed:
What|Removed |Added
Target||aarch64
CC|rguenther
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94400
Bug ID: 94400
Summary: 531.deepsjeng_r is 7% slower at -O2 -march=znver2 than
GCC 9
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94369
--- Comment #2 from Richard Biener ---
The profile looks unconclusive, the # samples differ but evenly increase. The
overall number of samples is missing - does that increase by 6-7%?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394
--- Comment #4 from Martin Liška ---
(In reply to ammy.yi from comment #3)
> Actually, there is some random kernel panic here.
>
> The following steps may reproduce this issue:
>
> 1. Enable gcov in kconfig
> 2. build kernel and boot to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
--- Comment #1 from z.zhanghaijian at huawei dot com ---
(gdb) bt
#0 aarch64_builtin_support_vector_misalignment (mode=E_VNx4SFmode,
type=0xb79ec2a0, misalignment=-1, is_packed=false)
at ../../gcc-git/gcc/config/aarch64/aarch64.c:17510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94399
Bug ID: 94399
Summary: analyzer reports false positives for stuff freed using
__attribute__((cleanup()))
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373
--- Comment #4 from Richard Biener ---
Note the cited commit simply caused more complete unrolling to happen. Too
much actually which is why I reverted it. Note GCC 9.2 does not have that more
unrolling so the difference must be something else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387
--- Comment #5 from Richard Biener ---
volatile semantics on misaligned fields and strict-align targets cannot be
honored. I suggest you add appropriate __attribute__((aligned(..))) if you
know the whole structure is aligned and just want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94396
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387
--- Comment #6 from Petro Karashchenko ---
Richard Biener thank you for suggestion, but __attribute__((aligned(..))) is
applied only to the base address of the struct, hence to the first field only,
so if I'm having other fields tightly packed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90332
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90332
--- Comment #11 from rguenther at suse dot de ---
On Mon, 30 Mar 2020, clyon at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90332
>
> Christophe Lyon changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314
--- Comment #7 from Martin Liška ---
> It should be sufficient to check whether they have the same DECL_CONTEXT.
This seems to work. I'm testing a patch candidate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368
--- Comment #4 from Jakub Jelinek ---
Testcase that still FAILs on the trunk:
/* PR target/94368 */
/* { dg-do compile { target fpic } } */
/* { dg-options "-fpic -O1 -fcommon" } */
int b, c, d, e, f, h;
short g;
int foo (int) __attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375
--- Comment #3 from Martin Jambor ---
(In reply to Hongtao.liu from comment #1)
> Try -mprefer-vector-width=128,256-bit vectorization is not helpful for 548
> according to our experience.
I have seen this helping on one system running SLES 15.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373
--- Comment #3 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #2)
> I think
> Change lea_cost from 2 --> 1 in skylake can fix this regressions.
>
> Since it's stage4 now, i hold my patch.
Classify: it's for -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394
--- Comment #2 from Martin Liška ---
If I remember correctly kernel implements its own "runtime library" libgcov, so
I would expect a crash somewhere in it. Anyway, a reasonable reproducer would
be needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94348
--- Comment #4 from CVS Commits ---
The releases/gcc-9 branch has been updated by Tobias Burnus
:
https://gcc.gnu.org/g:79166bd28d0296a510cc65aa21cd6797eba51144
commit r9-8423-g79166bd28d0296a510cc65aa21cd6797eba51144
Author: Tobias Burnus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94348
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93597
Richard Biener changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #14 from Richard Biener ---
(In reply to sandra from comment #13)
> Well, no. The problem is that the scheduler is moving
>
> ldw r2, 0(r4)
>
> ahead of
>
> stw zero, 0(r5)
>
> which is incorrect because
ing SELECT TYPE
at (1)
$gfortran-10 --version
GNU Fortran (GCC) 10.0.1 20200330 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94396
Bug ID: 94396
Summary: [8/9/10 Regression] fp16 feature bits not passed on to
assembler from Armv8.4-a and up.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94356
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94401
--- Comment #2 from Christophe Lyon ---
The defaults are OK (either native or cross aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94402
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94401
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94402
--- Comment #2 from Richard Biener ---
It only fails on systems with the libmvec enablement and vectorizes one more
loop. Not sure how to "fix" the testcase (split out the offending function,
add some dg-target looking for libmvec enablement?)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389
--- Comment #5 from Segher Boessenkool ---
The language frontend shouldn't do this kind of code transformations, whether
you think the warning should warn or not here, imo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94344
--- Comment #5 from Stefan Schulze Frielinghaus
---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 48145 [details]
> gcc10-pr94344.patch
LGTM. I did some tests (including the initial one) which all succeeded in
detecting a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
--- Comment #7 from Jakub Jelinek ---
--- gcc/config/aarch64/aarch64.c.jj 2020-03-18 12:51:41.051640609 +0100
+++ gcc/config/aarch64/aarch64.c2020-03-30 16:28:29.133717645 +0200
@@ -16030,6 +16030,16 @@ aapcs_vfp_sub_candidate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94298
--- Comment #5 from Vladimir Makarov ---
I think that the root of the problem is that IRA on register cost calculation
sub-pass chooses memory for the pseudo.
It happens because the current algorithm (which is just an adoption of old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94281
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10 Regression] g++:|[8/9 Regression] g++:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
--- Comment #5 from Jakub Jelinek ---
Smaller fix applied to GCC 10, larger one queued for GCC 11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87716
--- Comment #9 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:291aa50a63194245ad3ab8bd584f9c0286c5b44c
commit r10-7459-g291aa50a63194245ad3ab8bd584f9c0286c5b44c
Author: Martin Liska
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94402
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94402
--- Comment #6 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:3a9db91bee496712656e0f8aecf55f39cffd8413
commit r10-7458-g3a9db91bee496712656e0f8aecf55f39cffd8413
Author: Martin Liska
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #15 from Yuxuan Shui ---
(In reply to H.J. Lu from comment #12)
> (In reply to Yuxuan Shui from comment #11)
> > (In reply to Andrew Pinski from comment #8)
> > > Also it is wrong for a person to assume a normal C variable could be
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ec919cfcef8d7fcbaab24d0e0d472c65e5329ca6
commit r10-7457-gec919cfcef8d7fcbaab24d0e0d472c65e5329ca6
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug ID: 94404
Summary: [meta-bug] C++ core issues
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94406
--- Comment #1 from Martin Jambor ---
For the record, the collected profiles both for the traditional
"cycles:u" event and (originally unintended) "ls_stlf:u" event are
below:
-Ofast -march=native -mtune=native
# Samples: 894K of event
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94408
--- Comment #1 from michalak at ucar dot edu ---
Here is a slightly more simplified version of the test.F90 program that still
demonstrates the error with gcc 9.1.0 (below). The namelist_t type from the
previous reproducer code turns out not to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94406
--- Comment #3 from Martin Jambor ---
One more data point, binary compiled for cascadelake does not run on
Zen2, but one for znver2 runs on Cascade Lake and it makes no
difference in run-time.
If disapling epilogues helps on Intel, the
1 - 100 of 164 matches
Mail list logo
