[Bug middle-end/116454] [12/13/14/15 Regression] `*++ptr * 1j` is handled incorrectly with -ffast-math, increments ptr twice since r0-77972-g9f5396713d9e18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116454 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #8 from Richard Biener --- Mine then.
[Bug tree-optimization/101390] Expand vector mod as vector div + multiply-subtract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101390 --- Comment #9 from GCC Commits --- The master branch has been updated by Jennifer Schmitz : https://gcc.gnu.org/g:9bbad3685131ec95d970f81bf75f9556d4d92742 commit r15-3082-g9bbad3685131ec95d970f81bf75f9556d4d92742 Author: Jennifer Schmitz Date: Wed Aug 7 08:56:45 2024 -0700 PR tree-optimization/101390: Vectorize modulo operator This patch adds a new vectorization pattern that detects the modulo operation where the second operand is a variable. It replaces the statement by division, multiplication, and subtraction. The patch was bootstrapped and regtested on aarch64-linux-gnu, no regression. Ok for mainline? Signed-off-by: Jennifer Schmitz gcc/ PR tree-optimization/101390 * tree-vect-patterns.cc (vect_recog_mod_var_pattern): Add new pattern. gcc/testsuite/ PR tree-optimization/101390 * gcc.dg/vect/vect-mod-var.c: New test. * gcc.target/aarch64/sve/mod_1.c: Likewise. * lib/target-supports.exp: New selector expression.
[Bug c/116458] New: New valgrind error in search_line_ssse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458 Bug ID: 116458 Summary: New valgrind error in search_line_ssse3 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- >From today's valgrind build of gcc trunk: /usr/bin/valgrind -q build/genmatch --generic \ --header=tmp-generic-match-auto.h --include=generic-match-auto.h \ ../../trunk/gcc/match.pd tmp-generic-match-1.cc tmp-generic-match-2.cc tmp-generic-match-3.cc tmp-generic-match-4.cc tmp-generic-match-5.cc tmp-generic-match-6.cc tmp-generic-match-7.cc tmp-generic-match-8.cc tmp-generic-match-9.cc tmp-generic-match-10.cc ==238807== Conditional jump or move depends on uninitialised value(s) ==238807==at 0x42D5B4: search_line_ssse3(unsigned char const*, unsigned char const*) (lex.cc:378) ==238807==by 0x42E222: _cpp_clean_line (lex.cc:845) ==238807==by 0x42E6D2: bool get_fresh_line_impl(cpp_reader*) (lex.cc:3635) File lex.cc, line 378 is while (!found); Configure script is ../trunk/configure \ --disable-multilib \ --disable-bootstrap \ --enable-checking=valgrind \ --enable-languages=c,c++ git log libcpp/lex.cc says: commit 20a5b4824993ae1c99f3b965c5e07bbd2c64b2ce Author: Alexander Monakov Date: Tue Aug 6 09:47:23 2024 +0300 libcpp: replace SSE4.2 helper with an SSSE3 one
[Bug c/116458] New valgrind error in search_line_ssse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458 David Binderman changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from David Binderman --- Adding author of most recent commit for their opinion.
[Bug middle-end/116454] [12/13/14/15 Regression] `*++ptr * 1j` is handled incorrectly with -ffast-math, increments ptr twice since r0-77972-g9f5396713d9e18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116454 --- Comment #9 from Richard Biener --- One of the issues is that REALPART_EXPR , 0.0>> is no longer simplified. I don't think __real folding can look through a SAVE_EXPR but instead of building SAVE_EXPR > we could build COMPLEX_EXPR >, 0.0> here. I'm not exactly sure why we consider a function parameter (like in gcc.dg/fold-complex-1.c) as requiring a SAVE_EXPR, we're only resorting to tree_invariant_p_1 instead of looking at possible side-effects. For builtins-20.c we FAIL if (hypot (tan(-x), tan(-fabs(y))) != hypot (tan(x), tan(y))) link_error (); if (ccos(tan(x)+sin(x-y)*1i) != ccos(-tan(-x)-sin(y-x)*1i)) link_error (); if (tan(x)+tan(y)*1i != -~(tan(-x)+tan(y)*1i)) link_error (); if (hypotf (tanf(-x), tanf(-fabsf(y))) != hypotf (tanf(x), tanf(y))) link_error (); if (ccosf(tanf(x)+sinf(x-y)*1i) != ccosf(-tanf(-x)-sinf(y-x)*1i)) link_error (); if (tanf(x)+tanf(y)*1i != -~(tanf(-x)+tanf(y)*1i)) link_error (); if (hypotl (tanl(-x), tanl(-fabsl(y))) != hypotl (tanl(x), tanl(y))) link_error (); if (ccosl(tanl(x)+sinl(x-y)*1i) != ccosl(-tanl(-x)-sinl(y-x)*1i)) link_error (); if (tanl(x)+tanl(y)*1i != -~(tanl(-x)+tanl(y)*1i)) link_error (); for the first we have (in .optimized): [local count: 1073741824]: _1 = -x_96(D); y_115 = y_97(D) * 3.6e+1; _32 = tan (y_115); _33 = tan (_1); _34 = hypot (_33, _32); _36 = tan (x_96(D)); _37 = hypot (_36, _32); if (_34 != _37) in isolation we still optimize this so it's an odd interaction with surrounding code. We do observe similar differences with respect to SAVE_EXPRs compared to GCC 14. There's a difference after backprop: [local count: 1073741824]: - _1 = -x_64(D); + _1 = -x_96(D); [local count: 1073741824]: - _32 = tan (y_83); - _33 = tan (x_64(D)); + _32 = tan (y_115); + _33 = tan (_1); _34 = hypot (_33, _32); - _35 = tan (y_83); - _36 = tan (x_64(D)); + _35 = tan (y_115); + _36 = tan (x_96(D)); _37 = hypot (_36, _35); if (_34 != _37) where GCC 14 does [local count: 1073741824]: - _31 = .COPYSIGN (y_83, -1.0e+0); - _32 = tan (_31); - _33 = tan (_1); + _32 = tan (y_83); + _33 = tan (x_64(D)); but patched trunk only [local count: 1073741824]: - _31 = .COPYSIGN (y_115, -1.0e+0); - _32 = tan (_31); + _32 = tan (y_115); _33 = tan (_1); and that's because on trunk there's another use of _33 not ignoring sign which is already folded on the branch: [local count: 1073741824]: _65 = COMPLEX_EXPR <-0.0, _35>; _66 = _52 + _65; _67 = COMPLEX_EXPR <_33, 0.0>; _68 = _65 + _67; _69 = [conj_expr] _68; _70 = -_69; if (_66 != _70) that's the if (tan(x)+tan(y)*1i != -~(tan(-x)+tan(y)*1i)) link_error (); test which only complex lowering can now turn into something optimized, but we don't get any backprop after that. There's a missed optimization in backprop in that it doesn't realize we already compute tan(x) so instead of changing tan(-x) to compute tan(x) it could have used the result of the existing tan(x) compute. That's also something VN could do - for hypot (x, y) see if we have -x and use that, though it requires we simplify -tan(-x) to tan(x). The simplest way to avoid the regressions seen is to not build a SAVE_EXPR when arg0 is a COMPLEX_EXPR as we're then for sure folding - OTOH the GENERIC folding seems premature as complex lowering should deal with this as well. Restricting the transform to arg0 being a COMPLEX_EXPR would solve the issue as well. Disabling it completely shows we optimize the pr30172-1.c test even at -O0 during complex lowering.
[Bug other/115241] header-tools scripts not compatible to python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115241 --- Comment #4 from sadineniharish8446 at gmail dot com --- Is GCC upstream planning to backport the patch to older release branches for gcc versions? If yes, which release versions will have it? We can help to backport the patch, if needed.
[Bug other/115241] header-tools scripts not compatible to python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115241 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #5 from Sam James --- Do you really need them on older branches?
[Bug c/116458] New valgrind error in search_line_ssse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458 --- Comment #2 from Richard Biener --- It's likely the tail padding we possibly inspect, with now unrolling the loop twice to improve the number of badly predictable branches we can now end up with inspecting a completely uninitialized qword. This possibly makes valgrind fail to realize that uninit data doesn't actually influence the jump so IMO it's a valgrind issue.
[Bug other/115241] header-tools scripts not compatible to python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115241 --- Comment #6 from Andrew Pinski --- (In reply to sadineniharish8446 from comment #4) > Is GCC upstream planning to backport the patch to older release branches for > gcc versions? If yes, which release versions will have it? > > We can help to backport the patch, if needed. I doubt it since the scripts are not used for anything and plus if anything it is only used for development of gcc.
[Bug c/116458] [15 regression] New valgrind error in search_line_ssse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458 --- Comment #3 from Alexander Monakov --- David, thanks for Cc'ing me and for running Valgrind builds! Richi, I'll check in more detail later today, I think we should unbreak Valgrind builds ASAP by initializing padding under #ifdef ENABLE_VALGRIND_WORKAROUNDS. Your explanation makes sense to me, but it's pointing to a pedantically real issue (the code relies on never getting "wobbly values" from uninit reads, or else it needs asm propagation barriers or atomic-relaxed loads to ensure the values are really loaded just once, but neither would be visible to Valgrind in the end). "Wobbly values" aside, judging from how this never arised with other vectorized helpers, Valgrind treats some instructions optimistically? Probably pmovmskb from a partially-uninit vector yields a fully-initialized mask? If so, making the new helper work as well without workarounds should be doable (I'll see if I can come up with a testcase for Valgrind).
[Bug c/116458] [15 regression] New valgrind error in search_line_ssse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458 --- Comment #4 from David Binderman --- (In reply to Alexander Monakov from comment #3) > David, thanks for Cc'ing me and for running Valgrind builds! You are welcome. Its a normal weekly part of gcc testing for me. > "Wobbly values" aside, judging from how this never arised with other > vectorized helpers, Valgrind treats some instructions optimistically? I saw the problem first in a git development version of valgrind, but was able to duplicate it with the released version 3.23.0. I see no problems in this area with asan and ubsan.
[Bug preprocessor/116458] [15 regression] New valgrind error in search_line_ssse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Host||X86_64 Component|c |preprocessor
[Bug c++/116449] Miscompilation and missing bounds check with UBSAN with pointer to member functions and array accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116449 --- Comment #3 from Franz Sirl --- Isn't the missing bounds check on parr[c] on purpose? It's added with -fsanitize=bounds-strict.
[Bug libstdc++/116455] Should std::noop_coroutine() be constexpr?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116455 --- Comment #7 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > I think the standard does not define it as constexpr which is why it is not > constexpr in libstdc++. Right, the standard does not allow implementations to add constexpr to functions that are not specified as constexpr in the standard. (In reply to Andrew Pinski from comment #6) > https://github.com/cplusplus/ might be a good start, though there are others > too. No, that's for editorial changes to the draft only. See https://cplusplus.github.io/LWG/lwg-active.html#submit_issue or for larger changes https://isocpp.org/std/submit-a-proposal
[Bug c++/116449] Miscompilation and missing bounds check with UBSAN with pointer to member functions and array accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116449 --- Comment #4 from Andrew Pinski --- (In reply to Franz Sirl from comment #3) > Isn't the missing bounds check on parr[c] on purpose? It's added with > -fsanitize=bounds-strict. You might be right, I misread the original qnd gimple dump. But I suspect there is still a missing bounds check in some cases.
[Bug c++/115716] [12/13/14/15 regression] internal compiler error: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115716 Simon Martin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |simartin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Simon Martin --- Working on this one.
[Bug fortran/116261] [15 regression] gfortran.dg/sizeof_6.f90 -O1 timeout since r15-2739-g4cb07a38233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261 --- Comment #7 from Sam James --- The unreliable nature of the failure keeps confusing people. Any chance of a revert until it can be fixed properly?
[Bug fortran/116261] [15 regression] gfortran.dg/sizeof_6.f90 -O1 timeout since r15-2739-g4cb07a38233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261 Xi Ruoyao changed: What|Removed |Added Priority|P3 |P1
[Bug fortran/116261] [15 regression] gfortran.dg/sizeof_6.f90 -O1 timeout since r15-2739-g4cb07a38233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261 --- Comment #8 from Xi Ruoyao --- Raising to P1 because now automatic regression tracker has started to "bisect" on this and blame random people.
[Bug debug/37801] DWARF output for inlined functions doesn't always use DW_TAG_inlined_subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37801
--- Comment #15 from GCC Commits ---
The master branch has been updated by Bernd Edlinger :
https://gcc.gnu.org/g:bcb33b1237042e9540a905d9de19219f876e26c0
commit r15-3083-gbcb33b1237042e9540a905d9de19219f876e26c0
Author: Bernd Edlinger
Date: Fri Aug 16 12:26:27 2024 +0200
Do not emit a redundant DW_TAG_lexical_block for inlined subroutines
While this already works correctly for the case when an inlined
subroutine contains only one subrange, a redundant DW_TAG_lexical_block
is still emitted when the subroutine has multiple blocks.
Fixes: ac02e5b75451 ("re PR debug/37801 (DWARF output for inlined functions
doesn't always use DW_TAG_inlined_subroutine)")
gcc/ChangeLog:
PR debug/87440
* dwarf2out.cc (gen_inlined_subroutine_die): Handle the case
of multiple subranges correctly.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/dwarf2/inline7.c: New test.
[Bug debug/87440] GCC creates debug that confuses gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87440
--- Comment #7 from GCC Commits ---
The master branch has been updated by Bernd Edlinger :
https://gcc.gnu.org/g:bcb33b1237042e9540a905d9de19219f876e26c0
commit r15-3083-gbcb33b1237042e9540a905d9de19219f876e26c0
Author: Bernd Edlinger
Date: Fri Aug 16 12:26:27 2024 +0200
Do not emit a redundant DW_TAG_lexical_block for inlined subroutines
While this already works correctly for the case when an inlined
subroutine contains only one subrange, a redundant DW_TAG_lexical_block
is still emitted when the subroutine has multiple blocks.
Fixes: ac02e5b75451 ("re PR debug/37801 (DWARF output for inlined functions
doesn't always use DW_TAG_inlined_subroutine)")
gcc/ChangeLog:
PR debug/87440
* dwarf2out.cc (gen_inlined_subroutine_die): Handle the case
of multiple subranges correctly.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/dwarf2/inline7.c: New test.
[Bug target/116365] Add user-friendly arguments to --param aarch64-autovec-preference=N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116365 --- Comment #2 from GCC Commits --- The master branch has been updated by Jennifer Schmitz : https://gcc.gnu.org/g:313aa733e22b654ff822b867018b13ceb624c13a commit r15-3085-g313aa733e22b654ff822b867018b13ceb624c13a Author: Jennifer Schmitz Date: Mon Aug 19 08:42:55 2024 -0700 PR target/116365: Add user-friendly arguments to --param aarch64-autovec-preference=N The param aarch64-autovec-preference=N is a useful tool for testing auto-vectorisation in GCC as it allows the user to force a particular strategy. So far, N could be a numerical value between 0 and 4. This patch replaces the numerical values by more user-friendly names to distinguish the options. The patch was bootstrapped and regtested on aarch64-linux-gnu, no regression. Ok for mainline? Signed-off-by: Jennifer Schmitz gcc/ PR target/116365 * config/aarch64/aarch64-opts.h (enum aarch64_autovec_preference_enum): New enum. * config/aarch64/aarch64.cc (aarch64_cmp_autovec_modes): Change numerical to enum values. (aarch64_autovectorize_vector_modes): Change numerical to enum values. (aarch64_vector_costs::record_potential_advsimd_unrolling): Change numerical to enum values. * config/aarch64/aarch64.opt: Change param type to enum. * doc/invoke.texi: Update documentation. gcc/testsuite/ PR target/116365 * gcc.target/aarch64/autovec_param_asimd-only.c: New test. * gcc.target/aarch64/autovec_param_default.c: Likewise. * gcc.target/aarch64/autovec_param_prefer-asimd.c: Likewise. * gcc.target/aarch64/autovec_param_prefer-sve.c: Likewise. * gcc.target/aarch64/autovec_param_sve-only.c: Likewise. * gcc.target/aarch64/neoverse_v1_2.c: Update parameter value. * gcc.target/aarch64/neoverse_v1_3.c: Likewise. * gcc.target/aarch64/sve/cond_asrd_1.c: Likewise. * gcc.target/aarch64/sve/cond_cnot_4.c: Likewise. * gcc.target/aarch64/sve/cond_unary_5.c: Likewise. * gcc.target/aarch64/sve/cond_uxt_5.c: Likewise. * gcc.target/aarch64/sve/cond_xorsign_2.c: Likewise. * gcc.target/aarch64/sve/pr98268-1.c: Likewise. * gcc.target/aarch64/sve/pr98268-2.c: Likewise.
[Bug fortran/116261] [15 regression] gfortran.dg/sizeof_6.f90 -O1 timeout since r15-2739-g4cb07a38233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261 --- Comment #9 from Paul Thomas --- (In reply to Sam James from comment #7) > The unreliable nature of the failure keeps confusing people. Any chance of a > revert until it can be fixed properly? It is such an unreliable failure that I haven't seen it yet. However, I will revert the test this evening. Paul
[Bug fortran/116261] [15 regression] gfortran.dg/sizeof_6.f90 -O1 timeout since r15-2739-g4cb07a38233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #10 from Paul Thomas --- I guess that I should take it :-) Paul
[Bug middle-end/116358] [15 Regression] undefined reference to `__umindi3' at -O3 when compiling with SVE since r15-2890-g72c9b5f438f22c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116358 --- Comment #5 from Manolis Tsamis --- I had some trouble figuring the preferred way to address this. I made a choice by answering these questions: 1) Should the aarch64 min/max expand pattern be improved? This comment hints that we should get a cmp+csel when expanding this rather than a libcall: ;; Expander for integer smin, smax, umin. Mainly used to generate ;; straightforward RTL for TARGET_CSSC. When that is not available ;; FAIL and let the generic expanders generate the CMP + CSEL sequences, ;; except for the SMIN and SMAX with zero cases, for which we have a ;; single instruction even for the base architecture. Although aarch64.md could be changed to fix this, this wouldn't prevent similar issues from happening in other cases. 2) Should force_operand handle this in a better way? In theory, the expression involved can be forced in a register, but it's not due to implementation details of force_operand. But I also believe changing force_operand is too risky and out of scope. 3) Should noce_can_force_operand reject this RTL? noce_can_force_operand is already based on internals of force_operand and it would make sense to fix it there, but it doesn't look possible. As far as force_operand is conserned there's no error, just a libcall being emitted. Hence we would have to hardcode cases in noce_can_force_operand which is what r15-2890-g72c9b5f438f22c tried to avoid compared to the previous implementation. 4) Should we reject calls being generated in noce_convert_multiple_sets? Although this initially felt like a workaround, I believe is the best solution here. The reasoning is that, regardless of other factors, noce_convert_multiple_sets should never emit a call expression. Since this was already done for jump instructions, the change is also minimal: diff --git a/gcc/ifcvt.cc b/gcc/ifcvt.cc index da59c907891..b136d7dbbba 100644 --- a/gcc/ifcvt.cc +++ b/gcc/ifcvt.cc @@ -3550,7 +3550,7 @@ noce_convert_multiple_sets (struct noce_if_info *if_info) return false; for (insn = seq; insn; insn = NEXT_INSN (insn)) -if (JUMP_P (insn) +if (JUMP_P (insn) || CALL_P (insn) || recog_memoized (insn) == -1) return false; -- Sent to the lists: https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661145.html
[Bug middle-end/116454] [12/13/14/15 Regression] `*++ptr * 1j` is handled incorrectly with -ffast-math, increments ptr twice since r0-77972-g9f5396713d9e18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116454 --- Comment #10 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b07f8a301158e53717b8688cc8ea430b6f02574c commit r15-3087-gb07f8a301158e53717b8688cc8ea430b6f02574c Author: Andrew Pinski Date: Wed Aug 21 17:41:38 2024 -0700 fold: Fix `a * 1j` if a has side effects [PR116454] The problem here was a missing save_expr around arg0 since it is used twice, once in REALPART_EXPR and once in IMAGPART_EXPR. Thia adds the save_expr and reformats the code slightly so it is a little easier to understand. It excludes the case when arg0 is a COMPLEX_EXPR since in that case we'll end up with the distinct real and imaginary parts. This is important to retain early optimization in some testcases. Bootstapped and tested on x86_64-linux-gnu with no regressions. PR middle-end/116454 gcc/ChangeLog: * fold-const.cc (fold_binary_loc): Fix `a * +-1i` by wrapping arg0 with save_expr when it is not COMPLEX_EXPR. gcc/testsuite/ChangeLog: * gcc.dg/torture/pr116454-1.c: New test. * gcc.dg/torture/pr116454-2.c: New test. Signed-off-by: Andrew Pinski Co-Authored-By: Richard Biener
[Bug middle-end/116454] [12/13/14 Regression] `*++ptr * 1j` is handled incorrectly with -ffast-math, increments ptr twice since r0-77972-g9f5396713d9e18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116454 Richard Biener changed: What|Removed |Added Known to work||15.0 Summary|[12/13/14/15 Regression]|[12/13/14 Regression] |`*++ptr * 1j` is handled|`*++ptr * 1j` is handled |incorrectly with|incorrectly with |-ffast-math, increments ptr |-ffast-math, increments ptr |twice since |twice since |r0-77972-g9f5396713d9e18|r0-77972-g9f5396713d9e18 --- Comment #11 from Richard Biener --- Fixed on trunk sofar.
[Bug lto/116361] lto1: fatal error: multiple prevailing defs when using both LTO and OpenMP named critical sections with static libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361 --- Comment #6 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:a98dd536b1017c2b814a3465206c6c01b2890998 commit r15-3088-ga98dd536b1017c2b814a3465206c6c01b2890998 Author: H.J. Lu Date: Wed Aug 21 07:25:25 2024 -0700 Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook This hook allows the BFD linker plugin to distinguish calls to claim_file_handler that know the object is being used by the linker (from ldmain.c:add_archive_element), from calls that don't know it's being used by the linker (from elf_link_is_defined_archive_symbol); in the latter case, the plugin should avoid including the unused LTO archive members in link output. To get the proper support for archives with LTO common symbols, the linker fix commit a6f8fe0a9e9cbe871652e46ba7c22d5e9fb86208 Author: H.J. Lu Date: Wed Aug 14 20:50:02 2024 -0700 lto: Don't include unused LTO archive members in output is required. PR lto/116361 * lto-plugin.c (claim_file_handler_v2): Rename claimed to can_be_claimed. Include the LTO object only if it is known to be included in link output. Signed-off-by: H.J. Lu
[Bug target/116365] Add user-friendly arguments to --param aarch64-autovec-preference=N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116365 Jennifer Schmitz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jennifer Schmitz --- fixed in GCC 15.1
[Bug tree-optimization/101390] Expand vector mod as vector div + multiply-subtract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101390 Jennifer Schmitz changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jennifer Schmitz --- fixed in GCC 15.1
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 101390, which changed state. Bug 101390 Summary: Expand vector mod as vector div + multiply-subtract https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101390 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/116459] New: gcc 12.0 optimized out functions which has observable side affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
Bug ID: 116459
Summary: gcc 12.0 optimized out functions which has observable
side affect
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xiaohuba2021 at 163 dot com
Target Milestone: ---
The following code:
#include
#include
using namespace std;
struct Matrix {
long long mat[2][2];
Matrix() { memset(mat, 0, sizeof(mat)); }
Matrix operator*(Matrix b) {
Matrix ans;
ans.mat[0][0] = (mat[0][0] * b.mat[0][0] + mat[0][1] * b.mat[1][0]);
ans.mat[1][0] = (mat[1][0] * b.mat[0][0] + mat[1][1] * b.mat[1][0]);
ans.mat[0][1] = (mat[0][0] * b.mat[0][1] + mat[0][1] * b.mat[1][1]);
ans.mat[1][1] = (mat[1][0] * b.mat[0][1] + mat[1][1] * b.mat[1][1]);
return ans;
}
};
Matrix st, res;
volatile bool mask = 0;
void qpw(long long k) {
mask = 1;
while (k) {
if (k & 1) st = st * res;
res = res * res, k >>= 1;
}
}
int main() {
st.mat[0][0] = st.mat[0][1] = 1;
res.mat[0][0] = 6;
res.mat[1][0] = -2, res.mat[1][1] = 2;
qpw(2);
cout << st.mat[0][0] << '\n';
return 0;
}
seems to produce wrong output(1) with -O2 or -O1 enabled, while the correct
answer is 20.
Uncomment line 20 (mask = 1) or explicitly add operator= for struct Matrix
solves this problem.
By looking at the assemble code, I found that the compiler did compile function
qpw, however didn't call it. So it's most likely a compiler bug, as the
compiler thought qpw did not have any side affects and optimized it out.
Is it caused by the default copy assignment of a struct containing only 2D
array?
Compiler info:
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-12.2.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/compiler-explorer/gcc-12.2.0/bin/../libexec/gcc/x86_64-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-12.2.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc--binutils-2.38
--enable-libstdcxx-backtrace=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (Compiler-Explorer-Build-gcc--binutils-2.38)
[Bug c++/116459] gcc 12.0 optimized out functions which has observable side affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459 xiaohuba2021 changed: What|Removed |Added CC||xiaohuba2021 at 163 dot com --- Comment #1 from xiaohuba2021 --- compiler explorer: https://godbolt.org/z/hc9rP4b7K
[Bug c++/116459] gcc 12.2.0 optimized out functions which has observable side affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459 --- Comment #2 from xiaohuba2021 --- > Uncomment line 20 (mask = 1) or explicitly add operator= for struct Matrix > solves this problem. sorry, the code above produces the correct answer, since line 20 is uncommented. Comment it and it will output 1.
[Bug c++/116459] gcc 12.2.0 optimized out functions which has observable side affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459 Richard Biener changed: What|Removed |Added Known to fail||12.1.0, 12.2.0 Known to work||11.5.0, 12.3.0, 13.1.0 Resolution|--- |FIXED Target Milestone|--- |12.3 Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Biener --- Seems to be fixed in 12.3? Note the pasted testcase in the description needs the mask = 1; like commented to reproduce the issue with 12.1 and 12.2.
[Bug c++/116424] [13/14/15 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.c:904 creating static object from other static objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116424 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/116459] gcc 12.2.0 optimized out functions which has observable side affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459 --- Comment #4 from xiaohuba2021 --- Yes, it seems that only 12.1 and 12.2 are affected. But I wonder what's the cause of it, and are there any patches for it?
[Bug c++/116459] gcc 12.2.0 optimized out functions which has observable side affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #5 from Sam James --- The patch is to use GCC 12.3 or 12.4, ideally. You can bisect if you're really curious for the fix...
[Bug c++/116459] gcc 12.2.0 optimized out functions which has observable side affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459 --- Comment #6 from Jonathan Wakely --- Regression started with with r12-2523 and was fixed by r13-7206, which was backported as r12-9476. So this is a dup of either PR ipa/107769 or PR ipa/109318.
[Bug c++/116459] gcc 12.2.0 optimized out functions which has observable side affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459 --- Comment #7 from xiaohuba2021 --- Created attachment 58975 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58975&action=edit The miscompiled program
[Bug c++/116459] gcc 12.2.0 optimized out functions which has observable side affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
--- Comment #8 from Jonathan Wakely ---
(In reply to xiaohuba2021 from comment #0)
> struct Matrix {
> long long mat[2][2];
> Matrix() { memset(mat, 0, sizeof(mat)); }
N.B. there's no miscompilation if you change this to the more idiomatic and
sensible:
Matrix() : mat() { }
[Bug rtl-optimization/116420] [15 Regression] wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116420 Jeffrey A. Law changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org --- Comment #2 from Jeffrey A. Law --- So what's really interesting here is it appears that we're not queuing preds of the current block for reprocessing during the liveness computation. But it seems to be specific to a particular pred/succ in a given loop -- the other loop seems to iterate and reach a fixed point just fine. Weird. But definitely mine.
[Bug tree-optimization/116348] [15 regression] ICE when building gavl-1.4.0 with -O3 -march=znver4 since r15-2791-g2083389a18d366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116348 --- Comment #10 from Xi Ruoyao --- I've tested the change and it fixes PR116314 case as well. Richard: do you want me to send your change as a patch like before (the PR116142 fix)?
[Bug rtl-optimization/116420] [15 Regression] wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116420 --- Comment #3 from Jeffrey A. Law --- Fun. The DF framework provides us a way to run dataflow problems on sub-graphs. Naturally a bitmap of interesting blocks is passed into those routines. At a confluence point, the DF framework will not mark a block for re-processing if it's not in that set of interesting blocks. When ext-dce sets up that set of interesting blocks it's using the wrong counter. ie, it's using n_basic_blocks rather than last_basic_block. If there are holes in the block indices, some number of blocks won't get marked as interesting. In this case the block needing reprocessing has an index higher than n_basic_blocks. It never gets reprocessed and the newly found live chunks don't propagate further up the CFG -- ultimately resulting in a pseudo appearing to have only the low 8 bits live, when in fact the low 32 bits are actually live. Testing a pretty obvious fix.
[Bug c++/116439] [14/15 Regression] decltype(auto) in return type of lambda uses the type of the outer scope, not the capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116439 Patrick Palka changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Patrick Palka --- I believe GCC 14 is behaving correctly according to the standard now. According to https://eel.is/c++draft/expr.prim.lambda#capture-note-7, decltype(source) must be S not S&, despite the by-ref capture. And a decltype(auto) deduced return type is equivalent decltype(return-expr), so it must deduce to S here as well. GCC's previous behavior was inconsistent and incorrect in the decltype(auto) case. Doing an init-capture [&source = source] yields S& because in that case there is no "original entity" (the init-capture is its own independent entity), and the note doesn't apply, I think. See also https://stackoverflow.com/questions/33854388/decltypeauto-deduced-return-type-from-lambda-capture
[Bug c/84052] Using Randomizing structure layout plugin in linux kernel compilation doesn't generate proper debuginfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052 ezannoni changed: What|Removed |Added CC||ezannoni at gmail dot com --- Comment #10 from ezannoni --- Hi Andrew, do you have a pointer to the committee recommendation or discussion, it would be helpful to understand the reasoning. thanks
[Bug target/116329] no sibcalling for thumb1 (cortex-m0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116329 Richard Earnshaw changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #4 from Richard Earnshaw --- Direct tail-calls rely on having a usable direct-branch instruction. Cortex-m0+ (armv6-m) only has a 16-bit pc-relative direct-branch instruction, which has an effective branch range of about +/- 2kbytes from the current PC value (the BL instruction has a range of +/-4Mb). Even modest binaries on these platforms can easily exceed this limit and the result would be branches that are out of range and probably unfixable by the linker. We thus do not even try to support tail-calls on this platform.
[Bug lto/116460] New: ppc64le: LTO ICE during GIMPLE pass: forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460 Bug ID: 116460 Summary: ppc64le: LTO ICE during GIMPLE pass: forwprop Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ales.astone at gmail dot com Target Milestone: --- When recompiling https://github.com/esri/lerc on Ubuntu 24.10 with gcc-14 we hit this LTO error: during GIMPLE pass: forwprop Lerc.cpp: In function 'EncodeInternal.constprop': Lerc.cpp:606:9: internal compiler error: in build2, at tree.cc:5097 606 | ErrCode Lerc::EncodeInternal(const T* pData, int version, int nDepth, int nCols, int nRows, int nBands, | ^ 0x1074e99f internal_error(char const*, ...) ???:0 0x1074ead7 fancy_abort(char const*, int, char const*) ???:0 0x10887107 build2(tree_code, tree_node*, tree_node*, tree_node*) ???:0 0x10c7a91f gimple_assign_rhs_to_tree(gimple*) ???:0 0x10b97bd3 insert_debug_temp_for_var_def(gimple_stmt_iterator*, tree_node*) ???:0 0x1098a083 insert_debug_temps_for_defs(gimple_stmt_iterator*) ???:0 0x1098979f gsi_remove(gimple_stmt_iterator*, bool) ???:0 0x10a793eb simple_dce_from_worklist(bitmap_head*, bitmap_head*) ???:0 The command-line options required to trigger the error is: `-g -O3 -flto`. All three must be enabled. Steps to reproduce: ``` wget -qO- https://github.com/Esri/lerc/archive/refs/tags/v4.0.0.tar.gz | tar xvz cd lerc-4.0.0/src/LercLib g++ -shared -fPIC -g -O3 -flto *.cpp Lerc1Decode/*.cpp ``` I could reproduce with the gcc-14 packages from Ubuntu 24.10 and Fedora 41. I couldn't reproduce on any architecture but ppc64le. It can be reproduced both on a ppc64le machine (qemu-user is good enough), or by cross-compiling to ppc64le. Attaching intermediate files.
[Bug lto/116460] ppc64le: LTO ICE during GIMPLE pass: forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460 --- Comment #1 from Alessandro Astone --- Cannot attach intermediate files because the size is too large. Sorry that I don't have a minimal reproducer :/
[Bug middle-end/116460] ppc64le: LTO ICE during GIMPLE pass: forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460 --- Comment #2 from Andrew Pinski --- Can you try adding -fchecking and seeing if that fails differently?
[Bug middle-end/116460] ppc64le: LTO ICE during GIMPLE pass: forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460 --- Comment #3 from Alessandro Astone --- (In reply to Andrew Pinski from comment #2) > Can you try adding -fchecking and seeing if that fails differently? No, it fails in the same way. BTW i realize i didn't specify this other than mentioning 'lto': it fails at linking time.
[Bug target/115921] Missed optimization: and->ashift might be cheaper than ashift->and on typical RISC targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115921
Jovan Vukic changed:
What|Removed |Added
CC||jovan.vu...@rt-rk.com
--- Comment #2 from Jovan Vukic ---
I have reviewed the issue, specifically for the RISC-V platform, as I find the
difference between the results for 32-bit and 64-bit variants intriguing.
Here are my conclusions:
1. Both RISC-V 32-bit and 64-bit versions in the releases 14.1.0 and 14.2.0 do
not perform the optimization in question.
2. The GCC trunk code contains the optimization for this problem for both
RISC-V 32-bit and 64-bit, applicable to AND, OR, and XOR operations.
3. This optimization happens because of the pattern
_shift_reverse on line 2929 in riscv.md.
The optimization works correctly, as evidenced by the example C code below, for
which GCC generates optimized assembly code for both 32-bit and 64-bit
platforms:
typedef unsigned long target_wide_uint_t;
target_wide_uint_t test_ashift_and(target_wide_uint_t x) {
return (x & 0x3e) << 12;
}
test_ashift_and:
andi a0,a0,62
slli a0,a0,12
ret
However, the problem arises with the test example we are considering (repeated
below). It is optimized for 32-bit but not for 64-bit. Here are the results for
the 64-bit architecture (https://godbolt.org/z/6a7x9zTjs):
typedef unsigned long target_wide_uint_t;
target_wide_uint_t test_ashift_and(target_wide_uint_t x) {
return (x & 0x3f) << 12;
}
test_ashift_and:
li a5,258048
slli a0,a0,12
and a0,a0,a5
ret
In this example, we have 0x3f == 2^6 - 1. If we examine the pattern on line
2929 in riscv.md, there is a special condition:
(!TARGET_64BIT || (exact_log2((INTVAL(operands[3]) >> INTVAL(operands[2])) + 1)
== -1))
This condition indicates that optimization does not occur for 64-bit
architecture when the value 0x3f (or another number in its place) is of the
form 2^x - 1. This condition, introduced in this commit
[https://github.com/gcc-mirror/gcc/commit/236116068151bbc72aaaf53d0f223fe06f7e3bac],
seems to be the root of the issue for RISC-V 64-bit.
It would be helpful if someone could clarify the rationale behind the
exact_log2 condition, as it prevents optimization only for numbers of the form
2^x - 1, specifically for the 64-bit target, and its purpose is not immediately
clear to me.
[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324 --- Comment #29 from andi at firstfloor dot org --- The semantics of -foptimize-sibling-calls do not change. However if your program depends on sbling calls for correctness it should migrate to the new attribute
Re: K-12 schools, colleges, universities Contacts 2024
Hi there, Want to expand your outreach to K-12 schools, colleges, universities? Our email list of principals, superintendents, and key decision-makers is ideal for you! Our List Includes: * Principals * Superintendents * Board Members * Department Heads List Contains:- First Name, Last Name, Title, Email, Company Name, Phone Numbers, etc. in an Excel sheet.. If you're interested, we would be happy to provide you with relevant counts, cost and a test file based on your specific requirements. Looking forward to hearing from you. Best regards, Isabella Cooper To remove yourself from this mailing list, please reply with the subject line "LEAVE US."
[Bug fortran/106606] Internal compiler error with abstract derived type using recursive class() components. since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106606 --- Comment #4 from Paul Thomas --- Created attachment 58976 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58976&action=edit Full testcase that fails in runtime The patch regtests OK but the attached fails in runtime, as it does with ifort. nagfor on the other hand produces a runtime, including the commented out parts, that produces the expected result. There is clearly more work to do on this. Paul
[Bug other/116461] New: New test case gcc.dg/vect/vect-mod-var.c from r15-3082-g9bbad3685131ec fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461 Bug ID: 116461 Summary: New test case gcc.dg/vect/vect-mod-var.c from r15-3082-g9bbad3685131ec fails Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:9bbad3685131ec95d970f81bf75f9556d4d92742, r15-3082-g9bbad3685131ec make -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-mod-var.c" FAIL: gcc.dg/vect/vect-mod-var.c execution test FAIL: gcc.dg/vect/vect-mod-var.c -flto -ffat-lto-objects execution test Program received signal SIGABRT, Aborted. __pthread_kill_implementation (threadid=, signo=, no_tid=no_tid@entry=0) at pthread_kill.c:44 44return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0; (gdb) where #0 __pthread_kill_implementation (threadid=, signo=, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x77ca5814 in __pthread_kill_internal (signo=, threadid=) at pthread_kill.c:78 #2 0x77c47f20 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x77c2a574 in __GI_abort () at abort.c:79 #4 0x16e4 in main () at /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/vect-mod-var.c:34 for (int i = 0; i < N; ++i) if (c[i] != a[i] % b[i]) __builtin_abort (); // line 34 commit 9bbad3685131ec95d970f81bf75f9556d4d92742 (HEAD) Author: Jennifer Schmitz Date: Wed Aug 7 08:56:45 2024 -0700 PR tree-optimization/101390: Vectorize modulo operator
[Bug fortran/106606] Internal compiler error with abstract derived type using recursive class() components. since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106606 Paul Thomas changed: What|Removed |Added CC||vehre at gmx dot de --- Comment #5 from Paul Thomas --- Hi Andre, Could you take a look at this please? I cannot see why the last attachment is failing in runtime, other than that gdb reveals that 'root' has a null vptr. Cheers Paul
[Bug tree-optimization/116461] [15 regression] New test case gcc.dg/vect/vect-mod-var.c from r15-3082-g9bbad3685131ec fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461 Andrew Pinski changed: What|Removed |Added Severity|normal |blocker Target Milestone|--- |15.0 Keywords||wrong-code Summary|New test case |[15 regression] New test |gcc.dg/vect/vect-mod-var.c |case |from|gcc.dg/vect/vect-mod-var.c |r15-3082-g9bbad3685131ec|from |fails |r15-3082-g9bbad3685131ec ||fails Component|other |tree-optimization
[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361 Jerry DeLisle changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #18 from Jerry DeLisle --- (In reply to Edwin Lu from comment #17) > (In reply to Jerry DeLisle from comment #16) > > Created attachment 58799 [details] > > Revised test case with careful precision and tolerance values. > > > > New suggested test case which passes on x86-64-linux. > > We removed the test from our postcommit allowlist about 2 weeks ago and > haven't seen any flakiness appear since on riscv. Not sure if that's the > same on other architectures. > > https://github.com/patrick-rivos/gcc-postcommit-ci/issues?q=gfortran. > dg%2Fpr105361.f90 > > also tested the new testcase in c16 on riscv and haven't seen any failures. This confirms my suspicions. The original test was making floating point comparisons and floating ppoint is not exact and depends on architecture. I will push this revised test.
[Bug tree-optimization/116460] ppc64le: LTO ICE during GIMPLE pass: forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460 --- Comment #4 from Andrew Pinski --- (In reply to Alessandro Astone from comment #1) > Cannot attach intermediate files because the size is too large. > Sorry that I don't have a minimal reproducer :/ Is there a place where you could upload the intermediate files to?
[Bug preprocessor/116458] [15 regression] New valgrind error in search_line_ssse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-08-22 Assignee|unassigned at gcc dot gnu.org |amonakov at gcc dot gnu.org --- Comment #5 from Alexander Monakov --- Turns out we already initialize padding, just in a different file, and I completely overlooked that. That's why the SSE4.2 helper did not cause Valgrind errors. https://inbox.sourceware.org/gcc-patches/20240822182508.621-1-amona...@ispras.ru/
[Bug rtl-optimization/116420] [15 Regression] wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116420 --- Comment #4 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:c9377734b798d8d311dfd3a5618dc49407703b93 commit r15-3095-gc9377734b798d8d311dfd3a5618dc49407703b93 Author: Jeff Law Date: Thu Aug 22 12:48:49 2024 -0600 [PR rtl-optimization/116420] Fix interesting block bitmap DF dataflow The DF framework provides us a way to run dataflow problems on sub-graphs. Naturally a bitmap of interesting blocks is passed into those routines. At a confluence point, the DF framework will not mark a block for re-processing if it's not in that set of interesting blocks. When ext-dce sets up that set of interesting blocks it's using the wrong counter. ie, it's using n_basic_blocks rather than last_basic_block. If there are holes in the block indices, some number of blocks won't get marked as interesting. In this case the block needing reprocessing has an index higher than n_basic_blocks. It never gets reprocessed and the newly found live chunks don't propagate further up the CFG -- ultimately resulting in a pseudo appearing to have only the low 8 bits live, when in fact the low 32 bits are actually live. Fixed in the obvious way, by using last_basic_block instead. Bootstrapped and regression tested on x86_64. Pushing to the trunk. PR rtl-optimization/116420 gcc/ * ext-dce.cc (ext_dce_init): Fix loop iteration when setting up the interesting block for DF to analyze. gcc/testsuite * gcc.dg/torture/pr116420.c: New test.
[Bug other/116462] New: [15 regression] new test case gcc.dg/debug/dwarf2/inline7.c from r15-3083-gbcb33b1237042e fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462 Bug ID: 116462 Summary: [15 regression] new test case gcc.dg/debug/dwarf2/inline7.c from r15-3083-gbcb33b1237042e fails Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:bcb33b1237042e9540a905d9de19219f876e26c0, r15-3083-gbcb33b1237042e make -k check-gcc RUNTESTFLAGS="dwarf2.exp=gcc.dg/debug/dwarf2/inline7.c" FAIL: gcc.dg/debug/dwarf2/inline7.c scan-assembler-times DW_AT_ranges 2 # of expected passes3 # of unexpected failures1 commit bcb33b1237042e9540a905d9de19219f876e26c0 (HEAD) Author: Bernd Edlinger Date: Fri Aug 16 12:26:27 2024 +0200 Do not emit a redundant DW_TAG_lexical_block for inlined subroutines * gcc.dg/debug/dwarf2/inline7.c: New test.
[Bug rtl-optimization/116420] [15 Regression] wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116420 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jeffrey A. Law --- Fixed on the trunk.
[Bug tree-optimization/116463] New: [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
Bug ID: 116463
Summary: [15 Regression] fast-math-complex-mls-{double,float}.c
fail after r15-3087-gb07f8a301158e5
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization, testsuite-fail
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-*-*
make check-gcc RUNTESTFLAGS="complex.exp=fast-math-complex-mls-*.c"
FAIL: gcc.dg/vect/complex/fast-math-complex-mls-double.c scan-tree-dump vect
"Found COMPLEX_FMA"
FAIL: gcc.dg/vect/complex/fast-math-complex-mls-float.c scan-tree-dump vect
"Found COMPLEX_FMA"
[Bug tree-optimization/116463] [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0
[Bug tree-optimization/116463] [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463 --- Comment #1 from Andrew Pinski --- Created attachment 58977 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58977&action=edit Reduced testcase options: `-ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2 -ffast-math -march=armv8.3-a`
[Bug other/116462] [15 regression] new test case gcc.dg/debug/dwarf2/inline7.c from r15-3083-gbcb33b1237042e fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comment #1 from Bernd Edlinger ---
Ah, nice, it worked with arm, aarch64, x86_64, riscv, riscv64 so far...
only one of two inlined_subroutines have multiple subranges.
Can you try this:
index 48d457216b1..5342b87cd0f 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
@@ -10,7 +10,7 @@ static int foo (int i)
{
volatile int j = i + 3;
if (j == 3)
-return 0;
+return j - 3;
return j - 2;
}
int main()
[Bug preprocessor/116458] [15 regression] New valgrind error in search_line_ssse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458 --- Comment #6 from Alexander Monakov --- As for Valgrind false positive, it handles this SSSE3 code really well and misses the key point by a very narrow margin. We have found = m1 + (m2 << 16); where both m1 and m2 hold 16-bit masks from pmovmskb, so 'found' is just the 32-bit concatenation of those masks. Suppose m1 has uninit bits. In that case, its highest known bit is guaranteed to be non-zero (because our character stream always ends with a newline), in 'm2 << 16' the lower 16 bits are known, and therefore 'found' has a known non-zero bit, making the branch on found != 0 well-defined. If we instead combine the halves with an OR instead of PLUS: found = m1 | (m2 << 16); Valgrind properly computes known bits in 'found' and does not complain. I can see the difficulty in computing known bits after addition in the general case though.
[Bug tree-optimization/116463] [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463 Andrew Pinski changed: What|Removed |Added Attachment #58977|0 |1 is obsolete|| --- Comment #2 from Andrew Pinski --- Created attachment 58978 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58978&action=edit Better testcase Before the patch fms180snd could be detected but fms180snd_1 could not. BUT both are the same function just changed when the multiply by i happens. fms180snd_1 represents what happens after the patch for fms180snd .
[Bug tree-optimization/116463] [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463 Andrew Pinski changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org Blocks||53947 Status|UNCONFIRMED |NEW Last reconfirmed||2024-08-22 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- +Tamar since he wrote the original Complex vectorization support. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/113746] [14/15 Regression] ICE: tree check: expected enumeral_type, have error_mark in tsubst_expr, at cp/pt.cc:21458 with missing typename since r14-4796-g3e3d73ed5e85e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113746 Simon Martin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |simartin at gcc dot gnu.org --- Comment #9 from Simon Martin --- This is not ICE'ing anymore. I will identify what change removed the ICE and add a new testcase.
[Bug tree-optimization/116463] [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463 Andrew Pinski changed: What|Removed |Added Attachment #58978|0 |1 is obsolete|| --- Comment #4 from Andrew Pinski --- Created attachment 58979 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58979&action=edit Full testcase Before the change fms180snd_2a and fms180snd_1 could not be detected even though they are all the same. Note I think fms180snd_2a is more representative of what is done after the patch for fms180snd rather than fms180snd_1.
[Bug preprocessor/116458] [15 regression] New valgrind error in search_line_ssse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458 --- Comment #7 from Mark Wielaard --- You could try --expensive-definedness-checks=yes --expensive-definedness-checks= [default: auto] Controls whether Memcheck should employ more precise but also more expensive (time consuming) instrumentation when checking the definedness of certain values. In particular, this affects the instrumentation of integer adds, subtracts and equality comparisons. Selecting --expensive-definedness-checks=yes causes Memcheck to use the most accurate analysis possible. This minimises false error rates but can cause up to 30% performance degradation. Selecting --expensive-definedness-checks=no causes Memcheck to use the cheapest instrumentation possible. This maximises performance but will normally give an unusably high false error rate. The default setting, --expensive-definedness-checks=auto, is strongly recommended. This causes Memcheck to use the minimum of expensive instrumentation needed to achieve the same false error rate as --expensive-definedness-checks=yes. It also enables an instrumentation-time analysis pass which aims to further reduce the costs of accurate instrumentation. Overall, the performance loss is generally around 5% relative to --expensive-definedness-checks=no, although this is strongly workload dependent. Note that the exact instrumentation settings in this mode are architecture dependent.
[Bug other/116462] [15 regression] new test case gcc.dg/debug/dwarf2/inline7.c from r15-3083-gbcb33b1237042e fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
--- Comment #2 from Bernd Edlinger ---
no forget it, this might make arm unhappy...
lets try this instead:
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
@@ -1,9 +1,9 @@
-/* Verify that both inline instances have a DW_AT_ranges but
- no extra DW_TAG_lexical_block. */
+/* Verify that at least one of both inline instances have
+ a DW_AT_ranges but no extra DW_TAG_lexical_block. */
/* { dg-options "-O -gdwarf -dA" } */
/* { dg-do compile } */
/* { dg-final { scan-assembler-times "\\(DIE \\(\[^\n\]*\\)
DW_TAG_inlined_subroutine" 2 } } */
-/* { dg-final { scan-assembler-times " DW_AT_ranges" 2 } } */
+/* { dg-final { scan-assembler " DW_AT_ranges" } } */
/* { dg-final { scan-assembler-times "\\(DIE \\(\[^\n\]*\\)
DW_TAG_lexical_block" 0 } } */
static int foo (int i)
[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707 --- Comment #12 from Andrew Pinski --- (In reply to Andrew Pinski from comment #11) > Testing removal of this part from the driver. Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661228.html
[Bug driver/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 --- Comment #19 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661228.html
[Bug preprocessor/116458] [15 regression] New valgrind error in search_line_ssse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #8 from Alexander Monakov ---
Thanks for the reference, but it doesn't help. Something more subtle is going
on, because placing the shift-add combo in a separate function makes Valgrind
properly compute known bits even without the magic flag. Here's a testcase:
__attribute__((noipa))
static int f(short *s)
{
return s[0] + (s[1] << 16);
}
int main()
{
void *p = __builtin_malloc(64);
*(char *)p = 1;
asm("" ::: "memory");
if (!f(p))
__builtin_abort();
}
Compile with gcc -O2 and run under valgrind. Then comment out the attribute,
recompile (gcc will inline the function) and run again — valgrind will complain
==2617== Conditional jump or move depends on uninitialised value(s)
==2617==at 0x10908D: main (t.c:12)
[Bug c++/63287] __STDCPP_THREADS__ is not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287 --- Comment #7 from Alisdair Meredith --- Late comment: according to [intro.multithread.general] it is a requirement for hosted implementations to support more than one thread of execution, but implementation defined for a free-standing implementation. I am not sure if that has a bearing on the affected platforms.
[Bug bootstrap/105474] GCC fails to bootstrap with --disable-libstdcxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105474 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-August/ ||661231.html Keywords||patch --- Comment #6 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661231.html
[Bug other/116464] New: [15 regression] new test gcc.dg/torture/pr116420.c from r15-3095-gc9377734b798d8 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116464 Bug ID: 116464 Summary: [15 regression] new test gcc.dg/torture/pr116420.c from r15-3095-gc9377734b798d8 fails Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:c9377734b798d8d311dfd3a5618dc49407703b93, r15-3095-gc9377734b798d8 make -k check-gcc RUNTESTFLAGS="dg-torture.exp=gcc.dg/torture/pr116420.c" FAIL: gcc.dg/torture/pr116420.c -O0 execution test FAIL: gcc.dg/torture/pr116420.c -O1 execution test FAIL: gcc.dg/torture/pr116420.c -O2 execution test FAIL: gcc.dg/torture/pr116420.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gcc.dg/torture/pr116420.c -O3 -g execution test FAIL: gcc.dg/torture/pr116420.c -Os execution test FAIL: gcc.dg/torture/pr116420.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.dg/torture/pr116420.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test Program received signal SIGABRT, Aborted. __pthread_kill_implementation (threadid=, signo=, no_tid=no_tid@entry=0) at pthread_kill.c:44 44return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0; (gdb) where #0 __pthread_kill_implementation (threadid=, signo=, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x77ca5814 in __pthread_kill_internal (signo=, threadid=) at pthread_kill.c:78 #2 0x77c47f20 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x77c2a574 in __GI_abort () at abort.c:79 #4 0x17b0 in main () at /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr116420.c:15 13for (; e < 1; e++) 14 if (g >= a) 15__builtin_abort(); // line 15 16return 0; commit c9377734b798d8d311dfd3a5618dc49407703b93 (HEAD, origin/master, origin/HEAD) Author: Jeff Law Date: Thu Aug 22 12:48:49 2024 -0600 [PR rtl-optimization/116420] Fix interesting block bitmap DF dataflow * gcc.dg/torture/pr116420.c: New test.
[Bug testsuite/116464] [15 regression] new test gcc.dg/torture/pr116420.c from r15-3095-gc9377734b798d8 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116464 Andrew Pinski changed: What|Removed |Added Keywords||testsuite-fail Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |15.0 Component|other |testsuite Last reconfirmed||2024-08-22 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Simple fix: s/char b /signed char b/
[Bug testsuite/116464] [15 regression] new test gcc.dg/torture/pr116420.c from r15-3095-gc9377734b798d8 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116464 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Andrew Pinski --- Fixed.
[Bug testsuite/116464] [15 regression] new test gcc.dg/torture/pr116420.c from r15-3095-gc9377734b798d8 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116464 --- Comment #2 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:da043f9c7172bcbfda0cdb570fb3a979a4b1a525 commit r15-3096-gda043f9c7172bcbfda0cdb570fb3a979a4b1a525 Author: Andrew Pinski Date: Thu Aug 22 14:50:47 2024 -0700 testsuite: Fix gcc.dg/torture/pr116420.c for targets default unsigned char [PR116464] This is an obvious fix to the gcc.dg/torture/pr116420.c testcase which simplier changes from plain `char` to `signed char` so it works on targets where plain char defaults to unsigned. Pushed as obvious after a quick test for aarch64-linux-gnu to make sure the testcase passes now. PR testsuite/116464 gcc/testsuite/ChangeLog: * gcc.dg/torture/pr116420.c: Signed-off-by: Andrew Pinski
[Bug preprocessor/116458] [15 regression] New valgrind error in search_line_ssse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458 --- Comment #9 from Alexander Monakov --- Okay, if you take the addition and the branch from the inlined variant: addl %eax, %edx je .L3 and add a 'test' instruction: addl %eax, %edx test %edx, %edx je .L3 then Valgrind doesn't complain. So it looks like propagation of known bits is actually powerful enough, but there's a strange weakness in handling of ZF when it is used directly from addition.
[Bug tree-optimization/101139] Unable to remove double byteswap in fast path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101139
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 57993 [details]
> Patch but it does not work for the code in this testcase
>
> I have to look into why it is not working for the testcase in comment #0
> (factor_out_conditional_operation is not even called) but it does work for:
> ```
> short f(int a, short b, short c)
> {
> if (a)
> return __builtin_bswap16(b);
> return __builtin_bswap16(c);
> }
> ```
This patch was committed as r15-2986-gcd2f394418be0c.
[Bug tree-optimization/116463] [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463 --- Comment #5 from Tamar Christina --- Yeah, This is because they generate different gimple sequences and thus different SLP trees. The core of the problem is there's no canonical form here, and a missing gimple simplification rule: _33 = IMAGPART_EXPR <*_3> + ((REALPART_EXPR <*_5> * IMAGPART_EXPR <*_7>) + (IMAGPART_EXPR <*_5> * REALPART_EXPR <*_7>)); vs _37 = IMAGPART_EXPR <*_3> - ((REALPART_EXPR <*_5> * -IMAGPART_EXPR <*_7>) + (IMAGPART_EXPR <*_5> * -REALPART_EXPR <*_7>)); i.e. a - ((b * -c) + (d * -e)) == a + (b * c) + (d * e) So probably in match.pd we should fold _37 into _33 which is a simpler form of the same thing and it's better on scalar as well. It would be better to finally introduce a vectorizer canonical form, for instance the real part generates: _36 = (_31 - _30) + REALPART_EXPR <*_3>; vs _32 = REALPART_EXPR <*_3> + (_26 - _27); and this already is an additional thing to check, so it would be better if slp build always puts complex parts consistently on one side of commutative operations so we don't have to swap operands to check. In any case, I have some patches in this area and can take a look when I'm back, but think the new expression should be simplified back into the old one.
[Bug c/96290] nonsensical bounds in VLA types in -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96290
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment #1 from Gabriel Ravier ---
I've encountered a similarly nonsensical error on trunk, though not with VLAs,
instead with a char array of size 0:
#include
int main(){
puts(((char[0]){}));
}
: In function 'main':
:4:9: warning: 'puts' reading 1 or more bytes from a region of size 0
[-Wstringop-overread]
4 | puts(((char[0]){}));
| ^~~
:4:24: note: source object '' of size 0
4 | puts(((char[0]){}));
|^
ASM generation compiler returned: 0
: In function 'main':
:4:9: warning: 'puts' reading 1 or more bytes from a region of size 0
[-Wstringop-overread]
4 | puts(((char[0]){}));
| ^~~
:4:24: note: source object '' of size 0
4 | puts(((char[0]){}));
|^
[Bug c/116465] New: __builtin_eh_pointer ICEs when passed seemingly any argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116465
Bug ID: 116465
Summary: __builtin_eh_pointer ICEs when passed seemingly any
argument
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void canada(){
__builtin_eh_pointer(0);
}
This crashes GCC with the following error:
during GIMPLE pass: eh
: In function 'canada':
:1:6: internal compiler error: Segmentation fault
1 | void canada(){
| ^~
0x246c635 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1],
diagnostic_t)
???:0
0x247e785 internal_error(char const*, ...)
???:0
0x110541d verify_gimple_in_seq(gimple*, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/116466] New: The standard instruction pattern of RISC-V addv has generated an unnecessary instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116466
Bug ID: 116466
Summary: The standard instruction pattern of RISC-V addv has
generated an unnecessary instruction.
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: leidian900 at outlook dot com
Target Milestone: ---
In riscv.md, the code for the addv4 instruction pattern when handling
TARGET_64BIT and SImode is as follows:
{
rtx t3 = gen_reg_rtx (DImode);
rtx t4 = gen_reg_rtx (DImode);
rtx t5 = gen_reg_rtx (DImode);
rtx t6 = gen_reg_rtx (DImode);
emit_insn (gen_addsi3 (operands[0], operands[1], operands[2]));
if (GET_CODE (operands[1]) != CONST_INT)
emit_insn (gen_extend_insn (t4, operands[1], DImode, SImode, 0));
else
t4 = operands[1];
if (GET_CODE (operands[2]) != CONST_INT)
emit_insn (gen_extend_insn (t5, operands[2], DImode, SImode, 0));
else
t5 = operands[2];
emit_insn (gen_adddi3 (t3, t4, t5));
emit_insn (gen_extend_insn (t6, operands[0], DImode, SImode, 0));
riscv_expand_conditional_branch (operands[3], NE, t6, t3);
}
>From the code, it can be observed that emit_insn(gen_addsi3(operands[0],
operands[1], operands[2])) generates the addw instruction. This instruction
performs an addition operation and sign-extends the lower 32 bits of the result
to 64 bits before writing it to the destination register (operands[0]).
However, emit_insn(gen_extend_insn(t6, operands[0], DImode, SImode, 0))
performs an additional sign-extension on operands[0], resulting in an extra
sext.w extension instruction. The same issue exists with subv4.
[Bug middle-end/116465] __builtin_eh_pointer ICEs when passed seemingly any argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116465 --- Comment #1 from Gabriel Ravier --- (PS: I have no idea what this is caused by, somehow an assignment statement with no left hand side appears to be generated ?)
[Bug middle-end/116465] __builtin_eh_pointer ICEs when passed seemingly any argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116465 --- Comment #2 from Gabriel Ravier --- Looked into it a bit more and the root cause seems to be that gcc/tree-eh.cc:lower_eh_constructs_2, when attempting to handle the case where the user partakes in a little tomfoolery with its builtins (i.e. both __builtin_eh_pointer and __builtin_eh_filter), doesn't handle the case where the result of the builtin isn't assigned to anything (which is acceptable for a GIMPLE call, but not a GIMPLE assignment)
[Bug middle-end/111933] memcpy on Xtensa not optimized when n == sizeof(uint32_t) or sizeof(uint64_t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111933
rsaxvc at gmail dot com changed:
What|Removed |Added
CC||rsaxvc at gmail dot com
--- Comment #3 from rsaxvc at gmail dot com ---
(In reply to Davide Bettio from comment #2)
> ...I was writing a function for reading uint32_t and uint64_t values at any
> address...
I believe memcpy() is the right approach, as dereferencing a misaligned pointer
is unaligned behaviour.
My suspicion is that assuming unalinged access is unsafe is intentional for
ESP32, because some of the internal memories like IRAM require strict
alignment, though most do not. Quoting from
https://blog.espressif.com/esp32-programmers-memory-model-259444d89387 ,
"...IRAM has access limitations in terms of alignment of address and size. If
an unaligned access is made, it results into an exception. The ESP-IDF, after
release 4.2, handles these exceptions transparently to provide load/store as
desired by the caller. As these unaligned accesses result in exception, the
access is slower than the DRAM access. Typically each exception handling
requires approximately 167 CPU cycles (i.e. 0.7 usec per access at 240 MHz or 1
usec per access at 160 MHz)."
It does look like the equivalent 16-bit unaligned load could be faster:
uint16_t from_unaligned_u16(void*p){
uint16_t ret;
memcpy(&ret,p,sizeof(ret));
return ret;
}
readU16: //round-trips through the stack
entry sp, 48
l8uia8, a2, 0
l8uia2, a2, 1
s8i a8, sp, 0
s8i a2, sp, 1
l16ui a2, sp, 0
retw.n
uint32_t from_unaligned_u16_seq(uint8_t *p){
uint32_t p1 = p[1];
uint32_t p0 = p[0];
return p0 | p1 << 8;
}
readU16Seq: //works in registers
entry sp, 32
l8uia8, a2, 1
l8uia2, a2, 0
sllia8, a8, 8
or a2, a8, a2
retw.n
But for the 32-bit version I couldn't get anything shorter than what GCC did.
[Bug c++/113454] [14 regression] "assignment of read-only member" error with 483.xalancbmk from SPEC CPU 2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113454 --- Comment #5 from edison --- Thanks for your reply, could you provide the patch for gcc 14.1?
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #185 from Kazumoto Kojima --- Unfortunately, nothing new showed up in running gcc/g++ testsuite for sh-elf+sim with -mlra. OTOH, the segfault can be reproduced on qemu with the patched stage2 compiler built with -g -O2 -mlra -m4. gdb says that it occurs in the function call wide-int.cc:top_bit_of (a=0x407ff620, len=65792, prec=128) at the statement unsigned HOST_WIDE_INT val = a[len - 1]; which ends up "mov @r2, r3" as in c#173. Looks len=65792 is a wrong value. It seems that at least gcc/pointer-query.cc is miscompiled by the patched stage2 compiler built with -O2 -mlra -m4. Compiling pointer-query.cc with -O0 -mlra instead of -O2 -mlra, __muldi3 is compiled successfully. This compiler segfaults for another files of libgcc, i.e. there are another gcc objects miscompiled with -O2 -mlra. It is not at all clear what is causing the wrong value or code, though. We are still at the starting point of the bugfix.
[Bug target/116467] New: missed optimization: zero-extension duplicated on xtensa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116467
Bug ID: 116467
Summary: missed optimization: zero-extension duplicated on
xtensa
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsaxvc at gmail dot com
Target Milestone: ---
On GCC 12.2.0, -O2 -Wall -Wextra, the following code:
#include
__attribute__ ((noinline)) uint32_t callee(uint32_t x, uint16_t y){
return x + y;
}
__attribute__ ((noinline)) uint32_t caller(uint32_t x, uint32_t y){
return callee(x, y);
}
compiles to these xtensa instructions:
callee:
entry sp, 32
extui a3, a3, 0, 16
add.n a2, a3, a2
retw.n
caller:
entry sp, 32
extui a11, a3, 0, 16
mov.n a10, a2
call8 callee
mov.n a2, a10
retw.n
I was surprised to find that zero-extension (extui rDest, rSource, 0, 16)
occurs twice, once in each function. On other targets like ARM32, it looks like
uint16_t passed in a register is assumed to be passed zero-extended, so the
callee does not need to repeat it. ARM32, GCC12.2, same flags:
callee:
add r0, r0, r1
bx lr
caller:
uxthr1, r1 //similar to extui, .., .., 0, 16
b callee
Could xtensa do the same?
[Bug fortran/116468] New: Segmentation fault at intrinsic assignment to allocatable array component of derived type with kind type parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116468 Bug ID: 116468 Summary: Segmentation fault at intrinsic assignment to allocatable array component of derived type with kind type parameter Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at archaeologic dot codes Target Milestone: --- A program compiled with gfortran terminates with a segmentation fault at an intrinsic assignment to an allocatable array component of a derived type with a kind type parameter. Please see below. I tried several workarounds, including replacing the intrinsic assignment with a type-bound defined assignment, a non-type-bound defined assignment, and a source allocation. I also tried compiling code below with gfortran 12, 13, and 14. The only workaround that eliminates the segmentation fault is switching to source allocation. The code below terminates normally with the NAG and LLVM Flang (Flang-new) compilers. % cat reproducer.f90 implicit none type foo_t(k) integer, kind :: k real(k), allocatable :: bar(:) end type type(foo_t(kind(0.))) foo foo%bar = [0.] end % gfortran reproducer.f90 % ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x102dfad2f #1 0x102df9d83 #2 0x194afa583 #3 0x1027c7f4b zsh: segmentation fault ./a.out % gfortran --version GNU Fortran (Homebrew GCC 14.1.0_2) 14.1.0
[Bug tree-optimization/116461] [15 regression] New test case gcc.dg/vect/vect-mod-var.c from r15-3082-g9bbad3685131ec fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461 Kewen Lin changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED CC||linkw at gcc dot gnu.org Last reconfirmed||2024-08-23 Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org --- Comment #1 from Kewen Lin --- Confirmed, this is a test case issue: When i = 29, a[i] is 19, b[i] is 0, a[i]%b[i] is performing "% 0". vmodsw (Vector Modulo Signed Word) says: If an attempt is made to perform any of the modulo operations ... % 0 then the remainder is undefined. Similarly for scalar side, which adopts divw/mullw/subf, divw has: If an attempt is made to perform any of the divisions ... / 0 then the contents of register RT are undefined. Here we unfortunately gets 0 from vmodsw while 19 from the scalar sequence, so the abortion occurs.
[Bug fortran/116468] Segmentation fault at intrinsic assignment to allocatable array component of derived type with kind type parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116468 Jerry DeLisle changed: What|Removed |Added Last reconfirmed||2024-08-23 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jerry DeLisle --- Confirmed on latest trunk. $ gfc -g pr116468.f90 $ ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f066e64fcff in ??? #1 0x401173 in MAIN__ at /home/jerry/dev/test/pr116468/pr116468.f90:10 #2 0x4011b4 in main at /home/jerry/dev/test/pr116468/pr116468.f90:11 Segmentation fault (core dumped)
[Bug c/96290] nonsensical bounds in VLA types in -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96290 --- Comment #2 from Andrew Pinski --- (In reply to Gabriel Ravier from comment #1) > I've encountered a similarly nonsensical error on trunk, though not with > VLAs, instead with a char array of size 0: It is not nonsensical at all. It just has an anonymous name for the object which is different from the original issue of an anonynous name for the bounds.
