[Bug middle-end/99668] Converting argument _Complex double to double vector causes STLF stall

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

[Bug target/109854] Error: junk `(%rip)' after expression when using -flto on files compiled with and without -masm=intel

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

[Bug target/32187] Complex __float128 is rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187 --- Comment #13 from Andrew Pinski --- (In reply to jos...@codesourcery.com from comment #12) > You can now use _Complex _Float128. Given that, it's not obvious that > _Complex __float128, with the legacy __float128 type name, should be > supp

[Bug target/109854] Error: junk `(%rip)' after expression when using -flto on files compiled with and without -masm=intel

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

[Bug tree-optimization/79359] Squaring a complex float gives inefficient code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79359 --- Comment #4 from Andrew Pinski --- Confirmed, I suspect this is really a dup of bug 48609 (and others).

[Bug target/109854] Error: junk `(%rip)' after expression when using -flto on files compiled with and without -masm=intel

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109854 --- Comment #3 from Jakub Jelinek --- As for inline asm, one has always the possibility to support both through the {att|intel} syntax, not really sure in which dialect toplevel asms would be emitted though, and whether we allow inlining between

[Bug target/80372] non-optimal handling of copying a std::complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80372 Andrew Pinski changed: What|Removed |Added Component|middle-end |target Last reconfirmed|2021-07-24 00:

[Bug target/109797] 456.hmmer compiled with -O2 -flto regressed by 15% on AMD zen3 between r14-487-g6f18f344338b37 and r14-540-gb7fe38c14e5f1b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797 --- Comment #13 from Richard Biener --- (In reply to Uroš Bizjak from comment #5) > (In reply to Richard Biener from comment #4) > > No, it's indeed plain -O2 with the default architecture level, thus SSE2 > > only. > > > > For the case of "com

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 --- Comment #2 from Hongtao.liu --- Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help?

[Bug c++/109241] [12/13/14 Regression] ICE Segmentation fault for statement expression with a local type inside inside a generic lambda inside a generic lambda since r13-6722-gb323f52ccf966800

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241 Richard Biener changed: What|Removed |Added Summary|[12/13 Regression] ICE |[12/13/14 Regression] ICE

[Bug c++/106740] [11/12 Regression] ICE in instantiate_decl at gcc/cp/pt.cc:26515 since r12-8467-ge057d454db4dcf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106740 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug testsuite/108776] new test case c-c++-common/rotate-11.c from r12-9158-ga015ebe382cd6d fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108776 --- Comment #3 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:9410a52061ffe4a9e6ef8fd82f9c21d1874ff589 commit r12-9538-g9410a52061ffe4a9e6ef8fd82f9c21d1874ff589 Author: Richard Biener

[Bug testsuite/108776] new test case c-c++-common/rotate-11.c from r12-9158-ga015ebe382cd6d fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108776 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug libstdc++/109808] [12 regression] FAIL: libstdc++-prettyprinters/libfundts.cc print as with _GLIBCXX_USE_CXX11_ABI 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109808 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610 --- Comment #10 from Segher Boessenkool --- (In reply to Hongtao.liu from comment #5) > One solution is add an peephole for handle such redudancy. Not okay. > If powerpc maintainer doesn't like this way, another alternative is add a > target h

[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610 --- Comment #11 from Segher Boessenkool --- (In reply to Hongtao.liu from comment #5) > One solution is add an peephole for handle such redudancy. Not okay. > If powerpc maintainer doesn't like this way, another alternative is add a > target h

[Bug tree-optimization/109848] [14 Regression] Recent change causing testsuite ICE on csky port

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109848 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7db541ce448c2776971be63c957dcc887bd09bf8 commit r14-817-g7db541ce448c2776971be63c957dcc887bd09bf8 Author: Richard Biener Date:

[Bug tree-optimization/109848] [14 Regression] Recent change causing testsuite ICE on csky port

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

[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195 --- Comment #14 from CVS Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:676d33f95eede2dfa629c9b0174c15cc55c4a45a commit r14-819-g676d33f95eede2dfa629c9b0174c15cc55c4a45a Author: Kyrylo Tkachov Date:

[Bug c++/109859] New: ICE on concept mis-typed as template type parameter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109859 Bug ID: 109859 Summary: ICE on concept mis-typed as template type parameter Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compone

[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195 --- Comment #15 from CVS Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:e90791e5a02b021d22ffb4c36673b9af623e2063 commit r14-820-ge90791e5a02b021d22ffb4c36673b9af623e2063 Author: Kyrylo Tkachov Date:

[Bug c++/109860] New: ICE: in make_typename_type, at cp/decl.cc:4268

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109860 Bug ID: 109860 Summary: ICE: in make_typename_type, at cp/decl.cc:4268 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug debug/109805] LTO affecting -fdebug-prefix-map

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805 --- Comment #11 from Richard Biener --- Btw, streaming of the CWD is prone to breakage when it changes between preprocessing and compilation stage. I think at least for C family languages the CWD would need to be recorded by the preprocessor an

[Bug c++/109859] ICE on concept mis-typed as template type parameter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109859 康桓瑋 changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #1 from 康桓瑋

[Bug libgomp/109837] [OpenMP] despite 'requires unified_address' there is segfault when 'is_device_ptr' is not used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109837 --- Comment #1 from Tobias Burnus --- Minor correction/clarification: (B) omp_target_is_accessible - will properly work for such pointers. While it might be useful to handle also (C/C++) code like: ptr = omp_target_alloc (...); ... is_

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 --- Comment #3 from Kewen Lin --- (In reply to Hongtao.liu from comment #2) > Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help? Sorry, I just measured those degraded bmks with this fix, the results showed it didn't help.

[Bug testsuite/91884] libgomp testsuite: (not) using a specific driver for C++, Fortran

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91884 --- Comment #5 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:30e42bb66d39f542cb76e40ad367a7ae7f376dc7 commit r14-852-g30e42bb66d39f542cb76e40ad367a7ae7f376dc7 Author: Thomas Schwinge Date:

[Bug testsuite/91884] libgomp testsuite: (not) using a specific driver for C++, Fortran

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91884 --- Comment #6 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:982c869ec00c72176ddede9c0e3068c76dc871d2 commit r14-853-g982c869ec00c72176ddede9c0e3068c76dc871d2 Author: Thomas Schwinge Date:

[Bug libgomp/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #5 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:e797db5c744f7b4e110f23a495fca8e6b8aebe83 commit r14-854-ge797db5c744f7b4e110f23a495fca8e6b8aebe83 Author: Rainer Orth Date: Thu

[Bug libgomp/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #6 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba commit r14-855-g6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba Author: Thomas Schwinge Date:

[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 Thomas Schwinge changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug testsuite/91884] libgomp testsuite: (not) using a specific driver for C++, Fortran

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

[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Thomas Schwinge --- > Resolved for GCC 14. Not planning on backporting to release branches (but > could, if desired). Unfortunately not: flock is completely unpor

[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #9 from Jakub Jelinek --- r5-3553 uses if {![catch {open $path {RDWR CREAT EXCL} 0600} fd]} { to determine which make check invocation should be given a particular batch of tests (in an initially empty directory), could you use that i

[Bug c/109828] [13/14 Regression] static compound literal with flexible array in initializer leads to invalid size and ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828 --- Comment #7 from Yann Droneaud --- I've also experimented compound literal initialization at block level instead of file level. Except in case it's not supported, it shows the same issue at block level as file level. https://godbolt.org/z/vn

[Bug libstdc++/109857] tzdata 2021a has bad data that cannot be parsed by libstdc++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > On debian stable the tzdata.zi file is from version 2021a of the IANA time > zone database and contains this line: > > R K 2023 Max - O lastTh 24 0 - This

[Bug fortran/109861] New: Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 Bug ID: 109861 Summary: Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault. Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug libstdc++/109857] Debian stable's tzdata 2021a has bad data that cannot be parsed by libstdc++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857 Jonathan Wakely changed: What|Removed |Added See Also||http://bugs.debian.org/1036

[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 Thomas Schwinge changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #8 from Carlos Galvez --- Upon closer inspection, it turns out we were building with GCC 7, but then using libgcc_s.so.1 and libstdc++.so.6 from GCC trunk at runtime (via LD_LIBRARY_PATH). Building with GCC trunk instead solves the s

[Bug c++/109859] [12/13/14 Regression] ICE on concept mis-typed as template type parameter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109859 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|

[Bug c++/109859] [12/13/14 Regression] ICE on concept mis-typed as template type parameter

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

[Bug c++/109860] ICE: in make_typename_type with redudant template in requires with typename

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109860 Andrew Pinski changed: What|Removed |Added Known to fail||8.1.0 Summary|ICE: in make_t

[Bug c++/109860] ICE: in make_typename_type with redudant template in requires with typename

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109860 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-15 Ever confirmed|0

[Bug c++/109241] [12/13/14 Regression] ICE Segmentation fault for statement expression with a local type inside inside a generic lambda inside a generic lambda since r13-6722-gb323f52ccf966800

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:396a4e76afec30d2461638f569cae18955eb4ad2 commit r12-9539-g396a4e76afec30d2461638f569cae18955eb4ad2 Author: Jason Merrill

[Bug tree-optimization/109852] Making of gcc13 errors out compiling libcpp/charset.cc with Wstringop-overflow Error with "-march=native -O3 "

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852 --- Comment #4 from Erich --- Created attachment 55086 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55086&action=edit Compressed preprocessed charset.i file

[Bug tree-optimization/109852] Making of gcc13 errors out compiling libcpp/charset.cc with Wstringop-overflow Error with "-march=native -O3 "

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852 --- Comment #5 from Erich --- The output of -v -> Lesen der Spezifikationen von /home//software/gcc13/host-x86_64-pc-linux-gnu/prev-gcc/specs COLLECT_GCC=/home//software/gcc13/host-x86_64-pc-linux-gnu/prev-gcc/xg++ Ziel: x86_64-pc-linux-

[Bug tree-optimization/109862] New: IV-OPTs could use int but still uses smaller sized for IV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109862 Bug ID: 109862 Summary: IV-OPTs could use int but still uses smaller sized for IV Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization

[Bug tree-optimization/109862] IV-OPTs could use int but still uses smaller sized for IV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109862 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement

[Bug c/109863] New: RFE: more consistent flex array initialization: lift static storage requirement in gnu2x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109863 Bug ID: 109863 Summary: RFE: more consistent flex array initialization: lift static storage requirement in gnu2x Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c/109828] [13/14 Regression] static compound literal with flexible array in initializer leads to invalid size and ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828 --- Comment #8 from Yann Droneaud --- (In reply to Yann Droneaud from comment #7) > I've also experimented compound literal initialization at block level > instead of file level. Except in case it's not supported, it shows the same > issue at bl

[Bug other/105819] comma `,` in directory name causes build to fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819 --- Comment #17 from bug-reports.delphin at laposte dot net --- First of all, thank you very much. You were stronly right. In fact, it was not a PATH error, but a folder name error. I check it again and it was true : unfortunately, I changed a d

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695 --- Comment #36 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:76e11280e79c5dd5089c17d5726cae9a5a21bc2e commit r14-862-g76e11280e79c5dd5089c17d5726cae9a5a21bc2e Author: Aldy Hernandez Date:

[Bug fortran/109846] Pointer-valued function reference rejected as actual argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:fa0569e90efe8a5cb895a3f50dd502f849940828 commit r14-863-gfa0569e90efe8a5cb895a3f50dd502f849940828 Author: Harald Anlauf Date: Su

[Bug c++/109864] New: excplicit constructor considered during overload resolution leads to ambiguity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109864 Bug ID: 109864 Summary: excplicit constructor considered during overload resolution leads to ambiguity Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severit

[Bug c++/109864] excplicit constructor considered during overload resolution leads to ambiguity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109864 --- Comment #1 from Andrew Pinski --- Note there are some C++ defect reports in this area And this is most likely a dup of another bug.

[Bug c++/109864] excplicit constructor considered during overload resolution leads to ambiguity

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

[Bug target/105719] RFE: fixincludes should handle Frameworks

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105719 --- Comment #5 from Bruce Korb --- It's been a long time since I mucked with fixincludes. My first guess, without going back and reading code, would be to provide fixincludes with a list of trees to traverse and not have it burned into fixinclud

[Bug fortran/109865] New: different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 Bug ID: 109865 Summary: different results when routine moved inside the contains statement Product: gcc Version: og12 (devel/omp/gcc-12) Status: UNCONFIRMED Se

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-05-15 Statu

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-05-15 Statu

[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #11 from Thomas Schwinge --- (In reply to myself from comment #10) > Could we easily build a portable 'flock'-like using 'fcntl' locking > primitives? (, for example.)

[Bug rtl-optimization/109866] New: Sometimes using sub/test instead just test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109866 Bug ID: 109866 Summary: Sometimes using sub/test instead just test Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #1) > I think that you might want to cross-check your testcase with the NAG > compiler, or some other compiler which provides a means to initialize > INTENT(OUT) a

[Bug fortran/109865] different results when routine moved inside the contains statement

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

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856 Thomas Schwinge changed: What|Removed |Added CC||redi at gcc dot gnu.org,

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #3 from GARY.WHITE at ColoState dot edu --- (In reply to kargl from comment #2) > (In reply to gary.wh...@colostate.edu from comment #0) > > Created attachment 55087 [details] > > set of subroutines where moving mc11ad inside the con

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #4 from Steve Kargl --- On Mon, May 15, 2023 at 07:11:17PM +, Gary.White at ColoState dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 > (In reply to kargl from comment #2) > > (In reply to gary.wh...@colostat

[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #12 from Eric Gallager --- Note that there's a gnulib module for flock: https://www.gnu.org/software/gnulib/manual/html_node/flock.html

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 --- Comment #3 from Scot Breitenfeld --- I see the same issue with NAG, regardless of the optimization level. Our CI testing had missed it because this was a parallel test, and we don't test parallel with NAG. I guess the issue is whether marki

[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #13 from Jakub Jelinek --- And fcntl in tclx. Anyway, I think choosing between flock(1) and some python file locking would be better than using perl which is only needed in maintainer mode and not otherwise.

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #5 from GARY.WHITE at ColoState dot edu --- (In reply to Steve Kargl from comment #4) > On Mon, May 15, 2023 at 07:11:17PM +, Gary.White at ColoState dot edu > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 > > (I

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to gary.wh...@colostate.edu from comment #5) > (In reply to Steve Kargl from comment #4) > > I assume you've also tried with -fcheck=all. > > Your report states you're using og12. If >

[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #14 from Thomas Schwinge --- (In reply to Eric Gallager from comment #12) > Note that there's a gnulib module for flock: > https://www.gnu.org/software/gnulib/manual/html_node/flock.html I'd see that one -- but it also says: "the rep

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Scot Breitenfeld from comment #3) > I guess the issue is whether marking TYPE(C_PTR) as CLOBBER is correct. I > looked through the 2018 standard and could not locate anything that > a

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

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

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 Sam James changed: What|Removed |Added CC||aldyh at gcc dot gnu.org See Also

[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #7 from Paul Smith --- Just to note this code also throws this warning in GCC 12.3 but it doesn't complain in GCC 11.3 which is what I was using before.

[Bug c++/109867] New: -Wswicht-default reports missing default in coroutine

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109867 Bug ID: 109867 Summary: -Wswicht-default reports missing default in coroutine Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compo

[Bug tree-optimization/101805] Max -> bool0 | bool1 Min -> a & b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101805 Andrew Pinski changed: What|Removed |Added Keywords|patch | URL|https://gcc.gnu.org

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #7 from GARY.WHITE at ColoState dot edu --- Sorry I can't simplify this down to a nice compact piece of code, but ... In the attached test_case.zip file are all the *.f90 files, makefile, and some library files that work on ubuntu w

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #8 from GARY.WHITE at ColoState dot edu --- I just tried to send you a zip file with all the code and instructions (see below), but it is over 6Mb in size, and was rejected. Where can I put it that you can access it? I have put the

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

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

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 --- Comment #14 from Sam James --- (In reply to Alexander Monakov from comment #13) > The 128KB stack size is for *secondary* threads on musl (i.e. those created > via pthread_create). The main thread has the same stack as on glibc (GCC > extend

[Bug c++/109868] New: [13/14 regression] ICE: segmentation fault when building small C++ program

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 Bug ID: 109868 Summary: [13/14 regression] ICE: segmentation fault when building small C++ program Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: nor

[Bug c++/109868] [13/14 regression] ICE: segmentation fault when building small C++ program

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #1 from Sam James --- Created attachment 55088 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55088&action=edit clock.ii.orig

[Bug c++/109868] [13/14 regression] ICE: segmentation fault when building small C++ program

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #2 from Sam James --- Created attachment 55089 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55089&action=edit clock.ii (reduced)

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 --- Comment #15 from Jakub Jelinek --- That ICE is because layout_class_type calls c_build_bitfield_integer_type with width of 0 and that type is then seen by ranger for some reason: #7 0x00c4eee1 in layout_class_type (t=, virtuals_p=0x

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 Andrew Pinski changed: What|Removed |Added Component|c++ |tree-optimization Known to fail|

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #4 from Andrew Pinski --- Hmm: D.2948._startTime.D.2792 = 0; That seems wrong. Reduced further: ``` struct SimpleRefCounted { virtual void addRef(); }; struct ClockImpl : SimpleRefCounted { long tv_nsec; int : 0; }; void f(

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 --- Comment #16 from Sam James --- Filed my musl one as PR109868, sorry for clogging up this one!

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #5 from Andrew Pinski --- A little more reduced: ``` struct ClockImpl { virtual void addRef(); long tv_nsec; int : 0; }; void f() { ClockImpl b{}; } ``` So maybe this is a gimplifier issue producing the assignment to the zero

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #6 from Andrew Pinski --- See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806#c15 .

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > That might have been caused by r12-1150-g34aae6b561871d . I will look into > it soon because we should not be emitting an assignment here ... Yes it was introdu

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #9 from Jakub Jelinek --- The ICE started with r13-436-gaf34279921f4bb95b07c0be but the undesirable store is there already since r12-2975-g32c3a75390623a0470df52.

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #10 from Sam James --- fwiw, on glibc, I don't get the oob read w/ valgrind but still the ICE as you've already found.

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #11 from Andrew Pinski --- Created attachment 55090 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55090&action=edit Patch which I came up with This patch adds back zero_sized_field_decl but keeps the call to is_empty_type too

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #12 from Andrew Pinski --- Jakub, assign this to me if you think we should go down that route unless you want to take the patch further.

[Bug tree-optimization/101805] Max -> bool0 | bool1 Min -> a & b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101805 Andrew Pinski changed: What|Removed |Added Keywords||patch URL|

  1   2   >