[Bug c++/115792] GCC accepts [] throw () {}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792 --- Comment #1 from Andrew Pinski --- Note it looks like clang does not implement `parameter declaration before lambda declaration specifiers only optional with C++23` as clang rejects: ``` auto l = [] static {}; ``` Note all 3 accept: ``` auto

[Bug target/115789] gcc miscompile itself with CFLAGS -O3 -march=rv64gcv_zvl256b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115789 --- Comment #7 from lu_zero at gentoo dot org --- (In reply to Jeffrey A. Law from comment #3) > Thanks. Unfortunately GDB isn't dumping the vector regs, but I can make a > pretty good guess that this is an unaligned memory access. > > => 0x000

[Bug target/115789] gcc miscompile itself with CFLAGS -O3 -march=rv64gcv_zvl256b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115789 --- Comment #8 from lu_zero at gentoo dot org --- (In reply to Xi Ruoyao from comment #4) > Should we backport -mvector-strict-align to release branches then? Arguably > this is not a bug fix (for the compiler) but x86 (and maybe others) also >

[Bug c++/115792] GCC accepts [] throw () {}

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

[Bug c++/115792] GCC accepts [] throw () {}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792 --- Comment #3 from Andrew Pinski --- "Exception specifications and noexcept" from the paper. So yes GCC is correct.

[Bug c++/115792] GCC accepts [] throw () {}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Note it looks like clang does not implement `parameter declaration before > lambda declaration specifiers only optional with C++23` as clang rejects: s/clang/MS

[Bug target/115789] gcc miscompile itself with CFLAGS -O3 -march=rv64gcv_zvl256b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115789 --- Comment #9 from Xi Ruoyao --- (In reply to lu_zero from comment #8) > (In reply to Xi Ruoyao from comment #4) > > Should we backport -mvector-strict-align to release branches then? Arguably > > this is not a bug fix (for the compiler) but x

[Bug c++/115792] GCC accepts [] throw () {}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792 --- Comment #5 from Andrew Pinski --- Looks like clang misses exception specifiers as being optional before the parm. Most likely because only `throw()` is valid for C++17+.

[Bug sanitizer/115793] New: signed integer overflow check missing at optimization levels -O2, -O3, and -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115793 Bug ID: 115793 Summary: signed integer overflow check missing at optimization levels -O2, -O3, and -Os Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severit

[Bug c++/115792] GCC accepts [] throw () {}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792 --- Comment #6 from Andrew Pinski --- So I looked into the change for clang: https://github.com/llvm/llvm-project/commit/0620e6f4b76a9725dbd82454d58c5a68a7e47074 And they didn't add a testcase for throw(). Only noexcept. GCC add a testcase for

[Bug c++/115792] GCC accepts [] throw () {}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792 --- Comment #7 from 康桓瑋 --- (In reply to Andrew Pinski from comment #6) > So I looked into the change for clang: > https://github.com/llvm/llvm-project/commit/ > 0620e6f4b76a9725dbd82454d58c5a68a7e47074 > > And they didn't add a testcase for th

[Bug c++/115792] GCC accepts [] throw () {}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792 --- Comment #8 from Andrew Pinski --- (In reply to 康桓瑋 from comment #7) > (In reply to Andrew Pinski from comment #6) > > So I looked into the change for clang: > > https://github.com/llvm/llvm-project/commit/ > > 0620e6f4b76a9725dbd82454d58c5a6

[Bug c++/115794] New: gcc 15 (20240630 snapshot) ICEs while building gfortran while targeting rv64gcv_zvl256b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115794 Bug ID: 115794 Summary: gcc 15 (20240630 snapshot) ICEs while building gfortran while targeting rv64gcv_zvl256b Product: gcc Version: 15.0 Status: UNCONFIRMED

[Bug libstdc++/115743] libstdc++: pretty printer is installed in wrong location for mingw32/cygwin targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115743 --- Comment #10 from Ralf Habacker --- (In response to Jonathan Wakely from comment #9) > > Does the difference cause an actual problem? The installed *.dll-gdb.py needs to be moved to a different location for gdb to find it. Without this pa

[Bug libstdc++/115743] libstdc++: pretty printer is installed in wrong location for mingw32/cygwin targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115743 --- Comment #11 from Ralf Habacker --- (In reply to Ralf Habacker from comment #10) > (In response to Jonathan Wakely from comment #9) > > > > Does the difference cause an actual problem? > > The installed *.dll-gdb.py needs to be moved to a

[Bug target/115713] rs6000: Miss warning for incompatible no-altivec and vsx in target attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713 Kewen Lin changed: What|Removed |Added CC||jakub at gcc dot gnu.org,

[Bug rtl-optimization/115782] ICE on valid code at -O{2,3} with "-fno-guess-branch-probability -fgcse-sm -fno-expensive-optimizations -fno-gcse" on x86_64-linux-gnu: in possibly_queue_changes, at rtl-

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115782 Richard Sandiford changed: What|Removed |Added Last reconfirmed||2024-07-05 Status|UNCON

[Bug target/115713] rs6000: Miss warning for incompatible no-altivec and vsx in target attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713 --- Comment #5 from Richard Biener --- The docs are at least imprecise. Surely command-line -maltivec with target ("no-vsx") shouldn't revert to whatever is default with the target opts.

[Bug rtl-optimization/115785] ICE when building embree-4.3.1 on amd64 with -flate-combine-instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115785 Richard Sandiford changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassig

[Bug libstdc++/115743] libstdc++: pretty printer is installed in wrong location for mingw32/cygwin targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115743 --- Comment #12 from Jonathan Wakely --- (In reply to Ralf Habacker from comment #11) > BTW: I found an additional note that such a move is also required for other > targets > > from > https://build.opensuse.org/projects/devel:gcc/packages/gcc1

[Bug c/88737] RFE: Track ownership moves

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88737 Thomas Schwinge changed: What|Removed |Added CC||tschwinge at gcc dot gnu.org --- Comme

[Bug fortran/90608] Inline non-scalar minloc/maxloc calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #19 from Tamar Christina --- Hi Mikael, It looks like the last version of your patch already gets inlined in the call sites we cared about. Would it be possible for you to upstream it?

[Bug c++/115792] GCC accepts [] throw () {}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792 --- Comment #9 from Jonathan Wakely --- throw() is not valid in C++23 at all (nor in C++20). GCC accepts it as an extension, but should probably warn with -pedantic. I don't think Clang is wrong here. Should we reopen this to add a pedwarn for

[Bug target/114991] [14/15 Regression] AArch64: LDP pass does not handle some structure copies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114991 --- Comment #4 from Alex Coplan --- So the following is enough to fix the missed ldp due to alias analysis: diff --git a/gcc/pair-fusion.cc b/gcc/pair-fusion.cc index 31d2c21c88f..ab49d955ccf 100644 --- a/gcc/pair-fusion.cc +++ b/gcc/pair-fusio

[Bug tree-optimization/104265] Missed vectorization in 526.blender_r

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104265 --- Comment #4 from Tamar Christina --- (In reply to Richard Biener from comment #3) > Note the SLP discovery opportunity is from the "reduction" PHI to the > return which merges control flow to a zero/one flag. Right, so I get what you mean he

[Bug tree-optimization/104265] Missed vectorization in 526.blender_r

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104265 --- Comment #5 from Tamar Christina --- Also for fully masked architectures we can instead of recreating the vectors just mask out the irrelevant values. But we should still order the exits based on complexity.

[Bug c++/115792] GCC accepts [] throw () {}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792 Xi Ruoyao changed: What|Removed |Added Status|RESOLVED|REOPENED CC|

[Bug libstdc++/115040] Missed optimization opportunity in std::find of std::vector elements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115040 --- Comment #7 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:de19b516edbf919d31e9d22fdbf6066342d904a2 commit r15-1857-gde19b516edbf919d31e9d22fdbf6066342d904a2 Author: Jonathan Wakely Date:

[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545 --- Comment #13 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:de19b516edbf919d31e9d22fdbf6066342d904a2 commit r15-1857-gde19b516edbf919d31e9d22fdbf6066342d904a2 Author: Jonathan Wakely Date:

[Bug c++/115747] [C++26] P3144R2 - Deleting a pointer to an incomplete type should be ill-formed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115747 --- Comment #11 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f63896ff5a4fa4fe451f9ec7f16026eb97ed8e6d commit r15-1859-gf63896ff5a4fa4fe451f9ec7f16026eb97ed8e6d Author: Jonathan Wakely Date

[Bug target/87376] [avr] Miscompilation with __memx and long long addition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87376 --- Comment #8 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:23a0935262d6817097406578b1c70563f424804b commit r15-1860-g23a0935262d6817097406578b1c70563f424804b Author: Georg-Johann Lay Date

[Bug target/115795] New: RISC-V: vsetvl step causes wrong codegen after fusing info

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795 Bug ID: 115795 Summary: RISC-V: vsetvl step causes wrong codegen after fusing info Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Pr

[Bug libstdc++/115040] Missed optimization opportunity in std::find of std::vector elements

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

[Bug libstdc++/114149] lexicographical_compare should use memcmp for C++20 contiguous iterators as well as pointers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114149 --- Comment #2 from Jonathan Wakely --- I'm writing a proposal to say the library can assume contiguous iterators are sane.

[Bug target/87376] [avr] Miscompilation with __memx and long long addition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87376 --- Comment #9 from GCC Commits --- The releases/gcc-14 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:9f5620aed3976716e20e13c285dade56578d5bab commit r14-10382-g9f5620aed3976716e20e13c285dade56578d5bab Author: Georg-Johann

[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350 Jonathan Wakely changed: What|Removed |Added Target Milestone|13.4|---

[Bug target/87376] [avr] Miscompilation with __memx and long long addition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87376 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:4a49d212b54ab152737e3209b7f80af3a80966b8 commit r13-8893-g4a49d212b54ab152737e3209b7f80af3a80966b8 Author: Georg-Johann

[Bug target/87376] [avr] Miscompilation with __memx and long long addition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87376 --- Comment #11 from GCC Commits --- The releases/gcc-12 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:5f4a60c43d5cd805add6529b4528c35893c283ae commit r12-10602-g5f4a60c43d5cd805add6529b4528c35893c283ae Author: Georg-Johan

[Bug target/87376] [avr] Miscompilation with __memx and long long addition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87376 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|---

[Bug c++/115796] New: build failure since double_u -> __double_u change

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115796 Bug ID: 115796 Summary: build failure since double_u -> __double_u change Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug target/115188] [14/15 regression] invalid Thumb assembly for atomic store in loop on ARMv6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115188 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:100d353e545564931efaac90a089a4e8f3d42e6e commit r14-10383-g100d353e545564931efaac90a089a4e8f3d42e6e Author: Wilco Dijkstr

[Bug target/115188] [14/15 regression] invalid Thumb assembly for atomic store in loop on ARMv6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115188 Wilco changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 --- Comment #29 from GCC Commits --- The releases/gcc-12 branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:b9d16d8361a9e3a82a2f21e759e760d235d43322 commit r12-10603-gb9d16d8361a9e3a82a2f21e759e760d235d43322 Author: Wilco Dijkst

[Bug tree-optimization/104265] Missed vectorization in 526.blender_r

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104265 --- Comment #6 from Richard Biener --- Sure - the example is more complicated to what I'd initially try to handle ;) Consider a fully unrolled bool is_hello (const char *s) { for (int i = 0; i < 8; ++i) if (s[i] != "hello world][i])

[Bug target/115796] build failure since double_u -> __double_u change

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115796 Richard Biener changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org C

[Bug target/105886] -mstrict-align is ignorning unalign in some cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105886 Bug 105886 depends on bug 103100, which changed state. Bug 103100 Summary: [11 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 What|Removed

[Bug target/103100] [11 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 Wilco changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #15 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:acc3b703c05debc6276451f9daae5d0ffc797eac commit r15-1861-gacc3b703c05debc6276451f9daae5d0ffc797eac Author: Robin Dapp Date: Mon Ju

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 Robin Dapp changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/103100] [11 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 Richard Earnshaw changed: What|Removed |Added Target Milestone|11.5|12.5

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #20 from Thorsten Glaser --- I would like some assistance in debugging this further. I had been able to work around this by… -static int varsub(Expand *, const char *, const char *, unsigned int *, int *); +static int varsub(Expand

[Bug c++/115672] [11/12/13/14/15 Regression] Incorrect template type parameter deduced in non-deduced context if class template has template template parameter

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

[Bug jit/112574] Add support for bfloat16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112574 --- Comment #2 from GCC Commits --- The master branch has been updated by Antoni Boucher : https://gcc.gnu.org/g:1c314247aab43aaa278ecc51d666f8c5896d8bbb commit r15-1863-g1c314247aab43aaa278ecc51d666f8c5896d8bbb Author: Antoni Boucher Date:

[Bug c++/115778] Internal compiler error: in keep_template_parm, at cp/pt.cc:10960

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115778 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #21 from Thorsten Glaser --- … reverting that precise workaround FIXES the bug with GCC 14 🤯 Something deep inside must be buggy, and the triggering with this only an accident.

[Bug c++/115672] [11/12/13/14/15 Regression] Incorrect template type parameter deduced in non-deduced context if class template has template template parameter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115672 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org

[Bug analyzer/115784] -Wanalyzer-infinite-loop does not take into account noreturn attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115784 --- Comment #1 from David Malcolm --- Thanks for filing this bug report. The analyzer reports -Wanalyzer-infinite-loop on the example code you posted; trunk on Compiler Explorer: https://godbolt.org/z/WzPEc3hxh But it is indeed an infinite loo

[Bug analyzer/115784] -Wanalyzer-infinite-loop does not take into account noreturn attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115784 --- Comment #2 from Alexey --- Hi David, thank you for a quick reply! Maybe it does not critical for high-level applications, that usually don't use "noreturn" functions. In embedded world, it's a common practice to send a reset signal and inv

Paychex

Hello I would like to know if you are interested in acquiring the Paychex customer list. We are glad to inform you that, currently, we are running an Independence Day offer on all immediate purchases, where you can avail of the same list at a much lower price. These offers are like never b

[Bug target/115789] gcc miscompile itself with CFLAGS -O3 -march=rv64gcv_zvl256b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115789 --- Comment #11 from Xi Ruoyao --- (In reply to lu_zero from comment #10) > Passing `-mstrict-align` to gcc-14 to build gcc-14 does not seem to have > effect, same Bus error triggered. Then it's a different bug. As Craig said -march=rv64gcv_zv

[Bug target/115789] gcc miscompile itself with CFLAGS -O3 -march=rv64gcv_zvl256b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115789 --- Comment #10 from lu_zero at gentoo dot org --- Passing `-mstrict-align` to gcc-14 to build gcc-14 does not seem to have effect, same Bus error triggered.

[Bug analyzer/115784] -Wanalyzer-infinite-loop does not take into account noreturn attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115784 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/115797] New: [15 Regression] 'extern "C" { #include }' fails with 'error: template with C linkage' since r15-1857-gde19b516edbf91

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115797 Bug ID: 115797 Summary: [15 Regression] 'extern "C" { #include }' fails with 'error: template with C linkage' since r15-1857-gde19b516edbf91 Product: gcc Versio

[Bug c++/115797] [15 Regression] 'extern "C" { #include }' fails with 'error: template with C linkage' since r15-1857-gde19b516edbf91

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115797 --- Comment #1 from Jonathan Wakely --- Doing this is undefined (and annoying). [using.headers] in the standard says "A translation unit shall include a header only outside of any declaration or definition"

[Bug c++/115798] New: [15 Regression][modules] ICE when re-exporting a type exported from base module's GMF

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115798 Bug ID: 115798 Summary: [15 Regression][modules] ICE when re-exporting a type exported from base module's GMF Product: gcc Version: 15.0 Status: UNCONFIRMED Se

[Bug target/115153] [14/15 Regression] Error: bad immediate value for 8-bit offset - armv7ve

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153 --- Comment #9 from GCC Commits --- The master branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:44e5ecfd261afe72aa04eba4bf1a9ec782579cab commit r15-1865-g44e5ecfd261afe72aa04eba4bf1a9ec782579cab Author: Wilco Dijkstra Date:

[Bug c++/115798] [15 Regression][modules] ICE when re-exporting a type exported from base module's GMF

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115798 --- Comment #1 from m.cencora at gmail dot com --- Also this is specific to types exported from GMF, if type is declared directly in named module it works fine, i.e. $ cat base.cpp export module base; export { using int8_t = signed char; }

[Bug libstdc++/115797] [15 Regression] 'extern "C" { #include }' fails with 'error: template with C linkage' since r15-1857-gde19b516edbf91

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115797 --- Comment #2 from Jonathan Wakely --- I'll make this work again, but it's stupid code. If the file is being compiled as C++, then etc. are C++ headers, so it's either redundant or incorrect to mess with the language linkage of their contents

[Bug c++/115798] [15 Regression][modules] ICE when re-exporting a type exported from base module's GMF

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115798 --- Comment #2 from m.cencora at gmail dot com --- (In reply to m.cencora from comment #1) > Also this is specific to types exported from GMF, if type is declared > directly in named module it works fine, i.e. > > $ cat base.cpp > export module

[Bug libstdc++/115797] [15 Regression] 'extern "C" { #include }' fails with 'error: template with C linkage' since r15-1857-gde19b516edbf91

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115797 --- Comment #3 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #1) > Doing this is undefined (and annoying). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071#c12 Is libstdc++ still allowing this for qoi? Or we going to chang

[Bug libstdc++/115797] [15 Regression] 'extern "C" { #include }' fails with 'error: template with C linkage' since r15-1857-gde19b516edbf91

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115797 --- Comment #4 from Jonathan Wakely --- It's probably easier to just make it work than to deal with all the bug reports we'll get from broken code that stops working.

[Bug libstdc++/115797] [15 Regression] 'extern "C" { #include }' fails with 'error: template with C linkage' since r15-1857-gde19b516edbf91

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115797 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-07-05 Ever confirmed|0

[Bug libstdc++/115799] New: ranges::find's optimized branching for memchr is not quite right

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799 Bug ID: 115799 Summary: ranges::find's optimized branching for memchr is not quite right Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug libstdc++/115799] ranges::find's optimized branching for memchr is not quite right

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigne

[Bug c++/115296] CTAD fails

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

[Bug c++/115792] throw() should be diagnostic/errored out with C++20+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792 Andrew Pinski changed: What|Removed |Added Summary|GCC accepts [] throw () {} |throw() should be |

[Bug target/115796] [15 Regression] build failure since double_u -> __double_u change

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115796 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Summary|build failure s

[Bug target/115796] [15 Regression] build failure since double_u -> __double_u change

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

[Bug target/115800] New: PowerPC GCC cannot build a little endian compile if --with-cpu=power5 is used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800 Bug ID: 115800 Summary: PowerPC GCC cannot build a little endian compile if --with-cpu=power5 is used Product: gcc Version: unknown Status: UNCONFIRMED Severit

[Bug c++/115783] GCC accepts invalid program involving calling explicit object member function from static member function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115783 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Keywords|

[Bug target/115800] PowerPC GCC cannot build a little endian compile if --with-cpu=power5 is used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800 --- Comment #1 from Segher Boessenkool --- "If you build a little-endian compiler". What does that mean? A cpu=powerpc76le* compiler? Or something else? Note that *any* compiler can be used as little-endian, by just using -mlittle. Nothing m

[Bug target/115800] PowerPC GCC cannot build a little endian compile if --with-cpu=power5 is used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800 --- Comment #2 from Segher Boessenkool --- (In reply to Segher Boessenkool from comment #1) > "If you build a little-endian compiler". What does that mean? A > cpu=powerpc76le* compiler? Or something else? > > Note that *any* compiler can be

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #22 from Sam James --- In general, to help reduce miscompilations, there's a few options: * Bisecting GCC (which then also allows comparing object files before/after the relevant commit) * Comparing dumps with/without that commit (wh

[Bug c++/115801] New: [modules] segfault instantiating a template with a templated friend declaration referring to an unexported template using a qualified name

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115801 Bug ID: 115801 Summary: [modules] segfault instantiating a template with a templated friend declaration referring to an unexported template using a qualified name Product:

[Bug target/115800] PowerPC GCC cannot build a little endian compile if --with-cpu=power5 is used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800 --- Comment #3 from Segher Boessenkool --- Note that we *should* support ieee128 with *any* configuration, to avoid nonsense like this (and many more). But, alas.

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #23 from Sam James --- (Adding noipa or noinline attributes helps a lot as well, and then can easily just e.g. view values in gdb to create an artificial reproducer.)

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 Arsen Arsenović changed: What|Removed |Added CC||arsen at gcc dot gnu.org --- Comment

[Bug libstdc++/115797] [15 Regression] 'extern "C" { #include }' fails with 'error: template with C linkage' since r15-1857-gde19b516edbf91

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115797 --- Comment #6 from Sergei Trofimovich --- Another build failure example is pipewire-1.2.0. There is included indirectly through another header: https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/plugins/alsa/alsa-pcm.h#L2

[Bug target/115800] PowerPC GCC cannot build a little endian compile if --with-cpu=power5 is used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800 --- Comment #4 from Michael Meissner --- Libgfortran gives various errors that _Float128 is not supported on this target. libtool: compile: /home/meissner/fsf-build-ppc64le/work171-p5/./gcc/xgcc -B/home/meissner/fsf-build-ppc64le/work171-p5/./

[Bug target/115800] PowerPC GCC cannot build a little endian compile if --with-cpu=power5 is used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800 --- Comment #5 from Michael Meissner --- And libstdc++-v3 errors are similar: mkdir -p ./powerpc64le-unknown-linux-gnu/bits/stdc++.h.gch /home/meissner/fsf-build-ppc64le/work171-p5/./gcc/xgcc -shared-libgcc -B/home/meissner/fsf-build-ppc64le/wo

[Bug target/115800] PowerPC GCC cannot build a little endian compile if --with-cpu=power5 is used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800 --- Comment #6 from Michael Meissner --- Of course it would also apply if you are building a BE compiler that has little endian multilibs, you would run into the same situation.

[Bug c++/101232] Bad error message with stray semicolon in initializer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101232 --- Comment #6 from Jason Merrill --- It seems like the problem is that cp_parser_braced_list doesn't check whether braces.require_close succeeded and compensate if it fails; in that case it might make sense to cp_parser_skip_to_closing_brace a

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #25 from Thorsten Glaser --- Good as I can tell, __valgrind is always 1, at least when looking at it in gdb… I even had to add -ffreestanding because it otherwise triggered an optimisation to transform the loop into a call to strlen

[Bug rtl-optimization/115782] [15 Regression] ICE on valid code at -O{2,3} with "-fno-guess-branch-probability -fgcse-sm -fno-expensive-optimizations -fno-gcse" on x86_64-linux-gnu: in possibly_queue_

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115782 Andrew Pinski changed: What|Removed |Added Summary|ICE on valid code at|[15 Regression] ICE on

[Bug target/115751] [15 Regression] ICE building 521.wrf_r

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115751 --- Comment #7 from GCC Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:9a7e3f57e1ab8e6e4cf5ea3c0998aa50c6220579 commit r15-1869-g9a7e3f57e1ab8e6e4cf5ea3c0998aa50c6220579 Author: Roger Sayle Date: Sat J

[Bug rtl-optimization/115802] New: Non-atomic load of static variable moved out of loop despite atomic fences

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115802 Bug ID: 115802 Summary: Non-atomic load of static variable moved out of loop despite atomic fences Product: gcc Version: 14.1.1 Status: UNCONFIRMED Severity: n

[Bug rtl-optimization/115802] Non-atomic load of static variable moved out of loop despite atomic fences

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115802 --- Comment #1 from Andrew Pinski --- Note clang has similar code generation here.

[Bug middle-end/115802] Non-atomic load of static variable moved out of loop despite atomic fences

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115802 --- Comment #2 from Andrew Pinski --- I am not 100% sure this is a bug since cond_wait is known not to touch val even though it has an atomic in it. If you mark it as noipa, then the GCC trunk gets it "correct".

[Bug c++/115803] New: ICE: tree check: expected class 'type', have 'constant' (integer_cst) in cp_type_quals, at cp/typeck.cc:11646

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115803 Bug ID: 115803 Summary: ICE: tree check: expected class 'type', have 'constant' (integer_cst) in cp_type_quals, at cp/typeck.cc:11646 Product: gcc Version: 15.0

[Bug middle-end/115802] Non-atomic load of static variable moved out of loop despite atomic fences

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115802 --- Comment #3 from Ivan Bodrov --- Yes, but "wait" operation is not supposed to touch anything. The example shows typical usage of condition variable, except "real" code usually accesses data through some pointer, not as a static variable. Or

  1   2   >