[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 random number configurations of the shuffle function are the same, can the output differ depending on the gcc version?
[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 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Jonathan Wakely --- As requested when creating the bug, please read https://gcc.gnu.org/bugs/ and provide the missing information. You're asking us to download and analyze a whole codebase we've never seen before, which means your bug report will probably not get much attention.
[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 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: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: t3suzuki at ucsd dot edu Target Milestone: --- [gcc version] $ ./g++ -v Using built-in specs. COLLECT_GCC=./g++ COLLECT_LTO_WRAPPER=/home/tomoya-s/gcc-12.2.0/install/libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/tomoya-s/gcc-12.2.0/install --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (GCC) [the command line that triggers the bug] % git clone https://github.com/sbeamer/gapbs.git % cd gapbs % make bfs % ./bfs -g 10 -n 1 [the output by using g++-12.2.0 (or g++-11) ] Generate Time: 0.00282 Build Time: 0.00044 Graph has 1024 nodes and 10496 undirected edges for degree: 10 Source: 204 i0.1 td 2 0.0 td 59 0.0 e0.0 bu711 0.3 bu123 0.1 bu 0 0.1 c0.0 Trial Time: 0.00017 Average Time:0.00017 [the output by using g++-10 or earlier or clang++] Generate Time: 0.00797 Build Time: 0.00102 Graph has 1024 nodes and 10496 undirected edges for degree: 10 Source: 204 i0.1 td 15 0.1 e0.0 bu615 0.4 bu264 0.1 bu 1 0.1 c0.0 td 0 0.0 Trial Time: 0.00017 Average Time:0.00017 Of course, the execution time is different. We expect the numbers 2 and 59 and 711 after td and bu to be the same. This is because the input and the process itself are the same, and there is no randomness inside the process (random seed is fixed). Note that this program uses OpenMP, but even if we disable it, the results will be different depending on the g++ version as well.
[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 Date: Fri Nov 11 22:36:01 2022 + libstdc++: Define INSTANTIATE_FACET_ACCESSORS macro in compat source [PR103755] compatibility-ldbl-alt128.cc re-includes locale-inst-numeric.h and locale-inst-monetary.h but wasn't defining the macros added in r13-3888-gb3ac43a3c05744. Put those macros in a new internal header that can be included everywhere they're used. libstdc++-v3/ChangeLog: PR libstdc++/103755 * src/c++11/locale-inst-monetary.h: Include new header. * src/c++11/locale-inst-numeric.h: Likewise. * src/c++11/locale-inst.cc: Likewise. (INSTANTIATE_USE_FACET, INSTANTIATE_FACET_ACCESSORS): Move macro definitions to ... * src/c++11/facet_inst_macros.h: New file.
[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 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 53886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53886=edit single file source appears to be required to reproduce the problem This is reduced from a much larger (>100 000, line) code and is very sensitive to nearly any change to the remaining file, and requires everything being in a single file as well to reproduce reliably. I have workarounds now, but it might be a reproducer for something more generic. The "remove" C function is required, which is on Linux/Unix/... machines but not sure if that exists on MSWindows. gfortran -c xbug.f90 xbug.f90:42:27: 13 |function c_remove(c_path) bind(c,name="remove") result(c_err) | 2 .. 42 | call remove(self%key) | 1 Error: Global binding name ‘remove’ at (1) is already being used as a FUNCTION at (2) module m_system use,intrinsic :: iso_c_binding, only : c_int, c_char use,intrinsic :: iso_fortran_env, only : int32 implicit none private public :: CALLC contains elemental impure function CALLC(path) result(err) character(*),intent(in) :: path integer(c_int) :: err character(kind=c_char,len=1),allocatable :: temp(:) interface function c_remove(c_path) bind(c,name="remove") result(c_err) import c_char,c_int character(kind=c_char,len=1),intent(in) :: c_path(*) integer(c_int) :: c_err end function end interface err= c_remove(temp) end function CALLC end module m_system module m_list implicit none private public remove interface remove module procedure remove_char end interface public dictionary type dictionary character(len=:),allocatable :: key(:) end type dictionary contains subroutine remove_char(list) character(len=:),allocatable :: list(:) list=['a'] end subroutine remove_char subroutine dict_delete(self,key) class(dictionary),intent(in) :: self character(len=*),intent(in) :: key call remove(self%key) end subroutine dict_delete end module m_list
[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: > https://gcc.gnu.org/onlinedocs/gccint/target-macros/register-classes.html > > Splitted up: > https://gcc.gnu.org/onlinedocs/gccint/target-macros/stack-layout-and-calling- > conventions.html > > Both are on the same level and both have similar amount of information on > each section as far as I can tell. > > Does anyone understand how it was decided to split it up vs not splitting up? Sorry I copied the wrong one which was not split up. I Mean https://gcc.gnu.org/onlinedocs/gccint/target-macros/register-usage.html# Also the left side bar has an arrow next to that one but it expands to nothing.
[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: https://gcc.gnu.org/onlinedocs/gccint/target-macros/stack-layout-and-calling-conventions.html Both are on the same level and both have similar amount of information on each section as far as I can tell. Does anyone understand how it was decided to split it up vs not splitting 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 Version: 13.0 Status: UNCONFIRMED Keywords: documentation, internal-improvement Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- TARGET_EXPAND_TO_RTL_HOOK, TARGET_INSTANTIATE_DECLS and TARGET_MANGLE_TYPE are currently in the Storage Layout section of the manual. https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gccint/Storage-Layout.html#Storage-Layout But they don't belong there as they are not at all related to alignment or sizes. I don't know where the best place to put these though.
[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 post sphinx conversion is "random". Some sections are split up now while others are not. for an example the documentation for inline-asm is no longer split up (PR 107653). Does anyone understand the heurstic used for when sections were split up?
[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 sphinx, it is just C++ ABI parameters for both the section name and the heading: https://gcc.gnu.org/onlinedocs/gccint/target-macros/c%2B%2B-abi-parameters.html The file name definitely could just be C++-abi here since we are in the target macro section.
[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 #1 from Jakub Jelinek --- Why do you think so? MSVC doesn't implement (at least according to https://en.cppreference.com/w/cpp/compiler_support ) P2468R2 - The Equality Operator You Are Looking For, while GCC and clang trunks do. The paper has been accepted as DR, so it changes behavior of not just C++23, but also C++20 in this case. See https://wg21.link/p2468r2 for more details.
[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 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- These 4 target macros/hooks (PROMOTE_MODE is a macro) all are related and there should be one location which describes how they are related and examples of when you define them. Note the text of PROMOTE_MODE should be improved too: Do not define this macro if it would never modify m. I think a better way of writing that is: If the mode m will never be changed for the target, then this macro does not need to be defined.
[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 though; especially since target macros and hooks can sometimes take arguments.
[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: documentation Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Blocks: 107655 Target Milestone: --- https://gcc.gnu.org/onlinedocs/gccint/target-macros/storage-layout.html https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gccint/Storage-Layout.html#Storage-Layout For an example PROMOTE_MODE, in the texinfo version, it has: Macro: PROMOTE_MODE (m, unsignedp, type) while for TARGET_C_EXCESS_PRECISION: Target Hook: enum flt_eval_method TARGET_C_EXCESS_PRECISION (enum excess_precision_type type) But in the sphinx version, it does not list if it was a macro or a hook. Which makes these confusing of what each is. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107655 [Bug 107655] [meta-bug] tracker bug for issues encountered in the texinfo-to-sphinx migration
[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 Keywords: documentation, meta-bug Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Creating this tracker bug in case it helps organize the various texinfo-to-sphinx migration issues.
[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 Jonathan Wakely --- I see the problem here though, and can fix it easily enough.
[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 Date: Fri Nov 11 22:25:14 2022 + libstdc++: Fix for Windows [PR95048] I meant to include this change in r13-3909-gb331bf303bdc1e but I forgot to sync it from the machine where I did the mingw testing to the one where I pushed the commit. libstdc++-v3/ChangeLog: PR libstdc++/95048 * include/experimental/bits/fs_path.h (path::_Cvt::_S_wconvert): Construct codecvt directly instead of getting it from the locale.
[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 +6193,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
}
else if (arg->expr->expr_type == EXPR_NULL
&& fsym && !fsym->attr.pointer
+ && fsym->attr.optional
&& (fsym->ts.type != BT_CLASS
|| !CLASS_DATA (fsym)->attr.class_pointer))
{
[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 --- Comment #10 from seurer at gcc dot gnu.org --- It also breaks the build on one of our powerpc64 le machines (just the one). It fails in stage 1. g:b3ac43a3c05744d62a963d656bed782fc867ad79, r13-3888-gb3ac43a3c05744 When building gcc on one of our systems (just the one) the build fails in stage 1. Ubuntu 22.04.1 LTS gcc version 11.2.0 (Ubuntu 11.2.0-19ubuntu1) Ubuntu GLIBC 2.35-0ubuntu3.1) 2.35 make . . . libtool: compile: /home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gcc/xgcc -shared-libgcc -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gcc -nostdinc++ -L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/src -L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/sys-include -fno-checking -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/libsupc++ -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=compatibility-ldbl-alt128.lo -mno-gnu-attribute -g -O2 -D_GNU_SOURCE -mabi=ieeelongdouble -mno-gnu-attribute -Wno-psabi -std=gnu++11 -c /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/compatibility-ldbl-alt128.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o .libs/compatibility-ldbl-alt128.o In file included from /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/compatibility-ldbl-alt128.cc:36: /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/locale-inst-numeric.h:33:40: error: expected constructor, destructor, or type conversion before ';' token 33 | INSTANTIATE_FACET_ACCESSORS(num_get); |^ /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/locale-inst-numeric.h:34:40: error: expected constructor, destructor, or type conversion before ';' token 34 | INSTANTIATE_FACET_ACCESSORS(num_put); |^ In file included from /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/compatibility-ldbl-alt128.cc:37: /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/locale-inst-monetary.h:36:42: error: expected constructor, destructor, or type conversion before ';' token 36 | INSTANTIATE_FACET_ACCESSORS(money_put); | ^ /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/locale-inst-monetary.h:37:42: error: expected constructor, destructor, or type conversion before ';' token 37 | INSTANTIATE_FACET_ACCESSORS(money_get); | ^ In file included from /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/compatibility-ldbl-alt128.cc:44: /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/locale-inst-numeric.h:33:40: error: expected constructor, destructor, or type conversion before ';' token 33 | INSTANTIATE_FACET_ACCESSORS(num_get); |^ /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/locale-inst-numeric.h:34:40: error: expected constructor, destructor, or type conversion before ';' token 34 | INSTANTIATE_FACET_ACCESSORS(num_put); |^ In file included from /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/compatibility-ldbl-alt128.cc:45: /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/locale-inst-monetary.h:36:42: error: expected constructor, destructor, or type conversion before ';' token 36 | INSTANTIATE_FACET_ACCESSORS(money_put); | ^ /home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/src/c++11/locale-inst-monetary.h:37:42: error: expected constructor, destructor, or type conversion before ';' token 37 | INSTANTIATE_FACET_ACCESSORS(money_get); | ^ make[6]: *** [Makefile:1027:
[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: since the permutation of call s() works, I played and deactivated the if-branch at trans-expr.cc:6191, which avoids the assert, and I got a tree-dump that corresponds to my expectation.
[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 Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- I was trying to figure out where the documentation for constraints are located now but gcc/doc does not contain md.rst but it was in the toplevel doc directory. This makes it much harder to find documentation to update when we are updating target constraints.
[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. Keeping this RFE open to track -Wanalyzer-infinite-loop.
[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 Keywords: documentation, inline-asm Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- https://gcc.gnu.org/onlinedocs/gcc/extensions-to-the-c-language-family/how-to-use-inline-assembly-language-in-c-code.html really needs to split up into many different pages. Compared to https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Using-Assembly-Language-with-C.html#Using-Assembly-Language-with-C Having smaller pages is very useful, especially when you are going to just look at target constraints (which was a huge page even for texinfo generated documents): https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Machine-Constraints.html#Machine-Constraints having all information on inline-asm on one page makes it hard to figure out things even with the right side bar. The seperate pages of the texinfo generated files makes it easier to navigate especially to the specific topic you want to navigate to. Having a TOC page for each section is very very useful; the side bar only goes so far of describing things. Note I have not double checked to make sure that the internals document and the user manual are shared or not here plus disabling of some of the constraints for the user manual either.
[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 you have a list of env variables because of ASAN options. Or that should be part of the library section; I don't know fully.
[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: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tiagomacarios at gmail dot com
Target Milestone: ---
In C++20 gcc will chose the incorrect overload for this code. The overload
should be ambiguous (see msvc).
https://godbolt.org/z/rox1z1Txa
```
namespace N {
struct C;
struct B;
struct A {
bool fun(A, B, C);
bool operator==(A const&) const;
bool operator!=(A const&) const;
};
struct B : A {};
struct C : A {
bool operator==(C const&) const;
bool operator!=(C const&) const;
C(const B&);
};
} // namespace N
namespace N {
bool A::fun(A a, B b, C c) { return b == c; }
} // namespace N
```
[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: Fri Nov 11 15:58:40 2022 -0500
analyzer: new warning: -Wanalyzer-infinite-recursion [PR106147]
This patch adds a new -Wanalyzer-infinite-recursion warning to
-fanalyzer, which complains about certain cases of infinite recursion.
Specifically, when it detects recursion during its symbolic execution
of the user's code, it compares the state of memory to that at the
previous level of recursion, and if nothing appears to have effectively
changed, it issues a warning.
Unlike the middle-end warning -Winfinite-recursion (added by Martin
Sebor in GCC 12; r12-5483-g30ba058f77eedf), the analyzer warning
complains if there exists an interprocedural path in which recursion
occurs in which memory has not changed, whereas -Winfinite-recursion
complains if *every* intraprocedural path through the function leads to
a self-call.
Hence the warnings complement each other: there's some overlap, but each
also catches issues that the other misses.
For example, the new warning complains about a guarded recursion in
which the guard is passed unchanged:
void test_guarded (int flag)
{
if (flag)
test_guarded (flag);
}
t.c: In function 'test_guarded':
t.c:4:5: warning: infinite recursion [CWE-674]
[-Wanalyzer-infinite-recursion]
4 | test_guarded (flag);
| ^~~
'test_guarded': events 1-4
|
|1 | void test_guarded (int flag)
| | ^~~~
| | |
| | (1) initial entry to 'test_guarded'
|2 | {
|3 | if (flag)
| | ~
| | |
| | (2) following 'true' branch (when 'flag != 0')...
|4 | test_guarded (flag);
| | ~~~
| | |
| | (3) ...to here
| | (4) calling 'test_guarded' from 'test_guarded'
|
+--> 'test_guarded': events 5-6
|
|1 | void test_guarded (int flag)
| | ^~~~
| | |
| | (5) recursive entry to 'test_guarded'; previously
entered at (1)
| | (6) apparently infinite recursion
|
whereas the existing warning doesn't complain, since when "flag" is
false the function doesn't recurse.
The new warning doesn't trigger for e.g.:
void test_param_variant (int depth)
{
if (depth > 0)
test_param_variant (depth - 1);
}
on the grounds that "depth" is changing, and appears to be a variant
that enforces termination of the recursion.
gcc/ChangeLog:
PR analyzer/106147
* Makefile.in (ANALYZER_OBJS): Add analyzer/infinite-recursion.o.
gcc/analyzer/ChangeLog:
PR analyzer/106147
* analyzer.opt (Wanalyzer-infinite-recursion): New.
* call-string.cc (call_string::count_occurrences_of_function):
New.
* call-string.h (call_string::count_occurrences_of_function): New
decl.
* checker-path.cc (function_entry_event::function_entry_event):
New ctor.
(checker_path::add_final_event): Delete.
* checker-path.h (function_entry_event::function_entry_event): New
ctor.
(function_entry_event::get_desc): Drop "final".
(checker_path::add_final_event): Delete.
* diagnostic-manager.cc
(diagnostic_manager::emit_saved_diagnostic): Create the final
event via a new pending_diagnostic::add_final_event vfunc, rather
than checker_path::add_final_event.
(diagnostic_manager::add_events_for_eedge): Create function entry
events via a new pending_diagnostic::add_function_entry_event
vfunc.
* engine.cc (exploded_graph::process_node): When creating a new
PK_BEFORE_SUPERNODE node, call
exploded_graph::detect_infinite_recursion on it after adding the
in-edge.
* exploded-graph.h (exploded_graph::detect_infinite_recursion):
New decl.
(exploded_graph::find_previous_entry_to): New decl.
* infinite-recursion.cc: New file.
* pending-diagnostic.cc
(pending_diagnostic::add_function_entry_event): New.
(pending_diagnostic::add_final_event): New.
* pending-diagnostic.h
(pending_diagnostic::add_function_entry_event): New vfunc.
[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 Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- The texinfo generated indexes had two different kind of index. One for options and one for Concepts. I think for the user manual this should definitely stay around. If we could split it the concepts even further like lists all pargmas together and all attributes together that would even be better. Since indexes are currently broken, PR 107643. It is hard to tell what it will be like.
[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 very useful.
[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__) && defined(_GLIBCXX_FLOAT_IS_IEEE_BINARY32)
inline _Float16
__complex_abs(__complex__ _Float16 __z)
{ return _Float16(__builtin_cabsf(__z)); }
So should the __complex_type specializations that cause us to use __complex__
_Tp depend on those same macros? So we don't use the efficient representation
unless we can also define these overloads?
[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 Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- The texinfo generated HTML has an up link which links to the section that the page is linked from. While the Sphinx generated HTML does not. An example for texinfo is https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/eBPF-Options.html#eBPF-Options compared to https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/machine-dependent-options/ebpf-options.html . Is there a way to get this feature back? as it is useful when browsing the manual. The other thing that would be a nice feature back is having next/previous/up links at the start also and not just at the end of the page. The order of previous and next on the bottom of the page is ok even though it is swapped from what it was previously.
[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 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I think we just need all the new __complex_abs, __complex_pow etc. overloads to be earlier in the file.
[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: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
In we have:
template
requires(__complex_type<_Tp>::type)
class complex<_Tp>
{
This partial specialization is never used. The constraint looks for a constant
expression with true value, and none of the __complex_type specializations
provide that.
To test for a type name the constraint must be:
template
requires requires { typename __complex_type<_Tp>::type; }
class complex<_Tp>
{
However if I fix this, so that the partial specialization is used for float64_t
etc., then I get a cascade of errors for every overloaded function:
include/complex: In instantiation of '_Tp std::abs(const complex<_Tp>&) [with
_Tp = _Float16]':
testsuite/26_numerics/complex/ext_c++23.cc:28: required from 'void
test_functions(T*, std::complex<_Tp>*) [with T = _Float16]'
testsuite/26_numerics/complex/ext_c++23.cc:56: required from here
include/complex:629: error: call of overloaded
'__complex_abs(std::complex<_Float16>::_ComplexT)' is ambiguous
include/complex:618: note: candidate: 'float std::__complex_abs(__complex__
float)'
include/complex:621: note: candidate: 'double std::__complex_abs(__complex__
double)'
include/complex:624: note: candidate: 'long double std::__complex_abs(const
__complex__ long double&)'
include/complex: In instantiation of '_Tp std::arg(const complex<_Tp>&) [with
_Tp = _Float16]':
testsuite/26_numerics/complex/ext_c++23.cc:29: required from 'void
test_functions(T*, std::complex<_Tp>*) [with T = _Float16]'
testsuite/26_numerics/complex/ext_c++23.cc:56: required from here
include/complex:656: error: call of overloaded
'__complex_arg(std::complex<_Float16>::_ComplexT)' is ambiguous
include/complex:645: note: candidate: 'float std::__complex_arg(__complex__
float)'
include/complex:648: note: candidate: 'double std::__complex_arg(__complex__
double)'
include/complex:651: note: candidate: 'long double std::__complex_arg(const
__complex__ long double&)'
include/complex: In instantiation of 'std::complex<_Tp> std::cos(const
complex<_Tp>&) [with _Tp = _Float16]':
testsuite/26_numerics/complex/ext_c++23.cc:30: required from 'void
test_functions(T*, std::complex<_Tp>*) [with T = _Float16]'
testsuite/26_numerics/complex/ext_c++23.cc:56: required from here
This is because with the fix to the speclization, __rep() now returns a
__complex__ T and so we try to call one of the float/double/longdouble
overloads:
inline float
__complex_abs(__complex__ float __z) { return __builtin_cabsf(__z); }
inline double
__complex_abs(__complex__ double __z) { return __builtin_cabs(__z); }
inline long double
__complex_abs(const __complex__ long double& __z)
{ return __builtin_cabsl(__z); }
template
inline _Tp
abs(const complex<_Tp>& __z) { return __complex_abs(__z.__rep()); }
[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
CC||mpolacek at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #4 from Marek Polacek ---
We also crash on
asm (""_x);
but not
extern ""_x { void g(); }
A more complete test:
// PR c++/105300
void operator""_x(const char *, decltype(sizeof(0)));
static_assert(false, "foo"_x);
extern ""_x { void g(); }
void
lol ()
{
asm (""_x);
}
[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 Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- -fanalyzer implements -Wanalyzer-exposure-through-output-file, but it's currently just a proof-of-concept, where the only source of "sensitive" data is hardcoded as the result of the getpass function. Consider "explicit_bzero": https://man7.org/linux/man-pages/man3/bzero.3.html It would be nice to have an attribute for marking the argument to explicit_bzero as being security-sensitive, and the analyzer could perhaps then walk backwards from the callsite, checking that the contents of the buffer don't get exposed anywhere. Similarly, this could perhaps be used for annotating e.g. security APIs where private keys are passed in.
[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 dot gnu.org |mpolacek at gcc dot gnu.org Last reconfirmed||2022-11-11 Status|UNCONFIRMED |ASSIGNED
[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 ||a/show_bug.cgi?id=17107 --- Comment #3 from Andrew Pinski --- r0-49401-g85e50b6ba8ca22 introduced RANGE_TEST_NON_SHORT_CIRCUIT. r0-63607-gb8610a53763f72 renamed it to LOGICAL_OP_NON_SHORT_CIRCUIT. r0-126134-g5d2a9da9a7f7c1 introduced LOGICAL_OP_NON_SHORT_CIRCUIT to tree-ssa-ifcombine.c to basically do what was done in fold-const.c at the time. But again as mentioned dojump.c still undid what was done on the gimple level.
[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 LOGICAL_OP_NON_SHORT_CIRCUIT It would be better if it is defined in one place or better yet changed really to a target hook.
[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 override needs to happen in each place that LOGICAL_OP_NON_SHORT_CIRCUIT is used. This is fragil too.
[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|--- |FIXED --- Comment #3 from Andrew Macleod --- fixed.
[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: Fri Nov 11 12:22:33 2022 -0500 Don't add dependencies in update_stmt. gimple_ranger::update_stmt has no idea what the context of an update is, and should not be adding relations when it re-evaluates a stmt. PR tree-optimization/107523 gcc/ * gimple-range.cc (gimple_ranger::update_stmt): Use fur_stmt rather than fur_depend. gcc/testsuite/ * gcc.dg/pr107523.c: New.
[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 (reg:SI 13 %a5)
(const:SI (unspec:SI [
(symbol_ref:SI ("__gcov_kvp_dynamic_pool_index")
[flags 0x40] )
(const_int 0 [0])
] 6))) [0 S4 A8])) "gcc/libgcc/libgcov.h":472:44 55
{*movsi_m68k2}
(expr_list:REG_EQUAL (symbol_ref:SI ("__gcov_kvp_dynamic_pool_index")
[flags 0x40] )
(nil)))
Wrapping symbolic expressions into the unspec was added in the commit that
implemented TLS for m68k, but the 'CONST' case in the predicate code was not
updated to filter wrapped expressions out.
[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 |P2 Ever confirmed|0 |1 CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Invalid -> not P1. Started with r13-3550-g38a628f52cf0ff commit 38a628f52cf0ff5db6708578248484d50a50b366 Author: Jason Merrill Date: Fri Oct 28 10:45:06 2022 -0400 c++: apply friend attributes sooner
[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 --- Comment #3 from Marek Polacek --- Started with r241944 most likely.
[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 Summary|LOCAL_DECL_ALIGNMENT macro |LOCAL_DECL_ALIGNMENT and |documentation is incorrect. |TARGET_LOWER_LOCAL_DECL_ALI ||GNMENT macro documentation ||should be improved Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- There is now TARGET_LOWER_LOCAL_DECL_ALIGNMENT which was added by r11-2259-g 0a9d711df36b42 . We should provide examples of when one should be used vs the other. And maybe even better describe why there are two target hooks that seems like does the same thing now. I am going to try to this for GCC 14 with the other target macro/hooks cleanups I am doing.
[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|--- |13.0
[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 from Yann Droneaud ---
I'm reaching this bug too, compiling the following smaller reproducer:
extern void a(void);
inline void b(int c) { if (c) a(); }
void d(void) { b(0); }
[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 Date: Fri Nov 11 22:23:31 2022 +1100 libstdc++: Set active union member in constexpr std::string [PR103295] Clang still complains about using std::string in constexpr contexts due to the changes made in commit 98a0d72a. This patch ensures that we set the active member of the union as according to [class.union.general] p6. libstdc++-v3/ChangeLog: PR libstdc++/103295 * include/bits/basic_string.h (_M_use_local_data): Set active member to _M_local_buf. Signed-off-by: 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 FMA (or FMA-like) don't try to generate a FMA when -ffp-contract=off is supplied. The target backend should NOT know about flag_fp_contract_mode for the FMA like patterns. It is up to the middle-end optimizers to produce the correct thing.
[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 #20 from Jonathan Wakely --- *** Bug 102839 has been marked as a duplicate of this bug. ***
[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 |RESOLVED --- Comment #5 from Jonathan Wakely --- Dup of PR 95048 which is now fixed on trunk. *** This bug has been marked as a duplicate of bug 95048 ***
[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] |wstring-constructor of |wstring-constructor of |std::filesystem::path |std::filesystem::path |throws for non-ASCII|throws for non-ASCII |characters |characters Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #19 from Jonathan Wakely --- Thanks for the patch, but I've fixed this slightly differently. The conditional logic was a mess, I hope it's easier to follow now. The fix has also been applied to experimental::filesystem::path. The fix still needs to be backported to the release branches. Thanks to everybody who helped me understand what the right conversions were here.
[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 Date: Fri Nov 11 15:22:02 2022 + libstdc++: Fix wstring conversions in filesystem::path [PR95048] In commit r9-7381-g91756c4abc1757 I changed filesystem::path to use std::codecvt for conversions from all wide strings to UTF-8, instead of using std::codecvt_utf8. This was done because for 16-bit wchar_t, std::codecvt_utf8 only supports UCS-2 and not UTF-16. The rationale for the change was sound, but the actual fix was not. It's OK to use std::codecvt for char16_t or char32_t, because the specializations for those types always use UTF-8 , but std::codecvt uses the current locale's encodings, and the narrow encoding is probably ASCII and can't support non-ASCII characters. The correct fix is to use std::codecvt only for char16_t and char32_t. For 32-bit wchar_t we could have continued using std::codecvt_utf8 because that uses UTF-32 which is fine, switching to std::codecvt broke non-Windows targets with 32-bit wchar_t. For 16-bit wchar_t we did need to change, but should have changed to std::codecvt_utf8_utf16 instead, as that always uses UTF-16 not UCS-2. I actually noted that in the commit message for r9-7381-g91756c4abc1757 but didn't use that option. Oops. This replaces the unconditional std::codecvt with a type defined via template specialization, so it can vary depending on the wide character type. The code is also simplified to remove some of the mess of #ifdef and if-constexpr conditions. libstdc++-v3/ChangeLog: PR libstdc++/95048 * include/bits/fs_path.h (path::_Codecvt): New class template that selects the kind of code conversion done. (path::_Codecvt): Select based on sizeof(wchar_t). (_GLIBCXX_CONV_FROM_UTF8): New macro to allow the same code to be used for Windows and POSIX. (path::_S_convert(const EcharT*, const EcharT*)): Simplify by using _Codecvt and _GLIBCXX_CONV_FROM_UTF8 abstractions. (path::_S_str_convert(basic_string_view, const A&)): Simplify nested conditions. * include/experimental/bits/fs_path.h (path::_Cvt): Define nested typedef controlling type of code conversion done. (path::_Cvt::_S_wconvert): Use new typedef. (path::string(const A&)): Likewise. * testsuite/27_io/filesystem/path/construct/95048.cc: New test. * testsuite/experimental/filesystem/path/construct/95048.cc: New test.
[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 visibility pass we promote it to: Visibility: externally_visible semantic_interposition prevailing_def_ironly_exp public comdat So we disolve comdat group and turn off weak. This leads to better code generation and we know it does not affect dynamic linking since in shared library all symbols are interposable. So this is kind of feature. How the ODR violations are detected? I wonder if keeping weak flag disturbs something.
[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 that patterns correspond to basic fma
> > instructions (without intermediate rounding), and SLP pattern matching
> > should check flag_fp_contract_mode != FP_CONTRACT_OFF.
>
> I don't think they should. Because __builtin_fma (and fma and fmaf) should
> be able to be used from an user program and still get FMA instructions. And
> even the SLP instruction patterns can be generating using those.
That is:
void f(float *a, float *b, float *c)
{
float t0 = __builtin_fmaf(a[0], b[0], c[0]);
float t1 = __builtin_fmaf(a[1], b[1], c[1]);
a[0] = t0;
a[1] = t1;
}
Should produce:
vmovq xmm0, QWORD PTR [rdi]
vmovq xmm2, QWORD PTR [rsi]
vmovq xmm1, QWORD PTR [rdx]
vfmadd132ps xmm0, xmm1, xmm2
vmovlps QWORD PTR [rdi], xmm0
ret
Even with -ffp-contract=off -march=haswell -O3
[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 (without intermediate rounding), and SLP pattern matching > should check flag_fp_contract_mode != FP_CONTRACT_OFF. I don't think they should. Because __builtin_fma (and fma and fmaf) should be able to be used from an user program and still get FMA instructions. And even the SLP instruction patterns can be generating using those.
[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 dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2022-11-11 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 53885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53885=edit gcc13-pr107641.patch Untested fix. Using unsigned for upper is also quite suspicious, because the code then does if (upper <= UCHAR_MAX) something; else if (upper <= UINT_MAX) something else; else something different; but if upper is unsigned, then upper <= UINT_MAX is always true.
[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 --- Comment #3 from Alexander Monakov --- Nice catch, thanks for the report. This is due to g:7d810646d421 The documentation should clarify that patterns correspond to basic fma instructions (without intermediate rounding), and SLP pattern matching should check flag_fp_contract_mode != FP_CONTRACT_OFF.
[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 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org
[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 may produce FMAs |[12/13 Regression] GCC |even with -ffp-contract=off |12.2.0 may produce FMAs ||even with -ffp-contract=off Target Milestone|--- |12.3 Keywords||wrong-code Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-11-11 --- Comment #2 from Andrew Pinski --- Confirmed. It is SLP that is doing it. At -O3 even GCC 11 is working ok. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[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
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bartoldeman at users dot sourceforge.net
Target Milestone: ---
I stumped upon an example where GCC generates FMA instruction even when FMAs
are disabled using -ffp-contract=off (extracted from
https://github.com/xianyi/OpenBLAS/blob/develop/kernel/x86_64/cscal.c)
$ cat cscal.c
void cscal(int n, float da_r, float *x)
{
for (int i = 0; i < n; i += 4)
{
float temp0 = da_r * x[i] - x[i+1];
float temp1 = da_r * x[i+2] - x[i+3];
x[i+1] = da_r * x[i+1] + x[i];
x[i+3] = da_r * x[i+3] + x[i+2];
x[i] = temp0;
x[i+2] = temp1;
}
}
$ gcc -S -march=haswell -O2 -ffp-contract=off cscal.c
$ grep fma cscal.s
vfmaddsub231ps %xmm0, %xmm2, %xmm1
I would expect there to be no FMA instructions in there.
[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||2022-11-11 CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #3 from Eric Botcazou --- Indeed, there are now 746 files under doc/ with ridiculously long names for a bunch of them. I don't think that's even remotely manageable.
[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 Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- My gcc-python-plugin implements a crude static analysis of CPython code, using symbolic execution in a manner similar to how -fanalyzer works, but it's been bitrotting for years, and is slow (being written in Python itself): https://gcc-python-plugin.readthedocs.io/en/latest/cpychecker.html I *think* this could now be reimplemented as a plugin to GCC's -fanalyzer (in C++), where -fanalyzer provides most of the framework needed, and we'd mostly just need to write the CPython-specific parts. It would make an interesting GSoC project (albeit perhaps a challenging one).
[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 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jcmvbkbc at gcc dot gnu.org Target Milestone: --- Created attachment 53884 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53884=edit _gcov_indirect_call_profiler_v4.i Building gcc with --enable-checking=all for target=m68k-linux-uclibc breaks with the following error message: gcc/libgcc/libgcov-profiler.c: In function ‘__gcov_indirect_call_profiler_v4’: gcc/libgcc/libgcov-profiler.c:173:1: 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 It can be reproduced with the following command line and the attached source: cc1 -O2 -fPIC -g -fno-stack-protector -mcpu=68040 _gcov_indirect_call_profiler_v4.i Bisection points to the following revision: r0-93570-g75df395f15f2
[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 Target||*mingw* Known to fail||13.0 Summary|libgomp/env.c:286:20: |[13 Regression] |error: cast from pointer to |libgomp/env.c:286:20: |integer of different size |error: cast from pointer to |[-Werror=pointer-to-int-cas |integer of different size |t] |[-Werror=pointer-to-int-cas ||t] Known to work||12.2.0 Target Milestone|--- |13.0 --- Comment #1 from Jonathan Wakely --- Presumably started with r13-2545-g9f2fca56593a2b
[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 Keywords: documentation Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Created attachment 53883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53883=edit screen shot of my chrome window I have an ultra wide screen so I can read left to right without scrolling. With the current way sphinx generated web pages are, they are centered in the window even and just fill up part a small part of the window rather than the full left to right. If we can disable this centering and forcing only part of the window to be use that would be great.
[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 Severity: blocker Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- https://gcc.gnu.org/onlinedocs/gccint/indices-and-tables.html https://gcc.gnu.org/onlinedocs/gcc/indices-and-tables.html All say TODO
[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,
missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
LOGICAL_OP_NON_SHORT_CIRCUIT is defined as:
@defmac LOGICAL_OP_NON_SHORT_CIRCUIT
Define this macro if a non-short-circuit operation produced by
@samp{fold_range_test ()} is optimal. This macro defaults to true if
@code{BRANCH_COST} is greater than or equal to the value 2.
@end defmac
Some targets define it to 0 or something else:
apinski@xeond:~/src/upstream-gcc-git/gcc/gcc/config$ git grep
LOGICAL_OP_NON_SHORT_CIRCUIT */*.h
arc/arc.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT \
arm/arm.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT
\
csky/csky.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT \
loongarch/loongarch.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
mips/mips.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
msp430/msp430.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
nds32/nds32.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
pru/pru.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
riscv/riscv.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
rs6000/rs6000.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
visium/visium.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
arc.h:
#define LOGICAL_OP_NON_SHORT_CIRCUIT \
(BRANCH_COST (optimize_function_for_speed_p (cfun), \
false) > 9)
arm.h:
#define LOGICAL_OP_NON_SHORT_CIRCUIT\
((optimize_size) \
? (TARGET_THUMB ? false : true) \
: TARGET_THUMB ? static_cast
(current_tune->logical_op_non_short_circuit_thumb) \
: static_cast (current_tune->logical_op_non_short_circuit_arm))
csky.h (which is the default it seems):
#define LOGICAL_OP_NON_SHORT_CIRCUIT \
(csky_default_logical_op_non_short_circuit ())
...
bool
csky_default_logical_op_non_short_circuit (void)
{
return BRANCH_COST (optimize_function_for_speed_p (cfun), false) >= 2;
}
LOGICAL_OP_NON_SHORT_CIRCUIT is used in many few places than fold_range_test
these days too.
fold-const.cc:#ifndef LOGICAL_OP_NON_SHORT_CIRCUIT
fold-const.cc:#define LOGICAL_OP_NON_SHORT_CIRCUIT \
fold-const.cc: bool logical_op_non_short_circuit =
LOGICAL_OP_NON_SHORT_CIRCUIT;
fold-const.cc: bool logical_op_non_short_circuit =
LOGICAL_OP_NON_SHORT_CIRCUIT;
tree-ssa-ifcombine.cc:#ifndef LOGICAL_OP_NON_SHORT_CIRCUIT
tree-ssa-ifcombine.cc:#define LOGICAL_OP_NON_SHORT_CIRCUIT \
tree-ssa-ifcombine.cc:bool logical_op_non_short_circuit =
LOGICAL_OP_NON_SHORT_CIRCUIT;
fold_truth_andor in fold-const.cc
ifcombine_ifandif in tree-ssa-ifcombine.cc
What LOGICAL_OP_NON_SHORT_CIRCUIT is trying to say is that expansion (from
gimple to RTL) of
things like `a & b` (where a and b are bools) is cheaper than expanding out
using jumps.
Note this is not exactly true as there is code which does that again in
dojump.cc:
/* High branch cost, expand as the bitwise OR of the conditions.
Do the same if the RHS has side effects, because we're effectively
turning a TRUTH_OR_EXPR into a TRUTH_ORIF_EXPR. */
if (BRANCH_COST (optimize_insn_for_speed_p (), false) >= 4
|| TREE_SIDE_EFFECTS (TREE_OPERAND (exp, 1)))
[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|--- |13.0 Last reconfirmed||2022-11-11 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Whoops, sorry for the build breakage, I had wrongly assumed SUPPORTS_INIT_PRIORITY is always a simple constant. Instead of trying to statically exclude init_priority from the attribute table, I guess we should just special case init_priority in the __has_attribute handling.
[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 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- I'm seeing a bootstrap failure on mingw-w64 ../../../gcc/libgomp/env.c: In function 'parse_unsigned_long': ../../../gcc/libgomp/env.c:286:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 286 | unsigned upper = (unsigned long) params[2]; |^ cc1: all warnings being treated as errors unsigned long is 32-bit on Windows.
[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
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
Combining IPA-CP of (scalar) parameter values and of values passed by reference
(aggregate values) does not work in the same function parameter, we drop the
aggregate values on the floor.
The following aborts when compiled with -O2 -DFAIL
struct S
{
int a, b, c;
};
volatile int gi;
void __attribute__((noipa))
consume_s (struct S *p)
{
gi = p->a;
}
static void __attribute__((noinline))
foo (struct S *p)
{
if (!__builtin_constant_p (p->b))
__builtin_abort ();
consume_s (p);
}
static struct S __attribute((used)) gs;
int main (int argc, char *argv[])
{
struct S *p;
#ifdef FAIL
p =
#else
struct S s;
p =
#endif
p->a = 10;
p->b = 20;
foo (p);
return 0;
}
[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 |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Last reconfirmed||2022-11-11 CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed. Btw. what revision do you build and what command do you use?
[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 into invoke.texi and do a search for the options too. Splitting it up into different files is a HUGE downgrade.
[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: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jmuizelaar at mozilla dot com
Target Milestone: ---
Clang 14 is able to optimize this function to just 'ret'. GCC 12.2 is not.
#include
void do_checks(const int* begin, const size_t len){
size_t idx = 0;
const auto end = begin + len;
for (const int* it = begin; it!=end; ++it, ++idx){
if (idx <= len){
// Do something useful
}
else
{
throw 5;
}
}
}
https://godbolt.org/z/f7PjjqG9T
[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` files, but each of the libraries in that /home/sam/code/serac_libs_gcc12/gcc-12.1.0/ directory were built custom (and might be relevant to the failure) I can look into trying to reproduce the issue in a docker image-- would that be helpful?
[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 #7 from Jakub Jelinek --- I agree. For prep != NULL, we know it must fit into unsigned int, we don't even support longer STRING_CSTs, but for NULL prep it can be larger.
[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 confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-11-11
--- Comment #2 from Jakub Jelinek ---
Created attachment 53882
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53882=edit
gcc13-pr107636.patch
Untested fix.
I've just tested that
int bar ();
int
foo ()
{
return __extension__ bar ();
}
is accepted by both g++ and clang++.
[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 Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: ppalka at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 The following problem was introduced by commit d0a492faa6478c99d325fa4a7ed2e5633cef7529: g++ -std=c++11 -fno-PIE -c -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions - fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -W cast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I . -Icp -I../../gcc/gcc -I../../gcc/gcc/cp -I../../gcc/gcc/../include -I../../gcc /gcc/../libcpp/include -I../../gcc/gcc/../libcody -I/opt/gnu64/gcc/gmp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecn umber -I../../gcc/gcc/../libbacktrace -I/opt/gnu64/gcc/gmp/include -o cp/tree.o -MT cp/tree.o -MMD -MP -MF cp/.deps/tree.TPo ../../gcc/gcc/cp/tree.cc In file included from ../../gcc/gcc/tree.h:24, from ../../gcc/gcc/cp/tree.cc:24: ./options.h:239:36: error: token "." is not valid in preprocessor expressions 239 | #define target_flags global_options.x_target_flags |^ ./options.h:8725:25: note: in expansion of macro 'target_flags' 8725 | #define TARGET_GNU_LD ((target_flags & MASK_GNU_LD) != 0) | ^~~~ ../../gcc/gcc/config/pa/pa64-hpux.h:358:33: note: in expansion of macro 'TARGET_GNU_LD' 358 | #define SUPPORTS_INIT_PRIORITY (TARGET_GNU_LD ? 1 : 0) | ^ ../../gcc/gcc/cp/tree.cc:5039:5: note: in expansion of macro 'SUPPORTS_INIT_PRIORITY' 5039 | #if SUPPORTS_INIT_PRIORITY | ^~ make[3]: *** [Makefile:1135: cp/tree.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory '/home/dave/gnu/gcc/objdir64/gcc' make[2]: *** [Makefile:4915: all-stage1-gcc] Error 2 make[2]: Leaving directory '/home/dave/gnu/gcc/objdir64' make[1]: *** [Makefile:25469: stage1-bubble] Error 2 make[1]: Leaving directory '/home/dave/gnu/gcc/objdir64' make: *** [Makefile:25822: bootstrap] Error 2 Fri Nov 11 09:17:16 EST 2022 On hppa64-hpux, we have the following define for SUPPORTS_INIT_PRIORITY: #define SUPPORTS_INIT_PRIORITY (TARGET_GNU_LD ? 1 : 0) The goal was to support the init_priority attribute with GNU ld and not with HP ld. The documentation doesn't indicate whether C statements are allowed or not for SUPPORTS_INIT_PRIORITY.
[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 -fstrict-enums were implemented, they would
only help with the first testcase if the number of enum values was a power of
2. For {A,B,C}, -fstrict-enums still considers 3 a valid value.
I have long wanted an attribute to specify that a particular enum is only
allowed to take the values explicitly listed, though I cannot find a relevant
issue in bugzilla at the moment.
Comment #4 is an independent issue where gcc fails to notice that since the
static variable does not escape, it can be replaced with a local constant.
[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* [PR107488]
-Wdangling-reference complains here:
std::vector v = ...;
std::vector::const_iterator it = v.begin();
while (it != v.end()) {
const int = *it++; // warning
}
is the operator* here a non-member function?
[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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Testcase:
// P2644R1 - Final Fix of Broken Range‐based for Loop
// { dg-do run { target c++11 } }
extern "C" void abort ();
struct S
{
S () { ++s; }
S (const S &) { ++s; }
~S () { --s; }
static int s;
};
int S::s;
struct T
{
T (const S &, const S &) { ++t; }
T (const T &) { ++t; }
~T () { --t; }
static int t;
};
int T::t;
int a[4];
int *
begin (const S &)
{
return [0];
}
int *
end (const S &)
{
return [4];
}
int *
begin (const T &)
{
return [0];
}
int *
end (const T &)
{
return [4];
}
const S &
foo (const S )
{
return x;
}
const T &
foo (const T )
{
return x;
}
int
main ()
{
if (S::s != 0)
abort ();
for (auto x : S ())
{
if (S::s != 1)
abort ();
}
if (S::s != 0)
abort ();
for (auto x : foo (S ()))
{
if (S::s != (__cpp_range_based_for >= 202211L))
abort ();
}
if (S::s != 0)
abort ();
if (T::t != 0)
abort ();
for (auto x : T (S (), S ()))
{
if (S::s != 2 * (__cpp_range_based_for >= 202211L) || T::t != 1)
abort ();
}
if (S::s != 0 || T::t != 0)
abort ();
for (auto x : foo (T (S (), S (
{
if (S::s != 2 * (__cpp_range_based_for >= 202211L)
|| T::t != (__cpp_range_based_for >= 202211L))
abort ();
}
if (S::s != 0 || T::t != 0)
abort ();
}
if I understand the paper well.
Tried to play with it, but:
--- gcc/cp/decl.cc.jj 2022-11-11 08:43:28.296462815 +0100
+++ gcc/cp/decl.cc 2022-11-11 13:53:19.071246170 +0100
@@ -7809,7 +7809,14 @@ initialize_local_var (tree decl, tree in
gcc_assert (building_stmt_list_p ());
saved_stmts_are_full_exprs_p = stmts_are_full_exprs_p ();
- current_stmt_tree ()->stmts_are_full_exprs_p = 1;
+ // P2644R1 - for-range-initializer in C++23 should have temporaries
+ // destructed only at the end of the whole range for loop.
+ if (cxx_dialect >= cxx23
+ && DECL_ARTIFICIAL (decl)
+ && DECL_NAME (decl) == for_range__identifier)
+ current_stmt_tree ()->stmts_are_full_exprs_p = 0;
+ else
+ current_stmt_tree ()->stmts_are_full_exprs_p = 1;
finish_expr_stmt (init);
current_stmt_tree ()->stmts_are_full_exprs_p =
saved_stmts_are_full_exprs_p;
--- gcc/cp/semantics.cc.jj 2022-11-09 11:22:42.612628127 +0100
+++ gcc/cp/semantics.cc 2022-11-11 15:49:30.569832414 +0100
@@ -1408,7 +1408,10 @@ finish_for_stmt (tree for_stmt)
}
}
- add_stmt (do_poplevel (scope));
+ tree bind = do_poplevel (scope);
+ if (range_for_decl[0] && cxx_dialect >= cxx23)
+bind = maybe_cleanup_point_expr_void (bind);
+ add_stmt (bind);
/* If we're being called from build_vec_init, don't mess with the names of
the variables for an enclosing range-for. */
ICEs, not sure why the outer CLEANUP_POINT_EXPR doesn't catch those TARGET_EXPR
cleanups.
But, I think it could interact badly with the cleanups for extended lifetime
references.
So shall something walk init in cp_finish_decl of for_range__identifier decls,
look similarly to wrap_cleanups init and look for cleanups on TARGET_EXPRs not
nested inside of CLEANUP_POINT_EXPRs and somehow extend their lifetime (perhaps
move them out of the TARGET_EXPRs just into normal cleanups)?
Giving up on this...
[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
