[Bug bootstrap/77510] genautomata memory footprint for MIPS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77510 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org Last

[Bug c++/95944] New: Concept diagnostic has multiple copies of irrelevant type and displays correct type incorrectly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95944 Bug ID: 95944 Summary: Concept diagnostic has multiple copies of irrelevant type and displays correct type incorrectly Product: gcc Version: 10.0 Status: UNCONFIRMED

[Bug fortran/85541] ICE with parameterized derived type (PDT) and allocate

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85541 Fred Krogh changed: What|Removed |Added CC||siteg at mathalacarte dot com --- Comment

[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 prop_design at protonmail dot com changed: What|Removed |Added CC||prop_design at

[Bug fortran/95880] [9/10/11 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030 since r11-524-geb069ae8819c3a84

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95880 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot

[Bug fortran/95880] [9/10/11 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030 since r11-524-geb069ae8819c3a84

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

[Bug target/95943] New: arc -mbig-endian "inappropriate arguments" error from assembler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95943 Bug ID: 95943 Summary: arc -mbig-endian "inappropriate arguments" error from assembler Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #4 from Segher Boessenkool --- Or even just { target le } yes. You can put that as the selector on just the scan tests, and even do a separate BE version as well. You can quote regexps with {} instead of "", that makes them much

[Bug c/82206] -Wformat-nonliteral does not warn when passing a non literal to vprintf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82206 --- Comment #1 from Simon Marchi --- Stumbled on this again in the GDB code. Here's another reproducer, probably the same cause: --- #include #include void add_line (const std::string ); void string_vappendf (std::string , const char *fmt,

[Bug c++/95942] [11 regression] offsetof on an array: error: 'e' is not a constant expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment

[Bug c++/95942] [11 regression] offsetof on an array: error: 'e' is not a constant expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942 --- Comment #1 from Sergei Trofimovich --- Original code looks is at https://github.com/dolphin-emu/dolphin/blob/2e8d1dd1dbcca7095e9d842f1df037cbe76868e4/Source/Core/Core/DSP/Jit/x64/DSPEmitter.cpp#L476: """ ... Gen::OpArg

[Bug c++/95942] New: [11 regression] offsetof on an array: error: 'e' is not a constant expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942 Bug ID: 95942 Summary: [11 regression] offsetof on an array: error: 'e' is not a constant expression Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity:

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 Peter Dimov changed: What|Removed |Added CC||pdimov at gmail dot com --- Comment #30

[Bug c++/95937] ICE in finish_class_member_access_expr, at cp/typeck.c:3133

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95937 Marek Polacek changed: What|Removed |Added Keywords||error-recovery

[Bug c++/95938] ICE in synthesize_implicit_template_parm, at cp/parser.c:44077

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95938 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug libstdc++/95915] [10/11 Regression] std::variant doesn't like types with a defaulted virtual destructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915 --- Comment #1 from Ville Voutilainen --- Patch at https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549030.html

[Bug target/95941] New: Passing a struct by value wastes 16 bytes on the stack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95941 Bug ID: 95941 Summary: Passing a struct by value wastes 16 bytes on the stack Product: gcc Version: 10.1.0 Status: UNCONFIRMED Keywords: missed-optimization Severity:

[Bug c++/94260] Specific friend function inside c++20 concept-constrained class template triggers 'not usable in a constant expression' error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94260 --- Comment #2 from niek --- Dear Patrick, Nope, I cannot reproduce it anymore. It seems to be fixed! PS apologies for my delayed response; this is one of my public 'spam email addresses', just saw it now. best, Niek On 22/06/2020 15:45,

[Bug middle-end/95939] [11 Regression] ice with -O3 in compute_live_loop_exits

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

[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663 --- Comment #15 from Jakub Jelinek --- In the particular case we are talking about, security/non-security, it doesn't make sense to do anything but optimize it into straight line code, any __builtin_trap or similar will just hurt. If you feel

[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663 --- Comment #14 from Jeffrey A. Law --- The reason for turning the dereference into a trap is because we can clean up ancillary computations -- the address computation, the RHS of a store, and the like via standard dead code elimination

[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663 --- Comment #13 from Jeffrey A. Law --- Marc, Yes, absolutely. In fact, I think that falls out of the work Martin S is doing in this space. Conceptually we're looking to generalize that code so that we can route more cases where the compiler

[Bug lto/95928] LTO through ar breaks weak function resolution

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 --- Comment #13 from H.J. Lu --- (In reply to Andi Kleen from comment #12) > Okay. I only compared gcc-7 (working) vs gcc-9 (broken), but always with LTO. > > Looking at the kernel link it also uses --whole-archive. Perhaps that makes > a

[Bug lto/95928] LTO through ar breaks weak function resolution

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 --- Comment #12 from Andi Kleen --- Okay. I only compared gcc-7 (working) vs gcc-9 (broken), but always with LTO. Looking at the kernel link it also uses --whole-archive. Perhaps that makes a difference? I'll redo the test case with

[Bug target/95921] [m68k] invalid codegen for __builtin_sqrt

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921 --- Comment #3 from Rich Felker --- Yes,I'm aware m68k has FLT_EVAL_METHOD=2. That's not license for *functions* to return excess precision. The language specification is very clear about where excess precision is and isn't kept, and here it

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95820 --- Comment #5 from Marek Polacek --- *** Bug 95936 has been marked as a duplicate of this bug. ***

[Bug c++/95936] ICE in splice_late_return_type, at cp/pt.c:29114

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95936 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #3 from David Edelsohn --- { target { le } }

[Bug fortran/95881] [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175 since r7-5348-g6479f45b31c13f30

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

[Bug fortran/95881] [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175 since r7-5348-g6479f45b31c13f30

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:cb797c730dd37ffe88ed0b1d04aec01982feacb5 commit r9-8703-gcb797c730dd37ffe88ed0b1d04aec01982feacb5 Author: Harald Anlauf

[Bug lto/95928] LTO through ar breaks weak function resolution

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 --- Comment #11 from H.J. Lu --- (In reply to Andi Kleen from comment #9) > I think the STB_SECONDARY stuff is only needed if ld -r is used, but not for > ar Linker won't search archive to resolve weak definition. Since SECONDARY is between

[Bug fortran/95826] ICE in gfc_match_decl_type_spec, at fortran/decl.c:4290

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

[Bug fortran/95828] ICE in resolve_select_rank, at fortran/resolve.c:9774

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

[Bug lto/95928] LTO through ar breaks weak function resolution

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 --- Comment #10 from H.J. Lu --- (In reply to Andi Kleen from comment #8) > It works fine without LTO. > > Otherwise the Linux kernel wouldn't work. It relies on this behavior for its > syscalls. > [hjl@gnu-cfl-2 pr95928]$ make

[Bug fortran/95881] [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175 since r7-5348-g6479f45b31c13f30

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d12079381e25571f2d5f7bb16eaef07ee89b361b commit r10-8377-gd12079381e25571f2d5f7bb16eaef07ee89b361b Author: Harald Anlauf

[Bug lto/95928] LTO through ar breaks weak function resolution

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 --- Comment #9 from Andi Kleen --- I think the STB_SECONDARY stuff is only needed if ld -r is used, but not for ar

[Bug lto/95928] LTO through ar breaks weak function resolution

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 --- Comment #8 from Andi Kleen --- It works fine without LTO. Otherwise the Linux kernel wouldn't work. It relies on this behavior for its syscalls. The test case is extracted from there.

[Bug fortran/95881] [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175 since r7-5348-g6479f45b31c13f30

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3cbc0fb39c84ae0a51a9a88649dccd105bf17d6e commit r11-1688-g3cbc0fb39c84ae0a51a9a88649dccd105bf17d6e Author: Harald Anlauf Date:

[Bug tree-optimization/95923] Failure to optimize bool checks into and

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95923 --- Comment #1 from Marc Glisse --- (With one variant I ended up with (a|b)&(a==b), which we don't optimize to a) We don't optimize !(!a && !b) && !(!a && b) && !(a && !b) (we keep several branches), but we do optimize if I manually replace

[Bug lto/95928] LTO through ar breaks weak function resolution

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 --- Comment #7 from H.J. Lu --- (In reply to H.J. Lu from comment #6) > It has nothing to do with LTO. You get the same behavior without LTO. > This is how weak symbol works. BTW, this is why I proposed STB_SECONDARY:

[Bug tree-optimization/95929] Failure to optimize tautological comparisons of comparisons to a single one

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95929 --- Comment #1 from Marc Glisse --- Here gcc does optimize the first f to (a != 0) ^ (b != 0). However, for the second f, it does indeed generate something that looks like the first f before optimization... The optimization for the first f is

[Bug lto/95928] LTO through ar breaks weak function resolution

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #6

[Bug tree-optimization/95924] Failure to optimize some bit magic to one of the operands

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95924 --- Comment #1 from Marc Glisse --- * If I replace ~a with !a, we manage to do everything with type bool. With ~a, we don't, we stick to int. * We don't handle a?b:false the same as a& * Even for (a | !b) && (!(!a & b) && a) we don't

[Bug tree-optimization/95926] Failure to optimize xor pattern when using temporary variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95926 --- Comment #1 from Marc Glisse --- It is different to gcc because in the first case, tmp is used twice, while in the second case, each a is only used once, and gcc only transforms (a)^b to b&~a if this is the only use of a Yes, this heuristic

[Bug fortran/95939] [11 Regression] ice with -O3 in compute_live_loop_exits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95939 --- Comment #2 from David Binderman --- (In reply to David Binderman from comment #1) > I'll have a go at reducing the first. Pointless. It is only a few lines of code anyway.

[Bug fortran/95939] [11 Regression] ice with -O3 in compute_live_loop_exits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95939 --- Comment #1 from David Binderman --- Same error in testsuite files gcc.dg/tree-ssa/pr23433.c and gcc.target/aarch64/sve/reduc_strict_8.c. I'll have a go at reducing the first.

[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663 --- Comment #12 from Marc Glisse --- (In reply to Jeffrey A. Law from comment #10) > __builtin_trap emits an actual trap into the instruction stream which halts > the process immediately which is *much* better from a security standpoint

[Bug bootstrap/95940] New: sparc64-linux bootstrap with gcc-9.3 broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95940 Bug ID: 95940 Summary: sparc64-linux bootstrap with gcc-9.3 broken Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug fortran/95939] New: ice with -O3 in compute_live_loop_exits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95939 Bug ID: 95939 Summary: ice with -O3 in compute_live_loop_exits Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c++/95938] New: ICE in synthesize_implicit_template_parm, at cp/parser.c:44077

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95938 Bug ID: 95938 Summary: ICE in synthesize_implicit_template_parm, at cp/parser.c:44077 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords:

[Bug c++/95937] New: ICE in finish_class_member_access_expr, at cp/typeck.c:3133

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95937 Bug ID: 95937 Summary: ICE in finish_class_member_access_expr, at cp/typeck.c:3133 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code

[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 --- Comment #7 from Iain Sandoe --- (In reply to Michael Bruck from comment #6) > Is it possible to point the user to include here like other parts of > gcc do for standard library functions? > i.e. name-lookup.c missing_std_header That's also

[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 --- Comment #6 from Michael Bruck --- Is it possible to point the user to include here like other parts of gcc do for standard library functions? i.e. name-lookup.c missing_std_header

[Bug middle-end/95903] gcc 10: wrong code with -fwrapv

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903 --- Comment #10 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:37995960984ea346dd9d168d332cd6f7adf0 commit r11-1685-g37995960984ea346dd9d168d332cd6f7adf0 Author: Jakub Jelinek Date:

[Bug target/95674] Unnecessary move when doing division-by-multiplication

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

[Bug c++/95736] coroutine method improperly copies awaitable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95736 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:daaed0199ee57013ae011421a7e90b7bdd295373 commit r11-1684-gdaaed0199ee57013ae011421a7e90b7bdd295373 Author: Iain Sandoe Date: Sat

[Bug c++/95936] New: ICE in splice_late_return_type, at cp/pt.c:29114

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95936 Bug ID: 95936 Summary: ICE in splice_late_return_type, at cp/pt.c:29114 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal

[Bug bootstrap/92484] In tree build of ISL 0.22 fails: requires C++11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484 Romain Geissler changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #2 from Thomas Koenig --- The problem is in the scans; the code runs fine. Does anybody have the dejagnu-fu to run the scans only on little-endian systems?

[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917 Jonathan Wakely changed: What|Removed |Added CC|jwakely at redhat dot com | --- Comment #7 from Jonathan

[Bug bootstrap/95934] bootstrap fails in compiler assert in sanitizer_platform_limits_posix.cpp:1136

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95934 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |9.3

[Bug bootstrap/95934] bootstrap fails in compiler assert in sanitizer_platform_limits_posix.cpp:1136

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95934 Andreas Schwab changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug target/95921] [m68k] invalid codegen for __builtin_sqrt

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921 --- Comment #2 from Andreas Schwab --- The m68k backend generally does all floating point arithmethic in extended precision for !TARGET_68040, setting FLT_EVAL_METHOD to 2.