https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100114
Richard Biener changed:
What|Removed |Added
Known to work||11.0
--- Comment #7 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081
--- Comment #10 from Richard Biener ---
(In reply to Andrew Macleod from comment #8)
> OMG. Don't bother reducing. I can see the problem.
>
> EVRP is fine, but when wrestrict runs, its quite late, and the CFG has
>
> [local count: 28382607]:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100141
Bug ID: 100141
Summary: Unable to build amdgcn-amdhsa offload accelerator for
MinGW-w64 for both Windows 32-bit and 64-bit
Product: gcc
Version: 10.3.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236
Richard Biener changed:
What|Removed |Added
CC||sudi at gcc dot gnu.org
--- Comment #18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85804
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797
--- Comment #9 from Martin Uecker ---
The behavior of GCC is dangerous as the example in comment #1 show. You can not
reason at all about the generated code. It is not just that the uninitialized
value causes some random choice but it creates si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100140
Bug ID: 100140
Summary: Reference gcc development github mirror - Latest
Development Build
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100138
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2021-04-19
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859
Patrick Palka changed:
What|Removed |Added
CC||pkeir at outlook dot com
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96414
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100139
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100139
Bug ID: 100139
Summary: std::views::{take, drop} don't type erase
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100138
Bug ID: 100138
Summary: ICE with constructor constrained (C++20 Concepts) by
parameter pack length
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100137
--- Comment #1 from Moritz Beutel ---
The problem was discovered in gsl-lite by a user of the library:
https://github.com/gsl-lite/gsl-lite/issues/303
This bug (if confirmed) should probably be added to the -Warray-bounds
meta-bug:
https://gcc.
amp; ptr[len] )
{
++len;
}
return len;
}
int
main()
{
char hello[] = "hello";
span s{ hello, string_length( hello ) };
s.back() = '2';
}
-
`g++ -v` output:
-
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99255
--- Comment #2 from anlauf at gcc dot gnu.org ---
Replacing
class(t) :: x
by
class(t), allocatable :: x
avoids the ICE. Could be an error recovery issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
--- Comment #11 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:aff57bcebe534b1d92f78bdfb89a4001a6d12af2
commit r10-9712-gaff57bcebe534b1d92f78bdfb89a4001a6d12af2
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #4 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
--- Comment #8 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #14 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #13)
> The following variant gives an ICE
>
>type t
>end type
> contains
>function f() result(t)
> character(3) :: c
> c = 'a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104
康桓瑋 changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133
康桓瑋 changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133
--- Comment #2 from 康桓瑋 ---
After actually executing the same code on my local and remote servers, I did
not produce such a result. In both cases, std::copy achieved the expected
high-efficiency performance, so I think this should only be Quick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #18 from Seghe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136
Bug ID: 100136
Summary: ICE, regression, using flag -fcheck=pointer
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
--- Comment #17 from CVS Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:b412ce8e961052e6becea3bc783a53e1d5feaa0f
commit r11-8237-gb412ce8e961052e6becea3bc783a53e1d5feaa0f
Author: Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #20 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #19)
> Why is that needed? It says the location is something like:
>
> In member function ‘info& info::operator=(const info&)’,
>
> or:
>
> In copy constructor ‘inf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534
--- Comment #5 from Paul Thomas ---
This needs to be incorporated into the fix for PR100027. I hope that Jose takes
this PR over :-)
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99446
--- Comment #13 from Bernd Edlinger ---
Hi Nathan,
I've been playing with a variant of c-c++-common/raw-string-6.c
with your patch:
$ cat raw-string-6.c
$ cat raw-string-6.c
// { dg-do compile }
// { dg-options "-std=gnu99" { target c } }
// {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98088
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Hafiz Abid Qadeer
:
https://gcc.gnu.org/g:e4dcb3383bff4c209a918127551cabc56b4171ae
commit r10-9711-ge4dcb3383bff4c209a918127551cabc56b4171ae
Author: Hafiz Abid Q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #13 from Dominique d'Humieres ---
The following variant gives an ICE
type t
end type
contains
function f() result(t)
character(3) :: c
c = 'abc'
end
end
The back trace is
* thread #1, queue = 'com.apple.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99255
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2021-04-18
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100135
Bug ID: 100135
Summary: ICE when using constants in a mdoule
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100134
Bug ID: 100134
Summary: ICE when using a vector in a mdoule
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100132
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2021-04-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133
--- Comment #1 from 康桓瑋 ---
And the libstdc++‘s std::copy is also 8.9 times slower than the equivalent
std::tranfrom:
#include
#include
#include
const std::vector v(100, 42);
static void copy_from_vector(benchmark::State& state)
{
for (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133
Bug ID: 100133
Summary: std::copy extremely slow for random access iterator
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
38 matches
Mail list logo
