[Bug rtl-optimization/108681] [13 Regression] gcc hangs compiling opencv/channels_combine.cpp for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Target||aarch64 --- Comment #3 from Richard Biener --- there's another endless DCE bug somewhere.
[Bug ipa/108679] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-02-06 Priority|P3 |P1 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||needs-bisection --- Comment #1 from Richard Biener --- Confirmed with just -O2. during IPA pass: inline t.i: In function 'main': t.i:18:3: internal compiler error: in modify_call, at ipa-param-manipulation.cc:656 18 | func_6(l_10); | ^~~~ 0x129b0a1 ipa_param_adjustments::modify_call(cgraph_edge*, bool) /home/rguenther/src/trunk/gcc/ipa-param-manipulation.cc:656 0xec3b06 cgraph_edge::redirect_call_stmt_to_callee(cgraph_edge*) /home/rguenther/src/trunk/gcc/cgraph.cc:1530 0x16a9db7 redirect_all_calls(copy_body_data*, basic_block_def*) /home/rguenther/src/trunk/gcc/tree-inline.cc:2990 0x16aa5a3 copy_cfg_body /home/rguenther/src/trunk/gcc/tree-inline.cc:3145 0x16aadf8 copy_body /home/rguenther/src/trunk/gcc/tree-inline.cc:3326 0x16afd47 expand_call_inline /home/rguenther/src/trunk/gcc/tree-inline.cc:5112 0x16b0b2d gimple_expand_calls_inline /home/rguenther/src/trunk/gcc/tree-inline.cc:5307 0x16b12f3 optimize_inline_calls(tree_node*) /home/rguenther/src/trunk/gcc/tree-inline.cc:5479 0x12452ec inline_transform(cgraph_node*) /home/rguenther/src/trunk/gcc/ipa-inline-transform.cc:790
[Bug tree-optimization/108677] wrong vectorization (when copy constructor is present?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108677 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 CC||rguenth at gcc dot gnu.org Last reconfirmed||2023-02-06
[Bug testsuite/108675] FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675 --- Comment #1 from Richard Biener --- These tests are known to be a bit awkwardly implemented to check for optimizations done ... There might be a better way to provide definitions of fprintf, but is it possible to short-circuit those definitions in the stdio.h header with some macro definition? And would that make the execution succeed?
[Bug tree-optimization/108667] Spurious "may be used uninitialized [-Wmaybe-uninitialized]" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108667 --- Comment #3 from Richard Biener --- Yes, having the original code as well would be nice.
[Bug analyzer/108661] [13 Regression] -Wanalyzer-use-of-uninitialized-value false positive seen in haproxy's sink_rotate_file_backed_ring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug debug/108656] [12/13 Regression] '-fcompare-debug' failure (length) w/ -O2 -fno-ipa-pure-const -fno-tree-dce --param early-inlining-insns=0 since r12-5236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108656 --- Comment #4 from Richard Biener --- In general we avoid disallowing attribute combinations that at least in theory make sense. pure/const are about memory side-effects while returns_twice is about control flow, so in this regard I don't see how they should conflict. That we exclude !gimple_has_side_effects from call_can_make_abnormal_goto is somewhat of a chicken-and-egg thing - "side effect" is something not explicitely encoded in the IL but a returns_twice results in explicit encoding via abnormal edges. But then we cannot use that for CFG construction.
[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42566 Sergey Fedorov changed: What|Removed |Added CC||vital.had at gmail dot com --- Comment #13 from Sergey Fedorov --- Is --enable-decimal-float supported on PowerPC Darwin?? It seems that it is not, and DFP have been added in ISA 2.05.
[Bug preprocessor/61638] "warning: multi-line comment" unclear and has false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61638 --- Comment #10 from Andrew Pinski --- (In reply to Jack Adrian Zappa from comment #9) > > Suggest fix is to either: > > 1. Change the phase where this warning/error/ignored is tested so that the > #pragma GCC diagnostic is honoured or That is fixed on the trunk for GCC 13 (by r13-1544-ge46f4d7430c52104657916) for the C++ front-end, it was already working for the C front-end.
[Bug preprocessor/61638] "warning: multi-line comment" unclear and has false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61638 Jack Adrian Zappa changed: What|Removed |Added CC||adrianh.bsc at gmail dot com --- Comment #9 from Jack Adrian Zappa --- Issue: Cannot turn off the `-Wcomment` option using `#pragma GCC diagnostic ignored "-Wcomment"`. This is causing issues when I'm trying to document my macros and how to write them. Our coding standards at my work state that we are to use /// for documenting functions/variables/macros and not /** */. I grudgingly tried to use a space after the \, but that didn't work either. Also inadvertently found that ending with a double backslash (\\) also didn't work for some reason, which is odd because the backslash is escaped, so it cannot cause a comment continuation. Suggest fix is to either: 1. Change the phase where this warning/error/ignored is tested so that the #pragma GCC diagnostic is honoured or 2. If a line comment end in an \ but the next line is a comment, then do the same thing as is done for a multi-line comment, ignore it as not an issue. In addition, a line comment ending in an escaped backslash shouldn't cause any issue. It would be also preferable that an escaped whitespace that is not an eol character would be accepted (though it seems that this is unlikely given bug 8270). GCC versions tested on: 7.5, 11.3 12.2 System type: MSYS2 and whatever is running under godbolt.org Options given: -Wall -Werror Complete command line: g++ -Wall -Werror bug.cpp Source file: $ cat bug.cpp #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wcomment" /// #define macro_to_document(x) \ /// blah blah x blah /// /// Also doesn't work with a space after the \ /// as in this case. /// /// Also doesn't work with a double backslash \\ /// as in this case. /// #pragma GCC diagnostic pop Compiler output: $ g++ -v -Wall -Werror -save-temps bug.cpp Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-msys/11.3.0/lto-wrapper.exe Target: x86_64-pc-msys Configured with: /c/S/gcc/src/gcc-11.3.0/configure --build=x86_64-pc-msys --prefix=/usr --libexecdir=/usr/lib --enable-bootstrap --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --with-arch=x86-64 --with-tune=generic --disable-multilib --enable-__cxa_atexit --with-dwarf2 --enable-languages=c,c++,fortran,lto --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --disable-libssp --disable-win32-registry --disable-symvers --with-gnu-ld --with-gnu-as --disable-isl-version-check --enable-checking=release --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.3.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-Wall' '-Werror' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' /usr/lib/gcc/x86_64-pc-msys/11.3.0/cc1plus.exe -E -quiet -v -idirafter /usr/lib/gcc/x86_64-pc-msys/11.3.0/../../../../lib/../include/w32api -idirafter /usr/lib/gcc/x86_64-pc-msys/11.3.0/../../../../x86_64-pc-msys/lib/../lib/../../include/w32api bug.cpp -mtune=generic -march=x86-64 -Wall -Werror -fpch-preprocess -o a-bug.ii ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-msys/11.3.0/../../../../x86_64-pc-msys/include" ignoring duplicate directory "/usr/lib/gcc/x86_64-pc-msys/11.3.0/../../../../x86_64-pc-msys/lib/../lib/../../include/w32api" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-msys/11.3.0/include/c++ /usr/lib/gcc/x86_64-pc-msys/11.3.0/include/c++/x86_64-pc-msys /usr/lib/gcc/x86_64-pc-msys/11.3.0/include/c++/backward /usr/lib/gcc/x86_64-pc-msys/11.3.0/include /usr/lib/gcc/x86_64-pc-msys/11.3.0/include-fixed /usr/include /usr/lib/gcc/x86_64-pc-msys/11.3.0/../../../../lib/../include/w32api End of search list. bug.cpp:3:1: error: multi-line comment [-Werror=comment] 3 | /// #define macro_to_document(x) \ | ^ bug.cpp:6:1: error: multi-line comment [-Werror=comment] 6 | /// Also doesn't work with a space after the \ | ^ bug.cpp:9:1: error: multi-line comment [-Werror=comment] 9 | /// Also doesn't work with a double backslash \\ | ^ cc1plus: all warnings being treated as errors Preprocessed file: $ cat a-bug.ii # 0 "bug.cpp" # 0 "" # 0 "" # 1 "bug.cpp" #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wcomment" # 12 "bug.cpp" #pragma GCC diagnostic pop
[Bug rtl-optimization/108681] [13 Regression] gcc hangs compiling opencv/channels_combine.cpp for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Summary|gcc hangs compiling |[13 Regression] gcc hangs |opencv/channels_combine.cpp |compiling |for aarch64 |opencv/channels_combine.cpp ||for aarch64 Component|middle-end |rtl-optimization --- Comment #2 from Andrew Pinski --- rtl_dce seems stuck and keeps on adding to the worklist for: ;; Function carotene_o4t::combine2 (_ZN12carotene_o4t8combine2ERKNS_6Size2DEPKllS4_lPll, funcdef_no=5226, decl_uid=40999, cgraph_uid=4575, symbol_order=4584)
[Bug middle-end/108681] gcc hangs compiling opencv/channels_combine.cpp for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681 --- Comment #1 from Andrew Pinski --- Created attachment 54411 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54411=edit unreduced Testcase
[Bug c++/108681] New: gcc hangs compiling opencv/channels_combine.cpp for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681 Bug ID: 108681 Summary: gcc hangs compiling opencv/channels_combine.cpp for aarch64 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- GCC-trunk as of 31924665c86d47af6b1f22a74f594f2e1dc0ed2d is taking a long long time, probably a hang since I cancelled it after 12 mins ) compiling this file https://uclibc.org/~kraj/channels_combine.i aarch64-yoe-linux/aarch64-yoe-linux-g++ channels_combine.i -O2 ( hangs ) It compiled ok with -O0,-Os,-Og,-Oz but not with -O1,-O2,-O3
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 --- Comment #13 from Murugesan Nagarajan --- @Andrew, Thank you for updating current bug id: 94810 Old bug reported: On: Mon 27-Apr-2020 09:44:52 PM UTC Old Bug URL: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 Old Status: RESOLVED INVALID @Andrew's comment on 2023-02-03 07:47:43 PM UTC Related linked bug/url: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=4e4e3ffd10f53e Updated bug on: Sun 06-Nov-2022 04:16:00 PM UTC Updated status: Bug fix completed using "__attribute__" and new bug using "__has_attribute".
[Bug c++/107461] [12/13 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461 --- Comment #13 from Patrick Palka --- hb-aat-layout.cc.i and the comment #9 test should be accepted on trunk again now, backport to the 12 branch to follow. The comment #7 testcase I think is invalid because GCC incorrectly accepts the substitution 'typename U::E [with U=E]', which seems to be PR34810.
[Bug c++/107461] [12/13 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461 --- Comment #12 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:31924665c86d47af6b1f22a74f594f2e1dc0ed2d commit r13-5707-g31924665c86d47af6b1f22a74f594f2e1dc0ed2d Author: Patrick Palka Date: Sun Feb 5 21:35:33 2023 -0500 c++: equivalence of non-dependent calls [PR107461] After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of FUNCTION_DECL. This innocent change revealed that cp_tree_equal doesn't first check dependence of a CALL_EXPR before treating a FUNCTION_DECL callee as a dependent name, which leads to us incorrectly accepting the first two testcases below and rejecting the third: * In the first testcase, cp_tree_equal incorrectly returns true for the two non-dependent CALL_EXPRs f(0) and f(0) (whose CALL_EXPR_FN are different FUNCTION_DECLs) which causes us to treat #2 as a redeclaration of #1. * Same issue in the second testcase, for f() and f(). * In the third testcase, cp_tree_equal incorrectly returns true for f() and f() which causes us to conflate the two dependent specializations A()(U()))> and A()(U()))>. This patch fixes this by making called_fns_equal treat two callees as dependent names only if the overall CALL_EXPRs are dependent, via a new convenience function call_expr_dependent_name that is like dependent_name but also checks dependence of the overall CALL_EXPR. PR c++/107461 gcc/cp/ChangeLog: * cp-tree.h (call_expr_dependent_name): Declare. * pt.cc (iterative_hash_template_arg) : Use call_expr_dependent_name instead of dependent_name. * tree.cc (call_expr_dependent_name): Define. (called_fns_equal): Adjust to take two CALL_EXPRs instead of CALL_EXPR_FNs thereof. Use call_expr_dependent_name instead of dependent_name. (cp_tree_equal) : Adjust call to called_fns_equal. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/overload5.C: New test. * g++.dg/cpp0x/overload5a.C: New test. * g++.dg/cpp0x/overload6.C: New test.
[Bug other/108662] Cast between incompatible function types in libiberty/physmem.c under MinGW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108662 --- Comment #1 from Jan Dubiec --- Created attachment 54410 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54410=edit Proposed patch
[Bug libstdc++/108672] [13 Regression] g++.dg/modules/xtreme-header-2_a.H, _b.C, _c.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108672 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Hans-Peter Nilsson --- .
[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108450 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Mikael Morin --- Fixed for gcc-13.1 and gcc-12.3. Closing.
[Bug fortran/108592] In IF statements -Winteger-division is repeated 4 times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108592 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-13.
[Bug fortran/108592] In IF statements -Winteger-division is repeated 4 times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108592 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d042f118798ae0648b45f97e63b0e5ab7c82c8ef commit r13-5705-gd042f118798ae0648b45f97e63b0e5ab7c82c8ef Author: Harald Anlauf Date: Mon Jan 30 22:46:43 2023 +0100 Fortran: prevent redundant integer division truncation warnings [PR108592] gcc/fortran/ChangeLog: PR fortran/108592 * arith.cc (gfc_arith_divide): Emit integer division truncation warnings using gfc_warning instead of gfc_warning_now to prevent redundant messages. gcc/testsuite/ChangeLog: PR fortran/108592 * gfortran.dg/pr108592.f90: New test.
[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108450 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Mikael Morin : https://gcc.gnu.org/g:32502d82a5b54ca5b8e524df9fcad851727dc54a commit r12-9108-g32502d82a5b54ca5b8e524df9fcad851727dc54a Author: Mikael Morin Date: Sun Jan 29 21:57:24 2023 +0100 fortran: Set name for *LOC default BACK argument [PR108450] This change fixes an ICE caused by the double resolution of MINLOC, MAXLOC and FINDLOC expressions which get a default value for the BACK argument at resolution time. That argument is added without name, and argument reordering code is not prepared to handle unnamed arguments coming after named ones, so the second resolution causes a NULL pointer dereference. The problem is fixed by explicitly setting the argument name. PR fortran/108450 gcc/fortran/ChangeLog: * check.cc (gfc_check_minloc_maxloc): Explicitly set argument name. (gfc_check_findloc): Ditto. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/minmaxloc_1.f90: New test. (cherry picked from commit 2e32a12c04c72f692a7bd119fd3e4e5b74392c9d)
[Bug fortran/108680] New: Wrong DTIO arguments with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680 Bug ID: 108680 Summary: Wrong DTIO arguments with -fdefault-integer-8 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: albandil at atlas dot cz Target Milestone: --- Wrong DTIO arguments with -fdefault-integer-8 It seems that gfortran miscompiles the following simple program when `-fdefault-integer-8` compiler option is used: module types type dtype contains procedure :: write_formatted generic, public :: write(formatted) => write_formatted end type contains subroutine write_formatted (this, unit, iotype, v_list, iostat, iomsg) class(dtype), intent(in):: this integer, intent(in):: unit, v_list(:) character(*), intent(in):: iotype integer, intent(out) :: iostat character(*), intent(inout) :: iomsg iostat = 0 print *, 'v_list', v_list end subroutine write_formatted end module types program p use types, only: dtype type(dtype) :: data integer :: u open (file = 'output.txt', newunit = u, form = 'formatted') write (u, '(dt(1,2,3))') data close (u) end program p The derived type `dtype` should be given integers 1,2,3 in the v_list parameter of the `write(formatted)` subroutine, which only echoes them out for feedback. This works with Intel compilers regardless of the default integer type. However, the output is wrong if I combine gfortran `-fdefault-integer-8`. The behaviour is the same with the current git version as well as with GCC release 11.3, so the problem has been around for some time. $ /opt/gcc-git/bin/gfortran --version | head -n 1 GNU Fortran (GCC) 13.0.1 20230205 (experimental) $ /opt/gcc-git/bin/gfortran main.f90 $ ./a.out v_list 1 2 3 $ /opt/gcc-git/bin/gfortran -fdefault-integer-8 main.f90 $ ./a.out v_list 858993459330 $ gfortran-11 --version | head -n 1 GNU Fortran (SUSE Linux) 11.3.1 20221024 [revision bd0c76a2329e7fe6d6612c2259647bbb67f5866a] $ gfortran-11 -fdefault-integer-8 main.f90 $ ./a.out v_list 858993459330 $ ifx --version | head -n 1 ifx (IFORT) 2023.0.0 20221201 $ ifx -i8 main.f90 $ ./a.out v_list 1 2 3 $ ifort --version | head -n 1 ifort (IFORT) 2021.8.0 20221119 $ ifort -i8 main.f90 $ ./a.out v_list 1 2 3 It looks as if the subroutine was actually getting pointers to 4-byte integers regardless of the switch, because the large value pritned first is actually composition of the missing 2 and 1: 8589934593 ~ 0010 0001 ~ 2 1
[Bug tree-optimization/108677] wrong vectorization (when copy constructor is present?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108677 --- Comment #2 from Andrew Pinski --- Is the confusing part is the fmaddsub instruction?
[Bug fortran/108609] New test case gfortran.dg/pr108527.f90 in r13-5479-g22afa4947584c7 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108609 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1e60e9124543fd002f3e6dad8172cff8aa1b24b3 commit r12-9107-g1e60e9124543fd002f3e6dad8172cff8aa1b24b3 Author: Harald Anlauf Date: Wed Feb 1 21:01:32 2023 +0100 Fortran: error recovery on invalid array section [PR108609] The testcase for PR108527 uncovered a latent issue with invalid array sections that resulted in different paths being taken on different architectures. Detect the invalid array declaration for a clean recovery. gcc/fortran/ChangeLog: PR fortran/108609 * expr.cc (find_array_section): Add check to prevent interpreting an mpz non-integer constant as an integer. gcc/testsuite/ChangeLog: PR fortran/108609 * gfortran.dg/pr108527.f90: Adjust test pattern. (cherry picked from commit 88a2a09dd4529107e7ef7a6e7ce43acf96457173)
[Bug fortran/108527] [13 Regression] ICE in compare_bound_int(): Bad expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108527 --- Comment #10 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:511928102dc9fa3f9c377e01f9bfb605b4995a61 commit r12-9106-g511928102dc9fa3f9c377e01f9bfb605b4995a61 Author: Harald Anlauf Date: Tue Jan 24 22:36:25 2023 +0100 Fortran: fix ICE in compare_bound_int [PR108527] gcc/fortran/ChangeLog: PR fortran/108527 * resolve.cc (compare_bound_int): Expression to compare must be of type INTEGER. (compare_bound_mpz_t): Likewise. (check_dimension): Fix comment on checks applied to array section and clean up associated logic. gcc/testsuite/ChangeLog: PR fortran/108527 * gfortran.dg/pr108527.f90: New test. Co-authored-by: Steven G. Kargl (cherry picked from commit 22afa4947584c701633a79fd8750c9ceeaa96711)
[Bug tree-optimization/108677] wrong vectorization (when copy constructor is present?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108677 Andrew Pinski changed: What|Removed |Added Keywords|wrong-code |missed-optimization --- Comment #1 from Andrew Pinski --- >gcc vectorize the loop even if a dependency is present...[1] What dependency? TrigArr cannot point to tp. Also it is just doing just doing SLP, the vectorization is fine here even. It is only doing basic block form. IR: _2 = jp_31 + 4294967295; _3 = (long unsigned int) _2; _4 = _3 * 16; _5 = TrigArr.0_1 + _4; vect__22.19_48 = MEM [(double *)_5]; vect__22.23_43 = VEC_PERM_EXPR ; vect__20.15_54 = MEM [(double *)tp_14(D)]; vect__20.16_53 = VEC_PERM_EXPR ; vect__20.27_38 = VEC_PERM_EXPR ; vect__27.28_37 = vect__20.27_38 * vect__22.23_43; vect__57.29_36 = .VEC_FMADDSUB (vect__20.16_53, vect__22.19_48, vect__27.28_37); _7 = (long unsigned int) jp_31; _8 = _7 * 16; _9 = TrigArr.0_1 + _8; MEM [(double *)_9] = vect__57.29_36; _5 is [jp-1], _9 is [jp] This looks fine to me. As not doing SLP without the copy constructor, it seems like the IR changes and forced the load from tp_14 outside of the loop which caused SLP not do to the load there ...
[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 --- Comment #2 from Brecht Sanders --- I would love to give it a go if only I knew where to add the support. I actually got a Windows on ARM device hoping I could figure it out, bit it looks I will need tome help. The "Unknown tune used in --with-tune=generic" error is where I'm currently stuck, and I couldn't figure out in which file(s) I need to address this.
[Bug ipa/108679] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |13.0 CC||marxin at gcc dot gnu.org Summary|ice in modify_call, at |[13 Regression] ice in |ipa-param-manipulation.cc:6 |modify_call, at |56 |ipa-param-manipulation.cc:6 ||56 Component|c |ipa
[Bug fortran/108502] ICE in gfc_check_dependency, at fortran/dependency.cc:1295
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108502 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |10.5 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/108420] [13 Regression] ICE in check_charlen_present, at fortran/iresolve.cc:98 since r13-4394-g3832c6f7e672e76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|13.0|10.5 --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/108529] [10/11/12 Regression] ICE in transformational_result, at fortran/simplify.cc:478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108529 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/108453] [10/11/12/13 Regression] ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5361 since r6-3704-g2b3f52a2d0fb22ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/108529] [10/11/12 Regression] ICE in transformational_result, at fortran/simplify.cc:478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108529 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b66a0f2fecb4dc1ac5960ff5d630ab8f672b4106 commit r10-11198-gb66a0f2fecb4dc1ac5960ff5d630ab8f672b4106 Author: Harald Anlauf Date: Tue Jan 24 21:39:43 2023 +0100 Fortran: ICE in transformational_result [PR108529] gcc/fortran/ChangeLog: PR fortran/108529 * simplify.c (simplify_transformation): Do not try to simplify transformational intrinsic when the ARRAY argument has a NULL shape. gcc/testsuite/ChangeLog: PR fortran/108529 * gfortran.dg/pr108529.f90: New test. (cherry picked from commit 6c96382eed96a9285611f2e3e2e59557094172b8)
[Bug fortran/106209] ICE in add_init_expr_to_sym, at fortran/decl.cc:2132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106209 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b523b58690c84b04cc9695d2d652611beb6f28ca commit r10-11197-gb523b58690c84b04cc9695d2d652611beb6f28ca Author: Harald Anlauf Date: Thu Jul 14 22:24:55 2022 +0200 Fortran: error recovery for bad initializers of implied-shape arrays [PR106209] gcc/fortran/ChangeLog: PR fortran/106209 * decl.c (add_init_expr_to_sym): Handle bad initializers for implied-shape arrays. gcc/testsuite/ChangeLog: PR fortran/106209 * gfortran.dg/pr106209.f90: New test. Co-authored-by: Steven G. Kargl (cherry picked from commit 748f8a8b145dde59c7b63aa68b5a59515b7efc49)
[Bug fortran/108421] ICE in get_expr_storage_size, at fortran/interface.cc:2862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108421 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:068fce9743ec9f3181c189cb8d03a982ca30eb7e commit r10-11194-g068fce9743ec9f3181c189cb8d03a982ca30eb7e Author: Harald Anlauf Date: Mon Jan 16 21:30:56 2023 +0100 Fortran: fix ICE in get_expr_storage_size [PR108421] gcc/fortran/ChangeLog: PR fortran/108421 * interface.c (get_expr_storage_size): Check that we actually have an integer value before trying to extract it with mpz_get_si. gcc/testsuite/ChangeLog: PR fortran/108421 * gfortran.dg/pr108421.f90: New test. (cherry picked from commit a75760374ee54768e5fd6a27080698bfbbd041ab)
[Bug fortran/108501] [13 Regression] ICE in get_expr_storage_size, at fortran/interface.cc:2941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108501 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d4bb7751af090736fb4a3bd7278d7094f35e02e4 commit r10-11196-gd4bb7751af090736fb4a3bd7278d7094f35e02e4 Author: Harald Anlauf Date: Mon Jan 23 21:19:03 2023 +0100 Fortran: avoid ICE on invalid array subscript triplets [PR108501] gcc/fortran/ChangeLog: PR fortran/108501 * interface.c (get_expr_storage_size): Check array subscript triplets that we actually have integer values before trying to extract with mpz_get_si. gcc/testsuite/ChangeLog: PR fortran/108501 * gfortran.dg/pr108501.f90: New test. (cherry picked from commit 771d793df1622a476e1cf8d05f0a6aee350fa56b)
[Bug fortran/108502] ICE in gfc_check_dependency, at fortran/dependency.cc:1295
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108502 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c67d76171e87d3ce364400684a654712047058b1 commit r10-11195-gc67d76171e87d3ce364400684a654712047058b1 Author: Harald Anlauf Date: Mon Jan 23 22:13:44 2023 +0100 Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502] gcc/fortran/ChangeLog: PR fortran/108502 * dependency.c (gfc_check_dependency): Prevent NULL pointer dereference while recursively checking expressions. gcc/testsuite/ChangeLog: PR fortran/108502 * gfortran.dg/pr108502.f90: New test. (cherry picked from commit 51767f31878a95161142254dca7119b409699670)
[Bug fortran/108420] [13 Regression] ICE in check_charlen_present, at fortran/iresolve.cc:98 since r13-4394-g3832c6f7e672e76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b14dcf0c99fab065e11ec87984475580b649edeb commit r10-11193-gb14dcf0c99fab065e11ec87984475580b649edeb Author: Harald Anlauf Date: Mon Jan 16 21:41:09 2023 +0100 Fortran: fix ICE in check_charlen_present [PR108420] gcc/fortran/ChangeLog: PR fortran/108420 * iresolve.c (check_charlen_present): Preserve character length if there is no array constructor. gcc/testsuite/ChangeLog: PR fortran/108420 * gfortran.dg/pr108420.f90: New test. (cherry picked from commit e6669c0a50ed8aee9e5997d61e6271668d149218)
[Bug fortran/108453] [10/11/12/13 Regression] ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5361 since r6-3704-g2b3f52a2d0fb22ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:841e585ad936624f2d080512a9f6244b49e71969 commit r10-11192-g841e585ad936624f2d080512a9f6244b49e71969 Author: Harald Anlauf Date: Sat Jan 28 17:59:23 2023 +0100 Fortran: diagnose USE associated symbols in COMMON blocks [PR108453] gcc/fortran/ChangeLog: PR fortran/108453 * match.c (gfc_match_common): A USE associated name shall not appear in a COMMON block (F2018:C8121). gcc/testsuite/ChangeLog: PR fortran/108453 * gfortran.dg/common_27.f90: New test. (cherry picked from commit aba9ff8f30d4245294ea2583de1dc28f1c7ccf7b)
[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 --- Comment #1 from Andrew Pinski --- I have not seen anyone step up to patch GCC for aarch64-mingw yet. Most aarch64 developers don't use Windows at all. There is some support being worked on for aarch64 darwin (Mac OS) though.
[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=87334 Target||Aarch64-mingw
[Bug c/108679] New: ice in modify_call, at ipa-param-manipulation.cc:656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
Bug ID: 108679
Summary: ice in modify_call, at ipa-param-manipulation.cc:656
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
struct S1 {
signed f0;
};
struct S2 {
struct S1 f2;
short f8;
} g_18;
g_732, func_6_l_17;
static *func_12();
static func_6(struct S2 p_7) { func_12(func_6_l_17, p_7.f2, g_18, 0); }
*func_12(int, struct S1 p_14) {
safe_lshift_func_int16_t_s_u();
safe_unary_minus_func_uint64_t_u();
g_732 = safe_mul_func_uint8_t_u_u(0, p_14);
}
main() {
struct S2 l_10 = {3};
func_6(l_10);
}
compiled by recent gcc, does this:
$ /home/dcb36/gcc/results/bin/gcc -w -O2 -ftrivial-auto-var-init=zero bug881.c
during IPA pass: inline
bug881.c: In function ‘main’:
bug881.c:18:3: internal compiler error: in modify_call, at
ipa-param-manipulation.cc:656
18 | func_6(l_10);
| ^~~~
0xb64d40 ipa_param_adjustments::modify_call(cgraph_edge*, bool)
../../trunk.d1/gcc/ipa-param-manipulation.cc:656
The bug first seems to occur sometime between g:d0a3d55ae4a2656f
and g:1530a9b1f45a7ceb
[Bug c/108678] New: Windows on ARM64 platform target aarch64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 Bug ID: 108678 Summary: Windows on ARM64 platform target aarch64-w64-mingw32 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: brechtsanders at users dot sourceforge.net Target Milestone: --- Are there plans to support Windows (using MinGW-w64) on ARM64? The triplet for this platform should be: aarch64-w64-mingw32 I'm trying to build natively on a Windows on ARM device (bootstrapping from LLVM/CLang). Since binutils 2.40 there some support for aarch64 COFF/PE format, and I already built a working binutils with the following supported targets: ld --help|sed -n "s/^.*supported targets: //p" pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 pe-i386 pei-i386 elf32-i386 elf32-iamcu pdb elf64-little elf64-big elf32-little elf32-big pe-bigobj-i386 pe-aarch64-little pei-aarch64-little srec symbolsrec verilog tekhex binary ihex plugin So it looks like pe-aarch64-little and pei-aarch64-little are listed. I'm don't know if a pe-bigobj-aarch64-little is needed or if it will be supported in the future. My first attempt to get gcc (I tried with source tarball 12.2.0) to configure was changing the following line in gcc/config.gcc: i[34567]86-*-mingw* | x86_64-*-mingw*) to: i[34567]86-*-mingw* | x86_64-*-mingw* | aarch64-*-mingw*) but then I get the following error: Unknown tune used in --with-tune=generic What needs to be changed to get past that?
[Bug tree-optimization/108677] New: wrong vectorization (when copy constructor is present?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108677
Bug ID: 108677
Summary: wrong vectorization (when copy constructor is
present?)
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
Target Milestone: ---
in this real life code
#include
struct trig_pair {
double CosPhi;
double SinPhi;
trig_pair() : CosPhi(1.), SinPhi(0.) {}
trig_pair(const trig_pair ) : CosPhi(tp.CosPhi), SinPhi(tp.SinPhi) {}
trig_pair(const double C, const double S) : CosPhi(C), SinPhi(S) {}
trig_pair(const double phi) : CosPhi(cos(phi)), SinPhi(sin(phi)) {}
//Return trig_pair fo angle increased by angle of tp.
trig_pair Add(const trig_pair ) {
return trig_pair(this->CosPhi*tp.CosPhi - this->SinPhi*tp.SinPhi,
this->SinPhi*tp.CosPhi + this->CosPhi*tp.SinPhi);
}
};
trig_pair *TrigArr;
void FillTrigArr(trig_pair tp, unsigned MaxM)
{
//Fill TrigArr with trig_pair(jp*phi)
if (!TrigArr) return;;
TrigArr[1] = tp;
for (unsigned jp = 2; jp <= MaxM; ++jp) TrigArr[jp] = TrigArr[jp-1].Add(tp);
}
gcc vectorize the loop even if a dependency is present...[1]
It will not if I comment out the copy contructor...[2]
[1]
https://godbolt.org/z/vhPeh35n5
[2]
https://godbolt.org/z/YPjdYdqG8
[Bug c++/108676] template parameters are misprinted in function signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108676 --- Comment #1 from Ivan Sorokin --- I added a broken link to godbolt, here is a valid one: https://godbolt.org/z/EE5eezW1r
[Bug c++/108676] New: GCC prints function signature incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108676
Bug ID: 108676
Summary: GCC prints function signature incorrectly
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
Consider this code:
template
struct X
{};
template
X f();
template
X g();
int main()
{
g();
}
On GCC 12.2 it gives this error message:
:13:12: error: no matching function for call to 'g()'
13 | g();
| ~~~^~
:9:7: note: candidate: 'template X g()'
9 | X g();
| ^
Please note that the return type of 'g' is printed incorrectly. It should say
'X' instead of 'X'.
https://godbolt.org/z/EeWoo16M
