[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606 Thibaut M. changed: What|Removed |Added CC||dumoulin.thibaut at gmail dot com --- Comm

[Bug tree-optimization/107055] [13 Regression] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8415

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107055 --- Comment #2 from Hongtao.liu --- Hmm, vectorizable_nonlinear_induction doesn't guard nonlinear iv vectorization.

[Bug fortran/107062] [13 regression] gfortran.dg/ieee/fma_1.f90 fails after r13-2577-g7c4c65d11469d2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062 Francois-Xavier Coudert changed: What|Removed |Added Last reconfirmed||2022-09-28 Status

[Bug c++/107065] New: GCC treats rvalue like lvalue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065 Bug ID: 107065 Summary: GCC treats rvalue like lvalue Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ As

[Bug tree-optimization/107055] [13 Regression] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8415

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107055 --- Comment #3 from Hongtao.liu --- vect_peel_nonlinear_iv_init in vect_update_ivs_after_vectorizer should be guarded by vect_can_peel_nonlinear_iv_p

[Bug tree-optimization/107055] [13 Regression] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8415

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107055 --- Comment #4 from Hongtao.liu --- (In reply to Hongtao.liu from comment #3) > vect_peel_nonlinear_iv_init in vect_update_ivs_after_vectorizer should be > guarded by vect_can_peel_nonlinear_iv_p typo vect_can_advance_ivs_p

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #13 from Jakub Jelinek --- I wonder how it works for Tobias then. If the fixincluded headers go to /home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed/powerpc64le-linux-gnu/bits/floatn{,-common}.h and search path is: ... /home/s

[Bug tree-optimization/105414] constant folding for fmin/max(snan, snan) is wrong

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414 --- Comment #13 from CVS Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:b48d7ff3570fa0ebe7790275cf020d8885120338 commit r13-2914-gb48d7ff3570fa0ebe7790275cf020d8885120338 Author: Xi Ruoyao Date: Sat Sep

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #14 from Jakub Jelinek --- cppdefault.cc has: #ifdef FIXED_INCLUDE_DIR /* This is the dir for fixincludes. */ { FIXED_INCLUDE_DIR, "GCC", 0, 0, 0, /* A multilib suffix needs adding if different multilibs use d

[Bug target/106961] Testsuite failures after Command Line Tools update to v14

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106961 --- Comment #6 from simon at pushface dot org --- Installing the Command Line Tools 14.1 beta 3 fixes this problem.

[Bug tree-optimization/107066] New: Field initialized before ctor is mis-optimized away by DSE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107066 Bug ID: 107066 Summary: Field initialized before ctor is mis-optimized away by DSE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #15 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #13) > I wonder how it works for Tobias then. Bootstrap * works on x86_64 with Ubuntu 20.04.5 LTS (focal) with glibc 2.31-0ubuntu9.9 * fails on ppc64le with Ubuntu

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #16 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #14) > ..., so I think we could do: > --- gcc/cppdefault.cc.jj 2022-01-18 11:58:59.411984500 +0100 > +++ gcc/cppdefault.cc 2022-09-28 12:11:47.923603783 +0200 I

[Bug target/106961] Testsuite failures after Command Line Tools update to v14

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106961 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #17 from Tobias Burnus --- (In reply to Tobias Burnus from comment #16) > ln -s include-fixed/$target $target/include-fixed That should have been: ln -s ../include-fixed/$target $target/include-fixed with that change, ./gcc/x

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #18 from Jakub Jelinek --- You mean the #c14 change incorrectly adds /tmp/tburnus-gcc-test/gcc/powerpc64le-linux-gnu/include-fixed rather than /tmp/tburnus-gcc-test/gcc/include-fixed/powerpc64le-linux-gnu to search path?

[Bug c++/107065] GCC treats rvalue as an lvalue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFI

[Bug target/99723] [11/12/13 Regression] arm: ICE in build_function_type during selftests

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99723 --- Comment #3 from akrl at gcc dot gnu.org --- A fix was proposed here:

[Bug c++/107065] GCC treats rvalue as an lvalue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065 --- Comment #2 from Jason Liam --- Here is another reduced demo: https://godbolt.org/z/hGhfrKrad ``` #include int main() { bool b = true; std::cout << std::is_same::value << "\n"; auto bb = (!(!b)); std::cout << std::is_same:

[Bug c++/107065] GCC treats rvalue as an lvalue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065 --- Comment #3 from Jason Liam --- (In reply to Jonathan Wakely from comment #1) > Reduced to remove the library dependency: > > enum Cat { prvalue, lvalue, xvalue }; > > template > struct value_category { > // Or can be an integral or enu

[Bug c++/107065] GCC treats rvalue as an lvalue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065 --- Comment #4 from Jonathan Wakely --- Or as a compile-time test, not run-time: template struct is_same { static constexpr bool value = false; }; template struct is_same { static constexpr bool value = true; }; int main() { bool b = true;

[Bug fortran/107067] New: [OpenMP] ICE with metadirective block statements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107067 Bug ID: 107067 Summary: [OpenMP] ICE with metadirective block statements Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Prior

[Bug tree-optimization/107066] Field initialized before ctor is mis-optimized away by DSE

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

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #19 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #18) > You mean the #c14 comment 14 (< this adds a link) > change incorrectly adds > /tmp/tburnus-gcc-test/gcc/powerpc64le-linux-gnu/include-fixed > rather than >

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #20 from Tobias Burnus --- (In reply to Tobias Burnus from comment #19) > However, for the *installed* compiler, we have: ... > And as the fix-include floatn.h is under ... (To finish the sentence: Thus,) the *installed* compiler *

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #21 from Jakub Jelinek --- (In reply to Tobias Burnus from comment #19) Ah, so it is then correct for the installed compiler and we just need to figure out where the search paths for the build compiler come from and how they are dete

[Bug fortran/107068] New: Run-time error when reading logical arrays with a namelist

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068 Bug ID: 107068 Summary: Run-time error when reading logical arrays with a namelist Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal

[Bug c++/107069] New: string assignment triggers warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107069 Bug ID: 107069 Summary: string assignment triggers warning Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug fortran/107068] Run-time error when reading logical arrays with a namelist

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068 --- Comment #1 from Robert Potvliege --- Reading a logical array through a namelist triggers an (apparently) spurious run time error in some cases. E.g., when I am compiling the following code with gfortran, program test logical, di

[Bug c++/107065] GCC treats rvalue as an lvalue

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

[Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107060 --- Comment #4 from David Malcolm --- (In reply to David Malcolm from comment #3) > perf shows that 64% of the time is taken by this ctor: > shortest_paths::shortest_paths This is in the "find shortest feasible path for a diagnostic" code. F

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606 --- Comment #11 from R. Diez --- > Has a solution been found for embedded systems with very limited resources? > In this case for example, C++ exceptions can be disabled and this > emergency pool not needed. Contrary to popular belief, C++ exce

[Bug c++/107065] GCC treats rvalue as an lvalue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065 --- Comment #6 from Jason Liam --- The bug was discovered here: https://stackoverflow.com/questions/73877384/stdis-same-different-results-beween-compilers

[Bug middle-end/106776] Unexpected use-after-free warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106776 --- Comment #2 from Leandro Nini --- Oh, now I see it, it wasn't that obvious in the first test. But why is the compiler allowed to postpone the store after deleting the pointer? Is there some undefined behavior involved here or what?

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606 --- Comment #12 from Thibaut M. --- Thank you for the updated link! The problem with the original code is that it malloc unconditionally at least 2.4ko on the heap. This cannot be avoided when liking with libstdc++. This malloc is done very earl

[Bug fortran/107062] [13 regression] gfortran.dg/ieee/fma_1.f90 fails after r13-2577-g7c4c65d11469d2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062 --- Comment #2 from seurer at gcc dot gnu.org --- seurer@rain6p1:~/gcc/git/build/gcc-test$ cat a.f90 use ieee_arithmetic integer, parameter :: k1 = & max(ieee_selected_real_kind(precision(0.d0) + 1), kind(0.)) integer, parameter :: k2 =

[Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107060 David Malcolm changed: What|Removed |Added Depends on||99390 --- Comment #5 from David Malcolm

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606 --- Comment #13 from R. Diez --- It is hard to automatically tell whether nobody else is using such a statically-allocated emergency buffer. In my case, I am using C++ exceptions, so the linker will probably always include the buffer. My patch m

[Bug fortran/107062] [13 regression] gfortran.dg/ieee/fma_1.f90 fails after r13-2577-g7c4c65d11469d2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062 Francois-Xavier Coudert changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot g

[Bug fortran/107062] [13 regression] gfortran.dg/ieee/fma_1.f90 fails after r13-2577-g7c4c65d11469d2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062 --- Comment #3 from Francois-Xavier Coudert --- Hum, that one test for FMA is really unreliable. I think I need to remove it altogether, it fails on x86 as well for float and double, if it also fails on powerpc for long double, then let's get ri

[Bug c++/107070] New: GCC thinks !!b is an lvalue (bool b;)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107070 Bug ID: 107070 Summary: GCC thinks !!b is an lvalue (bool b;) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c++/107070] GCC thinks !!b is an lvalue (bool b;)

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

[Bug c++/107065] GCC treats rvalue as an lvalue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065 Marek Polacek changed: What|Removed |Added CC||nir.livne at gmail dot com --- Comment

[Bug fortran/107071] New: gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 Bug ID: 107071 Summary: gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compone

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 --- Comment #1 from Andreas Schwab --- STOP 3

[Bug analyzer/107072] New: Analyzer call summarization not taking into account side-effects of calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107072 Bug ID: 107072 Summary: Analyzer call summarization not taking into account side-effects of calls Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: norm

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 Francois-Xavier Coudert changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIR

[Bug fortran/107062] [13 regression] gfortran.dg/ieee/fma_1.f90 fails after r13-2577-g7c4c65d11469d2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062 --- Comment #4 from seurer at gcc dot gnu.org --- With that patch the test case passes.

[Bug tree-optimization/107066] Field initialized before ctor is mis-optimized away by DSE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107066 --- Comment #2 from Andrew Pinski --- See https://gcc.gnu.org/gcc-6/porting_to.html#flifetime-dse also. Which documented when the change happened back in GCC 6.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #22 from joseph at codesourcery dot com --- Even with the fixincluded headers properly being used, the powerpc64le issue still applies because of the issue I noted in https://sourceware.org/pipermail/libc-alpha/2022-September/14225

[Bug testsuite/107073] New: New test case gcc.dg/tree-ssa/gen-vect-34.c fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107073 Bug ID: 107073 Summary: New test case gcc.dg/tree-ssa/gen-vect-34.c fails Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug fortran/107074] New: ICE: Bad IO basetype (8)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107074 Bug ID: 107074 Summary: ICE: Bad IO basetype (8) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assig

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075 Bug ID: 107075 Summary: ICE in get, at cgraph.h:461 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran As

[Bug c/107076] New: ICE in gen_untyped_call, at config/i386/i386.md:15992

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107076 Bug ID: 107076 Summary: ICE in gen_untyped_call, at config/i386/i386.md:15992 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compo

[Bug c/107077] New: ICE in get_expr_operands, at tree-ssa-operands.cc:940

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107077 Bug ID: 107077 Summary: ICE in get_expr_operands, at tree-ssa-operands.cc:940 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compo

[Bug c/107077] __GIMPLE vs excess precision setting in std C with -m32 on x86_64 (ICE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107077 --- Comment #1 from Andrew Pinski --- The problem here is the C front-end adds a wrapper for double, float types (and sometimes half float types) and the gimple front-end part does not understand that.

[Bug target/107061] ENCODEKEY128 clobbers xmm4-xmm6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107061 --- Comment #1 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:db288230db55dc1ff626f46c708b555847013a41 commit r13-2919-gdb288230db55dc1ff626f46c708b555847013a41 Author: H.J. Lu Date: Tue Sep 27 16

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #7) > (In reply to Steve Kargl from comment #6) > > Yes, that would work! I was thinking of something more complex > > such as looking at the types of the operand(

[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Statu

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #23 from Tobias Burnus --- Regarding the $BUILD/gcc/include-fixed and xgcc -B $BUILD/gcc: In gcc.cc's driver_handle_option: add_prefix (&include_prefixes, arg, NULL, PREFIX_PRIORITY_B_OPT, 0, 0); Adds "$

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #24 from Jakub Jelinek --- (In reply to jos...@codesourcery.com from comment #22) > Even with the fixincluded headers properly being used, the powerpc64le > issue still applies because of the issue I noted in > https://sourceware.o

[Bug fortran/107074] ICE: Bad IO basetype (8)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107074 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #9 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #8) > (In reply to anlauf from comment #7) > > (In reply to Steve Kargl from comment #6) > > > Yes, that would work! I was thinking of something more complex > > >

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #25 from Tobias Burnus --- (In reply to jos...@codesourcery.com from comment #22) > with certain required changes to the powerpc version of bits/floatn.h not > being covered by the fixincludes fixes added. Jakub has posted a patch

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #26 from Jakub Jelinek --- (In reply to Tobias Burnus from comment #23) > Regarding the $BUILD/gcc/include-fixed and xgcc -B $BUILD/gcc: > > In gcc.cc's driver_handle_option: > > add_prefix (&include_prefixes, arg, NULL, >

[Bug fortran/107074] ICE: Bad IO basetype (8)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107074 --- Comment #2 from anlauf at gcc dot gnu.org --- We also crash in the same place on: program p implicit none procedure(real), pointer :: a print *, merge(a, a, .true.) end

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #27 from Manuel Lauss --- (In reply to Jakub Jelinek from comment #24) > (In reply to jos...@codesourcery.com from comment #22) > > Even with the fixincluded headers properly being used, the powerpc64le > > issue still applies becau

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-09-28 Ever confirme

[Bug c++/107069] string assignment triggers warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107069 --- Comment #1 from Jonathan Wakely --- This is a dup, but I don't have the PR number right now.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |13.0 Assignee|unassigned at

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606 --- Comment #15 from Jonathan Wakely --- (In reply to Thibaut M. from comment #10) > > see the "performance of exception handling" / "size of exception handling" > > thread in this month's archive of the gcc mailing list > I was not able to find

[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068 --- Comment #3 from Robert Potvliege --- Thanks for looking into this so quickly and for the work-round.

[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068 --- Comment #4 from Robert Potvliege --- Thanks for looking into this so quickly and for the work-round.

[Bug target/64215] -Os misses an opportunity to merge two ret instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64215 Tommy Murphy changed: What|Removed |Added CC||tommy_murphy at hotmail dot com --- Comme

[Bug target/64215] -Os misses an opportunity to merge two ret instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64215 --- Comment #3 from Andrew Pinski --- Hmm, I thought this would have been fixed by r13-2871-g1b74b5cb4e9d71 but it was not ...

[Bug lto/107078] New: LTO is causing that firebird build is core dumping

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 Bug ID: 107078 Summary: LTO is causing that firebird build is core dumping Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Compo

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772 --- Comment #17 from Thomas Rodgers --- Created attachment 53638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53638&action=edit benchmark main.cc

[Bug c++/107079] New: ICE initializing lifetime-extended constexpr variable that stores its this pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107079 Bug ID: 107079 Summary: ICE initializing lifetime-extended constexpr variable that stores its this pointer Product: gcc Version: 13.0 Status: UNCONFIRMED Sever

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772 --- Comment #18 from Mkkt Bkkt --- Thanks for provide source of your benchmarks! Can you also provide some example of usage atomic::notify where this optimization is needed? If it exists I think you right and it is necessary.

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772 --- Comment #19 from Mkkt Bkkt --- An example with a futex or other syscall would also work, because atomic::wait is still not widely used.

[Bug lto/107078] LTO is causing that firebird build is core dumping

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 Andrew Pinski changed: What|Removed |Added Version|unknown |12.2.1 --- Comment #1 from Andrew Pinsk

[Bug lto/107078] LTO is causing that firebird build is core dumping

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #2 from Andrew Pinski --- (In reply to Tomasz Kłoczko from comment #0) > I found that fedora spec file has disabled LTO as well with comment > > # firebird is mis-compiled when LTO is enabled. A root > # cause analysis has not yet b

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772 --- Comment #20 from Mkkt Bkkt --- My main concern with this optimization it's not zero-overhead. It's not necessary when we expect we have some waiters, in that case it just additional synchronization and contention in waiter pool (that have s

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772 --- Comment #21 from Thomas Rodgers --- (In reply to Mkkt Bkkt from comment #16) > > it with sarcasm > > I started with sarcasm because you restart this thread with some doubtful > benchmarks without code for them. > > I think it's very disres

[Bug target/64215] -Os misses an opportunity to merge two ret instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64215 --- Comment #4 from Tommy Murphy --- I meant to say that maybe the target needs to be widened/generalised beyond just "Target: x86_64-*-*"? As per my previous comment and link, the same issue has been observed with RISC-V and this comment a

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772 --- Comment #22 from Thomas Rodgers --- (In reply to Mkkt Bkkt from comment #20) > My main concern with this optimization it's not zero-overhead. > > It's not necessary when we expect we have some waiters, in that case it just > additional sync

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772 --- Comment #23 from Mkkt Bkkt --- (In reply to Thomas Rodgers from comment #21) > I wasn't sarcastic in what I posted. As I noted, this question has come up > before in different contexts, Bugzilla is a useful historical archive, so > updating

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772 --- Comment #24 from Mkkt Bkkt --- (In reply to Thomas Rodgers from comment #22) > Your example of '100+ core' systems especially on NUMA is certainly a valid > one. I would ask, at what point do those collisions and the resulting cache > invali

[Bug libstdc++/70692] No warning when std::function binds a reference to a temporary

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fa9bda3ea4315a7285edbc99323e3fa7885cbbb8 commit r13-2922-gfa9bda3ea4315a7285edbc99323e3fa7885cbbb8 Author: Jonathan Wakely Date:

[Bug libstdc++/70692] No warning when std::function binds a reference to a temporary

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|---

[Bug tree-optimization/90556] [meta-bug] bogus/missing -Wreturn-local-addr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556 Bug 90556 depends on bug 70692, which changed state. Bug 70692 Summary: No warning when std::function binds a reference to a temporary https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692 What|Removed |Added

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772 --- Comment #25 from Thomas Rodgers --- (In reply to Mkkt Bkkt from comment #24) > (In reply to Thomas Rodgers from comment #22) > > Your example of '100+ core' systems especially on NUMA is certainly a valid > > one. I would ask, at what point

[Bug c++/107080] New: ICE in verify_symtab_nodes using _Float64x with long double

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107080 Bug ID: 107080 Summary: ICE in verify_symtab_nodes using _Float64x with long double Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code

[Bug tree-optimization/107066] Field initialized before ctor is mis-optimized away by DSE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107066 --- Comment #3 from Feng Xue --- Got it. Thanks for that.

[Bug c/107081] New: ctime fct used twice in printf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107081 Bug ID: 107081 Summary: ctime fct used twice in printf Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c A

[Bug c/107081] ctime fct used twice in printf

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

[Bug c++/107080] ICE in verify_symtab_nodes using _Float64x with long double

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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #16 from Richard Biener --- (In reply to Alexander Monakov from comment #15) > (In reply to Richard Biener from comment #14) > > I can't > > seem to reproduce any vectorization for your smaller example though. > > My small C samples