[Bug c++/109666] [13/14 Regression] Segmentation fault with std::array using gcc 13 since r13-6788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666 --- Comment #5 from Carlos Galvez --- This commit fixes all the ICEs on our side, thank you!
[Bug c++/109680] [13/14 Regression] is_convertible incorrectly true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680 --- Comment #6 from Jakub Jelinek --- Not sure about the from case, but what do I know about C++? While To type is directly returned from a function, std::declval doesn't return >From but >From &&. #include using F1 = int (int); using T1 = int (*) (int); static_assert (std::is_convertible_v); using F2 = int (int) const; using T2 = int (*) (int); static_assert (!std::is_convertible_v); using F3 = int (*) (int); using T3 = int (int); static_assert (!std::is_convertible_v); using F4 = int (*) (int); using T4 = int (int) const; static_assert (!std::is_convertible_v); passes in both g++ 12 and clang++. And, on using F1 = int (int); using T1 = int (*) (int); static_assert (__is_convertible(F1, T1)); using F2 = int (int) const; using T2 = int (*) (int); static_assert (!__is_convertible(F2, T2)); using F3 = int (*) (int); using T3 = int (int); static_assert (!__is_convertible(F3, T3)); using F4 = int (*) (int); using T4 = int (int) const; static_assert (!__is_convertible(F4, T4)); clang++ emits: /tmp/2a.C:6:34: error: non-member function of type 'F2' (aka 'int (int) const') cannot have 'const' qualifier static_assert (!__is_convertible(F2, T2)); ^ /tmp/2a.C:6:1: error: static_assert failed due to requirement '!__is_convertible(int (int), int (*)(int))' static_assert (!__is_convertible(F2, T2)); ^ ~ /tmp/2a.C:12:38: error: non-member function of type 'T4' (aka 'int (int) const') cannot have 'const' qualifier static_assert (!__is_convertible(F4, T4)); ^ while g++ trunk /tmp/2a.C:6:16: error: static assertion failed 6 | static_assert (!__is_convertible(F2, T2)); |^
[Bug c++/109678] [13/14 Regression] exponential time behavior on std::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109678 --- Comment #2 from Gery Emreis --- Its not just about compilation time but also about RAM usage. Compilation of variation of std::variant as in provided example consumes unholy amounts of RAM which in the end makes some files uncompilable on my system, because GCC consumes all available RAM and swap and makes my system hang.
[Bug c/109693] New: trivial: unused private field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109693
Bug ID: 109693
Summary: trivial: unused private field
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
I just did a build of gcc with clang. It said:
trunk.year/gcc/value-range-storage.h:41:8: warning: private field 'm_gc' is not
used [-Wunused-private-field]
$ fgrep m_gc trunk.year/gcc/value-range-storage.{h,cc}
trunk.year/gcc/value-range-storage.h: bool m_gc;
trunk.year/gcc/value-range-storage.cc: : m_gc (gc)
$
[Bug libstdc++/109694] New: trivial: libstdc++-v3/src/c++98/ios_init.cc:203: alias between functions of incompatible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109694
Bug ID: 109694
Summary: trivial: libstdc++-v3/src/c++98/ios_init.cc:203: alias
between functions of incompatible types
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
I just tried a build of gcc trunk with clang. It said:
trunk.year/libstdc++-v3/src/c++98/ios_init.cc:203:8: warning: ‘void
std::ios_base_library_init()’ alias between functions of incompatible types
‘void()’ and ‘void (std::ios_base::Init::)()’ [-Wattribute-alias=]
Source code is
void ios_base_library_init (void)
__attribute__((alias ("_ZNSt8ios_base4InitC1Ev")));
Maybe a cast would shut up clang ?
[Bug tree-optimization/109689] [14 Regression] ICE at -O1 with "-ftree-vectorize": in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109689 --- Comment #3 from Richard Biener --- LC SSA is broken by unloop_loops (). That introduces BB 19 which is [count: 0]: f.8_13 = (unsigned char) f_19; _14 = f.8_13 + 1; f_38 = (char) _14; _16 = a_lsm.17_51 + 1; __builtin_unreachable (); but that's an exit from the loop and is missing LC PHI nodes for all of the SSA names used.
[Bug tree-optimization/109672] [14 regression] many ICEs after r14-323-g977a43f5ba778b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109672 --- Comment #3 from Richard Biener --- I think the issue is rev. r14-322-g821ef93976e750. We enter with vector(2) short using SImode and a PLUS_EXPR. Then bool using_emulated_vectors_p = vect_emulated_vector_p (vectype); yields true, but we've figured there's target support for SImode add so fail to hit /* Check only during analysis. */ if (maybe_ne (GET_MODE_SIZE (vec_mode), UNITS_PER_WORD) || (!vec_stmt && !vect_can_vectorize_without_simd_p (code))) return false; that we mash bit operations and arithmetics in the used predicates makes things a bit iffy - for bit operations we can really let things go. In theory we could also handle this SImode case (no need to always use word_mode - but at least for some targets subword operations might be more expensive).
[Bug tree-optimization/109672] [14 regression] many ICEs after r14-322-g821ef93976e750
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109672 Richard Biener changed: What|Removed |Added Summary|[14 regression] many ICEs |[14 regression] many ICEs |after |after |r14-323-g977a43f5ba778b |r14-322-g821ef93976e750 --- Comment #4 from Richard Biener --- I am testing a patch.
[Bug libstdc++/109694] trivial: libstdc++-v3/src/c++98/ios_init.cc:203: alias between functions of incompatible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109694 Jakub Jelinek changed: What|Removed |Added Version|13.0|14.0 Last reconfirmed||2023-05-02 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |14.0 Status|UNCONFIRMED |ASSIGNED CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- I doubt we support building libstdc++ with clang. Anyway, this warns also when built with GCC.
[Bug libstdc++/109694] trivial: libstdc++-v3/src/c++98/ios_init.cc:203: alias between functions of incompatible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109694 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:87de39e4c3686535728f3a347f772e73af4cf262 commit r14-389-g87de39e4c3686535728f3a347f772e73af4cf262 Author: Jakub Jelinek Date: Tue May 2 10:58:19 2023 +0200 ibstdc++: Shut up -Wattribute-alias warning [PR109694] I've followed what other files do, using attribute alias with not really matching function type (after all, it isn't really possible when it is a constructor), but seems I've missed it warns: ../../../../../libstdc++-v3/src/c++98/ios_init.cc:203:8: warning: âvoid std::ios_base_library_init()â alias between functions of incompatible types âvoid()â and âvoid +(std::ios_base::Init::)()â [-Wattribute-alias=] 203 | void ios_base_library_init (void) |^ ../../../../../libstdc++-v3/src/c++98/ios_init.cc:78:3: note: aliased declaration here 78 | ios_base::Init::Init() | ^~~~ The PR talks about clang++ warning there (which I think isn't really supported, libstdc++ sources ought to be built by GCC), but it warns when built with GCC too. The following patch fixes it by doing what other libstdc++ sources do in those cases. 2023-05-02 Jakub Jelinek PR libstdc++/109694 * src/c++98/ios_init.cc: Add #pragma GCC diagnostic ignored for -Wattribute-alias.
[Bug libstdc++/109694] trivial: libstdc++-v3/src/c++98/ios_init.cc:203: alias between functions of incompatible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109694 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/109667] [12/13/14 Regression] Unnecessary temporary storage used for 32-byte struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109667 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r12-155-gd8e1f1d24179690fd9c0
[Bug tree-optimization/109667] [12/13/14 Regression] Unnecessary temporary storage used for 32-byte struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109667
--- Comment #3 from Jakub Jelinek ---
So, either SRA should be tweaked so that it can deal with DSE trimming of
initializations (I think that is the best way forward, after all, user could
have
done it manually too -
struct i256 {
long v[4];
};
void assign(struct i256 *v, long z) {
struct i256 r;
__builtin_memset (&r.v[1], 0, sizeof (long) * 3);
for (int i = 0; i < 1; ++i)
r.v[i] = z;
*v = r;
}
regressed with r7-2588-gdf7ec09f1209a33b35 ), or we should do something at the
RTL level like it apparently worked before the r7-2588 change, or we should
disable trimming in the DSE part before SRA.
[Bug tree-optimization/109672] [14 regression] many ICEs after r14-322-g821ef93976e750
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109672 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f385252b2336a4a57a30fddf82e558c73bcc85cc commit r14-391-gf385252b2336a4a57a30fddf82e558c73bcc85cc Author: Richard Biener Date: Tue May 2 10:34:48 2023 +0200 tree-optimization/109672 - properly check emulated plus during vect The following refactors the check for emulated vector support for the cases of plus, minus and negate. In the PR we end up with a SImode plus, supported by the target but emulated and in this context fail to verify we are dealing with exactly word_mode. PR tree-optimization/109672 * tree-vect-stmts.cc (vectorizable_operation): For plus, minus and negate always check the vector mode is word mode.
[Bug tree-optimization/109672] [14 regression] many ICEs after r14-322-g821ef93976e750
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109672 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Should be fixed.
[Bug c/109695] New: crash in gimple_ranger::range_of_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695 Bug ID: 109695 Summary: crash in gimple_ranger::range_of_expr Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 54966 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54966&action=edit gzipped C++ source code The attached C++ code does this when compiled by today's gcc: $ ~/gcc/results.20230502.asan.ubsan/bin/gcc -c -w bug914.cc gcc: internal compiler error: Segmentation fault signal terminated program cc1plus Please submit a full bug report, with preprocessed source (by using -freport-bug). See <https://gcc.gnu.org/bugs/> for instructions. $ It was fine yesterday: $ ~/gcc/results.20230501.asan.ubsan/bin/gcc -c -w bug914.cc $ Here is a stack backtrace of the crash: #0 0x01f5328b in gimple_ranger::range_of_expr (this=0x36e4d50, r=..., expr=0x7fffe0369990, stmt=0x7fffe8cd6688) at ../../trunk.year/gcc/gimple-range.cc:87 #1 0x01f62f96 in fold_using_range::range_of_range_op ( this=this@entry=0x7c01e100, r=..., handler=..., src=...) at ../../trunk.year/gcc/gimple-range-fold.cc:559 #2 0x01f61d4e in fold_using_range::fold_stmt (this=0x7c01e100, r=..., s=0x7fffe8cd6688, src=..., name=0x7fffe0369cf0) at ../../trunk.year/gcc/gimple-range-fold.cc:490 #3 0x01f54220 in gimple_ranger::fold_range_internal (this=0x36e4d50, r=..., s=0x7fffe8cd6688, name=) at ../../trunk.year/gcc/gimple-range.cc:257
[Bug c/109695] crash in gimple_ranger::range_of_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695 David Binderman changed: What|Removed |Added CC||aldyh at redhat dot com --- Comment #1 from David Binderman --- I have a reduction running. Git range is g:4d68c7f7b5aea5e9 .. g:1fc8da95d93d1f1f, which is 21 commits. Given that Aldy did 13 of those 21, it looks to me to be a racing certainty that Aldy can help here.
[Bug c/109695] crash in gimple_ranger::range_of_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695 --- Comment #2 from David Binderman --- Created attachment 54967 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54967&action=edit gzipped C++ source code After an hour's reduction.
[Bug c/109696] New: ice: tree check fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109696
Bug ID: 109696
Summary: ice: tree check fail
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
sprint_tm(long ns) {
char buf;
double t = ns;
if (t)
sprintf(buf, "");
}
wait_for_reply_avg() { sprint_tm(wait_for_reply_avg); }
compiled by recent trunk gcc, does this:
$ ~/gcc/results.20230502.asan.ubsan/bin/gcc -c -w -O2 bug915.c
during IPA pass: inline
bug915.c:7:1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060
7 | wait_for_reply_avg() { sprint_tm(wait_for_reply_avg); }
| ^~
0x115a4fa tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../trunk.year/gcc/tree.cc:8948
0x1183d13 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../trunk.year/gcc/tree.h:3663
0x1183d13 irange::verify_range()
../../trunk.year/gcc/value-range.cc:1060
It was fine yesterday:
$ ~/gcc/results.20230501.asan.ubsan/bin/gcc -c -w -O2 bug915.c
$
I suspect this is another one for Aldy.
[Bug target/109661] [13/14 Regression] ICE in aarch64_function_arg_alignment when building erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109661 --- Comment #5 from Jakub Jelinek --- Is it worth to test my patch or are you working on something more complete (say -Wpsabi warnings for cases where the ABI changes between 12.x, ICE in 13.1, fixed with different ABI for 13.2/14+?
[Bug tree-optimization/109696] [14 Regression] ice: tree check fail since r14-377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109696
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Summary|ice: tree check fail|[14 Regression] ice: tree
||check fail since r14-377
CC||jakub at gcc dot gnu.org
Component|c |tree-optimization
Target Milestone|--- |14.0
--- Comment #1 from Jakub Jelinek ---
Started with r14-377-gc92b8be9b52b7e0de5ad
Cleaned up testcase:
void
foo (long x)
{
char buf;
double t = x;
if (t)
__builtin_sprintf ((char *) (__INTPTR_TYPE__) buf, "");
}
void
bar (int x)
{
foo (x);
}
[Bug target/109661] [13/14 Regression] ICE in aarch64_function_arg_alignment when building erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109661 --- Comment #6 from rsandifo at gcc dot gnu.org --- I'm working on a patch (though not literally right now).
[Bug ipa/106124] [11 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.cc:23254
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106124 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:1cfc7f22eb4587029624050006c2ab4e82e9a0b1 commit r11-10672-g1cfc7f22eb4587029624050006c2ab4e82e9a0b1 Author: Richard Biener Date: Mon Mar 27 16:40:15 2023 +0200 ipa/106124 - ICE with -fkeep-inline-functions and OpenMP The testcases in this bug reveal cases where an early generated type is collected because it was unused but gets attempted to be recreated later when a late DIE for a function (an OpenMP reduction) is created. That's unexpected and possibly the fault of OpenMP but the following allows the re-creation of the context type to succeed. PR ipa/106124 * dwarf2out.c (lookup_type_die): Reset TREE_ASM_WRITTEN so we can re-create the DIE for the type if required. * g++.dg/gomp/pr106124.C: New testcase. (cherry picked from commit 36330e2e95564a360e6dbcfb4e7566d5c2177415)
[Bug tree-optimization/108625] [11 Regression] forwprop introduces new UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108625 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:a0a1905b26751acea523a3bf1bca68d4ddc55c09 commit r11-10675-ga0a1905b26751acea523a3bf1bca68d4ddc55c09 Author: Richard Biener Date: Thu Feb 2 11:09:26 2023 +0100 middle-end/108625 - wrong folding due to misinterpreted ! The following fixes a problem with ! handling in genmatch which isn't conservative enough when intermediate simplifications push to the sequence but the final operation appears to just pick an existing (but in this case newly defined in the sequence) operand. The easiest fix is to disallow adding to the sequence when processing !. PR middle-end/108625 * genmatch.c (expr::gen_transform): Also disallow resimplification from pushing to lseq with force_leaf. (dt_simplify::gen_1): Likewise. * gcc.dg/pr108625.c: New testcase. (cherry picked from commit 605d1297b91c2c7c23ccfe669e66dda5791d1f55)
[Bug tree-optimization/108076] [10/11 Regression] GCC with -O3 produces code which fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108076 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:893b9d8d7df3f6134aa4dd5f501db652448df41f commit r11-10674-g893b9d8d7df3f6134aa4dd5f501db652448df41f Author: Richard Biener Date: Mon Dec 12 17:52:46 2022 +0100 tree-optimization/108076 - if-conversion and forced labels When doing if-conversion we simply throw away labels without checking whether they are possibly targets of non-local gotos or have their address taken. The following rectifies this and refuses to if-convert such loops. PR tree-optimization/108076 * tree-if-conv.c (if_convertible_loop_p_1): Reject blocks with non-local or forced labels that we later remove labels from. * gcc.dg/torture/pr108076.c: New testcase. (cherry picked from commit b4fddbe9592e9feb37ce567d90af822b75995531)
[Bug tree-optimization/107451] [11 Regression] Segmentation fault with vectorized code since r11-6434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451 --- Comment #14 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:e74518e28d98994c2059063f339533d344db85e0 commit r11-10673-ge74518e28d98994c2059063f339533d344db85e0 Author: Richard Biener Date: Thu Dec 22 09:36:17 2022 +0100 tree-optimization/107451 - SLP load vectorization issue When vectorizing SLP loads with permutations we can access excess elements when the load vector type is bigger than the group size and the vectorization factor covers less groups than necessary to fill it. Since we know the code will only access up to group_size * VF elements in the unpermuted vector we can simply fill the rest of the vector with whatever we want. For simplicity this patch chooses to repeat the last group. PR tree-optimization/107451 * tree-vect-stmts.c (vectorizable_load): Avoid loading SLP group members from group numbers in excess of the vectorization factor. * gcc.dg/torture/pr107451.c: New testcase. (cherry picked from commit 7b2cf5041460859ca4f58e5da1308b7ef9129d8b)
[Bug rtl-optimization/109585] [10/11 regression] Carla/sord miscompiled with -O2 on ARM64 with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 --- Comment #27 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:e54ecbcbe625847f384b11c41562038477a3eb2c commit r11-10678-ge54ecbcbe625847f384b11c41562038477a3eb2c Author: Richard Biener Date: Mon Apr 24 13:31:07 2023 +0200 rtl-optimization/109585 - alias analysis typo When r10-514-gc6b84edb6110dd2b4fb improved access path analysis it introduced a typo that triggers when there's an access to a trailing array in the first access path leading to false disambiguation. PR rtl-optimization/109585 * tree-ssa-alias.c (aliasing_component_refs_p): Fix typo. * gcc.dg/torture/pr109585.c: New testcase. (cherry picked from commit 6d4bd27a60447c7505cb4783e675e98a191a8904)
[Bug tree-optimization/109473] [10/11 Regression] ICE during GIMPLE pass: vect: verify_gimple failed with -O1 -ftree-loop-vectorize since r10-4076-g82e8e335f917b9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109473 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:54ddf6426e04e4b0d24bbc7e37d40acbf5fbfe3b commit r11-10676-g54ddf6426e04e4b0d24bbc7e37d40acbf5fbfe3b Author: Richard Biener Date: Wed Apr 12 10:22:08 2023 +0200 tree-optimization/109473 - ICE with reduction epilog adjustment op The following makes sure to carry out the reduction epilog adjustment in the original computation type which for pointers is an unsigned integer type. There's a similar issue with signed vs. unsigned ops and overflow which is fixed by this as well. PR tree-optimization/109473 * tree-vect-loop.c (vect_create_epilog_for_reduction): Convert scalar result to the computation type before performing the reduction adjustment. * gcc.dg/vect/pr109473.c: New testcase. (cherry picked from commit df7f55cb2ae550adeda339a57b657ebe1ad39367)
[Bug tree-optimization/109502] [11 Regression] wrong code with -O -ftree-vectorize -fvect-cost-model=unlimited on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109502 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:7fc59677f7a9a2bff75e0002fef303a41a9ebe9d commit r11-10677-g7fc59677f7a9a2bff75e0002fef303a41a9ebe9d Author: Richard Biener Date: Fri Apr 14 09:55:27 2023 +0200 tree-optimization/109502 - vector conversion between mask and non-mask The following fixes a check that should have rejected vectorizing a conversion between a mask and non-mask type. Those should be done via pattern statements. PR tree-optimization/109502 * tree-vect-stmts.c (vectorizable_assignment): Fix check for conversion between mask and non-mask types. * gcc.dg/vect/pr109502.c: New testcase. (cherry picked from commit bf24f2db2841b97bc5e86bf9294d61eef32f83b3)
[Bug ipa/106124] [11 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.cc:23254
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106124 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to work||11.3.1 Status|ASSIGNED|RESOLVED Known to fail||11.3.0 --- Comment #10 from Richard Biener --- Fixed.
[Bug tree-optimization/107451] [11 Regression] Segmentation fault with vectorized code since r11-6434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451 Richard Biener changed: What|Removed |Added Known to work||11.3.1 Resolution|--- |FIXED Known to fail||11.3.0 Status|ASSIGNED|RESOLVED --- Comment #15 from Richard Biener --- Fixed.
[Bug tree-optimization/108625] [11 Regression] forwprop introduces new UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108625 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||11.3.0 Resolution|--- |FIXED Known to work||11.3.1 --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/109502] [11 Regression] wrong code with -O -ftree-vectorize -fvect-cost-model=unlimited on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109502 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail||11.3.0 --- Comment #10 from Richard Biener --- Fixed.
[Bug target/109697] New: arm: lack of MVE instruction costing causing worse codegen on a vec_duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109697 Bug ID: 109697 Summary: arm: lack of MVE instruction costing causing worse codegen on a vec_duplicate Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: stammark at gcc dot gnu.org Target Milestone: --- Hi all, In the arm backend, for MVE targets we previously had this bug on the vcmp patterns: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107987 The fix is fine, but it resulted in some failing tests: * gcc.target/arm/mve/intrinsics/vcmpcsq_n_u16.c * gcc.target/arm/mve/intrinsics/vcmpcsq_n_u32.c * gcc.target/arm/mve/intrinsics/vcmpcsq_n_u8.c * gcc.target/arm/mve/intrinsics/vcmpeqq_n_f16.c * gcc.target/arm/mve/intrinsics/vcmpeqq_n_f32.c * gcc.target/arm/mve/intrinsics/vcmpeqq_n_u16.c * gcc.target/arm/mve/intrinsics/vcmpeqq_n_u32.c * gcc.target/arm/mve/intrinsics/vcmpeqq_n_u8.c * gcc.target/arm/mve/intrinsics/vcmpgeq_n_f16.c * gcc.target/arm/mve/intrinsics/vcmpgeq_n_f32.c * gcc.target/arm/mve/intrinsics/vcmpgtq_n_f16.c * gcc.target/arm/mve/intrinsics/vcmpgtq_n_f32.c * gcc.target/arm/mve/intrinsics/vcmphiq_n_u16.c * gcc.target/arm/mve/intrinsics/vcmphiq_n_u32.c * gcc.target/arm/mve/intrinsics/vcmphiq_n_u8.c * gcc.target/arm/mve/intrinsics/vcmpleq_n_f16.c * gcc.target/arm/mve/intrinsics/vcmpleq_n_f32.c * gcc.target/arm/mve/intrinsics/vcmpltq_n_f16.c * gcc.target/arm/mve/intrinsics/vcmpltq_n_f32.c * gcc.target/arm/mve/intrinsics/vcmpneq_n_f16.c * gcc.target/arm/mve/intrinsics/vcmpneq_n_f32.c * gcc.target/arm/mve/intrinsics/vcmpneq_n_u16.c * gcc.target/arm/mve/intrinsics/vcmpneq_n_u32.c * gcc.target/arm/mve/intrinsics/vcmpneq_n_u8.c (after Andrea improved these tests in GCC13) The testcases that are failing are the ones that compare against a scalar immediate (e.g. "vcmpeqq (a, 1.1)"), because the compiler prefers to do: ``` vldr.64 d6, .L5 vldr.64 d7, .L5+8 vcmp.f16eq, q0, q3 ``` When previously we would much more simply: ``` movsr3, #1 vcmp.u16cs, q0, r3 ``` The underlying reason for this change is a known deficiency of the MVE implementation: the lack of proper instruction costing. The compiler falls back to calculating costs based on the operands and the new vec_duplicate in the patterns (mve_vcmpq_n_, etc) gets given a cost of 32 (when instead it should know that the vec duplicate is free and this is all just one instruction...), so the "literal load + vector-vector compare" wins out against the "put the immediate in a GP reg + vector-scalar compare". For now, I plan on simply XFAIL-ing the tests.
[Bug tree-optimization/109696] [14 Regression] ice: tree check fail since r14-377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109696 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-02 Ever confirmed|0 |1
[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695 Richard Biener changed: What|Removed |Added Version|13.0|14.0 Component|c |tree-optimization Target Milestone|--- |14.0 Summary|crash in|[14 Regression] crash in |gimple_ranger::range_of_exp |gimple_ranger::range_of_exp |r |r
[Bug modula2/109675] GCC 13.1: the Modula-2 front-end fails to build on some platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109675 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2023-05-02 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Gaius Mulley --- Yes indeed writeAddress needs to be re-written.
[Bug tree-optimization/109573] [11 regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:9060 with -march=ivybridge since r11-3025-g095d42feed09f8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573 Richard Biener changed: What|Removed |Added Target Milestone|11.5|11.4 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to fail||11.3.0 Known to work||11.3.1 --- Comment #10 from Richard Biener --- Fixed.
[Bug tree-optimization/109573] [11 regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:9060 with -march=ivybridge since r11-3025-g095d42feed09f8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:8ee420c763add757bfb7c451f3ec986046644021 commit r11-10679-g8ee420c763add757bfb7c451f3ec986046644021 Author: Richard Biener Date: Fri Apr 21 12:57:17 2023 +0200 tree-optimization/109573 - avoid ICEing on unexpected live def The following relaxes the assert in vectorizable_live_operation where we catch currently unhandled cases to also allow an intermediate copy as it happens here but also relax the assert to checking only. PR tree-optimization/109573 * tree-vect-loop.c (vectorizable_live_operation): Allow unhandled SSA copy as well. Demote assert to checking only. * g++.dg/vect/pr109573.cc: New testcase. (cherry picked from commit cddfe6bc40b3dc0806e260bbfb4cac82d609a258)
[Bug lto/109263] [10/11 Regression] '-g0 -ggdb -flto' gives linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109263 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:d4baf9f030f3b61499f3e83a3f5fc39bc8427cb5 commit r11-10680-gd4baf9f030f3b61499f3e83a3f5fc39bc8427cb5 Author: Richard Biener Date: Thu Mar 23 16:56:53 2023 +0100 lto/109263 - lto-wrapper and -g0 -ggdb The following makes lto-wrapper deal with non-combined debug disabling / enabling option combinations properly. Interestingly -gno-dwarf also enables debug. PR lto/109263 * lto-wrapper.c (run_gcc): Parse alternate debug options as well, they always enable debug. (cherry picked from commit 4cbd5ef0350d8ab04993eb4c48ab80999fb4f358)
[Bug c++/109506] [10/11/12/13/14 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109506 --- Comment #11 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9a9840cedbdc8be8252fd8f2d31d8fbd36632a2e commit r14-393-g9a9840cedbdc8be8252fd8f2d31d8fbd36632a2e Author: Patrick Palka Date: Tue May 2 08:48:59 2023 -0400 c++: Add testcase for already fixed PR [PR109506] The PR109666 fix r14-386-g07c52d1eec967 incidentally also fixes this PR. PR c++/109506 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template26.C: New test.
[Bug c++/109698] New: gcc/g++ build/link fails for libhwasan.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109698 Bug ID: 109698 Summary: gcc/g++ build/link fails for libhwasan.so Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dnewtonrichards at gmail dot com Target Milestone: --- building on Debian 10 (Buster) uname -a: Linux relativity1 4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux configure: --prefix=/usr/local/GCC --disable-nls --disable-multilib --enable-languages=c,c+ building with gcc/g++ version 12.2 stage_current: stage3 I make it as far as stage 3 and the build fails while linking libhwasan.so.0.0.0 libtool: link: /home/odysseus/Downloads/gcc-13.1.0/objdir/./gcc/xgcc -shared-libgcc -B/home/odysseus/Downloads/gcc-13.1.0/objdir/./gcc -nostdinc++ -L/home/odysseus/Downloads/gcc-13.1.0/objdir/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/odysseus/Downloads/gcc-13.1.0/objdir/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/odysseus/Downloads/gcc-13.1.0/objdir/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/GCC/x86_64-pc-linux-gnu/bin/ -B/usr/local/GCC/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/GCC/x86_64-pc-linux-gnu/include -isystem /usr/local/GCC/x86_64-pc-linux-gnu/sys-include -fPIC -DPIC -shared -nostdlib /lib/x86_64-linux-gnu/crti.o /home/odysseus/Downloads/gcc-13.1.0/objdir/./gcc/crtbeginS.o .libs/hwasan_allocation_functions.o .libs/hwasan_allocator.o .libs/hwasan.o .libs/hwasan_dynamic_shadow.o .libs/hwasan_exceptions.o .libs/hwasan_fuchsia.o .libs/hwasan_globals.o .libs/hwasan_interceptors.o .libs/hwasan_interceptors_vfork.o .libs/hwasan_linux.o .libs/hwasan_memintrinsics.o .libs/hwasan_new_delete.o .libs/hwasan_poisoning.o .libs/hwasan_report.o .libs/hwasan_setjmp_aarch64.o .libs/hwasan_setjmp_x86_64.o .libs/hwasan_tag_mismatch_aarch64.o .libs/hwasan_thread.o .libs/hwasan_thread_list.o .libs/hwasan_type_test.o -Wl,--whole-archive ../sanitizer_common/.libs/libsanitizer_common.a ../interception/.libs/libinterception.a ../libbacktrace/.libs/libsanitizer_libbacktrace.a -Wl,--no-whole-archive -Wl,-rpath -Wl,/home/odysseus/Downloads/gcc-13.1.0/objdir/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -Wl,-rpath -Wl,/usr/local/GCC/lib/../lib64 -L/home/odysseus/Downloads/gcc-13.1.0/objdir/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/odysseus/Downloads/gcc-13.1.0/objdir/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/odysseus/Downloads/gcc-13.1.0/objdir/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -ldl -lrt -lpthread ../../libstdc++-v3/src/.libs/libstdc++.so -lm -L/home/odysseus/Downloads/gcc-13.1.0/objdir/./gcc -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -lc -lgcc_s /home/odysseus/Downloads/gcc-13.1.0/objdir/./gcc/crtendS.o /lib/x86_64-linux-gnu/crtn.o -mshstk -Wl,-soname -Wl,libhwasan.so.0 -o .libs/libhwasan.so.0.0.0 /usr/bin/ld: .libs/hwasan.o: relocation R_X86_64_PC32 against undefined symbol `__ehdr_start' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: nonrepresentable section on output collect2: error: ld returned 1 exit status make[4]: *** [Makefile:559: libhwasan.la] Error 1 make[4]: Leaving directory '/home/odysseus/Downloads/gcc-13.1.0/objdir/x86_64-pc-linux-gnu/libsanitizer/hwasan' make[3]: *** [Makefile:532: all-recursive] Error 1 make[3]: Leaving directory '/home/odysseus/Downloads/gcc-13.1.0/objdir/x86_64-pc-linux-gnu/libsanitizer' make[2]: *** [Makefile:419: all] Error 2 make[2]: Leaving directory '/home/odysseus/Downloads/gcc-13.1.0/objdir/x86_64-pc-linux-gnu/libsanitizer' make[1]: *** [Makefile:19101: all-target-libsanitizer] Error 2 make[1]: Leaving directory '/home/odysseus/Downloads/gcc-13.1.0/objdir' make: *** [Makefile:1082: all] Error 2
[Bug sanitizer/109698] gcc/g++ build/link fails for libhwasan.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109698 Andrew Pinski changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=24458 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2023-05-02 --- Comment #1 from Andrew Pinski --- What version of ld is this? It might be bug there: https://sourceware.org/bugzilla/show_bug.cgi?id=24458
[Bug sanitizer/109698] gcc/g++ build/link fails for libhwasan.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109698 --- Comment #2 from Jakub Jelinek --- Seems binutils has added support for __ehdr_start only in https://sourceware.org/legacy-ml/binutils/2012-06/msg00171.html in 2012. Do you have binutils older than that?
[Bug fortran/55207] [F08] Variables declared in the main program should implicitly get the SAVE attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 --- Comment #24 from Tobias Burnus --- Created attachment 54968 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54968&action=edit WIP patch – still many testcase fails Patch to fixes some MODULE and PROGRAM issues with automatic save. TODO: (a) Fix testsuite fails (required) [(b) Anything to do for COMMON or DATA blocks?] (c) as follow up, cleanup code for no-longer needed checks (can be follow up)
[Bug tree-optimization/108821] [11 Regression] LIM reissuing a violatile store when it cannot/should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108821 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:bd0192968999661d103bb9d974a8ad3be4ef3d9b commit r11-10681-gbd0192968999661d103bb9d974a8ad3be4ef3d9b Author: Richard Biener Date: Fri Feb 17 12:36:44 2023 +0100 tree-optimization/108821 - store motion and volatiles The following fixes store motion to not re-issue volatile stores to preserve TBAA behavior since that will result in the number of volatile accesses changing. PR tree-optimization/108821 * tree-ssa-loop-im.c (sm_seq_valid_bb): We can also not move volatile accesses. * gcc.dg/tree-ssa/ssa-lim-24.c: New testcase. (cherry picked from commit 4c4f0f7acd6b96ee744ef598cbea5c7046a33654)
[Bug tree-optimization/108821] [11 Regression] LIM reissuing a violatile store when it cannot/should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108821 Richard Biener changed: What|Removed |Added Known to fail||11.3.0 Known to work||11.3.1 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed. Thanks for reporting.
[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695 Aldy Hernandez changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org Priority|P3 |P1 CC|aldyh at redhat dot com|aldyh at gcc dot gnu.org --- Comment #3 from Aldy Hernandez --- Mine. Started with: c92b8be9b52b7e0de5ad67bc268dad1498181908 is the first bad commit commit c92b8be9b52b7e0de5ad67bc268dad1498181908 Author: Aldy Hernandez Date: Sun Feb 19 17:43:43 2023 +0100 Convert internal representation of irange to wide_ints.
[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695 Aldy Hernandez changed: What|Removed |Added Last reconfirmed||2023-05-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug c++/109645] [14 Regression] ICE in instantiate_decl, at cp/pt.cc:27097 since r14-283-g95d4c0d2e6318a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109645 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Summary|ice in instantiate_decl, at |[14 Regression] ICE in |cp/pt.cc:27097 |instantiate_decl, at ||cp/pt.cc:27097 since ||r14-283-g95d4c0d2e6318a --- Comment #8 from Martin Liška --- So started with r14-283-g95d4c0d2e6318a.
[Bug c++/109648] ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13551 since r13-272-gdc6c96f0707aba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109648 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Last reconfirmed||2023-05-02 Summary|ICE: tree check: expected |ICE: tree check: expected |type_pack_expansion or |type_pack_expansion or |expr_pack_expansion, have |expr_pack_expansion, have |error_mark in |error_mark in |tsubst_pack_expansion, at |tsubst_pack_expansion, at |cp/pt.cc:13551 |cp/pt.cc:13551 since ||r13-272-gdc6c96f0707aba Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r13-272-gdc6c96f0707aba.
[Bug libgcc/109685] [13/14 Regression] Memory leak in `__deregister_frame`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109685 --- Comment #1 from Thomas Neumann --- Created attachment 54969 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54969&action=edit fix for the issue
[Bug libgcc/109685] [13/14 Regression] Memory leak in `__deregister_frame`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109685 --- Comment #2 from Thomas Neumann --- I can reproduce the issue. The attached patch fixes the problem, I will send it for reviewing.
[Bug tree-optimization/109689] [14 Regression] ICE at -O1 with "-ftree-vectorize": in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r14-301-gf2d6beb7a4ddf1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109689 Martin Liška changed: What|Removed |Added Summary|[14 Regression] ICE at -O1 |[14 Regression] ICE at -O1 |with "-ftree-vectorize": in |with "-ftree-vectorize": in |check_loop_closed_ssa_def, |check_loop_closed_ssa_def, |at |at |tree-ssa-loop-manip.cc:645 |tree-ssa-loop-manip.cc:645 ||since ||r14-301-gf2d6beb7a4ddf1 CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Started with r14-301-gf2d6beb7a4ddf1.
[Bug c++/109692] [12/13/14 Regression] ICE on concept as default template parameter to iife lambda in fold expression in static member template function since r12-8110-ge2c7070ac77405
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109692 Martin Liška changed: What|Removed |Added Summary|ICE on concept as default |[12/13/14 Regression] ICE |template parameter to iife |on concept as default |lambda in fold expression |template parameter to iife |in static member template |lambda in fold expression |function|in static member template ||function since ||r12-8110-ge2c7070ac77405 Last reconfirmed||2023-05-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r12-8110-ge2c7070ac77405.
[Bug c++/109679] export using for functions does not work as specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109679 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-05-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||rejects-valid --- Comment #2 from Jonathan Wakely --- Confirmed. testfoo.cpp: In function 'int main()': testfoo.cpp:5:10: error: 'foo' was not declared in this scope 5 | return foo(); | ^~~
[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #4 from Aldy Hernandez --- Deep recursion in the ranger is causing us to run out of stack space. This failure coincides with switching the internal representation of irange's to wide_ints which take more space. The problem happens in the waccess pass and can be seen with: --param=ranger-debug=all It looks like we start going bat shit crazy around: 2401 range_on_edge (_1011) on edge 1016->1017 2402 range_on_exit (_1011) from BB 1016 2403 range_of_expr(_1011) at stmt resx 4 2404 range_on_entry (_1011) to BB 1016 2405 range_of_stmt (_1011) at stmt _1011 = PHI <_1947(3), _1010(1013)>
[Bug sanitizer/109698] gcc/g++ build/link fails for libhwasan.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109698 --- Comment #3 from David Richards --- (In reply to Andrew Pinski from comment #1) > What version of ld is this? > > It might be bug there: > https://sourceware.org/bugzilla/show_bug.cgi?id=24458 ld --version: GNU ld (GNU Binutils for Debian) 2.31.1 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. Note: I have built gcc/g++ version 12.2 without issue on this system... Thanks! Dave
[Bug sanitizer/109698] gcc/g++ build/link fails for libhwasan.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109698 --- Comment #4 from David Richards --- ld --version: GNU ld (GNU Binutils for Debian) 2.31.1 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. NOTE: I have built gcc/g++ version 12.2 o0n this same system Thanks! Dave On Tue, May 2, 2023 at 9:18 AM jakub at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109698 > > --- Comment #2 from Jakub Jelinek --- > Seems binutils has added support for __ehdr_start only in > https://sourceware.org/legacy-ml/binutils/2012-06/msg00171.html in 2012. > Do > you have binutils older than that? > > -- > You are receiving this mail because: > You reported the bug.
[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632 --- Comment #10 from rsandifo at gcc dot gnu.org --- After prototyping this further, I no longer think that lowering at the gimple level is the best answer. (I should have listened to Richi.) Although it works, its major drawback is that it's one-sided: it allows the current function's PARM_DECLs and returns to be lowered to individual scalars, but it does nothing for calls to other functions. Being one-sided means (a) that lowering only solves half the problem and (b) that tail calls cannot be handled easily after lowering. One thing that does seem to work is to force the structure to have V2SF (and fix the inevitable ABI fallout). That could only be done conditionally, based on a target hook. But it seems to fix both test cases: the pass-by-reference one and the pass-by-value one.
[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695 --- Comment #5 from Andrew Macleod --- have a look at the changes in waccess... this compiles fine with --disable-tree-waccess1
[Bug fortran/109699] New: With OpenACC reallocating a fortran pointer on a user type with allocatable fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109699 Bug ID: 109699 Summary: With OpenACC reallocating a fortran pointer on a user type with allocatable fails. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: patrick.be...@univ-grenoble-alpes.fr Target Milestone: --- Created attachment 54970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54970&action=edit Test case to show the problem With OpenACC reallocating a fortran pointer on a user type with allocatable fails. Type is: type r2tab double precision, dimension(:,:), allocatable :: val integer :: dim1 integer :: dim2 end type r2tab Variable in main to offload is: type(r2tab), pointer :: tab=>null() Gfortran 14.0 from master branch commit 8d2793ef6b15dbdd347c854f663eb145af5ee593 Author: Marek Polacek Date: Thu Mar 9 18:43:34 2023 -0500 But also 12.2.1 20230302 [OG12] Short test case attached to reproduce. Compilation with gfortran 14 using: gfortran -cpp -g -fopenacc testcase_begou.f90 -o testcase_begou Execution output (wrong) with gfortran from master: $ ./testcase_begou = === 1 === = =>> ajoute: allocating on host and on device =>> ajoute OK > usage in main: set array to 1 on device > usage in main OK Before update from the device, on host (should be 0): 0.00 After update from device, on host shoud be 100: 100.00 =>> destroy datas on device and on host =>> destroy OK = === 2 === = =>> ajoute: allocating on host and on device =>> ajoute OK > usage in main: set array to 2 on device libgomp: cuStreamSynchronize error: an illegal memory access was encountered With gfortran 12.2.1 the error message is a little bit more detailed (only error message below, standard output is the same): libgomp: cuStreamSynchronize error: an illegal memory access was encountered libgomp: cuModuleGetFunction (__do_global_dtors__entry) error: an illegal memory access was encountered libgomp: device finalization failed Hosts used with GNU compilers: - AMD Epyc 7302 + Nvidia A100, CentOS8 - i7-12700H + Nvidia T600, Alma Linux8 Code works on : - AMD Epyc 7302 + Nvidia A100, CentOS8 with Nvfortran 22.5-0: nvfortran -acc=gpu,noautopar -gpu=cc80 -Mpreprocess testcase_begou.f90 -o testcase_begou - i7-12700H + Nvidia T600, Alma Linux8 with Nvfortran 23.3-0: - nvfortran -acc=gpu,noautopar -gpu=cc75 -Mpreprocess testcase_begou.f90 -o testcase_begou - AMD EPYC 7542 + AMD MI 100 with Cray ftn 14.0.2: - ftn -g -hacc -hnoomp -eF testcase_begou.f90 -o testcase_begou Correct output is: = === 1 === = =>> ajoute: allocating on host and on device =>> ajoute OK > usage in main: set array to 1 on device > usage in main OK Before update from the device, on host (should be 0): 0.00 After update from device, on host shoud be 100: 100.00 =>> destroy datas on device and on host =>> destroy OK = === 2 === = =>> ajoute: allocating on host and on device =>> ajoute OK > usage in main: set array to 2 on device > usage in main OK Before update from the device, on host (should be 0): 0.00 After update from device, on host shoud be 800: 800.00 =>> destroy datas on device and on host =>> destroy OK Thanks Patrick
[Bug target/109617] RISC-V: ICE for vlmul_ext_v intrinsic API
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109617 --- Comment #1 from CVS Commits --- The master branch has been updated by Kito Cheng : https://gcc.gnu.org/g:1adb1a653d6739589b12337c974c7e741cfb187c commit r14-395-g1adb1a653d6739589b12337c974c7e741cfb187c Author: Yanzhang Wang Date: Wed Apr 26 21:06:02 2023 +0800 RISC-V: ICE for vlmul_ext_v intrinsic API PR target/109617 gcc/ChangeLog: * config/riscv/vector-iterators.md: Support VNx2HI and VNX4DI when MIN_VLEN >= 128. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/vlmul_ext-1.c: New test. Signed-off-by: Yanzhang Wang Co-authored-by: Pan Li Signed-off-by: Yanzhang Wang
[Bug target/109617] RISC-V: ICE for vlmul_ext_v intrinsic API
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109617 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Kito Cheng --- fixed on trunk
[Bug sanitizer/109700] New: [13/14 regression] ICE with address sanitizer after declaring __builtin_alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109700
Bug ID: 109700
Summary: [13/14 regression] ICE with address sanitizer after
declaring __builtin_alloca
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jlegg at feralinteractive dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Created attachment 54971
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54971&action=edit
Preprocessed source, GCC 13.1.1
When compiling this as C++:
void *__builtin_alloca(unsigned long);
void f(int *);
void g() {
int x;
int *y = (int *)__builtin_alloca(sizeof(int));
*y = 0;
f(&x);
}
using g++ -fsanitize=address -Og test.cpp -c, I get the following error with
GCC 13.1.1:
during GIMPLE pass: ehcleanup
test.cpp: In function ‘void g()’:
test.cpp:3:6: internal compiler error: in mark_reachable_handlers, at
tree-eh.cc:4063
3 | void g() {
| ^
The GCC trunk option on Compiler Explorer currently
((Compiler-Explorer-Build-gcc-4d68c7f7b5aea5e95f44c3af13a24aa3daae9cf5-binutils-2.40)
14.0.0 20230501 (experimental)) has a different internal compiler error:
: In function 'void g()':
:5:6: error: BB 2 cannot throw but has an EH edge
5 | void g() {
| ^
during GIMPLE pass: asan
:5:6: internal compiler error: verify_flow_info failed
0x23643ae internal_error(char const*, ...)
???:0
0xe18267 verify_flow_info()
???:0
GCC 12.2 compiles this code.
[Bug sanitizer/109700] [13/14 regression] ICE with address sanitizer after declaring __builtin_alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109700 Jakub Jelinek changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from Jakub Jelinek --- You are not supposed to declare builtin functions (especially not when the declaration isn't even correct).
[Bug sanitizer/109700] [13/14 regression] ICE with address sanitizer after declaring __builtin_alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109700 --- Comment #2 from Andrew Pinski --- It is replacing __builtin_alloca with __builtin_alloca_with_align . __builtin_alloca is NOT known not to throw with the definition provided and that is the cause of the issue. Adding [[gnu::nothrow]] fixes the issue.
[Bug middle-end/109650] avr-gcc incorrect code with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109650 Georg-Johann Lay changed: What|Removed |Added CC||saaadhu at gcc dot gnu.org --- Comment #6 from Georg-Johann Lay --- As it appears, disabling avr.cc's machine dependent reorg by means of -fdisable-rtl-mach can stop this PR. Maybe avr.cc::avr_reorg() is no more correct after PR92729 because contrary to cc0, now a branch instruction may have more than one CCmode setter. A part of this optimization could be run prior to .split2 when cbranch insns are still intact. In particular transformations like from "if (x <= 2)" to "if (x < 3)" must be performed on cbranch, or otherwise avr_reorg() must check that there is only one CCmode setter, or otherwise adjust *all* CCmode setters. This optimization should not run too early so that avr_reorg_remove_redundant_compare can still do its job on switch-case if-else trees. I am allowing me to add Senthil to CC, maybe he has some ideas.
[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695 --- Comment #6 from Aldy Hernandez --- I forgot to add. Running with "ulimit -s unlimited" does not segfault.
[Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240
--- Comment #6 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #5)
> There are multiple issues.
>
> 1. The out-of-line definition and the inline definition of
> std::type_info::before do different things. Specifically, only one name is
> detected against to '*' in the former, but two in the latter. It seems the
> latter is more correct. ("More", because it is still not quite correct, see
> below.)
I think the latter is completely correct.
> 2. As stated in https://reviews.llvm.org/D100134, mixture of different
> methods of comparisons breaks the ordering.
I don't think that's a problem for our inline implementation.
For non-unique A, unique B, non-unique C we would always do string comparisons,
and we would consistently have "*B" < "A" < "C" in all TUs.
We would only do pointer comparisons for when comparing two unique types, e.g.
comparing "*B" and "*B" or comparing "*B" and "*D".
> I've actually encountered the problem with std::type_index as the key type
> when using flat_map::emplace (like
> https://github.com/WG21-SG14/SG14/blob/master/SG14/flat_map.h, which uses
> std::partition_point to find the position of insertion). The insertion
> suddenly fails when std::partition_point meets two std::type_info objects x
> and y which are unordered. It works with the workaround
> '-U__GXX_MERGED_TYPEINFO_NAMES -D__GXX_MERGED_TYPEINFO_NAMES=1' in the
> compiler command line, but it seems not enough in general without fixing the
> issue 2 here. (Although the same sequence of key on std::map does not fail,
> occasionally, due to less comparisons are made.)
What are the mangled type names that are unordered? (that's all you need to
describe, everything about flat_map and partition_point is irrelevant; just
tell us which names are unordered).
Is this using the inline implementation? (I assume so, otherwise redefining
__GXX_MERGED_TYPEINFO_NAMES won't do anything). How does forcing address
comparisons for all types solve anything? That isn't just "not enough in
general" it's **wrong** in general.
> 3. Not sure the original change in r179236 is correct.
It was an improvement, at least.
> 4. '||' in the condition of the inline definition of std::type_info::before
> seems an overkill. '&&' may be enough. Assuming string comparison is more
> expensive, this is a simple optimization. But once the issue 2 is fixed, the
> change would look quite different.
I don't think that's correct. We can only do a pointer comparison if both
strings begin with '*'. If we compared pointers for "*foo" and "bar" (where
"bar" is not unique), we might have "*foo" < "bar" in one TU and "*foo" >
"bar" in another TU where "bar" has a different address. We need to do a string
comparison if either of them is not unique. Which is what the inline
implementation does.
It also correctly handles the problem case described by Richard Smith, because
all unique names start with '*' and all non-unique names start with one of
[A-Za-z_], and those are ordered after '*', at least for ASCII and UTF-8.
I agree there are issues with the non-inline implementation. We could just make
it match the inline one:
--- a/libstdc++-v3/libsupc++/tinfo2.cc
+++ b/libstdc++-v3/libsupc++/tinfo2.cc
@@ -33,15 +33,11 @@ using std::type_info;
bool
type_info::before (const type_info &arg) const _GLIBCXX_NOEXCEPT
{
-#if __GXX_MERGED_TYPEINFO_NAMES
- return name () < arg.name ();
-#else
- /* The name() method will strip any leading '*' prefix. Therefore
- take care to look at __name rather than name() when looking for
- the "pointer" prefix. */
- return (__name[0] == '*') ? name () < arg.name ()
-: __builtin_strcmp (name (), arg.name ()) < 0;
+#if !__GXX_MERGED_TYPEINFO_NAMES
+ if (__name[0] == '*' || arg.__name[0] == '*')
+return __builtin_strcmp (__name, arg.__name) < 0;
#endif
+ return __name < arg.__name
}
#endif
[Bug fortran/109701] New: I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701
Bug ID: 109701
Summary: I have a MWE where an omp reduction breaks if I add
the option for GPU offloading (even if it isn't used).
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.meltzer1 at gmail dot com
Target Milestone: ---
Created attachment 54972
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54972&action=edit
source code to reproduce bug
I think I have identified a bug when using gfortran and openMP. I have tested
on gfortran versions:
* gfortran 10.3.0
* gfortran 11.3.0
* gfortran 12.2.0
I have posted a question on stackoverflow:
https://stackoverflow.com/questions/76119137/potential-gfortran-or-openmp-bug-when-using-omp-if-and-reduction
Here is mwe:
---
program test
use omp_lib
implicit none
integer, parameter :: N=3
integer:: i, j
real :: a(N,N), b(N,N), max_diff
logical:: is_GPU
is_GPU = .false.
#ifdef USEGPU
is_GPU = .true.
#endif
!$omp target data if(is_GPU) map(to:a, b)
!$omp target teams if(is_GPU)
!$omp distribute parallel do simd collapse(2)
do j = 1, N
do i = 1, N
a(i, j) = i*j
b(i, j) = i*j*0.9
end do
end do
!$omp end target teams
max_diff = 0.0
!$omp target teams if(is_GPU) !< comment this
!$omp distribute parallel do simd reduction(max:max_diff) collapse(2)
do j = 1, N
do i = 1, N
max_diff = max(max_diff, abs(b(i, j) - a(i, j)))
end do
end do
!$omp end target teams !< comment this
write (*,'("max_diff = ", F6.3)') max_diff
!$omp end target data
end program
---
Here is the command to compile and run:
gfortran -cpp -fopenmp mwe.f90 && OMP_NUM_THREADS=2 ./a.out
I have also tried with extra flags (-Wall -Wextra) and there are no reported
warnings.
Expected output is:
max_diff = 0.900
but with gfortran I get:
max_diff = 0.000
It works with nvfortran 22.5-0 (from nvhpc toolkit) but not for gfortran.
Command for nvfortran is:
nvfortran -cpp -mp=multicore mwe.f90 && OMP_NUM_THREADS=2 ./a.out
I want to keep portability so that openMP handles whether I build with GPU or
not. I am aware I can workaround it without openMP "if" statements and instead
use pre-processor directives.
If I comment out the lines marked with (!< comment this) and remove
"distribute" from the line "!$omp distribute parallel do simd
reduction(max:max_diff) collapse(2)" then the code runs as expected.
Am I mis-using the openMP if statements or doing something else which is not
portable or is this a bug?
Please let me know if you need any further information.
gfortran -v 11.3.0 output:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
gfortran -v 12.2.0 output:
Reading specs from
/software/spack/opt/spack/linux-ubuntu22.04-skylake/gcc-11.3.0/gcc-12.2.0-7szeaw2tk7ndv3brjeitsqmi3r6cz2sx/lib/gcc/x86_64-pc-linux-gnu/12.2.0/specs
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/software/spack/opt/spack/linux-ubuntu22.04-skylake/gcc-11.3.0/gcc-12.2.0-7szeaw2tk7ndv3brjeitsqmi3r6cz2sx/libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/tmp/melt/spack-stage/spack-
[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 --- Comment #1 from Thomas Meltzer --- Could be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 but I am not sure. In my case the GPU offloading should be ignored.
[Bug middle-end/109128] [Offload][OpenMP][OpenACC] Static linking with unused offload function will lead to mismatch number of offload fn/symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128 --- Comment #7 from Tobias Burnus --- RFC with patch to extend the linker plugin API: linker side: https://sourceware.org/pipermail/binutils/2023-May/127271.html GCC side: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617277.html
[Bug tree-optimization/109702] New: [14 Regression] Wrong code with if and __builtin_bswap and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109702
Bug ID: 109702
Summary: [14 Regression] Wrong code with if and __builtin_bswap
and others
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: critical
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
I totally messed up the match.pd patterns such that we start to transform:
```
unsigned f(unsigned t, unsigned t1)
{
if (t != 0)
return __builtin_bswap32(t1);
return 0;
}
```
To just `return __builtin_bswap32(t1)` . I only noticed this after the review
of the patch for CLRSB
(https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617228.html ) but the
review didn't fully notice how it was incorrect; just noticed there was an
unused capture.
[Bug tree-optimization/109702] [14 Regression] Wrong code with if and __builtin_bswap and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109702 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-05-02 Target Milestone|--- |14.0 --- Comment #1 from Andrew Pinski --- Mine, I am going to commit a patch to fix this obvious issue later today, just filing it so I have a testcase of what goes wrong.
[Bug sanitizer/109700] ICE with address sanitizer after declaring __builtin_alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109700 Andrew Pinski changed: What|Removed |Added Known to fail||10.1.0, 12.2.0, 8.1.0 Summary|[13/14 regression] ICE with |ICE with address sanitizer |address sanitizer after |after declaring |declaring __builtin_alloca |__builtin_alloca Known to work||7.1.0 --- Comment #3 from Andrew Pinski --- Note GCC 12.2.0 also ICEs; just not with checking enabled (or even just -fchecking).
[Bug sanitizer/109700] ICE with address sanitizer after declaring __builtin_alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109700 --- Comment #4 from Andrew Pinski --- Most likely started with r8-1884-ge3174bdf35c172f (just like PR 104449 ). PR 104449 was supposed to fix part of this but it seems like it didn't.
[Bug sanitizer/109700] ICE with address sanitizer after declaring __builtin_alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109700 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-02 --- Comment #5 from Andrew Pinski --- Note GCC 9.x ICEs even without checking enabled. It just happens GCC 10.x-12.x does not. Anyways don't declare __builtin_alloca; it is NOT needed.
[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||openmp --- Comment #2 from anlauf at gcc dot gnu.org --- If I compile the code with -g -fsanitize=thread, I see a data race in the second loop nest pointing to a possible issue with the reduction.
[Bug libstdc++/109703] New: __builtin_unreachable() reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703
Bug ID: 109703
Summary: __builtin_unreachable() reached
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: christian.morales.vega at gmail dot com
Target Milestone: ---
This
(https://github.com/gcc-mirror/gcc/commit/bf78b43873b0b7e8f9a430df38749b8b61f9c9b8#diff-c8a656ef205ec6452ef0bed111a387dc9e7eb2404fb3222a48f9f93b2460bd55R278)
__builtin_unreachable() is reached using this code
--
#include
#include
int main() {
auto lower = std::string{"0123456789ABCDEF"};
auto upper = boost::algorithm::to_upper_copy(lower);
}
--
with Boost 1.82.
Doing "g++ -O1 -fsanitize=undefined -o main main.cpp && ./main" results in
/usr/include/c++/13/bits/basic_string.h:278:29: runtime error: execution
reached an unreachable program point
This is with gcc-13.1.1-1.fc38.x86_64 from Fedora 38.
AFAICT the bug is in libstdc++.
During the first iteration, is not until
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libstdc%2B%2B-v3/include/bits/basic_string.tcc#L201
that the data pointer is replaced from the SSO to the heap one; but one line
before, in
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libstdc%2B%2B-v3/include/bits/basic_string.tcc#L200
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libstdc%2B%2B-v3/include/bits/basic_string.h#L293
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libstdc%2B%2B-v3/include/bits/basic_string.h#L275
, it checks whether it should destroy the data based on whether _M_data() ==
_M_local_data().
[Bug sanitizer/109700] ICE with address sanitizer after declaring __builtin_alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109700 --- Comment #6 from James Legg --- Yes, declaring bulitin functions is bad, but I didn't expect the ICE. It wasn't done intentionally. glibc's alloca.h defines a alloca(s) macro as __builtin_alloca(s). I had some code defining _alloca as alloca for compatibility with code written to use MSC's _alloca function, and some code intended to build with MSC that attempted to declare _alloca instead of including the appropriate header, but due to macro expansion it was actually declaring __builtin_alloca.
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||13.1.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #25 from anlauf at gcc dot gnu.org --- Fixed in gcc-13.
[Bug c++/109680] [13/14 Regression] is_convertible incorrectly true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680
--- Comment #7 from Marek Polacek ---
Ah, I think I see what's going on here. Once again, the problem is that this
assert no longer passes:
#include
static_assert (!std::is_convertible_v , "");
std::is_convertible does
To test() { return std::declval(); }
here, From is 'int () const'.
std::declval is defined as:
template
typename std::add_rvalue_reference::type declval() noexcept;
Now, std::add_rvalue_reference is defined as "If T is a function type that has
no cv- or ref- qualifier or an object type, provides a member typedef type
which is T&&, otherwise type is T."
In our case, T is cv-qualified, so the result is T, so we end up with
int () const declval() noexcept;
which is invalid. In other words:
using T = int () const;
T fn1(); // bad, fn returning a fn
T& fn2(); // bad, cannot declare reference to qualified function type
T* fn3(); // bad, cannot declare pointer to qualified function type
using U = int ();
U fn4(); // bad, fn returning a fn
U& fn5(); // OK
U* fn6(); // OK
So the check we're looking for is probably
if (TREE_CODE (type) == FUNCTION_TYPE
&& (type_memfn_quals (type) != TYPE_UNQUALIFIED
|| type_memfn_rqual (type) != REF_QUAL_NONE))
but I think it should be put wherever we simulate declval().
[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Thomas Meltzer from comment #1) > Could be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 but I > am not sure. In my case the GPU offloading should be ignored. Replacing the line !$omp target teams if(is_GPU) !< comment this by !$omp target teams if(is_GPU) map(max_diff) seems to make a difference for me. So it might be related to pr99928.
[Bug c++/109640] Spurious Wdangling-reference for argument to temporary lambda cast to rvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109640 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:6b927b1297e66e26e62e722bf15c921dcbbd25b9 commit r13-7276-g6b927b1297e66e26e62e722bf15c921dcbbd25b9 Author: Marek Polacek Date: Tue May 2 15:48:40 2023 -0400 c++: Move -Wdangling-reference to -Wextra [PR109642] Sadly, -Wdangling-reference generates false positives for std::span-like user classes, and it seems imprudent to attempt to improve the heuristic in GCC 13. Let's move the warning to -Wextra, that will hopefully reduce the number of false positives the users have been seeing with 13. I'm leaving the warning in -Wall in 14 where I think I can write code to detect std::span-like classes. PR c++/109642 PR c++/109640 PR c++/109671 gcc/c-family/ChangeLog: * c.opt (Wdangling-reference): Move from -Wall to -Wextra. gcc/ChangeLog: * doc/invoke.texi: Document that -Wdangling-reference is enabled by -Wextra.
[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642 --- Comment #7 from CVS Commits --- The releases/gcc-13 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:6b927b1297e66e26e62e722bf15c921dcbbd25b9 commit r13-7276-g6b927b1297e66e26e62e722bf15c921dcbbd25b9 Author: Marek Polacek Date: Tue May 2 15:48:40 2023 -0400 c++: Move -Wdangling-reference to -Wextra [PR109642] Sadly, -Wdangling-reference generates false positives for std::span-like user classes, and it seems imprudent to attempt to improve the heuristic in GCC 13. Let's move the warning to -Wextra, that will hopefully reduce the number of false positives the users have been seeing with 13. I'm leaving the warning in -Wall in 14 where I think I can write code to detect std::span-like classes. PR c++/109642 PR c++/109640 PR c++/109671 gcc/c-family/ChangeLog: * c.opt (Wdangling-reference): Move from -Wall to -Wextra. gcc/ChangeLog: * doc/invoke.texi: Document that -Wdangling-reference is enabled by -Wextra.
[Bug c++/109671] Spurious dangling reference warning in GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:6b927b1297e66e26e62e722bf15c921dcbbd25b9 commit r13-7276-g6b927b1297e66e26e62e722bf15c921dcbbd25b9 Author: Marek Polacek Date: Tue May 2 15:48:40 2023 -0400 c++: Move -Wdangling-reference to -Wextra [PR109642] Sadly, -Wdangling-reference generates false positives for std::span-like user classes, and it seems imprudent to attempt to improve the heuristic in GCC 13. Let's move the warning to -Wextra, that will hopefully reduce the number of false positives the users have been seeing with 13. I'm leaving the warning in -Wall in 14 where I think I can write code to detect std::span-like classes. PR c++/109642 PR c++/109640 PR c++/109671 gcc/c-family/ChangeLog: * c.opt (Wdangling-reference): Move from -Wall to -Wextra. gcc/ChangeLog: * doc/invoke.texi: Document that -Wdangling-reference is enabled by -Wextra.
[Bug target/89835] The RISC-V target uses amoswap.w for relaxed stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89835 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick O'Neill : https://gcc.gnu.org/g:6a2383f47ae70c31f91775142b9fb03f697741c2 commit r14-403-g6a2383f47ae70c31f91775142b9fb03f697741c2 Author: Patrick O'Neill Date: Wed Apr 5 09:56:33 2023 -0700 RISC-V: Strengthen atomic stores This change makes atomic stores strictly stronger than table A.6 of the ISA manual. This mapping makes the overall patchset compatible with table A.7 as well. 2023-04-27 Patrick O'Neill PR target/89835 gcc/ChangeLog: * config/riscv/sync.md (atomic_store): Use simple store instruction in combination with fence(s). gcc/testsuite/ChangeLog: * gcc.target/riscv/pr89835.c: New test. Signed-off-by: Patrick O'Neill
[Bug libstdc++/109703] [13/14 Regression] __builtin_unreachable() reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703 Andrew Pinski changed: What|Removed |Added Summary|__builtin_unreachable() |[13/14 Regression] |reached |__builtin_unreachable() ||reached Target Milestone|--- |13.2
[Bug libstdc++/109703] [12/13/14 Regression] __builtin_unreachable() reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703 Andrew Pinski changed: What|Removed |Added Target Milestone|13.2|12.3 Summary|[13/14 Regression] |[12/13/14 Regression] |__builtin_unreachable() |__builtin_unreachable() |reached |reached
[Bug c/107127] [11 Regression] Long compile times on code with C complex since r11-3299-gcba079f354a55363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107127 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:21d09955d2b7755db7d5ba3cd4a314930b470da7 commit r11-10682-g21d09955d2b7755db7d5ba3cd4a314930b470da7 Author: Jakub Jelinek Date: Wed Nov 23 19:09:31 2022 +0100 c: Fix compile time hog in c_genericize [PR107127] The complex multiplications result in deeply nested set of many SAVE_EXPRs, which takes even on fast machines over 5 minutes to walk. This patch fixes that by using walk_tree_without_duplicates where it is instant. 2022-11-23 Andrew Pinski Jakub Jelinek PR c/107127 * c-gimplify.c (c_genericize): Use walk_tree_without_duplicates instead of walk_tree for c_genericize_control_r. * gcc.dg/pr107127.c: New test. (cherry picked from commit 8a0fce6a51915c29584427fd376b40073c328090)
[Bug c/107127] [11 Regression] Long compile times on code with C complex since r11-3299-gcba079f354a55363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107127
--- Comment #13 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:21ffe7bc50422bbf2fc844f4e69a16d7e8d35698
commit r11-10683-g21ffe7bc50422bbf2fc844f4e69a16d7e8d35698
Author: Jakub Jelinek
Date: Thu Nov 24 10:33:00 2022 +0100
testsuite: Fix up broken testcase [PR107127]
I've added { dg-options "" } line manually in the patch but
forgot to adjust the number of added lines.
2022-11-24 Jakub Jelinek
PR c/107127
* gcc.dg/pr107127.c (foo): Add missing closing }.
(cherry picked from commit add0f941be18cdf962a0f300019acacbf2325d41)
[Bug middle-end/107317] [10/11 Regression] ICE in emit_redzone_byte, at asan.cc:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:07b397d7720c062d91669d49fbfb644fb3eb81d8 commit r11-10684-g07b397d7720c062d91669d49fbfb644fb3eb81d8 Author: Jakub Jelinek Date: Thu Nov 24 11:29:54 2022 +0100 asan: Fix up error recovery for too large frames [PR107317] asan_emit_stack_protection and functions it calls have various asserts that verify sanity of the stack protection instrumentation. But, that verification can easily fail if we've diagnosed a frame offset overflow. asan_emit_stack_protection just emits some extra code in the prologue, if we've reported errors, we aren't producing assembly, so it doesn't really matter if we don't include the protection code, compilation is going to fail anyway. 2022-11-24 Jakub Jelinek PR middle-end/107317 * asan.c: Include diagnostic-core.h. (asan_emit_stack_protection): Return NULL early if seen_error (). * gcc.dg/asan/pr107317.c: New test. (cherry picked from commit b6330a7685476fc30b8ae9bbf3fca1a9b0d4be95)
[Bug debug/106719] [10/11 Regression] '-fcompare-debug' failure w/ -O2 since r10-6038-ge5e07b68187b9a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106719
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:f187d4c17546df91c3b6b9c0912403d14c6eb3c8
commit r11-10686-gf187d4c17546df91c3b6b9c0912403d14c6eb3c8
Author: Jakub Jelinek
Date: Thu Dec 8 14:57:22 2022 +0100
cfgbuild: Fix DEBUG_INSN handling in find_bb_boundaries [PR106719]
The following testcase FAILs on aarch64-linux. We have some atomic
instruction followed by 2 DEBUG_INSNs (if -g only of course) followed
by NOTE_INSN_EPILOGUE_BEG followed by some USE insn.
Now, split3 pass replaces the atomic instruction with a code sequence
which ends with a conditional jump and the split3 pass calls
find_many_sub_basic_blocks.
For -g0, find_bb_boundaries sees the flow_transfer_insn (the new
conditional
jump), then NOTE_INSN_EPILOGUE_BEG which can live in between basic blocks
and then the USE insn, so splits block after the NOTE_INSN_EPILOGUE_BEG
and puts the NOTE in between the blocks.
For -g, if sees a DEBUG_INSN after the flow_transfer_insn, so sets
debug_insn to it, then walks over another DEBUG_INSN,
NOTE_INSN_EPILOGUE_BEG
until it finally sees the USE insn, and triggers the:
rtx_insn *prev = PREV_INSN (insn);
/* If the first non-debug inside_basic_block_p insn after a
control
flow transfer is not a label, split the block before the debug
insn instead of before the non-debug insn, so that the debug
insns are not lost. */
if (debug_insn && code != CODE_LABEL && code != BARRIER)
prev = PREV_INSN (debug_insn);
code I've added for PR81325. If there are only DEBUG_INSNs, that is
the right thing to do, but if in between debug_insn and insn there are
notes which can stay in between basic blocks or simnilarly JUMP_TABLE_DATA
or their associated CODE_LABELs, it causes -fcompare-debug differences.
The following patch fixes it by clearing debug_insn if JUMP_TABLE_DATA
or associated CODE_LABEL is seen (I'm afraid there is no good answer
what to do with DEBUG_INSNs before those; the code then removes them:
/* Clean up the bb field for the insns between the blocks.
*/
for (x = NEXT_INSN (flow_transfer_insn);
x != BB_HEAD (fallthru->dest);
x = next)
{
next = NEXT_INSN (x);
/* Debug insns should not be in between basic blocks,
drop them on the floor. */
if (DEBUG_INSN_P (x))
delete_insn (x);
else if (!BARRIER_P (x))
set_block_for_insn (x, NULL);
}
but if there are NOTEs, the patch just reorders the NOTEs and DEBUG_INSNs,
such that the NOTEs come first (so that they stay in between basic blocks
like with -g0) and DEBUG_INSNs after those (so that bb is split before
them, so they will be in the basic block after NOTE_INSN_BASIC_BLOCK).
2022-12-08 Jakub Jelinek
PR debug/106719
* cfgbuild.c (find_bb_boundaries): If there are NOTEs in between
debug_insn (seen after flow_transfer_insn) and insn, move NOTEs
before all the DEBUG_INSNs and split after NOTEs. If there are
other insns like jump table data, clear debug_insn.
* gcc.dg/pr106719.c: New test.
(cherry picked from commit d9f9d5d30feb33c359955d7030cc6be50ef6dc0a)
[Bug target/106875] [11 Regression] ICE in ix86_emit_outlined_ms2sysv_save with -mabi=ms -mcall-ms2sysv-xlogues and "#pragma GCC target" since r11-3183-gba948b37768c99cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106875
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:511b878b6a808c3d46dccf806223a851e63ad562
commit r11-10685-g511b878b6a808c3d46dccf806223a851e63ad562
Author: Jakub Jelinek
Date: Mon Nov 28 10:13:43 2022 +0100
i386: Fix up ix86_abi handling [PR106875]
The following testcase fails since my changes to make also
opts_set saved/restored upon function target/optimization changes
(before it has been acting as "has this option be ever explicit
anywhere?").
The problem is that for ix86_abi we depend on the opts_set
value for it in ix86_option_override_internal:
SET_OPTION_IF_UNSET (opts, opts_set, ix86_abi, DEFAULT_ABI);
but as it is a TargetSave, the backend code is required to
save/restore it manually (it does that) and since gcc 11 also
to save/restore the opts_set bit for it (which isn't done).
We don't do that for various other TargetSave which
ix86_function_specific_{save,restore} saves/restores, but as long
as we never test opts_set for it, it doesn't really matter.
One possible fix would be to introduce some new TargetSave into
which ix86_function_specific_{save,restore} would save/restore a bitmask
of the opts_set bits. The following patch uses an easier fix, by
making it a TargetVariable instead the saving/restoring is handled
by the generated code.
The differences in options.h are just slight movements on where
*ix86_abi stuff appears in it, ditto for options.cc, the real
differences are just in options-save.cc, where cl_target_option_save
gets:
+ ptr->x_ix86_abi = opts->x_ix86_abi;
...
+ if (opts_set->x_ix86_abi) mask |= HOST_WIDE_INT_1U << 3;
(plus adjustments of following TargetVariables mask related stuff),
cl_target_option_restore gets:
+ opts->x_ix86_abi = ptr->x_ix86_abi;
...
+ opts_set->x_ix86_abi = static_cast((mask & 1) != 0);
+ mask >>= 1;
plus the movements in other functions too. So, by it being a
TargetVariable, the only thing that changed is that we don't need to
handle it manually in ix86_function_specific_{save,restore} because it
is handled automatically including the opts_set stuff.
2022-11-28 Jakub Jelinek
PR target/106875
* config/i386/i386.opt (x_ix86_abi): Remove TargetSave.
(ix86_abi): Replace it with TargetVariable.
* config/i386/i386-options.c (ix86_function_specific_save,
ix86_function_specific_restore): Don't save and restore x_ix86_abi.
* g++.target/i386/pr106875.C: New test.
(cherry picked from commit ee629d242d9f93a38e49bed904bb334bbe15dde1)
[Bug rtl-optimization/106751] [10/11 Regression] internal compiler error: in purge_dead_edges with inline-asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106751 --- Comment #16 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:945edfa2d24e310bf3549a16f2ea4c881a9a138a commit r11-10690-g945edfa2d24e310bf3549a16f2ea4c881a9a138a Author: Jakub Jelinek Date: Fri Dec 16 10:19:22 2022 +0100 loop-invariant: Split preheader edge if the preheader bb ends with jump [PR106751] The RTL loop passes only request simple preheaders, but don't require fallthru preheaders, while move_invariant_reg apparently assumes the latter, that it can just append instruction(s) to the end of the preheader basic block. The following patch fixes that by splitting the preheader edge if the preheader bb ends with a JUMP_INSN (asm goto in this case). Without that we get control flow in the middle of a bb. 2022-12-16 Jakub Jelinek PR rtl-optimization/106751 * loop-invariant.c (move_invariant_reg): If preheader bb ends with a JUMP_INSN, split the preheader edge and emit invariants into the new preheader basic block. * gcc.c-torture/compile/pr106751.c: New test. (cherry picked from commit ddcaa60983b50378bde1b7e327086fe0ce101795)
[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108095
--- Comment #11 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:9b580f5d7cb3c23866cdbd19e3c1bfc407e9e9c5
commit r11-10688-g9b580f5d7cb3c23866cdbd19e3c1bfc407e9e9c5
Author: Jakub Jelinek
Date: Thu Dec 15 09:26:44 2022 +0100
into-ssa: Fix emitting debug stmts after asm goto [PR108095]
The following testcase ICEs, because ccp1 replaced
s.0_1 = &s;
__asm__ goto("" : "=r" MEM[(T *)s.0_1] : : : "lab" lab);
with
__asm__ goto("" : "=r" s : : : "lab" lab);
and because s is no longer addressable, we are rewriting it into
ssa and want
__asm__ goto("" : "=r" s_7 : : : "lab" lab);
plus debug stmt
# DEBUG s => s_7
The code assumes that there is at most one non-EH edge in that
case, but with the addition of outputs to asm goto that is no longer the
case, we can have many outgoing edges.
The patch keeps the checking assertion that there is at most one such
edge for everything but asm goto, but moves the addition of the debug
stmt into the loop, so that it can be added on all edges where it is
possible, not just one of them.
Furthermore, looking at gsi_insert_on_edge_immediate
-> gimple_find_edge_insert_loc, the conditions to insert stmt there
to the destination block are
if (single_pred_p (dest)
&& gimple_seq_empty_p (phi_nodes (dest))
&& dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
(plus there is code to insert it in the previous block but that is
never true when the pred is known to be stmt_ends_bb_p), while
mayube_register_def was just checking
if (ef && single_pred_p (ef->dest)
&& ef->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
so if for whatever reason ef->dest had any PHIs, we'd split the
edge for -g and not for -g0, something we must avoid for -fcompare-debug
stability. So, I've added the no phi_nodes check too.
2022-12-15 Jakub Jelinek
PR tree-optimization/108095
* tree-into-ssa.c (maybe_register_def): Insert debug stmt
on all non-EH edges from asm goto if they have a single
predecessor rather than asserting there is at most one such edge.
Test whether there are no PHI nodes next to the single predecessor
test.
* gcc.dg/pr108095.c: New test.
(cherry picked from commit bf3ce6f84a7a994a0fc87419b383b9ce4efed442)
[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5a0fd69bb3aa1709f0bea5d6b91fb30ca226c1ed commit r11-10687-g5a0fd69bb3aa1709f0bea5d6b91fb30ca226c1ed Author: Jakub Jelinek Date: Sat Dec 10 16:50:39 2022 +0100 ivopts: Fix IP_END handling for asm goto [PR107997] The following testcase ICEs, because the latch bb ends with asm goto which has both fallthrough to the header and one or more labels in the header too. In that case there is just a single edge out of the latch block, but still the asm goto is stmt_ends_bb_p statement, yet ivopts decides to emit an IV bump at the IP_END position and inserts it into the same bb as the asm goto after it, which then fails verification (control flow in the middle of bb). The following patch fixes it by splitting the latch -> header edge in that case and inserting into the newly created bb, where split_edge -> redirect_edge_and_branch is able to deal with this case correctly. 2022-12-10 Jakub Jelinek PR tree-optimization/107997 * tree-ssa-loop-ivopts.c: Include cfganal.h. (create_new_iv) : If ip_end_pos bb is non-empty and ends with a stmt which ends bb, instead of adding iv update after it split the latch edge and insert iterator into the new latch bb. * gcc.c-torture/compile/pr107997.c: New test. (cherry picked from commit 7676235f690e624b7ed41a22b22ce8ccfac1492f)
[Bug testsuite/108151] gcc.dg/pr64536.c stores pointers in a long, broken for llp64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108151 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ab03e6bdc590393a36d62cf14fe0280529c933ae commit r11-10692-gab03e6bdc590393a36d62cf14fe0280529c933ae Author: Jakub Jelinek Date: Mon Dec 19 15:05:16 2022 +0100 testsuite: Fix up pr64536.c for LLP64 targets [PR108151] Apparently llp64 had 2 further warnings, fixed thusly. 2022-12-19 Jakub Jelinek PR testsuite/108151 * gcc.dg/pr64536.c (bar): Cast long to __INTPTR_TYPE__ before casting to long *. (cherry picked from commit 6e85f89a7d59a99a3395b6e153b99262a58b2f6c)
[Bug tree-optimization/108068] [10/11 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d8f95474581843c605bb97ba83d482d642da3a1b commit r11-10695-gd8f95474581843c605bb97ba83d482d642da3a1b Author: Jakub Jelinek Date: Fri Dec 23 16:12:21 2022 +0100 tree-ssa-dom: can_infer_simple_equiv fixes [PR108068] As reported in the PR, tree-ssa-dom.cc uses real_zerop call to find if a floating point constant is zero and it shouldn't try to infer equivalences from comparison against it if signed zeros are honored. This doesn't work at all for decimal types, because real_zerop always returns false for them (one can have different representations of decimal zero beyond -0/+0), and it doesn't work for vector compares either, as real_zerop checks if all elements are zero, while we need to avoid infering equivalences from comparison against vector constants which have at least one zero element in it (if signed zeros are honored). Furthermore, as mentioned by Joseph, for decimal types many other values aren't singleton. So, this patch stops infering anything if element mode is decimal, and otherwise uses instead of real_zerop a new function, real_maybe_zerop, which will work even for decimal types and for complex or vector will return true if any element is or might be zero (so it returns true for anything but constants for now). 2022-12-23 Jakub Jelinek PR tree-optimization/108068 * tree.h (real_maybe_zerop): Declare. * tree.c (real_maybe_zerop): Define. * tree-ssa-dom.c (record_edge_info): Use it instead of real_zerop or TREE_CODE (op1) == SSA_NAME || real_zerop. Always set can_infer_simple_equiv to false for decimal floating point types. * gcc.dg/dfp/pr108068.c: New test. (cherry picked from commit fd1b0aefda5b65f3f841ca6e61ccea6a72daa060)
