[Bug sanitizer/96318] FAIL: c-c++-common/asan/strncpy-overflow-1.c * output pattern test with C on Darwin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96318 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/96328] [11 Regression] Single keyword "friend" makes GCC ICE in cp_lexer_previous_token, at cp/parser.c:769 since r11-891-g1dc83b460653c29f

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96328 Martin Liška changed: What|Removed |Added Summary|Single keyword "friend" |[11 Regression] Single

[Bug middle-end/96326] [10/11 Regression] Incorrect loop optimization at -O3 since r10-4803-g8489e1f45b50600c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96326 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org,

[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 --- Comment #2 from ensadc at mailnesia dot com --- See also LWG 3408 (https://wg21.link/lwg3408), which also suggests that the `iterator_traits>` specialization is problematic. I think the standard could remove this specialization (and define `i

[Bug c++/96328] New: Singe keyword "friend" makes GCC ICE in cp_lexer_previous_token, at cp/parser.c:769

s: zlib gcc version 11.0.0 20200726 (experimental) (GCC) Interestingly, this case only occurred in the 20200726 trunk version, it does not crash on 20200725. Thanks, Haoxin

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #9 from Damian Rouson --- (In reply to Dominique d'Humieres from comment #3) > > Do you mean this is F2008 extension? Usually I think of "extension" as describing something non-standard. This is a standard feature. I meant simply

[Bug target/96327] Inefficient increment through pointer to volatile on x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327 --- Comment #4 from Paul McKenney --- Bug 3506 has since been fixed, at least for the example shown in this bug report, as you can see if you look at the godbolt, which shows that both compilers generate a single addl instruction, which is exactl

[Bug target/96327] Inefficient increment through pointer to volatile on x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/3506] weird behaviour when incrementing volatile ints

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506 Andrew Pinski changed: What|Removed |Added CC||paulmckrcu at gmail dot com --- Comment #

[Bug c++/96321] GCC accepts conversion-function-id after the keyword template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96321 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc d

[Bug target/96327] Inefficient increment through pointer to volatile on x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327 Andrew Pinski changed: What|Removed |Added Component|c |target Keywords|

[Bug c/96327] Inefficient increment through pointer to volatile on x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327 --- Comment #1 from Paul McKenney --- This manifests on GCC trunk (see the godbolt.org URL), but was first noted in gcc version 7.5.0. This is specific to x86, but might apply to any other architecture that provides increment-memory instructions

[Bug middle-end/96326] Incorrect loop optimization at -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96326 --- Comment #2 from Pascal Terjan --- No: $ gcc -O3 -Wall -fno-strict-aliasing t.c; ./a.out 24 However -fno-tree-loop-vectorize fixes it: $ gcc -O3 -Wall -fno-tree-loop-vectorize t.c; ./a.out 68

[Bug c/96327] New: Inefficient increment through pointer to volatile on x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327 Bug ID: 96327 Summary: Inefficient increment through pointer to volatile on x86 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Pri

[Bug middle-end/96326] Incorrect loop optimization at -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96326 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Keywords|

[Bug c/96326] New: Incorrect loop optimization at -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96326 Bug ID: 96326 Summary: Incorrect loop optimization at -O3 Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c A

[Bug c++/95820] [10 Regression] ICE in splice_late_return_type, at cp/pt.c:29034

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95820 --- Comment #9 from Marek Polacek --- We usually don't backport fixed for ices-on-invalid but I could be convinced in this case.

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #8 from Steve Kargl --- On Sun, Jul 26, 2020 at 09:35:56PM +, jvdelisle at charter dot net wrote: > > I my too simple terms, when you define the interface and then use > module procedure in the contains, all of the declarations in

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #7 from Damian Rouson --- For context, I nearly always put the procedure definition in a submodule. In this case, I'm attempting to use a tool that needs to parse the code and the tool doesn't support submodules so I moved the proced

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 kargl at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-07-27 Ever confirmed|

[Bug libstdc++/96322] 22_locale/numpunct/members/char/3.cc is outdated: expects grouping=0, actual=3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96322 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot ne

[Bug fortran/90112] internal procedure using module procedure instead of "sibling" internal procedure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90112 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org ---

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 --- Comment #4 from Kirill Chilikin --- Thus, this error (or, more exactly, absence of error) does not depend on the presence of a type-bound procedure with the same name for another derived type. The bug description should probably be modified.

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 --- Comment #3 from Kirill Chilikin --- I tested the reduced test case. It also compiles successfully with version 10.2.0, while it should not. With 8.3.0, an error is reported: $ /usr/bin/gfortran -c -o test.o test2.f90 test2.f90:14:9:

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 --- Comment #2 from Kirill Chilikin --- Yes, there is no type-bound procedure really, and, yes, there is a bug in the code (intentionally: it was called for the wrong variable, which is removed for the test case). The module M2 indeed does not us

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- C

[Bug fortran/96325] New: Invalid call of a type-bound procedure is accepted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 Bug ID: 96325 Summary: Invalid call of a type-bound procedure is accepted Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug libstdc++/96324] New: two semantic errors in polymorphic allocator for Ranges because it is attributed by constexpr.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96324 Bug ID: 96324 Summary: two semantic errors in polymorphic allocator for Ranges because it is attributed by constexpr. Product: gcc Version: 10.2.0 Status: UNCONFIRMED

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 kargl at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW Priority|P3

[Bug c/96317] [8/9/10/11] Int compare optimizations make some errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96317 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3

[Bug c/96315] ICE with variable size struct and openmp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96315 --- Comment #2 from Jakub Jelinek --- I guess the best solution will be to disallow VL structure in OpenMP constructs (well, privatization and mapping thereof), it is so rare extension that it is IMHO not worth the trouble. Will have to check if

[Bug c/96315] ICE with variable size struct and openmp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96315 Martin Liška changed: What|Removed |Added Summary|internal compiler error |ICE with variable size

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- C

[Bug c++/95820] [10 Regression] ICE in splice_late_return_type, at cp/pt.c:29034

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95820 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comme

[Bug preprocessor/96323] [11 Regression] ICE in lex_raw_string, at libcpp/lex.c:1764

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96323 --- Comment #1 from Arseny Solokha --- (In reply to Arseny Solokha from comment #0) > | ^% gcc-11.0.0 -c rozdnj5v.c -wrapper valgrind,-q > rozdnj5v.c:1:24: error: invalid new-line in raw string delimiter <…> Oh, an excessive copy-past

[Bug preprocessor/96323] New: [11 Regression] ICE in lex_raw_string, at libcpp/lex.c:1764

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96323 Bug ID: 96323 Summary: [11 Regression] ICE in lex_raw_string, at libcpp/lex.c:1764 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code

[Bug c++/79504] Overload resolution in trailing-return-type ignores reference qualifier and leads to recursive template instantiation.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79504 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug c++/57255] [meta-bug] ref-qualifiers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57255 Bug 57255 depends on bug 79504, which changed state. Bug 79504 Summary: Overload resolution in trailing-return-type ignores reference qualifier and leads to recursive template instantiation. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79504

[Bug c++/79504] Overload resolution in trailing-return-type ignores reference qualifier and leads to recursive template instantiation.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79504 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:798ff1c3e10c6926263f17704137e8c1a0d39be0 commit r11-2330-g798ff1c3e10c6926263f17704137e8c1a0d39be0 Author: Patrick Palka Date: Su

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #3 from Dominique d'Humieres --- > Fortran 2008 added module subroutine interface bodies specifically to allow > interface bodies in the same scope a the corresponding procedure definitions. > In order to avoid duplication, the standa

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #2 from Damian Rouson --- Hi Dominique, > What do you want to do with your test? I don't understand the question. The submitted code is designed to be a minimal demonstration of the problem so I don't want to do anything with it oth

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-07-26 Status|UNC

[Bug fortran/94327] Bind(c) argument attributes are incorrectly set

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug lto/70611] Compiling binutils with -flto -Wstack-usage fails.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611 --- Comment #7 from Mark Wielaard --- (In reply to Mark Wielaard from comment #6) > Sorry, commented on the wrong bug, the above was meant for bug #93865 Groan, I seem very confused today. That comment was fine. It was me who got confused becaus

[Bug lto/70611] Compiling binutils with -flto -Wstack-usage fails.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611 --- Comment #6 from Mark Wielaard --- (In reply to Mark Wielaard from comment #5) > This is also one of the issues that prevent elfutils to build with LTO. > The workaround is to compile with -Wno-error=stack-usage= added to CFLAGS: > https://sou

[Bug debug/93865] .debug_line with LTO refers to bogus file-names

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 --- Comment #2 from Mark Wielaard --- This also impacts rpm (find-debuginfo.sh) when it tries to extract the source files from binaries compiled with LTO enabled: https://github.com/rpm-software-management/rpm/issues/1207

[Bug libstdc++/96322] New: 22_locale/numpunct/members/char/3.cc is outdated: expects grouping=0, actual=3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96322 Bug ID: 96322 Summary: 22_locale/numpunct/members/char/3.cc is outdated: expects grouping=0, actual=3 Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity:

[Bug target/96206] internal compiler error: in convert_move, at expr.c:218

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96206 --- Comment #2 from Enrico Zini --- Unfortunately I do not have access to gcc 8.4.0. I also found a workaround for the ICE that allowed me to unblock the next step of an immense yak shaving quest to compile Qt5: https://www.enricozini.org/blog/2

[Bug fortran/95585] ICE in gfc_check_reshape, at fortran/check.c:4751

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95585 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:5aa8760e31909d278f28d7d4bb1479d7607228c6 commit r9-8767-g5aa8760e31909d278f28d7d4bb1479d7607228c6 Author: Mark Eggleston D

[Bug fortran/95585] ICE in gfc_check_reshape, at fortran/check.c:4751

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95585 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:7dcd5b38fa91326e120a7ebb6f521330d83ff757 commit r10-8534-g7dcd5b38fa91326e120a7ebb6f521330d83ff757 Author: Mark Eggleston

[Bug fortran/96319] Don't warn for LOGICAL kind conversion with -Wconversion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96319 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978 Thomas Koenig changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org