[Bug middle-end/99797] accessing uninitialized automatic variables

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

[Bug c/100140] New: Reference gcc development github mirror - Latest Development Build

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

[Bug c++/100138] ICE with constructor constrained (C++20 Concepts) by parameter pack length

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100138 Patrick Palka changed: What|Removed |Added Last reconfirmed||2021-04-19 Ever confirmed|0

[Bug c++/99859] constexpr evaluation with member function is incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 Patrick Palka changed: What|Removed |Added CC||pkeir at outlook dot com --- Comment

[Bug c++/96414] Second char relation test incorrect with constexpr dynamic allocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96414 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/100139] std::views::{take, drop} don't type erase

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100139 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment

[Bug libstdc++/100139] New: std::views::{take, drop} don't type erase

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:

[Bug c++/100138] New: ICE with constructor constrained (C++20 Concepts) by parameter pack length

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:

[Bug c++/100137] -Werror=array-bounds false positive:"subscript -1 is outside array bounds"

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:

[Bug c++/100137] New: -Werror=array-bounds false positive:"subscript -1 is outside array bounds"

} 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/bin/g++ Target: x86_64-linux-gnu Configured with: .

[Bug fortran/99255] ICE in gfc_dt_upper_string, at fortran/module.c:441

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.

[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED

[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'

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

[Bug libstdc++/100133] std::copy extremely slow for random access iterator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #4 from Jonathan

[Bug middle-end/99797] accessing uninitialized automatic variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 Andrew Pinski changed: What|Removed |Added Component|c |middle-end --- Comment #8 from Andrew

[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747

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 =

[Bug middle-end/100104] std::transform is 1.5 times faster than std::copy with -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104 康桓瑋 changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

[Bug libstdc++/100133] std::copy extremely slow for random access iterator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133 康桓瑋 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/100133] std::copy extremely slow for random access iterator

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

[Bug rtl-optimization/99927] Wrong code since r11-39-gf9e1ea10e657af9f

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #18 from

[Bug fortran/100136] New: ICE, regression, using flag -fcheck=pointer

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:

[Bug tree-optimization/99927] [11 Regression] Wrong code since r11-39-gf9e1ea10e657af9f

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

[Bug middle-end/88175] GCC should not warn within implicit copy-constructor (or should report the implicit function in a special way)

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

[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments

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

[Bug preprocessor/99446] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005 since r11-6325

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 } } //

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

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

[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747

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 =

[Bug fortran/99255] ICE in gfc_dt_upper_string, at fortran/module.c:441

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99255 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-04-18

[Bug c++/100135] New: ICE when using constants in a mdoule

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++

[Bug c++/100134] New: ICE when using a vector in a mdoule

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++

[Bug fortran/100132] Optimization breaks pointer association

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

[Bug libstdc++/100133] std::copy extremely slow for random access iterator

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

[Bug libstdc++/100133] New: std::copy extremely slow for random access iterator

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