[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 107033, which changed state. Bug 107033 Summary: [13 Regression] [modules] Variable template of type trait via importable header gives wrong result https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107033 What|

[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #12 from Steve Kargl --- On Thu, Sep 29, 2022 at 08:10:14PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 > > --- Comment #11 from Steve Kargl --- > On Thu, Sep 29, 2022

[Bug fortran/107075] ICE in get, at cgraph.h:461

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #3) > (In reply to Richard Biener from comment #2) > > > > But maybe 'z' shouldn't be of static storage duration ... > > No, I think it shouldn't. A shoul

[Bug c/107091] Misleading error message "incompatible types when returning ..."

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

[Bug tree-optimization/85611] Suboptimal code generation for (potentially) redundant atomic loads

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85611 AK changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug c++/106649] [C++23] P2448 - Relaxing some constexpr restrictions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106649 Marek Polacek changed: What|Removed |Added Last reconfirmed||2022-09-29 Status|UNCONFIRM

[Bug tree-optimization/107090] [aarch64] sequence logic should be combined with mul and umulh

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-09-29 Component|middle-en

[Bug tree-optimization/102892] [12/13 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892 --- Comment #18 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:845ee38e9b40230fbb1b9825fb62146fd858cd96 commit r13-2970-g845ee38e9b40230fbb1b9825fb62146fd858cd96 Author: Andrew MacLeod Date:

[Bug preprocessor/107089] Line-terminating '\' leaves the characters when the next-line is a multi-line comment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107089 --- Comment #1 from Andrew Pinski --- >I found it when I tried to use the CPP as a general-purpose macro. Well it is not designed to be a general purpose macro processor. You might want to try something like m4 instead. https://en.wikipedia.or

[Bug ipa/96503] attribute alloc_size effect lost after inlining

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503 Kees Cook changed: What|Removed |Added CC||kees at outflux dot net --- Comment #1 from

[Bug preprocessor/107089] Line-terminating '\' leaves the characters when the next-line is a multi-line comment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107089 --- Comment #2 from JohnDoe --- >Andrew Pinski Thank you for your reply. That's right. Therefore, I am currently using my own parser. Nobody needs fix, so you can close this topic. However, the cause of the bug seems to be a mistake in the po

[Bug libstdc++/107092] New: std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107092 Bug ID: 107092 Summary: std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type Product: gcc Version: 12.1

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #19 from Alexander Monakov --- (In reply to rguent...@suse.de from comment #18) > True - but does that catch the cases people are interested and are > allowed by the FP contraction rules? I'm thinking of > > x = a*b + c*d + e + f;

<    1   2