[Bug preprocessor/101168] gnu++14 complains about altivec types defined with using keyword in the same file with preprocessor macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101168 --- Comment #4 from Andrew Pinski --- Note I noticed s390 has the similar issue, see PR 95782 .
[Bug c++/79371] ICE on valid C++14 code on x86_64-linux-gnu: in build_class_member_access_expr, at cp/typeck.c:2296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79371 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to work||14.0 Known to fail||7.1.0 --- Comment #2 from Andrew Pinski --- Looks to be fixed on the trunk.
[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #1 from Jiang An --- Constructors of the following types seemly need to be changed: basic_istream_view::_Iterator filter_view::_Iterator filter_view::_Sentinel transform_view::_Iterator join_view::_Sentinel lazy_split_view::_OuterIter split_view::_Iterator split_view::_Sentinel Currently libstdc++'s versions take pointers to the base views, while the standard requires to take references.
[Bug tree-optimization/114027] [11/12 Regression] miscompile at `-O3 -fno-vect-cost-model -msse4.2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
chenglulu changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
--- Comment #17 from chenglulu ---
(In reply to Richard Biener from comment #14)
> int __attribute__((noipa))
> foo (int *f, int n)
> {
> int res = 0;
> for (int i = 0; i < n; ++i)
> {
> if (f[2*i])
> res = 2;
> if (f[2*i+1])
> res = -2;
Sorry I have a problem, the array f has 16 elements, the value of n is 16, when
the value of i is greater than 7, isn't it out of bounds to access f[2*i] and
f[2*i+1]?
[Bug c++/86862] Segfault using extern template on class deriving from streambuf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86862
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
```
namespace std {
template struct char_traits {};
}
template class Traits>
struct b { virtual ~b(); };
template
struct d : public b {};
extern template class d;
```
Note `std::char_traits` needs to be exactly that; otherwise the ICE does not
show up.
[Bug c++/96396] initializer_list in `-fconcepts -std=c++11` reports internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96396 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #3 from Andrew Pinski --- Seems fixed in GCC 13+
[Bug c++/70037] [concepts] comdat group error and an ICE with a conceptified tuple implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70037 --- Comment #6 from Andrew Pinski --- I suspect this is a dup of another bug too where the ABI for constraints just was defined ...
[Bug bootstrap/100175] ICE in cp_parser_lookup_name, at cp/parser.c:28265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100175 Andrew Pinski changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #5 from Andrew Pinski --- Using `--disable-bootstrap` is almost never a decent thing to do unless you are doing developing. Anyways nobody else has run into this for the last 3 years so closing as works for me.
[Bug tree-optimization/114471] [14 regression] ICE when building liblc3-1.0.4 with -fno-vect-cost-model -march=x86-64-v4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Richard Biener --- Mine.
[Bug c++/80679] call of overloaded is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80679 Andrew Pinski changed: What|Removed |Added Keywords||ice-checking --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > The trunk ICEs. But that is just checking turned on. Here is the ICE: ``` :12:9: internal compiler error: in comptypes, at cp/typeck.cc:1684 12 | Call(Method(), int()); | ^ 0x266c94c internal_error(char const*, ...) ???:0 0xa57369 fancy_abort(char const*, int, char const*) ???:0 0xcb492f more_specialized_fn(tree_node*, tree_node*, int) ???:0 0xa860c9 build_new_function_call(tree_node*, vec**, int) ???:0 ```
[Bug analyzer/114472] [14 Regression] ICE: in falls_short_of_p, at analyzer/store.cc:365 (in exceeds_p, at analyzer/store.cc:342) with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114472 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug analyzer/114473] [13/14 Regression] ICE: in deref_rvalue, at analyzer/region-model.cc:2780 with -fanalyzer -fanalyzer-call-summaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114473 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.3 Priority|P1 |P2
[Bug target/39787] ICE with #pragma GCC target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39787 Andrew Pinski changed: What|Removed |Added Known to work||14.0 --- Comment #5 from Andrew Pinski --- Looks fully fixed on the trunk, in that we no longer get a warning about the return type of _mm256_andnot_pd while compiling avx_routine . and _mm_andnot_pd is rejected from being inlined from sse3_routine.
[Bug fortran/114475] [14 Regression] Regression with iso_c_binding and submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Summary|[14.0 Regression] |[14 Regression] Regression |Regression with |with iso_c_binding and |iso_c_binding and |submodules |submodules | Target Milestone|--- |14.0
[Bug tree-optimization/114476] [13/14 Regression] wrong code with -fwrapv -O3 -fno-vector-cost-mode (and -march=armv9-a+sve2 on aarch64 and -march=rv64gcv on riscv)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114476 Richard Biener changed: What|Removed |Added Target Milestone|14.0|13.3 Priority|P3 |P2
[Bug c++/79786] [11/12/13/14 Regression] ICE tree check: expected class 'type', have 'declaration' (var_decl) in iamcu_alignment, at config/i386/i386.c:30263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79786 Andrew Pinski changed: What|Removed |Added Summary|ICE tree check: expected|[11/12/13/14 Regression] |class 'type', have |ICE tree check: expected |'declaration' (var_decl) in |class 'type', have |iamcu_alignment, at |'declaration' (var_decl) in |config/i386/i386.c:30263|iamcu_alignment, at ||config/i386/i386.c:30263 Target Milestone|--- |11.5 CC||hubicka at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > Note the bug was introduced at r5-869. So techincally this is a regression.
[Bug c++/96396] initializer_list in `-fconcepts -std=c++11` reports internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96396 Jonathan Wakely changed: What|Removed |Added Keywords|needs-bisection | --- Comment #4 from Jonathan Wakely --- Fixed by r13-3639 c++: change -fconcepts to mean C++20 concepts It was always weird that -fconcepts in C++17 mode meant the same thing as -fconcepts-ts in C++20 mode; this patch harmonizes the flags so that for TS concepts you always need to write -fconcepts-ts. In the unlikely event anyone is still using -fconcepts in C++17 mode, they can either fix their code to work with C++20 concepts or adjust the compiler flag. It still ICEs with -fconcepts-ts -std=c++11 But I'm not surprised that combination doesn't work, the Concepts TS is supposed to be used with C++17.
[Bug c++/86862] Segfault using extern template on class deriving from streambuf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86862
--- Comment #3 from Andrew Pinski ---
Note here is the backtrace:
```
t.cc: In instantiation of ‘class std::base’:
t.cc:6:7: required from ‘class std::derived’
6 | class derived : public base {};
| ^~~
t.cc:7:23: required from here
7 | extern template class derived;
| ^
t.cc:4:7: internal compiler error: Segmentation fault
4 | class base { virtual ~base(); };
| ^~~~
0x1341fcf crash_signal
/home/apinski/src/upstream-gcc-match/gcc/gcc/toplev.cc:319
0xb5fa80 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree.h:3619
0xb5fa80 is_std_substitution_char
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/mangle.cc:570
0xb6a384 find_substitution
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/mangle.cc:684
0xb670ee write_type
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/mangle.cc:2400
0xb6949f mangle_special_for_type
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/mangle.cc:4581
0xa6b6f5 get_vtable_name
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/class.cc:794
0xa6b6f5 get_vtable_decl(tree_node*, int)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/class.cc:877
0xa7e40f modify_all_vtables
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/class.cc:3112
0xa7e40f finish_struct_1(tree_node*)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/class.cc:7839
0xc8b266 instantiate_class_template(tree_node*)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/pt.cc:12683
0xcdf890 complete_type(tree_node*)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/typeck.cc:138
0xcdfb2d complete_type_or_maybe_complain(tree_node*, tree_node*, int)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/typeck.cc:151
0xcdfb2d complete_type_or_else(tree_node*, tree_node*)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/typeck.cc:169
0xb1049e xref_basetypes(tree_node*, tree_node*)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/decl.cc:16713
0xc8aeed instantiate_class_template(tree_node*)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/pt.cc:12396
0xcdf890 complete_type(tree_node*)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/typeck.cc:138
0xc7f5ea do_type_instantiation(tree_node*, tree_node*, int)
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/pt.cc:26470
0xc28075 cp_parser_explicit_instantiation
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/parser.cc:19828
0xc2bf00 cp_parser_declaration
/home/apinski/src/upstream-gcc-match/gcc/gcc/cp/parser.cc:15539
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477 Jonathan Wakely changed: What|Removed |Added Priority|P3 |P4 --- Comment #2 from Jonathan Wakely --- (In reply to 康桓瑋 from comment #0) > auto begin = decltype(filter.begin())(filter, base.begin()); // should ok I have very little motivation to "fix" this. Nobody should be writing code like that anyway.
[Bug tree-optimization/114464] [14 regression] ICE when building tdscpp-20240212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114464 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Richard Biener --- Mine.
[Bug tree-optimization/114027] [11/12 Regression] miscompile at `-O3 -fno-vect-cost-model -msse4.2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027 --- Comment #18 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4470611e20f3217ee81647b01fda65b6a62229aa commit r14-9662-g4470611e20f3217ee81647b01fda65b6a62229aa Author: Richard Biener Date: Tue Mar 26 09:46:06 2024 +0100 tree-optimization/114027 - fix testcase The following fixes out-of-bounds read in the testcase. PR tree-optimization/114027 * gcc.dg/vect/pr114027.c: Fix iteration count.
[Bug tree-optimization/114027] [11/12 Regression] miscompile at `-O3 -fno-vect-cost-model -msse4.2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027 --- Comment #19 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:66090b8f438daff7b529f9adae0d6d5be7aa2a1f commit r13-8497-g66090b8f438daff7b529f9adae0d6d5be7aa2a1f Author: Richard Biener Date: Tue Mar 26 09:46:06 2024 +0100 tree-optimization/114027 - fix testcase The following fixes out-of-bounds read in the testcase. PR tree-optimization/114027 * gcc.dg/vect/pr114027.c: Fix iteration count. (cherry picked from commit 4470611e20f3217ee81647b01fda65b6a62229aa)
[Bug tree-optimization/114027] [11/12 Regression] miscompile at `-O3 -fno-vect-cost-model -msse4.2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027 --- Comment #20 from Richard Biener --- Thanks for reporting.
[Bug c++/112724] C++ "'excess_precision_expr' not supported by dump_expr"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112724 --- Comment #4 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:10accfde57951db9f726e996f1b0be165df00f5c commit r14-9663-g10accfde57951db9f726e996f1b0be165df00f5c Author: Jakub Jelinek Date: Tue Mar 26 10:03:27 2024 +0100 c-family, c++: Handle EXCESS_PRECISION_EXPR in pretty printers [PR112724] I've noticed that the c-c++-common/gomp/depobj-3.c test FAILs on i686-linux: PASS: c-c++-common/gomp/depobj-3.c -std=c++17 at line 17 (test for warnings, line 15) FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 at line 39 (test for warnings, line 37) PASS: c-c++-common/gomp/depobj-3.c -std=c++17 at line 43 (test for errors, line 41) PASS: c-c++-common/gomp/depobj-3.c -std=c++17 (test for warnings, line 45) FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 (test for excess errors) Excess errors: /home/jakub/src/gcc/gcc/testsuite/c-c++-common/gomp/depobj-3.c:37:38: warning: the 'destroy' expression ''excess_precision_expr' not supported by dump_expr' should +be the same as the 'depobj' argument 'obj' [-Wopenmp] The following patch replaces that 'excess_precision_expr' not supported by dump_expr with (float)(((long double)a) + (long double)5) Still ugly and doesn't actually fix the FAIL (will deal with that incrementally), but at least valid C/C++ and shows the excess precision handling in action. 2024-03-26 Jakub Jelinek PR c++/112724 gcc/c-family/ * c-pretty-print.cc (pp_c_cast_expression, c_pretty_printer::expression): Handle EXCESS_PRECISION_EXPR like NOP_EXPR. gcc/cp/ * error.cc (dump_expr): Handle EXCESS_PRECISION_EXPR like NOP_EXPR.
[Bug c++/114439] [14 Regression] icu4c-73.2 build failure: invalid initializer for array member with initialization of array of struct containing arrays since r14-9622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439 --- Comment #6 from Sergei Trofimovich --- The change also fixed full icu4c-73.2 build for me. Thank you!
[Bug c++/112724] C++ "'excess_precision_expr' not supported by dump_expr"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112724 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/114464] [14 regression] ICE when building tdscpp-20240212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114464 --- Comment #8 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:226a220d0056396e825e12435cc0da52cbd5ac56 commit r14-9665-g226a220d0056396e825e12435cc0da52cbd5ac56 Author: Richard Biener Date: Tue Mar 26 09:39:30 2024 +0100 tree-optimization/114464 - verify types in recurrence vectorization The following adds missing verification of vector type compatibility to recurrence vectorization. PR tree-optimization/114464 * tree-vect-loop.cc (vectorizable_recurr): Verify the latch vector type is compatible with what we chose for the recurrence. * g++.dg/vect/pr114464.cc: New testcase.
[Bug tree-optimization/114464] [14 regression] ICE when building tdscpp-20240212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114464 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed (but possibly latent in GCC 13).
[Bug tree-optimization/114471] [14 regression] ICE when building liblc3-1.0.4 with -fno-vect-cost-model -march=x86-64-v4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471 --- Comment #8 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f4e92d62dccb96ade753f3a8f49be1b5f61c31f1 commit r14-9666-gf4e92d62dccb96ade753f3a8f49be1b5f61c31f1 Author: Richard Biener Date: Tue Mar 26 09:11:00 2024 +0100 tree-optimization/114471 - ICE with mismatching vector types The following fixes too lax verification of vector type compatibility in vectorizable_operation. When we only have a single vector size then comparing the number of elements is enough but with SLP we mix those and thus for operations like BIT_AND_EXPR we need to verify compatible element types as well. Allow sign changes for ABSU_EXPR though. PR tree-optimization/114471 * tree-vect-stmts.cc (vectorizable_operation): Verify operand types are compatible with the result type. * gcc.dg/vect/pr114471.c: New testcase.
[Bug tree-optimization/114471] [14 regression] ICE when building liblc3-1.0.4 with -fno-vect-cost-model -march=x86-64-v4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Richard Biener --- Fixed, possibly latent. Note this didn't fix the vector types chosen (bool patterns ...) but instead hardens against choices that don't work out. A missed-optimization bug might be filed (ISTR there are some around bool patterns already).
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #18 from Richard Biener --- Just as hint we've had wrong upper bounds on vectorized loops/epilogues which would trigger wrong unrolling. But then unrolling also always hints as eventually having wrong range-info.
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #30 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:471967ab8b4c49338ba77defbe24b06cc51c0093 commit r14-9667-g471967ab8b4c49338ba77defbe24b06cc51c0093 Author: Jakub Jelinek Date: Tue Mar 26 11:06:15 2024 +0100 tsan: Don't instrument non-generic AS accesses [PR111736] Similar to the asan and ubsan changes, we shouldn't instrument non-generic address space accesses with tsan, because we just have library functions which take address of the objects as generic address space pointers, so they can't handle anything else. 2024-03-26 Jakub Jelinek PR sanitizer/111736 * tsan.cc (instrument_expr): Punt on non-generic address space accesses. * gcc.dg/tsan/pr111736.c: New test.
[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51 --- Comment #15 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c4f2c84e8fa369856aee76679590eb613724bfb0 commit r14-9668-gc4f2c84e8fa369856aee76679590eb613724bfb0 Author: Jakub Jelinek Date: Tue Mar 26 11:21:38 2024 +0100 fold-const: Punt on MULT_EXPR in extract_muldiv MIN/MAX_EXPR case [PR51] As I've tried to explain in the comments, the extract_muldiv_1 MIN/MAX_EXPR optimization is wrong for code == MULT_EXPR. If the multiplication is done in unsigned type or in signed type with -fwrapv, it is fairly obvious that max (a, b) * c in many cases isn't equivalent to max (a * c, b * c) (or min if c is negative) due to overflows, but even for signed with undefined overflow, the optimization could turn something without UB in it (where say a * c invokes UB, but max (or min) picks the other operand where b * c doesn't). As for division/modulo, I think it is in most cases safe, except if the problematic INT_MIN / -1 case could be triggered, but we can just punt for MAX_EXPR because for MIN_EXPR if one operand is INT_MIN, we'd pick that operand already. It is just for completeness, match.pd already has an optimization which turns x / -1 into -x, so the division by zero is mostly theoretical. That is also why in the testcase the i case isn't actually miscompiled without the patch, while the c and f cases are. 2024-03-26 Jakub Jelinek PR middle-end/51 * fold-const.cc (extract_muldiv_1) : Punt for MULT_EXPR altogether, or for MAX_EXPR if c is -1. * gcc.c-torture/execute/pr51.c: New test.
[Bug middle-end/111151] [12/13 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14 Regression] Wrong |[12/13 Regression] Wrong |code at -O0 on |code at -O0 on |x86_64-pc-linux-gnu |x86_64-pc-linux-gnu Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- Should be fixed on the trunk so far.
[Bug tree-optimization/112303] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_flow_info failed since r14-3459-g0c78240fd7d519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303 --- Comment #10 from Richard Biener --- Looks like so, can you test that? I think !(bb->count >= new_count) is good, we're using this kind of compare regularly.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #21 from Richard Biener --- Honza, can you please have a look here?
[Bug tree-optimization/112303] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_flow_info failed since r14-3459-g0c78240fd7d519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303 --- Comment #11 from Jakub Jelinek --- (In reply to Richard Biener from comment #10) > Looks like so, can you test that? I think !(bb->count >= new_count) is good, > we're using this kind of compare regularly. Sure, I'll test that.
[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Richard Biener --- Honza is working on this.
[Bug ipa/113359] [13/14 Regression] LTO miscompilation of ceph on aarch64 and x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #21 from Richard Biener --- Martin, please work on this together with Honza (might be an actual duplicate).
[Bug rtl-optimization/113390] [14 Regression] ICE: in model_update_limit_points_in_group, at haifa-sched.cc:1986 with -O2 --param=max-sched-region-insns=200 --param=max-sched-extend-regions-iters=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113390 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Priority|P1 |P2 --- Comment #5 from Richard Biener --- P2, mostly because it's an uncovered latent issue and because it needs two --param specifiers and plus we didn't hit this in real-world code. Now, Richard Sandiford wrote the function we ICE in, so he might know what's going on here.
[Bug modula2/114478] New: isnormal builtin unavailable from m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114478 Bug ID: 114478 Summary: isnormal builtin unavailable from m2 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- As reported in a document the isnormal builtin is currently unavailable for modula2.
[Bug modula2/114478] isnormal builtin unavailable from m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114478 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-03-26 Ever confirmed|0 |1 --- Comment #1 from Gaius Mulley --- Confirmed and it appears that the comparison builtins are also unavailable.
[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 Richard Biener changed: What|Removed |Added Known to work||13.2.1 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-03-26 --- Comment #7 from Richard Biener --- Confirmed btw., works with checking-enabled GCC 13.
[Bug gcov-profile/113765] [14 Regression] ICE: autofdo: val-profiler-threads-1.c compilation, error: probability of edge from entry block not initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765 --- Comment #5 from Richard Biener --- Can somebody prepare a patch along this line?
[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 --- Comment #8 from Richard Biener --- With release checking we ICE with t.c: In function 'main': t.c:46:11: internal compiler error: Segmentation fault 46 | #pragma omp target data map(S1.p[:N],S1.p,S1.a,S1.b) | ^~~ 0xd320af crash_signal /home/rguenther/src/trunk/gcc/toplev.cc:319 0xa3b5b0 omp_gather_mapping_groups_1 /home/rguenther/src/trunk/gcc/gimplify.cc:9593 0xa3b769 omp_gather_mapping_groups /home/rguenther/src/trunk/gcc/gimplify.cc:9621
[Bug tree-optimization/114057] [14 Regression] 435.gromacs fails verification with -Ofast -march={znver2,znver4} and PGO after r14-7272-g57f611604e8bab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #7 from Richard Biener --- I guess that bisecting with -fno-vect-cost-model might reveal the actual offender. (if it doesn't turn up other problems, of course)
[Bug c++/114479] New: std::is_array_v changed from false to true in GCC 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479 Bug ID: 114479 Summary: std::is_array_v changed from false to true in GCC 14 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nikolasklauser at berlin dot de Target Milestone: --- ``` #include static_assert(!std::is_array_v); ``` works with GCC 13, but GCC 14 fails to compile. This is most likely caused by the use of the new `__is_array` builtin. It probably has the same bug as Clang (https://github.com/llvm/llvm-project/issues/54705).
[Bug tree-optimization/114057] [14 Regression] 435.gromacs fails verification with -Ofast -march={znver2,znver4} and PGO after r14-7272-g57f611604e8bab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-26 Status|UNCONFIRMED |NEW --- Comment #8 from Richard Biener --- Confirmed on Zen2 btw. I'm going to have a closer look here.
[Bug c++/110730] STL internal allocation/deallocation might lead to core dump in the use of header units of the modules feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110730 --- Comment #5 from Shuangcheng Ni --- Thanks for the bug fix. TBH it is hard to pinpoint the issue, as the code triggers a runtime error rather than a linkage error.
[Bug c++/114480] New: g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480 Bug ID: 114480 Summary: g++: internal compiler error: Segmentation fault signal terminated program cc1plus Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: douglas.boffey at gmail dot com Target Milestone: --- Received a Segmentation fault compiling the attached.
[Bug c++/114479] [14 Regression] std::is_array_v changed from false to true in GCC 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Summary|std::is_array_v |[14 Regression] |changed from false to true |std::is_array_v |in GCC 14 |changed from false to true ||in GCC 14 Target Milestone|--- |14.0
[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480 --- Comment #1 from Douglas Boffey --- Unable to add attachment.
[Bug c++/114479] [14 Regression] std::is_array_v changed from false to true in GCC 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479 Jonathan Wakely changed: What|Removed |Added CC||kmatsui at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-26 --- Comment #1 from Jonathan Wakely --- Ha, this again. I first observed this in Feb 2022, before GCC's new behaviour. The MSVC behaviour was because their compiler intercepts the std::is_array trait and replaces it with a call to their __is_array intrinsic, which does exactly what clang and gcc's __is_array does. GCC should fix it too.
[Bug tree-optimization/112303] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_flow_info failed since r14-3459-g0c78240fd7d519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303 --- Comment #12 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #11) > (In reply to Richard Biener from comment #10) > > Looks like so, can you test that? I think !(bb->count >= new_count) is > > good, > > we're using this kind of compare regularly. > > Sure, I'll test that. Actually no, that doesn't help, nor the IMO better if (!new_count.initialized_p () || bb->count < new_count) new_count = bb->count; because if say bb->count is not initialized but e->count is, we don't want to overwrite it. The thing is that new_count is actually not used unless e is non-NULL. The actual problem is different, bb->count of one of the duplicated blocks is initialized to the largest possible unitialized m_val (0x3ffe aka 2305843009213693950 (estimated locally, freq 144115188075855872.) ) and then scaled to uninitialized. This is because in the second duplicate_loop_body_to_header_edge on the testcase (with the #c9 patch to reproduce it even on the trunk) we have (gdb) p count_le.debug () 1729382256910270463 (estimated locally, freq 108086391056891904.) (gdb) p count_out_orig.debug () 576460752303423488 (estimated locally, freq 36028797018963968.) but 1264 profile_count new_count_le = count_le + count_out_orig; is (gdb) p new_count_le.debug () uninitialized because 0x17ff + 0x800 yields the largest possible value. If profile_count wants to use the 0x1fff value as unitialized, shouldn't it perform saturating arithmetics such that the counts will be never larger than 0x1ffe unless it is really meant to be uninitialized? I mean in all those spots like operator+ which just m_val + other.m_val and similar without checking for overflow? What about apply_scale etc.? Honza?
[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480 --- Comment #2 from Andrew Pinski --- (In reply to Douglas Boffey from comment #1) > Unable to add attachment. try compressing it first.
[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-03-26 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING
[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480 Douglas Boffey changed: What|Removed |Added CC||douglas.boffey at gmail dot com --- Comment #3 from Douglas Boffey --- Created attachment 57815 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57815&action=edit Zipped preprocessed file
[Bug target/114481] New: [14 Regression] 14% exec time slowdown of 433.milc on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114481 Bug ID: 114481 Summary: [14 Regression] 14% exec time slowdown of 433.milc on aarch64 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization, needs-bisection Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: aarch64-gnu-linux Target: aarch64-gnu-linux As seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=686.70.0 between the commits g:8b483cd5521de79c g:81ee1298b47d3f3b there was an 14% runtime slowdown of 433.milc on aarch64. The CPU is Ampere Altra Neoverse N1. The compilation options were -O2 -flto PGO. --- Btw here is a plot that also includes GCC13 and GCC12. https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=686.70.0&plot.4=749.70.0&plot.5=869.70.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/114481] [14 Regression] 14% exec time slowdown of 433.milc on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114481 Filip Kastl changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/114057] [14 Regression] 435.gromacs fails verification with -Ofast -march={znver2,znver4} and PGO after r14-7272-g57f611604e8bab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057 --- Comment #9 from Richard Biener --- Interestingly r14-7272-g57f611604e8bab causes quite some BB vectorization cases to be rejected - I would have expected it to only get us more vectorization? -innerf.f:277:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:281:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:284:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:323:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:327:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:330:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:630:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:634:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:637:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:679:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:683:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:686:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:1283:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:1287:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:1290:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:1354:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:1358:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:1361:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:2004:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:2008:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:2011:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:2082:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:2086:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:2089:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:2365:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:2369:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:2372:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:3347:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:3351:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:3354:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:3390:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:3394:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:3397:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:3434:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:3438:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:3441:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:4477:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:4481:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:4484:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:4520:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:4524:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:4527:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:4567:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:4571:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:4574:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:5702:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:5706:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:5709:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:5745:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:5749:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:5752:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:5815:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:5819:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:5822:72: optimized: basic block part vectorized using 8 byte vectors +innerf.f:6114:72: optimized: basic block part vectorized using 8 byte vectors +innerf.f:6118:72: optimized: basic block part vectorized using 32 byte vectors +innerf.f:6127:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:7050:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:7054:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:7057:72: optimized: basic block part vectorized using 8 byte vectors -innerf.f:7093:72:
[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING |UNCONFIRMED
Keywords||compile-time-hog,
||memory-hog
--- Comment #4 from Andrew Pinski ---
Hmm, this file contains a huge initialization like:
{{0, 1, 2, 3, 4}, {0, 24}, {fpToT, f, fpHoT, foT}},
repeated in a similar pattern a lot ...
[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480 --- Comment #5 from Andrew Pinski --- remove_unreachable_eh_regions_worker has a deep recusive which could cause issues on host with limited stack space.
[Bug middle-end/114482] New: remove_unreachable_eh_regions could use a work queue instead of being recusive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114482 Bug ID: 114482 Summary: remove_unreachable_eh_regions could use a work queue instead of being recusive Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Noticed while looking PR 114480, remove_unreachable_eh_regions uses remove_unreachable_eh_regions_worker which does a huge recusive work but maybe we should remove this recusiveness behavior, especially if the number of regions is huge.
[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480 --- Comment #6 from Andrew Pinski --- Just to check what options are you using passing to gcc?
[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480 --- Comment #7 from Andrew Pinski --- the code does compile for x86_64-linux-gnu on the trunk (though very slowly).
[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480 --- Comment #8 from Douglas Boffey --- (In reply to Andrew Pinski from comment #6) > Just to check what options are you using passing to gcc? Using the default options: g++ -o test-poly a-test-poly.ii
[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480 --- Comment #9 from Jonathan Wakely --- It compiles OK with GCC 11.4.0 on x86_64-pc-linux-gnu, it just takes a very long time. I think you probably just ran out of memory or stack space. -ftime-report shows: Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 1562k ( 0%) phase parsing : 1.85 ( 1%) 0.84 ( 44%) 2.69 ( 1%) 231M ( 20%) phase lang. deferred : 0.44 ( 0%) 0.09 ( 5%) 0.54 ( 0%) 46M ( 4%) phase opt and generate : 238.73 ( 99%) 0.96 ( 51%) 240.34 ( 99%) 852M ( 75%) |name lookup : 0.24 ( 0%) 0.07 ( 4%) 0.24 ( 0%) 2189k ( 0%) |overload resolution : 0.97 ( 0%) 0.20 ( 11%) 1.25 ( 1%) 151M ( 13%) garbage collection : 0.33 ( 0%) 0.01 ( 1%) 0.34 ( 0%) 0 ( 0%) dump files : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) callgraph construction : 0.20 ( 0%) 0.01 ( 1%) 0.20 ( 0%) 45M ( 4%) callgraph optimization : 0.07 ( 0%) 0.00 ( 0%) 0.07 ( 0%) 0 ( 0%) callgraph ipa passes : 1.50 ( 1%) 0.36 ( 19%) 1.87 ( 1%) 103M ( 9%) ipa dead code removal : 0.02 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) ipa inlining heuristics: 0.05 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 ( 0%) cfg construction : 0.03 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 3959k ( 0%) cfg cleanup: 0.17 ( 0%) 0.00 ( 0%) 0.17 ( 0%) 928 ( 0%) trivially dead code: 0.16 ( 0%) 0.00 ( 0%) 0.17 ( 0%) 0 ( 0%) df scan insns : 0.57 ( 0%) 0.15 ( 8%) 0.73 ( 0%) 14k ( 0%) df live regs : 0.41 ( 0%) 0.04 ( 2%) 0.47 ( 0%) 0 ( 0%) df reg dead/unused notes : 0.50 ( 0%) 0.00 ( 0%) 0.50 ( 0%) 31M ( 3%) register information : 1.55 ( 1%) 0.00 ( 0%) 1.55 ( 1%) 0 ( 0%) alias analysis : 0.08 ( 0%) 0.01 ( 1%) 0.09 ( 0%) 10M ( 1%) alias stmt walking : 0.02 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 36k ( 0%) rebuild jump labels: 0.11 ( 0%) 0.00 ( 0%) 0.11 ( 0%) 0 ( 0%) preprocessing : 0.23 ( 0%) 0.20 ( 11%) 0.40 ( 0%) 1219k ( 0%) parser (global): 1.42 ( 1%) 0.52 ( 28%) 1.91 ( 1%) 213M ( 19%) parser struct body : 0.06 ( 0%) 0.02 ( 1%) 0.08 ( 0%) 8434k ( 1%) parser enumerator list : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 51k ( 0%) parser function body : 0.07 ( 0%) 0.04 ( 2%) 0.06 ( 0%) 3008k ( 0%) parser inl. func. body : 0.03 ( 0%) 0.02 ( 1%) 0.02 ( 0%) 2894k ( 0%) parser inl. meth. body : 0.06 ( 0%) 0.01 ( 1%) 0.04 ( 0%) 4000k ( 0%) template instantiation : 0.17 ( 0%) 0.07 ( 4%) 0.28 ( 0%) 21M ( 2%) constant expression evaluation : 0.25 ( 0%) 0.04 ( 2%) 0.39 ( 0%) 17M ( 2%) inline parameters : 0.16 ( 0%) 0.00 ( 0%) 0.17 ( 0%) 8247k ( 1%) tree gimplify : 0.95 ( 0%) 0.03 ( 2%) 0.99 ( 0%) 83M ( 7%) tree eh: 8.63 ( 4%) 0.04 ( 2%) 8.67 ( 4%) 86M ( 8%) tree CFG construction : 0.08 ( 0%) 0.00 ( 0%) 0.07 ( 0%) 31M ( 3%) tree CFG cleanup : 0.14 ( 0%) 0.00 ( 0%) 0.14 ( 0%) 720 ( 0%) tree PHI insertion : 0.50 ( 0%) 0.00 ( 0%) 0.50 ( 0%) 7901k ( 1%) tree SSA rewrite : 0.10 ( 0%) 0.00 ( 0%) 0.11 ( 0%) 40M ( 4%) tree SSA other : 0.21 ( 0%) 0.15 ( 8%) 0.31 ( 0%) 45k ( 0%) tree SSA incremental : 0.08 ( 0%) 0.00 ( 0%) 0.07 ( 0%) 0 ( 0%) tree operand scan : 0.32 ( 0%) 0.19 ( 10%) 0.55 ( 0%) 18M ( 2%) dominance frontiers: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) dominance computation : 0.14 ( 0%) 0.00 ( 0%) 0.16 ( 0%) 0 ( 0%) out of ssa : 0.06 ( 0%) 0.00 ( 0%) 0.08 ( 0%) 1057k ( 0%) expand vars: 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 10M ( 1%) expand : 0.64 ( 0%) 0.08 ( 4%) 0.73 ( 0%) 226M ( 20%) post expand cleanups : 0.11 ( 0%) 0.00 ( 0%) 0.10 ( 0%) 16M ( 1%) varconst : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 9184 ( 0%) loop init
[Bug tree-optimization/114476] [13/14 Regression] wrong code with -fwrapv -O3 -fno-vector-cost-mode (and -march=armv9-a+sve2 on aarch64 and -march=rv64gcv on riscv)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114476 --- Comment #5 from Robin Dapp --- So the result is -9 instead of 9 (or vice versa) and this happens (just) with vectorization. We only vectorize with -fwrapv. >From a first quick look, the following is what we have before vect: (loop) [local count: 991171080]: ... # b_lsm.5_5 = PHI <_4(7), b_lsm.5_17(2)> ... _4 = -b_lsm.5_5; (check) [local count: 82570744]: ... # b_lsm.5_22 = PHI ... if (b_lsm.5_22 != -9) I.e. b gets negated with every iteration and we check the second to last against -9. With vectorization we have: (init) [local count: 82570744]: b_lsm.5_17 = b; (vectorized loop) [local count: 247712231]: ... # b_lsm.5_5 = PHI <_4(7), b_lsm.5_17(2)> ... _4 = -b_lsm.5_5; ... goto (epilogue) [local count: 82570741]: ... # b_lsm.5_7 = PHI <_25(11), b_lsm.5_17(13)> ... _25 = -b_lsm.5_7; (check) [local count: 82570744]: ... # b_lsm.5_22 = PHI if (b_lsm.5_22 != -9) What looks odd here is that b_lsm.5_7's fallthrough argument is b_lsm.5_17 even though we must have come through the vectorized loop (which negated b at least once). This makes us skip inversions. Indeed, as b_lsm.5_22 is only dependent on the initial value of b it gets optimized away and we compare b != -9. Maybe I missed something but it looks like # b_lsm.5_7 = PHI <_25(11), b_lsm.5_17(13)> should have b_lsm.5_5 or _4 as fallthrough argument.
[Bug gcov-profile/113765] [14 Regression] ICE: autofdo: val-profiler-threads-1.c compilation, error: probability of edge from entry block not initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765 --- Comment #6 from Jan Hubicka --- Running auto-fdo without guessing branch probabilities is somewhat odd idea in general. I suppose we can indeed just avoid setting full_profile flag. Though the optimization passes are not that much tested to work with non-full profiles so there is some risk that resulting code will be worse than without auto-FDO.
[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97600 CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- FWIW these ctors were originally changed to take view* instead of view& with r11-4584 to work around the unstable satisfaction issue PR97600#c1, and then with r11-5954 we implemented an optimization in the frontend to avoid considering non-class conversion operators when computing a conversion to a class type (IIRC), which made the workaround redundant. So I guess we can remove this workaround and make these ctors take view& again. But I don't feel totally confident that there isn't an IFNDR issue in this standard formulation that only GCC was able to detect (before the optimization)...
[Bug c++/112624] Internal compiler error when compiling a module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112624 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org --- Comment #1 from Nathaniel Shead --- I haven't been able to reproduce this; it looks like some of the C++ standard library headers were compiled as importable modules (hence the preprocessed file including translated 'import' declarations), but apart from and I'm not sure which other headers have been compiled as such and in which order. (It's worth noting that only mod_impl.cpp is relevant here, mod.cxx would not be used in causing the ICE.)
[Bug target/104817] mips: ICE in mips_output_move, at config/mips/mips.cc:5323 with -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #4 from qinzhao at gcc dot gnu.org --- (In reply to Xi Ruoyao from comment #3) > Hi Qing, > > Any progress on the > https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592002.html stuff? > > We just got another complain about -fzero-call-used-regs= on mips today... > (PR114466) and let's make another try to solve it (maybe for GCC 15). not sure if I have time working on this one right now, but I will put it in my todo list for GCC15. At the same time, if you have time, you can fix this yourself, I can help with reviewing the code.
[Bug c++/101140] [modules] no matching function for call to ‘operator new(sizetype, void*)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101140 Nathaniel Shead changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||nshead at gcc dot gnu.org Last reconfirmed||2024-03-26 --- Comment #3 from Nathaniel Shead --- I believe this should be valid. The declaration of `::operator new` should be reachable within the instantiation context of 'construct_at' , and thus shouldn't need to be exported to be called. (See [module.context] and [module.reach].) The issue looks to be that `tsubst_expr` when handling a NEW_EXPR just calls `build_new`, which ultimately does `build_operator_new_call` that uses normal `lookup_qualified_name (global_namespace, fnname)` that doesn't consider non-exported entities. We need some way to signify that lookup should also consider declarations reachable from other points in the template's instantiation context. This could be related to one of the issues causing PR114275, but in that cases it's failing to find instantiations of friend classes in the instantiation context.
[Bug target/114272] SCHEDULER_IDENT incorrect for Cortex-A520 and Cortex-A510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114272 --- Comment #3 from GCC Commits --- The master branch has been updated by Richard Ball : https://gcc.gnu.org/g:cab53aae43cf94171b01320c08302e47a5daa391 commit r14-9672-gcab53aae43cf94171b01320c08302e47a5daa391 Author: Richard Ball Date: Tue Mar 26 13:54:31 2024 + aarch64: Fix SCHEDULER_IDENT for Cortex-A510 and Cortex-A520 The SCHEDULER_IDENT for these two CPUs was incorrectly set to cortexa55. This can cause sub-optimal asm to be generated. gcc/ChangeLog: PR target/114272 * config/aarch64/aarch64-cores.def (AARCH64_CORE): Change SCHEDULER_IDENT from cortexa55 to cortexa53 for Cortex-A510 and Cortex-A520.
[Bug target/114272] SCHEDULER_IDENT incorrect for Cortex-A520 and Cortex-A510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114272 --- Comment #4 from Richard Ball --- Fixed on Trunk so far
[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477 --- Comment #4 from Jonathan Wakely --- Changing them seems like a bad idea. Maybe we could keep the pointer constructors for internal use (possibly making them private and adding friend decls as needed) and *also* add the ones taking references, so pedantic conformance (but never use those ourselves). But I think it would be safer to just do nothing, since I don't think this has ever caused a real problem in real code.
[Bug c++/100557] [11/12/13/14 Regression] Internal compiler error: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557 --- Comment #7 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:c0e199e4dbe652cd16d7248f0bfe166540f5d95b commit r14-9674-gc0e199e4dbe652cd16d7248f0bfe166540f5d95b Author: Marek Polacek Date: Tue Mar 26 10:39:48 2024 -0400 c++: add fixed test [PR100557] We used to hit the "Error reporting routines re-entered." ICE here but it was fixed by Patrick's r14-3809. PR c++/100557 gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-pr100557.C: New test.
[Bug c++/114483] New: #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114483 Bug ID: 114483 Summary: #include changes ::abs in std::abs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vincenzo.innocente at cern dot ch Target Milestone: ---
[Bug c++/114484] New: #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 Bug ID: 114484 Summary: #include changes ::abs in std::abs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vincenzo.innocente at cern dot ch Target Milestone: ---
[Bug c++/100557] [11/12/13/14 Regression] Internal compiler error: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Added.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 100557, which changed state. Bug 100557 Summary: [11/12/13/14 Regression] Internal compiler error: Error reporting routines re-entered. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/114484] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 --- Comment #1 from vincenzo Innocente --- xmmintrin.h includes mm_malloc.h which #include which using std::abs; (among others) see https://godbolt.org/z/cxo65rnr9 or this excerpt from c++ -E dump ``` # 32 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/lib/gcc/x86_64-redhat-linux-gnu/12.3.1/include/xmmintrin.h" 2 3 4 # 1 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/lib/gcc/x86_64-redhat-linux-gnu/12.3.1/include/mm_malloc.h" 1 3 4 # 27 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/lib/gcc/x86_64-redhat-linux-gnu/12.3.1/include/mm_malloc.h" 3 4 # 1 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/stdlib.h" 1 3 4 # 36 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/stdlib.h" 3 4 # 1 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/cstdlib" 1 3 4 # 39 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/cstdlib" 3 4 # 40 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/cstdlib" 3 # 37 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/stdlib.h" 2 3 4 using std::abort; using std::atexit; using std::exit; using std::at_quick_exit; using std::quick_exit; using std::div_t; using std::ldiv_t; using std::abs; using std::atof; using std::atoi; using std::atol; using std::bsearch; using std::calloc; using std::div; using std::free; using std::getenv; using std::labs; using std::ldiv; using std::malloc; using std::mblen; using std::mbstowcs; using std::mbtowc; using std::qsort; using std::rand; using std::realloc; using std::srand; using std::strtod; using std::strtol; using std::strtoul; using std::system; using std::wcstombs; using std::wctomb; # 28 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/lib/gcc/x86_64-redhat-linux-gnu/12.3.1/include/mm_malloc.h" 2 3 4 ```
[Bug c++/101140] [modules] no matching function for call to ‘operator new(sizetype, void*)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101140 Patrick Palka changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- FWIW I was thinking we might want to perform two-phase name lookup for new-expressions like we do for other operator expressions, wherein unqualified lookup is performed at template definition time, saved inside the expression (via DEPENDENT_OPERATOR_TYPE) and then reused at instantiation time. But name lookup for a new-expression doesn't do unqualified lookup, it does qualified lookup in the global namespace ::. And unlike true two-phase name lookup which prevents operator overloads declared after the template definition from being considered, it seems GCC/Clang/MSVC all consider later-declared global operator new declarations during instantiation of a new-expression: https://godbolt.org/z/o6r9MYbKc. So it seems two-phase name lookup isn't appropriate for new-expressions, and something like your idea is the way to go? I wonder what Jason thinks.
[Bug c++/112624] Internal compiler error when compiling a module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112624 Patrick Palka changed: What|Removed |Added Last reconfirmed||2024-03-26 CC||ppalka at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING
[Bug tree-optimization/114485] New: [14] Wrong code with -O3 -march=rv64gcv on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485
Bug ID: 114485
Summary: [14] Wrong code with -O3 -march=rv64gcv on riscv
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
Testcase:
int b, c = 8, d;
int e[23];
int main() {
int *h = e;
for (int i = 1; i < b + 21; i += 2) {
c *= -1;
d = h[i] ? i : 0;
}
__builtin_printf("%u\n", c);
}
Commands
> /scratch/tc-testing/tc-mar-25/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv -O3 red.c -o red.out
> /scratch/tc-testing/tc-mar-25/build-rv64gcv/bin/qemu-riscv64 red.out
4294967288
> /scratch/tc-testing/tc-mar-25/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv -O2 red.c -o red.out
> /scratch/tc-testing/tc-mar-25/build-rv64gcv/bin/qemu-riscv64 red.out
8
This is likely a duplicate of pr114476 (but this testcase does not require
-fwrapv).
Found via fuzzer
[Bug rtl-optimization/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838 --- Comment #21 from GCC Commits --- The releases/gcc-13 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:c6e171ff827f8ff1bd160babac0dd24933972664 commit r13-8498-gc6e171ff827f8ff1bd160babac0dd24933972664 Author: Richard Biener Date: Thu Jul 27 13:08:32 2023 +0200 tree-optimization/91838 - fix FAIL of g++.dg/opt/pr91838.C The following fixes the lack of simplification of a vector shift by an out-of-bounds shift value. For scalars this is done both by CCP and VRP but vectors are not handled there. This results in PR91838 differences in outcome dependent on whether a vector shift ISA is available and thus vector lowering does or does not expose scalar shifts here. The following adds a match.pd pattern to catch uniform out-of-bound shifts, simplifying them to zero when not sanitizing shift amounts. PR tree-optimization/91838 * gimple-match-head.cc: Include attribs.h and asan.h. * generic-match-head.cc: Likewise. * match.pd (([rl]shift @0 out-of-bounds) -> zero): New pattern. (cherry picked from commit d1c072a1c3411a6fe29900750b38210af8451eeb)
[Bug tree-optimization/110838] [14 Regression] wrong code on x365-3.5, -O3, sign extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110838 --- Comment #13 from GCC Commits --- The releases/gcc-13 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:b170ab1d051dc97b2e5c03984dbe406939364adc commit r13-8499-gb170ab1d051dc97b2e5c03984dbe406939364adc Author: Richard Biener Date: Fri Aug 4 11:24:49 2023 +0200 tree-optimization/110838 - less aggressively fold out-of-bound shifts The following adjusts the shift simplification patterns to avoid touching out-of-bound shift value arithmetic right shifts of possibly negative values. While simplifying those to zero isn't wrong it's violating the principle of least surprise. PR tree-optimization/110838 * match.pd (([rl]shift @0 out-of-bounds) -> zero): Restrict the arithmetic right-shift case to non-negative operands. (cherry picked from commit 04aa0edcace22a7815cfc57575f1f7b1f166ac10)
[Bug c++/114483] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114483 vincenzo Innocente changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from vincenzo Innocente --- please close this *** This bug has been marked as a duplicate of bug 114484 ***
[Bug c++/114484] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 --- Comment #2 from vincenzo Innocente --- *** Bug 114483 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838 --- Comment #22 from GCC Commits --- The releases/gcc-12 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:1ddd9f9e53bd649d3d236f7941106d8cc46e7358 commit r12-10293-g1ddd9f9e53bd649d3d236f7941106d8cc46e7358 Author: Richard Biener Date: Thu Jul 27 13:08:32 2023 +0200 tree-optimization/91838 - fix FAIL of g++.dg/opt/pr91838.C The following fixes the lack of simplification of a vector shift by an out-of-bounds shift value. For scalars this is done both by CCP and VRP but vectors are not handled there. This results in PR91838 differences in outcome dependent on whether a vector shift ISA is available and thus vector lowering does or does not expose scalar shifts here. The following adds a match.pd pattern to catch uniform out-of-bound shifts, simplifying them to zero when not sanitizing shift amounts. PR tree-optimization/91838 * gimple-match-head.cc: Include attribs.h and asan.h. * generic-match-head.cc: Likewise. * match.pd (([rl]shift @0 out-of-bounds) -> zero): New pattern. (cherry picked from commit d1c072a1c3411a6fe29900750b38210af8451eeb)
[Bug tree-optimization/110838] [14 Regression] wrong code on x365-3.5, -O3, sign extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110838 --- Comment #14 from GCC Commits --- The releases/gcc-12 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:d0eed43ff39a0bad4a02f8af7a4795e06aea6f80 commit r12-10294-gd0eed43ff39a0bad4a02f8af7a4795e06aea6f80 Author: Richard Biener Date: Fri Aug 4 11:24:49 2023 +0200 tree-optimization/110838 - less aggressively fold out-of-bound shifts The following adjusts the shift simplification patterns to avoid touching out-of-bound shift value arithmetic right shifts of possibly negative values. While simplifying those to zero isn't wrong it's violating the principle of least surprise. PR tree-optimization/110838 * match.pd (([rl]shift @0 out-of-bounds) -> zero): Restrict the arithmetic right-shift case to non-negative operands. (cherry picked from commit 04aa0edcace22a7815cfc57575f1f7b1f166ac10)
[Bug target/112787] Codegen regression of large GCC vector extensions when enabling SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787 --- Comment #13 from avieira at gcc dot gnu.org --- They have both been backported, @Eric the tests should be passing again now.
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #41 from Avraham Adler --- It has been a few years since the last comment. I recently got hit by this bug for the first time in about a decade and a half of compiling R for Windows 64 using GCC 13.2.0 as packaged in Rtools44 [1]. Does it remain true that the only option to get around this bug without killing all AVX2 is to pass "-Wa,-muse-unaligned-vector-move" when compiling using GCC on Windows 64? Thank you. [1] https://stat.ethz.ch/pipermail/r-sig-windows/2024q1/000113.html
[Bug testsuite/114486] New: new test gcc.c-torture/execute/pr111151.c in r14-9668-gc4f2c84e8fa369 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114486 Bug ID: 114486 Summary: new test gcc.c-torture/execute/pr51.c in r14-9668-gc4f2c84e8fa369 fails Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:c4f2c84e8fa369856aee76679590eb613724bfb0, r14-9668-gc4f2c84e8fa369 make -k check-gcc RUNTESTFLAGS="execute.exp=gcc.c-torture/execute/pr51.c" FAIL: gcc.c-torture/execute/pr51.c -O0 execution test FAIL: gcc.c-torture/execute/pr51.c -O1 execution test FAIL: gcc.c-torture/execute/pr51.c -O2 execution test FAIL: gcc.c-torture/execute/pr51.c -O3 -g execution test FAIL: gcc.c-torture/execute/pr51.c -Os execution test FAIL: gcc.c-torture/execute/pr51.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.c-torture/execute/pr51.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test # of expected passes7 # of unexpected failures7 (gdb) run Starting program: /home/seurer/gcc/git/build/gcc-test/pr51.exe Program received signal SIGABRT, Aborted. 0x77c296f8 in raise () from /lib64/glibc-hwcaps/power9/libc-2.28.so Missing separate debuginfos, use: yum debuginfo-install glibc-2.28-236.el8_9.12.ppc64le (gdb) where #0 0x77c296f8 in raise () from /lib64/glibc-hwcaps/power9/libc-2.28.so #1 0x77c03ff4 in abort () from /lib64/glibc-hwcaps/power9/libc-2.28.so #2 0x1558 in main () at /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.c-torture/execute/pr51.c:15 if (f != 120) __builtin_abort (); // line 15 commit c4f2c84e8fa369856aee76679590eb613724bfb0 (HEAD) Author: Jakub Jelinek Date: Tue Mar 26 11:21:38 2024 +0100 fold-const: Punt on MULT_EXPR in extract_muldiv MIN/MAX_EXPR case [PR51] * gcc.c-torture/execute/pr51.c: New test.
[Bug target/114484] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 --- Comment #3 from Andrew Pinski --- Why do you think this is a bug? Including an intrinsic header will almost always pull in other headers.
[Bug tree-optimization/114057] [14 Regression] 435.gromacs fails verification with -Ofast -march={znver2,znver4} and PGO after r14-7272-g57f611604e8bab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057 --- Comment #10 from Richard Biener --- So the ref output is -3.22397e+05 3.07684e+02 1.06621e+10 and before the change we get -3.22205e+05 3.05161e+02 1.06660e+10 while after it is -3.22401e+05 3.11606e+02 1.06579e+10 vectorization differences show in innerf.o, bondfree.o, clincs.o, coupling.o, disre.o and update.o while all but innerf.o show only less vectorization. Only using the "bad" version of innerf.o gets us -3.23378e+05 3.08348e+02 1.06697e+10 which should still PASS. Replacing all above TUs with the bad objects reproduces the bad output. Replacing update.o, disre.o, coupling.o or clincs.o with the GOOD version doesn't change the output, so it's only innerf.o and bondfree.o making a difference. Using only BAD bondfree.o gives -3.22265e+05 3.07882e+02 1.06644e+10 That would have been OK as well. The bondfree.o change is small: @@ -2720,9 +2588,6 @@ vec.h:252:8: optimized: basic block part vectorized using 8 byte vectors vec.h:419:8: optimized: basic block part vectorized using 8 byte vectors vec.h:419:8: optimized: basic block part vectorized using 8 byte vectors -vec.h:378:9: optimized: basic block part vectorized using 16 byte vectors -vec.h:379:9: optimized: basic block part vectorized using 16 byte vectors -vec.h:380:9: optimized: basic block part vectorized using 16 byte vectors bondfree.c:806:16: optimized: basic block part vectorized using 8 byte vectors vec.h:239:8: optimized: basic block part vectorized using 8 byte vectors vec.h:265:8: optimized: basic block part vectorized using 8 byte vectors while the innerf.o changes are many (but possibly similar). I will see to understand the bondfree change first. That's the following change in the function idihs: vec.h:380:9: note: Cost model analysis for part in loop 1: - Vector cost: 624 - Scalar cost: 700 -vec.h:380:9: note: Basic block will be vectorized using SLP -vec.h:252:8: optimized: basic block part vectorized using 8 byte vectors -vec.h:252:8: optimized: basic block part vectorized using 8 byte vectors -vec.h:252:8: optimized: basic block part vectorized using 8 byte vectors -vec.h:419:8: optimized: basic block part vectorized using 8 byte vectors -vec.h:419:8: optimized: basic block part vectorized using 8 byte vectors -vec.h:378:9: optimized: basic block part vectorized using 16 byte vectors -vec.h:379:9: optimized: basic block part vectorized using 16 byte vectors -vec.h:380:9: optimized: basic block part vectorized using 16 byte vectors -vec.h:380:9: note: Vectorizing SLP tree: -vec.h:380:9: note: node 0x345f188 (max_nunits=2, refcnt=1) vector(2) float + Vector cost: 640 + Scalar cost: 532 +vec.h:380:9: missed: not vectorized: vectorization is not profitable. where it basically changes what nodes we think are live. Note this is a larger graph with multiple instances so we might suffer from what I noted in PR114413. The IL has all but the call to do_dih_fup inlined into idihs.
[Bug modula2/114478] isnormal builtin unavailable from m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114478 --- Comment #2 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:b1af867d22e3108402c62f97d8fcd1df303c9dab commit r14-9675-gb1af867d22e3108402c62f97d8fcd1df303c9dab Author: Gaius Mulley Date: Tue Mar 26 15:33:52 2024 + PR modula2/114478 isnormal builtin unavailable from m2 This patch adds isnormal (and isgreater, isless, isgreaterequal, islessequal, islessgreater, isunordered) c99 macro similar prototyped builtins to m2. gcc/m2/ChangeLog: PR modula2/114478 * gm2-gcc/m2builtins.cc (struct builtin_macro_definition): New struct. (lookup_builtin_macro): New function. (m2builtins_BuildBuiltinTree): Rewrite to lookup builtin function and builtin macro. (lookup_builtin_function): New function. (define_builtin): Rename parameter type to prototype push macro definition to builtin_macros vector. (define_builtin_ext): New function. (define_builtin_math): New function. (m2builtins_init): Add isgreater, isless, isgreaterequal, islessequal, islessgreater, isunordered, isnormal to macro definitions. * gm2-libs/Builtins.def (isgreater): New procedure function. (isgreaterf): Ditto. (isgreaterl): Ditto. (isgreaterequal): Ditto. (isgreaterequalf): Ditto. (isgreaterequall): Ditto. (isless): Ditto. (islessf): Ditto. (islessl): Ditto. (islessequal): Ditto. (islessequalf): Ditto. (islessequall): Ditto. (islessgreater): Ditto. (islessgreaterf): Ditto. (islessgreaterl): Ditto. (isunordered): Ditto. (isunorderedf): Ditto. (isunorderedl): Ditto. (iseqsig): Ditto. (iseqsigf): Ditto. (iseqsigl): Ditto. (isnormal): Ditto. (isnormalf): Ditto. (isnormall): Ditto. (isinf_sign): Ditto. (isinf_signf): Ditto. (isinf_signl): Ditto. * gm2-libs/Builtins.mod (isgreater): New procedure function. (isgreaterf): Ditto. (isgreaterl): Ditto. (isgreaterequal): Ditto. (isgreaterequalf): Ditto. (isgreaterequall): Ditto. (isless): Ditto. (islessf): Ditto. (islessl): Ditto. (islessequal): Ditto. (islessequalf): Ditto. (islessequall): Ditto. (islessgreater): Ditto. (islessgreaterf): Ditto. (islessgreaterl): Ditto. (isunordered): Ditto. (isunorderedf): Ditto. (isunorderedl): Ditto. (iseqsig): Ditto. (iseqsigf): Ditto. (iseqsigl): Ditto. (isnormal): Ditto. (isnormalf): Ditto. (isnormall): Ditto. (isinf_sign): Ditto. (isinf_signf): Ditto. (isinf_signl): Ditto. gcc/testsuite/ChangeLog: PR modula2/114478 * gm2/builtins/run/pass/builtins-run-pass.exp: New test. * gm2/builtins/run/pass/testcomparisons.mod: New test. * gm2/builtins/run/pass/testisnormal.mod: New test. * gm2/pimlib/run/pass/testchar.mod: New test. Signed-off-by: Gaius Mulley
[Bug tree-optimization/114057] [14 Regression] 435.gromacs fails verification with -Ofast -march={znver2,znver4} and PGO after r14-7272-g57f611604e8bab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057 --- Comment #11 from Richard Biener --- Created attachment 57816 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57816&action=edit manually reduced preprocessed source This is the TU reduced to idihs where I put flatten on, with just -Ofast -march=znver2 one can reproduce the vectorization difference when reverting the offending revision ontop of trunk. I'll have a closer look tomorrow.
[Bug tree-optimization/114057] [14 Regression] 435.gromacs fails verification with -Ofast -march={znver2,znver4} and PGO after r14-7272-g57f611604e8bab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug modula2/114478] isnormal builtin unavailable from m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114478 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Gaius Mulley --- Closing now the patch has been applied.
