https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600
--- Comment #3 from Richard Biener ---
Confirmed on arm. The odd thing is that the optimized GIMPLE for foo() is
much nicer:
foo ()
{
[local count: 153437707]:
MEM[(volatile struct t0 *)655404B] ={v} a0[0];
MEM[(volatile struct t0 *)6554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94602
Bug ID: 94602
Summary: wrong semantic check to prvalue as decltype operand
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
On Tue, Apr 14, 2020 at 7:36 PM Nathan Sidwell wrote:
>
> Richard,
> I think 94454 is a P1. We have an inconsistency between specialization
> hasher and equality. arguments may compare equal but hash differently.
It doesn't seem to be a regression so bug priority has no meaning ;)
But yeah, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495
Martin Liška changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94597
Martin Liška changed:
What|Removed |Added
Known to fail||10.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94598
Martin Liška changed:
What|Removed |Added
Known to work||9.3.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94596
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
--- Comment #8 from Andrew Pinski ---
(In reply to fdlbxtqi from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > https://github.com/zerovm/glibc/commit/9f3f5229848390ae921f77c92f666ca6f0bff
> >
> > is more the correct fix.
> > Or u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
--- Comment #7 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #6)
> https://github.com/zerovm/glibc/commit/9f3f5229848390ae921f77c92f666ca6f0bff
>
> is more the correct fix.
> Or use an older version of Bison.
But I am using windows.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601
--- Comment #5 from Andrew Pinski ---
(In reply to fdlbxtqi from comment #4)
> Created attachment 48276 [details]
> Let me try whether this patch works.
That is wrong. See the duplicated bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
--- Comment #6 from Andrew Pinski ---
https://github.com/zerovm/glibc/commit/9f3f5229848390ae921f77c92f666ca6f0bff
is more the correct fix.
Or use an older version of Bison.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601
--- Comment #4 from fdlbxtqi ---
Created attachment 48276
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48276&action=edit
Let me try whether this patch works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
--- Comment #5 from Andrew Pinski ---
Looks like the problem is with Bison 3.0 and above with the internal intl
BASH has/had the same issue:
https://savannah.gnu.org/support/?109469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
Andrew Pinski changed:
What|Removed |Added
CC||euloanty at live dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601
--- Comment #2 from Andrew Pinski ---
(In reply to fdlbxtqi from comment #1)
> Can you guys stop using macros and migrate to namespace?
This is C code .
Plus this code has not changed and is really pulled in from upstream (libintl).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601
--- Comment #1 from fdlbxtqi ---
Can you guys stop using macros and migrate to namespace?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601
Bug ID: 94601
Summary: Build Latest GCC on MinGW-w64 failed. Conflict macro
PLURAL_PARSE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19856
--- Comment #5 from Bryan Henderson ---
A quick check of the latest manual shows the same description, and a quick
strace of GCC 6.3 shows the same behavior, so my guess is no one has touched
this area.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94584
jcmvbkbc at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92777
Jason Cobb changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89743
Jason Cobb changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89657
Jason Cobb changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 89657, which changed state.
Bug 89657 Summary: [concepts] ICE when calling lambda returning
requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89657
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94475
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94584
--- Comment #1 from CVS Commits ---
The master branch has been updated by Max Filippov :
https://gcc.gnu.org/g:a288e202c5e50704968685fc2922d159335be2cb
commit r10-7728-ga288e202c5e50704968685fc2922d159335be2cb
Author: Max Filippov
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #10 from dave.anglin at bell dot net ---
On 2020-04-14 6:08 p.m., sgk at troutmask dot apl.washington.edu wrote:
> So, hppa64 has REAL(16), but it does not use __float128 or
> GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Inste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59673
Cameron changed:
What|Removed |Added
CC||dacamara.cameron at gmail dot
com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600
--- Comment #2 from Hans-Peter Nilsson ---
For various targets and gcc versions I've noticed this bug as far back as
gcc-4.7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600
Hans-Peter Nilsson changed:
What|Removed |Added
Last reconfirmed||2020-04-14
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600
Bug ID: 94600
Summary: Ignored volatile specifier on loop unrolling and
bitfield misoptimization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94562
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #9 from Steve Kargl ---
On Tue, Apr 14, 2020 at 08:48:47PM +, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #8 from dave.anglin at bell dot net ---
> On 2020-04-14 2:12 p.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94554
--- Comment #3 from Daniel Krügler ---
(In reply to Melissa from comment #0)
> Clang errors on this case, so it's possible that my code is invalid: Is it
> legal to compare a function pointer against null in a constant-expression?
The example is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587
--- Comment #8 from Patrick J. LoPresti ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Patrick J. LoPresti from comment #5)
> > I did not use -ffp-contract=fast nor -funsafe-math-optimizations nor
> > -ffast-math. Yet the statemen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69075
--- Comment #8 from Charles ---
It is not for me as I explained in Comment 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #53 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #19 from Jakub Jelinek ---
Since Richard's change, assign_parm_data_one has the arg member with
function_arg_info type, and that class has a user-provided default constructor.
Perhaps for old GCC we could instead of
*data = assign_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #18 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #17)
> So, what exactly happens? Does GCC 4.2 e.g. fail to initialize all members
> to zeros in the
> - memset (data, 0, sizeof (*data));
> + *data = assign_parm_data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94562
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:f5fa62ed19a1c85cda920bbe05eb075d8f2a0b42
commit r10-7725-gf5fa62ed19a1c85cda920bbe05eb075d8f2a0b42
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #8 from dave.anglin at bell dot net ---
On 2020-04-14 2:12 p.m., sgk at troutmask dot apl.washington.edu wrote:
> #ifdef HAVE_GFC_REAL_16
> #endif
This one.
>
> Is hppa64 claiming support for a REAL type that it actually
> doesn't supp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587
--- Comment #7 from Jakub Jelinek ---
Note, clang defaults to -ffp-contract=on which is like =fast (except when you
use FP_CONTRACT pragma).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587
--- Comment #6 from Andrew Pinski ---
(In reply to Patrick J. LoPresti from comment #5)
> I did not use -ffp-contract=fast nor -funsafe-math-optimizations nor
> -ffast-math. Yet the statements were contracted. So the documentation has a
> bug.
N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94025
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
--- Comment #13 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:a126a1577ffcbf62d97723b35d343bdff014bb40
commit r10-7724-ga126a1577ffcbf62d97723b35d343bdff014bb40
Author: Iain Sandoe
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94048
--- Comment #2 from José Rui Faustino de Sousa ---
Please ignore the last attachment I mixed up the bug report...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022
--- Comment #3 from José Rui Faustino de Sousa ---
Created attachment 48274
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48274&action=edit
The cleaned-up version with pointer and bind(c) tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94048
--- Comment #1 from José Rui Faustino de Sousa ---
Created attachment 48273
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48273&action=edit
The cleaned-up version with pointer and bind(c) tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94542
--- Comment #1 from CVS Commits ---
The master branch has been updated by Aaron Sawdey :
https://gcc.gnu.org/g:aba6453890ce1754b7d1c01a67612766690ff15e
commit r10-7722-gaba6453890ce1754b7d1c01a67612766690ff15e
Author: Aaron Sawdey
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022
--- Comment #2 from José Rui Faustino de Sousa ---
Hi Thomas!
The fix to this problem seems to be simple:
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index fdca9cc..9ad885b 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587
--- Comment #5 from Patrick J. LoPresti ---
(In reply to Andrew Pinski from comment #4)
>
> Note this is true even without using intrinsics really. You can get the
> same behavior you are seeing with using standard C code.
Yes, which is one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83138
Hubert Tong changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94571
--- Comment #5 from Jakub Jelinek ---
(In reply to Marek Polacek from comment #4)
> I think that won't handle
>
> auto x(1), [e,f] = test2;
>
> where we should also say what clang says (or at least give inform()).
That gives
error: expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93207
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 93207, which changed state.
Bug 93207 Summary: [concepts] Variadic concepts refuse to compile when function
definition is not inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93207
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93207
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:52d4ed1d96d48e2ceafc89a8734e14de3d5de3fe
commit r10-7721-g52d4ed1d96d48e2ceafc89a8734e14de3d5de3fe
Author: Patrick Palka
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
Iain Sandoe changed:
What|Removed |Added
Component|target |c++
--- Comment #12 from Iain Sandoe ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94593
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83138
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69075
--- Comment #7 from Arseny Solokha ---
Is it still an issue? I cannot reproduce it from g++ 6.4 onwards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85278
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 85278, which changed state.
Bug 85278 Summary: [concepts] Garbled diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85278
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85278
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:58a29af8ef14bfa2d595deed5144891bff821eff
commit r10-7720-g58a29af8ef14bfa2d595deed5144891bff821eff
Author: Patrick Palka
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94599
Bug ID: 94599
Summary: Invalid constructor for derived types with recursive
allocatable components
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #7 from Steve Kargl ---
On Tue, Apr 14, 2020 at 05:24:51PM +, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #6 from dave.anglin at bell dot net ---
> On 2020-04-14 11:40 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48655
Nick changed:
What|Removed |Added
CC||nickpapior at gmail dot com
--- Comment #9 from N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94598
Bug ID: 94598
Summary: ICE in verify_sra_access_forest, at tree-sra.c:2360
with -O1 or higher
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
ined conversion operator.
GCC INFO:
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20200414/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
Richard,
I think 94454 is a P1. We have an inconsistency between specialization
hasher and equality. arguments may compare equal but hash differently.
nathan
--
Nathan Sidwell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #18 from Martin Jambor ---
I posted a patch to fix this for review to the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543659.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93500
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454
--- Comment #12 from Nathan Sidwell ---
Created attachment 48270
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48270&action=edit
asserts to trigger it
I have found the cause, but not the underlying reason. We have template
arguments that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94434
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94434
--- Comment #4 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:9707b593f88041e74e5cf5640ec64fea13a0387c
commit r10-7719-g9707b593f88041e74e5cf5640ec64fea13a0387c
Author: Martin Jambor
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #6 from dave.anglin at bell dot net ---
On 2020-04-14 11:40 a.m., sgk at troutmask dot apl.washington.edu wrote:
> After '#include ' in trigd.c, add
>
> #if (__STDC_VERSION__ < 199901L)
> #define fmaf(a,b,c) ((a)*(b)+(c))
> #define fma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93948
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
--- Comment #11 from Christophe Lyon ---
(In reply to Wilco from comment #10)
>
> For example:
>
> int x;
> int f1 (void) { return x; }
>
> with eg. -O2 -mcpu=cortex-m0 -mpure-code I get:
>
> movsr3, #:upper8_15:#.LC1
> ls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed||2020-04-14
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110
Thomas Koenig changed:
What|Removed |Added
Severity|normal |enhancement
Summary|Erroneous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270
--- Comment #8 from CVS Commits ---
The releases/gcc-8 branch has been updated by Thomas Kथà¤nig
:
https://gcc.gnu.org/g:5e67ee3aa084a54f59c0848c32c17faddbb04c4c
commit r8-10179-g5e67ee3aa084a54f59c0848c32c17faddbb04c4c
Author: Thomas König
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592
--- Comment #6 from Paco Arjonilla ---
Thanks for supporting this feature. I think it is one of the core features that
modern C++ should have.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592
--- Comment #5 from Marek Polacek ---
{} as a template argument is currently only supported by GCC as an extension,
but I raised this on the core C++ list and it seems that the the conclusion is
that we want this to work, though there's no CWG fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94596
Bug ID: 94596
Summary: possible false positive when analyze OVS macro
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #5 from Steve Kargl ---
On Tue, Apr 14, 2020 at 12:55:45PM +, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #4 from dave.anglin at bell dot net ---
> On 2020-04-13 11:02 p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110
--- Comment #2 from José Rui Faustino de Sousa ---
Hi Thomas!
IIRC assumed-size arrays are implemented has packaged descriptor less arrays.
In order to point to them or to pass them to a procedure expecting an assumed
or deferred-shape array one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587
Patrick J. LoPresti changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034
--- Comment #8 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:b256222910cfa4a9b2b477dff8954e51fdc36bb9
commit r10-7718-gb256222910cfa4a9b2b477dff8954e51fdc36bb9
Author: Patrick Palka
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94593
--- Comment #2 from Jakub Jelinek ---
error: Only one unified_shared_memory clause can appear on a requires directive
in a single translation unit
is incorrect, dunno where they took it from.
The same clause can't appear multiple times on the sam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578
--- Comment #4 from Thomas Koenig ---
Looks like span is not handled in reshape (at all).
It will be interesting to see how other intrinsics
such as maxloc and just about everything else
handles this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94593
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
--- Comment #10 from Wilco ---
(In reply to Christophe Lyon from comment #8)
> > Adding Christophe. I'm thinking the best approach right now is to revert
> > given -mpure-code doesn't work at all on Thumb-1 targets - it still emits
> > literal po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053
Richard Biener changed:
What|Removed |Added
Target Milestone|10.0|9.4
Known to work|
1 - 100 of 174 matches
Mail list logo
