[Bug c++/107660] Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660 --- Comment #3 from Tomoya Suzuki --- Perhaps I should ask the question in libc instead of gcc?

[Bug c++/107660] Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660 --- Comment #2 from Tomoya Suzuki --- I Sorry I didn't follow your bug report guidelines. After this, I investigated the cause by myself, and it seems that there is a difference in the output of the std::shuffle function. Even if the input and

[Bug c++/107660] Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-11-12 Ever confirmed|0

[Bug c++/97452] [coroutines] incorrect sequencing of await_resume() when multiple co_await expressions occur in a single statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97452 --- Comment #11 from David Ledger --- This did not occur with GCC 10.2, it started in GCC 10.3: 10.3 (https://godbolt.org/z/jrdv31M17): ``` 0x15d1ed3 A 0x15d1ed2 ~A 0x15d1ed3 ~A ``` 10.2 (https://godbolt.org/z/rrvKh9h6K): ``` 0x2322ed1 A

[Bug c++/107660] New: Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660 Bug ID: 107660 Summary: Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier Product: gcc Version: 12.2.0 Status:

[Bug sanitizer/64234] Statically sanitized executable does not export ASan symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64234 --- Comment #8 from lo1ol --- https://www.youtube.com/watch?v=Ua3TiOSwVTI

[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755 --- Comment #14 from Jonathan Wakely --- Should be fixed now, I think

[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755 --- Comment #13 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a7f51059fb009dcd7d491d6b2164bce75dbd9975 commit r13-3917-ga7f51059fb009dcd7d491d6b2164bce75dbd9975 Author: Jonathan Wakely

[Bug fortran/107659] New: C procedure with no global scope is seen as global

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107659 Bug ID: 107659 Summary: C procedure with no global scope is seen as global Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c/107653] how-to-use-inline-assembly-language-in-c-code page is huge and should be split up

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107653 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > I thought it went one layer deap but nope it is kinda of random. > For an example: > Not split up: >

[Bug c/107653] how-to-use-inline-assembly-language-in-c-code page is huge and should be split up

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107653 --- Comment #1 from Andrew Pinski --- I thought it went one layer deap but nope it is kinda of random. For an example: Not split up: https://gcc.gnu.org/onlinedocs/gccint/target-macros/register-classes.html Splitted up:

[Bug middle-end/107658] New: TARGET_EXPAND_TO_RTL_HOOK, TARGET_INSTANTIATE_DECLS, TARGET_MANGLE_TYPE don't really belong in the Storage Layout target hook section

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107658 Bug ID: 107658 Summary: TARGET_EXPAND_TO_RTL_HOOK, TARGET_INSTANTIATE_DECLS, TARGET_MANGLE_TYPE don't really belong in the Storage Layout target hook section Product: gcc

[Bug other/107634] Very long filenames and URLs for sphinx-based docs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 --- Comment #5 from Andrew Pinski --- One of the biggest drawbacks of not having one file is when you need to add a new section, you have to add a new file/directory rather than edditing one file. I also noticed the splitting up sections of the

[Bug other/107634] Very long filenames and URLs for sphinx-based docs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 --- Comment #4 from Andrew Pinski --- I came across a related issue here: Take: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gccint/C_002b_002b-ABI.html The original section name was just C++-ABI but had a heading of C++ ABI parameters Now post

[Bug c++/107652] c++20 gccchoses incorrect operator== overload

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107652 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment

[Bug middle-end/107657] New: PROMOTE_MODE, TARGET_PROMOTE_FUNCTION_MODE, TARGET_FUNCTION_VALUE and TARGET_PROMOTE_FUNCTION_MODE should describe better their interactions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107657 Bug ID: 107657 Summary: PROMOTE_MODE, TARGET_PROMOTE_FUNCTION_MODE, TARGET_FUNCTION_VALUE and TARGET_PROMOTE_FUNCTION_MODE should describe better their interactions

[Bug middle-end/107656] post sphinx conversion, can't tell between a target macro or a target hook

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107656 --- Comment #1 from Andrew Pinski --- .. c:macro:: PROMOTE_MODE (m, unsignedp, type) .. function:: enum flt_eval_method TARGET_C_EXCESS_PRECISION (enum excess_precision_type type) It is really hard to tell the difference in the generated page

[Bug middle-end/107656] New: post sphinx conversion, can't tell between a target macro or a target hook

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107656 Bug ID: 107656 Summary: post sphinx conversion, can't tell between a target macro or a target hook Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords:

[Bug other/107655] New: [meta-bug] tracker bug for issues encountered in the texinfo-to-sphinx migration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107655 Bug ID: 107655 Summary: [meta-bug] tracker bug for issues encountered in the texinfo-to-sphinx migration Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance

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

[Bug libstdc++/95048] [10/11/12 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 --- Comment #21 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8214ec0cf33482f60139ae18a40567317e63c1ff commit r13-3915-g8214ec0cf33482f60139ae18a40567317e63c1ff Author: Jonathan Wakely

[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576 --- Comment #4 from anlauf at gcc dot gnu.org --- Partial fix: diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc index b95c5cf2f96..f09fad337bc 100644 --- a/gcc/fortran/trans-expr.cc +++ b/gcc/fortran/trans-expr.cc @@ -6193,6

[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755 --- Comment #11 from Jonathan Wakely --- As I said in Bug 107632 comment 2: I'm kinda tempted to just disable the new optimization on these targets, the handling of compat facets for different float ABIs is impossible to get right.

[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance

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

[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576 --- Comment #3 from anlauf at gcc dot gnu.org --- I am still wondering if this is really invalid code. null(z) has the same characteristics as z, see F2018:16.9.144 So is there really a mismatch of arguments? Second, just one observation:

[Bug middle-end/107654] [13 Regression] md.rst should be in gcc/doc and not in doc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107654 --- Comment #1 from Andrew Pinski --- cppdiropts.rst cppenv.rst cppopts.rst cppwarnopts.rst Also maybe should not be in the toplevel directory. Maybe place them in libcpp instead?

[Bug middle-end/107654] [13 Regression] md.rst should be in gcc/doc and not in doc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107654 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0

[Bug middle-end/107654] New: [13 Regression] md.rst should be in gcc/doc and not in doc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107654 Bug ID: 107654 Summary: [13 Regression] md.rst should be in gcc/doc and not in doc Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation

[Bug analyzer/106147] RFE: -fanalyzer could complain about some cases of infinite loops and infinite recursion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147 --- Comment #6 from David Malcolm --- The above patch implements -Wanalyzer-infinite-recursion for GCC 13. I also have the beginnings of an implementation of -Wanalyzer-infinite-loop, but it won't be ready for the close of GCC 13 stage 1.

[Bug c/107653] New: how-to-use-inline-assembly-language-in-c-code page is huge and should be split up

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107653 Bug ID: 107653 Summary: how-to-use-inline-assembly-language-in-c-code page is huge and should be split up Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug web/107651] Having two different kind of indexes is very useful still

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 --- Comment #1 from Andrew Pinski --- For the install page, one index should be index of configure option and another one will be of the env variables. For the preprocessor has an index of env variables too. Maybe even in the main document

[Bug c++/107652] New: c++20 gccchoses incorrect operator== overload

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107652 Bug ID: 107652 Summary: c++20 gccchoses incorrect operator== overload Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug analyzer/106147] RFE: -fanalyzer could complain about some cases of infinite loops and infinite recursion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:12c583a2a3da798e82737c2d0e11fd686636cfeb commit r13-3912-g12c583a2a3da798e82737c2d0e11fd686636cfeb Author: David Malcolm Date:

[Bug web/107651] New: Having two different kind of indexes is very useful still

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 Bug ID: 107651 Summary: Having two different kind of indexes is very useful still Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation

[Bug web/107650] Sphinx generated web pages don't have up (to the section index)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107650 --- Comment #1 from Andrew Pinski --- The side bar has issues with the text being so much bigger and popping out compared to the main text. Plus when I scroll it, the search and icon part just takes up so much of it, the side bar becomes not

[Bug libstdc++/107649] New std::complex specializations are never used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649 --- Comment #2 from Jonathan Wakely --- Although if the _GLIBCXX_FLOAT_IS_IEEE_BINARY32 macro is not defined, it will still be ambiguous, because we won't define these overloads: #if _GLIBCXX_USE_C99_COMPLEX #if defined(__STDCPP_FLOAT16_T__)

[Bug web/107650] New: Sphinx generated web pages don't have up (to the section index)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107650 Bug ID: 107650 Summary: Sphinx generated web pages don't have up (to the section index) Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation

[Bug libstdc++/107649] New std::complex specializations are never used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-11-11

[Bug libstdc++/107649] New: New std::complex specializations are never used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649 Bug ID: 107649 Summary: New std::complex specializations are never used Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c++/105300] [10/11/12/13 Regression] segfault from static_assert with user-defined string suffix argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105300 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org

[Bug analyzer/107648] New: RFE: add an attribute for indicating security-sensitive data

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107648 Bug ID: 107648 Summary: RFE: add an attribute for indicating security-sensitive data Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633 --- Comment #5 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605800.html, if accepted, should help.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

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

[Bug middle-end/107642] LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107642 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug middle-end/107642] LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107642 --- Comment #2 from Andrew Pinski --- LOGICAL_OP_NON_SHORT_CIRCUIT has to be defined (if not already defined) in each file that uses it too. fold-const.cc:#ifndef LOGICAL_OP_NON_SHORT_CIRCUIT tree-ssa-ifcombine.cc:#ifndef

[Bug middle-end/107642] LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107642 --- Comment #1 from Andrew Pinski --- A --param option was added in 2018 to override the setting of LOGICAL_OP_NON_SHORT_CIRCUIT : https://gcc.gnu.org/legacy-ml/gcc-patches/2018-11/msg02604.html But the way it is implemented is such that the

[Bug tree-optimization/107523] [13 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu since r13-3628-g6fd485d15c1a2c42

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

[Bug tree-optimization/107523] [13 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu since r13-3628-g6fd485d15c1a2c42

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107523 --- Comment #2 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:0a7b437ca71e2721e9bcf070762fc54ef7991aeb commit r13-3911-g0a7b437ca71e2721e9bcf070762fc54ef7991aeb Author: Andrew MacLeod Date:

[Bug target/107645] internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'E' (rtx unspec) in symbolic_operand_1, at config/m68k/predicates.md:144

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107645 --- Comment #1 from jcmvbkbc at gcc dot gnu.org --- ICE in the reproducer is generated when predicate 'symbolic_operand' is applied to the 'const' node in the following rtl: (insn 342 341 343 35 (set (reg:SI 97) (mem/u:SI (plus:SI

[Bug c++/107484] [13 Regression] ICE: Segmentation fault (in decls_match)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107484 Marek Polacek changed: What|Removed |Added Last reconfirmed||2022-11-11 Priority|P1

[Bug c++/105221] [10/11/12/13 Regression] gcc rejects true ? [](auto) noexcept {} : [](int) {} in C++17+ (works for C++14)

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

[Bug target/95885] LOCAL_DECL_ALIGNMENT and TARGET_LOWER_LOCAL_DECL_ALIGNMENT macro documentation should be improved

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95885 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org

[Bug libstdc++/107636] [13 regression] r13-3761-ga239a63f868e29 breaks build on powerpc64le with __float128 support

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107636 Andrew Pinski changed: What|Removed |Added Keywords||build Target Milestone|---

[Bug ipa/106061] [13 Regression] during GIMPLE pass: einline ICE: verify_cgraph_node failed (edge points to wrong declaration) with -Og since r13-1204-gd68d366425369649

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106061 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #6

[Bug libstdc++/103295] constexpr std::string does not work for clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 --- Comment #21 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:52672be7d328df50f9a05ce3ab44ebcae50fee1b commit r13-3910-g52672be7d328df50f9a05ce3ab44ebcae50fee1b Author: Nathaniel Shead

[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #7 from Andrew Pinski --- (In reply to Alexander Monakov from comment #6) > Sure, but I was talking specifically about the pattern matching introduced > by that commit. The general rule for pattern matching is if you don't have a

[Bug libstdc++/95048] [10/11/12 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 Jonathan Wakely changed: What|Removed |Added CC||jengelh at inai dot de --- Comment

[Bug libstdc++/102839] filesystem::path::wstring runs in C locale / practically always throws

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102839 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW

[Bug libstdc++/95048] [10/11/12 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 Jonathan Wakely changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression]

[Bug libstdc++/95048] [10/11/12/13 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 --- Comment #18 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b331bf303bdc1edead41e2b3d11d1a7804b433cf commit r13-3909-gb331bf303bdc1edead41e2b3d11d1a7804b433cf Author: Jonathan Wakely

[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #6 from Alexander Monakov --- Sure, but I was talking specifically about the pattern matching introduced by that commit.

[Bug c++/107597] LTO causes static inline variables to get a non-uniqued global symbol

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107597 --- Comment #2 from Jan Hubicka --- Hi, What happens is that we read the symbol as: Visibility: externally_visible semantic_interposition prevailing_def_ironly_exp public weak comdat comdat_group:_ZN12NonTemplated1xE one_only While in

[Bug go/107491] Gccgo stack not resizing on Solaris

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491 --- Comment #9 from Ian Lance Taylor --- I would suggest adding a new field to the GODEBUG parsing in go/runtime/runtime1.go and then calling a new C function defined in libgo/runtime/proc.c to store the value in a C static variable.

[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > (In reply to Alexander Monakov from comment #3) > > Nice catch, thanks for the report. This is due to g:7d810646d421 > > > > The documentation should clarify

[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #4 from Andrew Pinski --- (In reply to Alexander Monakov from comment #3) > Nice catch, thanks for the report. This is due to g:7d810646d421 > > The documentation should clarify that patterns correspond to basic fma > instructions

[Bug libgomp/107641] [13 Regression] libgomp/env.c:286:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107641 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc

[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org ---

[Bug middle-end/107642] LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion

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

[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 Andrew Pinski changed: What|Removed |Added Blocks||53947 Summary|GCC 12.2.0

[Bug tree-optimization/107647] GCC 12.2.0 may produce FMAs even with -ffp-contract=off

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #1 from bartoldeman at users dot sourceforge.net --- According to godbolt it's still producing FMAs on trunk: https://godbolt.org/z/aWh6d1E4E

[Bug tree-optimization/107647] New: GCC 12.2.0 may produce FMAs even with -ffp-contract=off

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 Bug ID: 107647 Summary: GCC 12.2.0 may produce FMAs even with -ffp-contract=off Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal

[Bug other/107634] Very long filenames and URLs for sphinx-based docs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 Eric Botcazou changed: What|Removed |Added Severity|normal |critical

[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 --- Comment #1 from David Malcolm --- In particular, reference-count checking would probably be the most interesting aspect of the project.

[Bug other/107634] Very long filenames and URLs for sphinx-based docs

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

[Bug analyzer/107646] New: RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 Bug ID: 107646 Summary: RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin? Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug web/107644] [13 Regression] Sphinx generated web pages is not using the full width of the window

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107644 --- Comment #1 from Andrew Pinski --- Note sphinx is not the only one which hates my ultrawide screen too. Madoko hates it too as witness by https://p4.org/p4-spec/docs/P4-16-working-spec.html#sec-actions

[Bug target/107645] New: internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'E' (rtx unspec) in symbolic_operand_1, at config/m68k/predicates.md:144

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107645 Bug ID: 107645 Summary: internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'E' (rtx unspec) in symbolic_operand_1, at config/m68k/predicates.md:144

[Bug libgomp/107641] [13 Regression] libgomp/env.c:286:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107641 Jonathan Wakely changed: What|Removed |Added CC||marcel at codesourcery dot com

[Bug web/107644] [13 Regression] Sphinx generated web pages is not using the full width of the window

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107644 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0

[Bug web/107644] New: [13 Regression] Sphinx generated web pages is not using the full width of the window

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107644 Bug ID: 107644 Summary: [13 Regression] Sphinx generated web pages is not using the full width of the window Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug web/107643] [13 Regression] sphix generated indexes are not working at all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 --- Comment #1 from Andrew Pinski --- I had used these to find the options and other keywords for GCC 12 manual all the time. Because searching to find the right page is hard. Especially if it is 2 layers down.

[Bug web/107643] [13 Regression] sphix generated indexes are not working at all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0

[Bug web/107643] New: [13 Regression] sphix generated indexes are not working at all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 Bug ID: 107643 Summary: [13 Regression] sphix generated indexes are not working at all Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation

[Bug middle-end/107642] New: LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107642 Bug ID: 107642 Summary: LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation, internal-improvement,

[Bug c++/107638] [13 Regression] options.h:239:36: error: token "." is not valid in preprocessor expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107638 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|---

[Bug libgomp/107641] New: libgomp/env.c:286:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107641 Bug ID: 107641 Summary: libgomp/env.c:286:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] Product: gcc Version: 13.0

[Bug ipa/107640] New: IPA-CP drops known values passed by reference when the reference is to a global variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107640 Bug ID: 107640 Summary: IPA-CP drops known values passed by reference when the reference is to a global variable Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug other/107620] Build errors when using sphinx

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107620 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug other/107634] Very long filenames and URLs for sphinx-based docs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 --- Comment #2 from Andrew Pinski --- Hmm, I thought at one point we were producing also one big HTML for the manual but maybe that was just binutils. Also sphinx does not produce postscript? Just PDFs? Seems a downgrade. And yes I used to go

[Bug tree-optimization/107639] GCC unable to reason about range of idx/len

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107639 --- Comment #1 from Jeff Muizelaar --- This test case comes from https://github.com/llvm/llvm-project/issues/56612

[Bug tree-optimization/107639] New: GCC unable to reason about range of idx/len

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107639 Bug ID: 107639 Summary: GCC unable to reason about range of idx/len Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #24 from Sam Mish --- > Good! Can you please provide steps how to build the reproducer project? Unfortunately, this project uses a large and unconventional build system, so it's difficult to reproduce. I could upload the `.ii`

[Bug tree-optimization/107554] [10/11/12 Regression] Segmentation fault during GIMPLE pass: strlen (tree-ssa-strlen.cc:4772)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107554 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment

[Bug libstdc++/107636] [13 regression] r13-3761-ga239a63f868e29 breaks build on powerpc64le with __float128 support

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107636 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Ever

[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633 --- Comment #4 from Marek Polacek --- Actually, the patch I plan to post in a little bit should fix the problem above because the reference we're initializing here is non-const.

[Bug c++/107638] New: [13 Regression] options.h:239:36: error: token "." is not valid in preprocessor expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107638 Bug ID: 107638 Summary: [13 Regression] options.h:239:36: error: token "." is not valid in preprocessor expressions Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug c++/107622] Missing optimization of switch-statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622 --- Comment #7 from Marc Glisse --- (Wilhelm, when you post testcases, please post the full file including the #include lines) (In reply to Richard Biener from comment #5) > Did you try -fstrict-enums? IIUC, even if optimizations using

[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633 --- Comment #3 from Marek Polacek --- I thought this had been fixed by commit 32a06ce38a38bf37db468f0e6c83520fcc221534 Author: Marek Polacek Date: Tue Nov 1 17:05:52 2022 -0400 c++: Quash -Wdangling-reference for member operator*

[Bug c++/107637] New: C++23: Implement P2644R1 - Final Fix of Broken Range‐based for Loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107637 Bug ID: 107637 Summary: C++23: Implement P2644R1 - Final Fix of Broken Range‐based for Loop Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug libstdc++/107636] [13 regression] r13-3761-ga239a63f868e29 breaks build on powerpc64le with __float128 support

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107636 --- Comment #1 from Enrico Seiler --- The `#define`s can also be omitted. Then the error will occur when compiling with -std=c++23

  1   2   >