[Bug analyzer/96841] [11 Regression] ICE: tree check: expected integer_cst, have nop_expr in to_wide, at tree.h:5904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96841 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/96646] [11 Regression] ICE: Segmentation fault (in tree_class_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96646 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/94355] support for C++ new expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:d4a906e7b51f3fc31f3328810f45ae4cf2e7bbc3 commit r11-3472-gd4a906e7b51f3fc31f3328810f45ae4cf2e7bbc3 Author: David Malcolm Date: Fri Sep 25 14:31:46 2020 -0400 analyzer: add test for placement new gcc/testsuite/ChangeLog: PR analyzer/94355 * g++.dg/analyzer/placement-new.C: New test.
[Bug analyzer/96841] [11 Regression] ICE: tree check: expected integer_cst, have nop_expr in to_wide, at tree.h:5904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96841 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:29f5db8ef81fac4db8e66e5f06fdf1d469e8161c commit r11-3471-g29f5db8ef81fac4db8e66e5f06fdf1d469e8161c Author: David Malcolm Date: Fri Sep 25 17:15:42 2020 -0400 analyzer: fix ICEs treeifying offset_region [PR96646, PR96841] gcc/analyzer/ChangeLog: PR analyzer/96646 PR analyzer/96841 * region-model.cc (region_model::get_representative_path_var): When handling offset_region, wrap the MEM_REF's first argument in an ADDR_EXPR of pointer type, rather than simply using the tree for the parent region. Require the MEM_REF's second argument to be an integer constant. gcc/testsuite/ChangeLog: PR analyzer/96646 PR analyzer/96841 * gcc.dg/analyzer/pr96646.c: New test. * gcc.dg/analyzer/pr96841.c: New test.
[Bug analyzer/96646] [11 Regression] ICE: Segmentation fault (in tree_class_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96646 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:29f5db8ef81fac4db8e66e5f06fdf1d469e8161c commit r11-3471-g29f5db8ef81fac4db8e66e5f06fdf1d469e8161c Author: David Malcolm Date: Fri Sep 25 17:15:42 2020 -0400 analyzer: fix ICEs treeifying offset_region [PR96646, PR96841] gcc/analyzer/ChangeLog: PR analyzer/96646 PR analyzer/96841 * region-model.cc (region_model::get_representative_path_var): When handling offset_region, wrap the MEM_REF's first argument in an ADDR_EXPR of pointer type, rather than simply using the tree for the parent region. Require the MEM_REF's second argument to be an integer constant. gcc/testsuite/ChangeLog: PR analyzer/96646 PR analyzer/96841 * gcc.dg/analyzer/pr96646.c: New test. * gcc.dg/analyzer/pr96841.c: New test.
[Bug c/97206] [11 Regression] internal compiler error: in composite_type, at c/c-typeck.c:447 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97206 --- Comment #4 from Martin Sebor --- A different/simpler test case that doesn't involve a call to handle_access_attribute(): $ cat pr97206.c && gcc -O2 -S -Wall pr97206.c void a (char *); void a (char [restrict]); extern const char b[]; extern const char b[1]; pr97206.c:5:19: error: conflicting type qualifiers for ‘b’ 5 | extern const char b[1]; | ^ pr97206.c:4:19: note: previous declaration of ‘b’ was here 4 | extern const char b[]; | ^
[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #21 from Marek Polacek --- Implemented in GCC 11.
[Bug c++/88323] implement C++20 language features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323 Bug 88323 depends on bug 88335, which changed state. Bug 88335 Summary: Implement P1073R3, C++20 immediate functions (consteval). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/97201] [11 Regression] ICE in location_wrapper_p at gcc/gcc/tree.h:4002 since r11-3410-g67aeddb785ddcc86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97201 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554893.html
[Bug c++/84930] Brace-closed initialization of cstring (i.e."abcdefghi") to coresponding aggregate types fails in certain situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84930
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #7 from Marek Polacek ---
Related:
const char (&)[5] = {"abc"};
This should work, see [dcl.init.list]/3.10, we should create a temporary of the
referenced type and bind the reference to it.
[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 --- Comment #16 from Yuxuan Shui --- But yeah, that's definitely a bug in itself as well.
[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 --- Comment #15 from Yuxuan Shui --- (In reply to Jonathan Wakely from comment #13) > (In reply to Yuxuan Shui from comment #1) > > Example: > > > > This program normally deadlocks when using linked pthread: > > > > https://godbolt.org/z/Yrza4e > > > > But it will throw recursive_init_error when using dlopen'd pthread: > > > > https://godbolt.org/z/afMe5d > > I'm not sure what these examples are very helpful. Throwing > recursive_init_error is the correct behaviour here, it's a bug that we fail > to detect the recursion when it happens in the same thread. This is just to demonstrate the difference in the behavior. It's easy to imagine this happen in a legitimate use case (and we indeed have one).
[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97211 --- Comment #14 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #13) > I'm not sure what these examples are very helpful. Throwing > recursive_init_error is the correct behaviour here, it's a bug that we fail > to detect the recursion when it happens in the same thread. I created PR 97211 for that.
[Bug libstdc++/97211] New: __cxa_guard_acquire fails to detect recursive init in multithreaded code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97211
Bug ID: 97211
Summary: __cxa_guard_acquire fails to detect recursive init in
multithreaded code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
In a single-threaded program this detects recursive init:
#include
int a() {
static int xx = a();
return 1;
}
extern "C" void* b(void*)
{
a();
return NULL;
}
int main() {
b(NULL);
}
terminate called after throwing an instance of
'__gnu_cxx::recursive_init_error'
what(): std::exception
Aborted (core dumped)
When we know there are no threads in the program we can assume that attempting
to acquire the guard variable when it's already in progress means recursive
init. Because no other thread exists, so it must have been the current thread
that started it, and we've re-entered the initialization.
But if there are multiple threads we just go to sleep waiting forever for
initialization to finish:
#include
int a() {
static int xx = a();
return 1;
}
extern "C" void* b(void*)
{
a();
return NULL;
}
int main() {
pthread_t thrd;
pthread_create(, NULL, b, NULL);
pthread_join(thrd, NULL);
}
Clang makes this work by storing the result of SYS_gettid in the last four
bytes of the guard variable, so it can detect when the same thread re-enters
the guard.
[Bug fortran/97210] New: Intrinsic function get_team() does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97210 Bug ID: 97210 Summary: Intrinsic function get_team() does not work Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 49273 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49273=edit Test case The attached test program fails with the following error message: eams_02_pos.f90:8:9: 8 | init = get_team() | 1 Error: Cannot convert INTEGER(4) to TYPE(team_type) at (1) teams_02_pos.f90:16:19: 16 | if (this_image(init) == me) then | 1 Error: Expected coarray variable as ‘coarray’ argument to the this_image intrinsic at (1) Error: comand: `/opt/gcc/10.2/bin/gfortran -I/opt/gcc/10.2/coarrays_mpich/include/OpenCoarrays-2.9.0_GNU-10.2.0 -fcoarray=lib -Wl,-rpath -Wl,/opt/mpich/3.3.2_gcc10/lib -Wl,--enable-new-dtags teams_02_pos.f90 /opt/gcc/10.2/coarrays_mpich/lib/libcaf_mpi.a /opt/mpich/3.3.2_gcc10/lib/libmpifort.so /opt/mpich/3.3.2_gcc10/lib/libmpi.so` failed to compile. So, apart from missing or incorrectly implemented support for get_team also the TEAM argument for this_image() is not accepted.
[Bug c++/97198] __is_constructible(int[], int) should return true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198 --- Comment #3 from Marek Polacek --- (In reply to Jonathan Wakely from comment #2) > Hmm. It should be false for construction from no arguments i.e. > __is_constructible(int[]). > > But thanks to parenthesized aggregate init, you can actually do: > > using T = int[]; > T t(1); > > It's still true that int[] is incomplete, but in the example above you > actually construct is a int[1] not int[]. Agreed. > I think this should be an LWG issue. Yes, I'd prefer LWG guidance before making any changes here.
[Bug analyzer/97111] Support for exception-handling within -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111
--- Comment #1 from David Malcolm ---
References:
https://en.cppreference.com/w/cpp/language/exceptions
https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html ("Itanium C++ ABI:
Exception Handling")
[Bug c++/97198] __is_constructible(int[], int) should return true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198 --- Comment #2 from Jonathan Wakely --- Hmm. It should be false for construction from no arguments i.e. __is_constructible(int[]). But thanks to parenthesized aggregate init, you can actually do: using T = int[]; T t(1); It's still true that int[] is incomplete, but in the example above you actually construct is a int[1] not int[]. I think this should be an LWG issue.
[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 --- Comment #13 from Jonathan Wakely --- (In reply to Yuxuan Shui from comment #1) > Example: > > This program normally deadlocks when using linked pthread: > > https://godbolt.org/z/Yrza4e > > But it will throw recursive_init_error when using dlopen'd pthread: > > https://godbolt.org/z/afMe5d I'm not sure what these examples are very helpful. Throwing recursive_init_error is the correct behaviour here, it's a bug that we fail to detect the recursion when it happens in the same thread.
[Bug c/97206] [11 Regression] internal compiler error: in composite_type, at c/c-typeck.c:447 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97206 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- Hmm, this one is strange. Somehow the qualifiers on the pointer argument (but not the type it points to) in the function argument list are ending up in the type of the array with unspecified bound. The error is then issued in diagnose_mismatched_decls when verifying that the qualifiers on the array type are the same between the two declarations of b. Something about the change to handle_access_attribute in r11-3303 is causing the restrict qualifier (or any other qualifier on the pointer argument, including const and volatile) to be set on the type of the array. Another test case that reproduces it is: $ cat pr97206.c && gcc -O2 -S -Wall pr97206.c void a (char * volatile); __attribute__((__access__ (__read_only__, 1))) void a (char *volatile); extern const char b[]; extern const char b[1]; pr97206.c:5:19: error: conflicting type qualifiers for ‘b’ 5 | extern const char b[1]; | ^ pr97206.c:4:19: note: previous declaration of ‘b’ was here 4 | extern const char b[]; | ^
[Bug c++/97198] __is_constructible(int[], int) should return true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198 Marek Polacek changed: What|Removed |Added CC||redi at gcc dot gnu.org Status|ASSIGNED|SUSPENDED --- Comment #1 from Marek Polacek --- I'm actually not sure what we want to do. I'd expect: __is_constructible(int[]) // false in any mode __is_constructible(int[], int) // true in C++20, false in C++17 __is_constructible(int[], int, int) // true in C++20, false in C++17 but that would go against PR90532. Suspending until it's clear what we want.
[Bug middle-end/95464] [10 Regression] Miscompilation of mesa on x86_64-linux since r10-6426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:038b65f378b36624b1fd3867fa5e578c1bfa50cc commit r10-8799-g038b65f378b36624b1fd3867fa5e578c1bfa50cc Author: Vladimir N. Makarov Date: Thu Jun 4 12:04:48 2020 -0400 Add processing STRICT_LOW_PART for matched reloads. 2020-06-04 Vladimir Makarov PR middle-end/95464 * lra.c (lra_emit_move): Add processing STRICT_LOW_PART. * lra-constraints.c (match_reload): Use STRICT_LOW_PART in output reload if the original insn has it too. (cherry picked from commit 5261cf8ce824bfc75eb6f12ad5e3716c085b6f9a)
[Bug middle-end/95464] [10 Regression] Miscompilation of mesa on x86_64-linux since r10-6426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:957e37ac288fe6c40ee0bb98a0b06a85be8a35e3 commit r10-8800-g957e37ac288fe6c40ee0bb98a0b06a85be8a35e3 Author: Vladimir N. Makarov Date: Thu Jun 4 13:32:24 2020 -0400 Add test for PR95464.c. 2020-06-04 Vladimir Makarov PR middle-end/95464 * gcc.target/i386/pr95464.c: New. (cherry picked from commit e7ef9a40cd0c688cd331bc26224d1fbe360c1fe6)
[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233 --- Comment #45 from CVS Commits --- The releases/gcc-8 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:1788d74b05b7936e9e8dd01a8f66701ad2bc2951 commit r8-10536-g1788d74b05b7936e9e8dd01a8f66701ad2bc2951 Author: Tamar Christina Date: Thu Jan 10 03:30:59 2019 + AArch64: Implement Armv8.3-a complex arithmetic intrinsics I'd like to backport some patches from Tamar in GCC 9 to GCC 8 that implement the complex arithmetic intrinsics for Advanced SIMD. These should have been present in GCC 8 that gained support for Armv8.3-a. There were 4 follow-up fixes that I've rolled into the one commit. Bootstrapped and tested on aarch64-none-linux-gnu and arm-none-linux-gnueabihf on the GCC 8 branch. gcc/ PR target/71233 * config/aarch64/aarch64-builtins.c (enum aarch64_type_qualifiers): Add qualifier_lane_pair_index. (emit-rtl.h): Include. (TYPES_QUADOP_LANE_PAIR): New. (aarch64_simd_expand_args): Use it. (aarch64_simd_expand_builtin): Likewise. (AARCH64_SIMD_FCMLA_LANEQ_BUILTINS, aarch64_fcmla_laneq_builtin_datum): New. (FCMLA_LANEQ_BUILTIN, AARCH64_SIMD_FCMLA_LANEQ_BUILTIN_BASE, AARCH64_SIMD_FCMLA_LANEQ_BUILTINS, aarch64_fcmla_lane_builtin_data, aarch64_init_fcmla_laneq_builtins, aarch64_expand_fcmla_builtin): New. (aarch64_init_builtins): Add aarch64_init_fcmla_laneq_builtins. (aarch64_expand_buildin): Add AARCH64_SIMD_BUILTIN_FCMLA_LANEQ0_V2SF, AARCH64_SIMD_BUILTIN_FCMLA_LANEQ90_V2SF, AARCH64_SIMD_BUILTIN_FCMLA_LANEQ180_V2SF, AARCH64_SIMD_BUILTIN_FCMLA_LANEQ2700_V2SF, AARCH64_SIMD_BUILTIN_FCMLA_LANEQ0_V4HF, AARCH64_SIMD_BUILTIN_FCMLA_LANEQ90_V4HF, AARCH64_SIMD_BUILTIN_FCMLA_LANEQ180_V4HF, AARCH64_SIMD_BUILTIN_FCMLA_LANEQ270_V4HF. * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Add __ARM_FEATURE_COMPLEX. * config/aarch64/aarch64-simd-builtins.def (fcadd90, fcadd270, fcmla0, fcmla90, fcmla180, fcmla270, fcmla_lane0, fcmla_lane90, fcmla_lane180, fcmla_lane270, fcmla_laneq0, fcmla_laneq90, fcmla_laneq180, fcmla_laneq270, fcmlaq_lane0, fcmlaq_lane90, fcmlaq_lane180, fcmlaq_lane270): New. * config/aarch64/aarch64-simd.md (aarch64_fcmla_lane, aarch64_fcmla_laneqv4hf, aarch64_fcmlaq_lane,aarch64_fcadd, aarch64_fcmla): New. * config/aarch64/arm_neon.h: (vcadd_rot90_f16): New. (vcaddq_rot90_f16): New. (vcadd_rot270_f16): New. (vcaddq_rot270_f16): New. (vcmla_f16): New. (vcmlaq_f16): New. (vcmla_lane_f16): New. (vcmla_laneq_f16): New. (vcmlaq_lane_f16): New. (vcmlaq_rot90_lane_f16): New. (vcmla_rot90_laneq_f16): New. (vcmla_rot90_lane_f16): New. (vcmlaq_rot90_f16): New. (vcmla_rot90_f16): New. (vcmlaq_laneq_f16): New. (vcmla_rot180_laneq_f16): New. (vcmla_rot180_lane_f16): New. (vcmlaq_rot180_f16): New. (vcmla_rot180_f16): New. (vcmlaq_rot90_laneq_f16): New. (vcmlaq_rot270_laneq_f16): New. (vcmlaq_rot270_lane_f16): New. (vcmla_rot270_laneq_f16): New. (vcmlaq_rot270_f16): New. (vcmla_rot270_f16): New. (vcmlaq_rot180_laneq_f16): New. (vcmlaq_rot180_lane_f16): New. (vcmla_rot270_lane_f16): New. (vcadd_rot90_f32): New. (vcaddq_rot90_f32): New. (vcaddq_rot90_f64): New. (vcadd_rot270_f32): New. (vcaddq_rot270_f32): New. (vcaddq_rot270_f64): New. (vcmla_f32): New. (vcmlaq_f32): New. (vcmlaq_f64): New. (vcmla_lane_f32): New. (vcmla_laneq_f32): New. (vcmlaq_lane_f32): New. (vcmlaq_laneq_f32): New. (vcmla_rot90_f32): New. (vcmlaq_rot90_f32): New. (vcmlaq_rot90_f64): New. (vcmla_rot90_lane_f32): New. (vcmla_rot90_laneq_f32): New. (vcmlaq_rot90_lane_f32): New. (vcmlaq_rot90_laneq_f32): New. (vcmla_rot180_f32): New. (vcmlaq_rot180_f32): New. (vcmlaq_rot180_f64): New. (vcmla_rot180_lane_f32): New. (vcmla_rot180_laneq_f32): New. (vcmlaq_rot180_lane_f32): New. (vcmlaq_rot180_laneq_f32): New. (vcmla_rot270_f32): New. (vcmlaq_rot270_f32): New. (vcmlaq_rot270_f64): New. (vcmla_rot270_lane_f32): New. (vcmla_rot270_laneq_f32): New. (vcmlaq_rot270_lane_f32): New. (vcmlaq_rot270_laneq_f32): New.
[Bug fortran/97209] New: TODO: building array references needs a big tidy up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97209 Bug ID: 97209 Summary: TODO: building array references needs a big tidy up Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- The fix for PR97045 flags up the need for rationalization of building array references in trans-array.c and trans.c. The patch works but the result has made this area of gfortran even more difficult to understand and to maintain. At present, I just do not have the bandwidth to do the job but have noted it for the future. If somebody else could take it on that would be great :-) Paul
[Bug target/97127] FMA3 code transformation leads to slowdown on Skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97127 --- Comment #17 from Alexander Monakov --- To me this suggests that in fact it's okay to carry the combined form in RTL up to register allocation, but RA should decompose it to load+fma instead of inserting a register copy that preserves the live operand. (not a fan of "RA should deal with it" theme, but here it does look like the most appropriate resolution)
[Bug ipa/96394] [10/11 Regression] ICE in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #15 from Martin Jambor ---
so after Martin asked some good questions, it turns out this should probably be
avoided in ipa-prop, after all, as with, for example (untested):
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index b28c78eeab4..58ffedc20b1 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -3787,11 +3787,12 @@ update_indirect_edges_after_inlining (struct
cgraph_edge *cs,
param_index = ici->param_index;
jfunc = ipa_get_ith_jump_func (top, param_index);
- cgraph_node *spec_target = NULL;
- /* FIXME: This may need updating for multiple calls. */
- if (ie->speculative)
- spec_target = ie->first_speculative_call_target ()->callee;
+ auto_vec spec_targets;
+ for (cgraph_edge *direct = ie->first_speculative_call_target ();
+ direct;
+ direct = direct->next_speculative_call_target ())
+ spec_targets.safe_push (direct->callee);
if (!opt_for_fn (node->decl, flag_indirect_inlining))
new_direct_edge = NULL;
@@ -3814,7 +3815,7 @@ update_indirect_edges_after_inlining (struct cgraph_edge
*cs,
/* If speculation was removed, then we need to do nothing. */
if (new_direct_edge && new_direct_edge != ie
- && new_direct_edge->callee == spec_target)
+ && spec_targets.contains (new_direct_edge->callee))
{
new_direct_edge->indirect_inlining_edge = 1;
top = IPA_EDGE_REF (cs);
[Bug fortran/97045] A wrong column is selected when addressing individual elements of unlimited polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97045
--- Comment #2 from Paul Thomas ---
Created attachment 49272
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49272=edit
Updated patch
It turned out that with the original patch, character payloads of the unlimited
polymorphic array were still not behaving properly - see the test below.
I am about to submit to the fortran list.
Thanks again
Paul
! { dg-do run }
!
! Test the fix for PR97045. The report was for the INTEGER version. Testing
! revealed a further bug with the character versions.
!
! Contributed by Igor Gayday
!
program test_prg
implicit none
integer :: i
integer, allocatable :: arr(:, :)
character(kind = 1, len = 2), allocatable :: chr(:, :)
character(kind = 4, len = 2), allocatable :: chr4(:, :)
arr = reshape ([(i, i = 1, 9)], [3, 3])
do i = 1, 3
call write_array(arr(1:2, i), i)
end do
chr = reshape([(char (i)//char (i+1), i = 65, 83, 2)], [3, 3])
do i = 1, 3
call write_array (chr(1:2, i), i)
end do
chr4 = reshape([(char (i, kind = 4)//char (i+1, kind = 4), i = 65, 83, 2)], &
[3, 3])
do i = 1, 3
call write_array (chr4(1:2, i), i)
end do
contains
subroutine write_array(array, j)
class(*), intent(in) :: array(:)
integer :: i = 2
integer :: j, k
select type (elem => array(i))
type is (integer)
k = 3*(j-1)+i
if (elem .ne. k) stop 1
type is (character(kind = 1, len = *))
k = 63 + 2*(3*(j-1)+i)
if (elem .ne. char (k)//char (k+1)) print *, elem, " ", char
(k)//char (k+1)
type is (character(kind = 4, len = *))
k = 63 + 2*(3*(j-1)+i)
if (elem .ne. char (k, kind = 4)//char (k+1, kind = 4)) stop 3
end select
end subroutine
end program
[Bug tree-optimization/97201] [11 Regression] ICE in location_wrapper_p at gcc/gcc/tree.h:4002 since r11-3410-g67aeddb785ddcc86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97201 --- Comment #3 from Martin Sebor --- The decision to use null for the upper bound can be traced to this message: https://gcc.gnu.org/pipermail/gcc-patches/2015-December/437361.html
[Bug tree-optimization/97201] [11 Regression] ICE in location_wrapper_p at gcc/gcc/tree.h:4002 since r11-3410-g67aeddb785ddcc86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97201 --- Comment #2 from Martin Sebor --- Just a correction to the comment: + /* Zero-length arrays have a null upper bound in C++ and +SIZE_MAX in C. */ It's actually the other way around.
[Bug tree-optimization/97201] [11 Regression] ICE in location_wrapper_p at gcc/gcc/tree.h:4002 since r11-3410-g67aeddb785ddcc86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97201
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #1 from Martin Sebor ---
Ugh. This is the result of the gratuitous difference in the representation of
zero-length arrays between C and C++. The patch below fixes it though the
difference is a gotcha that will likely keep causing more problems down the
road (I don't think this isn't the first one).
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index ecb41e82d8c..59c915deb1f 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -951,8 +951,9 @@ dump_type_suffix (cxx_pretty_printer *pp, tree t, int
flags)
if (tree dtype = TYPE_DOMAIN (t))
{
tree max = TYPE_MAX_VALUE (dtype);
- /* Zero-length arrays have an upper bound of SIZE_MAX. */
- if (integer_all_onesp (max))
+ /* Zero-length arrays have a null upper bound in C++ and
+SIZE_MAX in C. */
+ if (!max || integer_all_onesp (max))
pp_character (pp, '0');
else if (tree_fits_shwi_p (max))
pp_wide_integer (pp, tree_to_shwi (max) + 1);
[Bug middle-end/95464] [10 Regression] Miscompilation of mesa on x86_64-linux since r10-6426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464 --- Comment #8 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #7) > Vlad, do you plan to backport this to 10.3? I guess so. We had enough time to test it. I don't see any complaints about this patch. I'll backport it today into release/gcc-10 branch.
[Bug c++/97197] With -O2, Incorrect -Werror=maybe-uninitialized thrown, leads to 'target_mem_ref' and 'dump_expr' in message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97197 --- Comment #4 from David Fink --- Hi Jakub, I tried to reduce the code as much as possible before reporting, which is why the example has the "this != " check in the copy constructor. The original code where I saw this problem had the "this != " check in the assignment operator, and the copy constructor called the assignment operator. In the reported version, I manually inlined the assignment operator. I think the original code is also silly, but not as clearly wrong as the pointer check in the copy constructor. Note that the warning happens on a completely different class "Normal" from the silly code "Weirdo", so I'd consider that a bug in addition to the diagnostic containing 'target_mem_ref' and 'dump_expr'.
[Bug jit/97169] [11 Regression] Most jit.dg tests segfaulting (modref_summaries finalizer?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97169 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Fixed by g:c9da53d6987af5f8ff68b58dd76a9fbc900a6a21. With the previous commit, jit.sum had: # of expected passes5751 # of unexpected failures64 # of unresolved testcases 1 with a number of SIGSEGV showing up in the FAIL reports, whereas with g:c9da53d6987af5f8ff68b58dd76a9fbc900a6a21, jit.sum is restored to: # of expected passes10854 Thanks Honza!
[Bug gcov-profile/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 Martin Liška changed: What|Removed |Added Known to fail|11.0| Known to work||11.0 --- Comment #16 from Martin Liška --- Fixed on master so far.
[Bug gcov-profile/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 --- Comment #15 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:1921ebcaf6467996aede69e1bbe32400d8a20fe7 commit r11-3463-g1921ebcaf6467996aede69e1bbe32400d8a20fe7 Author: Martin Liska Date: Fri Sep 25 16:21:34 2020 +0200 gcov: fix streaming of HIST_TYPE_IOR histogram type. gcc/ChangeLog: PR gcov-profile/64636 * value-prof.c (stream_out_histogram_value): Allow negative values for HIST_TYPE_IOR.
[Bug gcov-profile/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 Martin Liška changed: What|Removed |Added Component|lto |gcov-profile CC||marxin at gcc dot gnu.org Status|WAITING |ASSIGNED
[Bug gcov-profile/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #14 from Martin Liška --- Confirmed.
[Bug ipa/96394] [10/11 Regression] ICE in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394 --- Comment #14 from Martin Jambor --- I can confirm the analysis, except that I see the edge we're trying to add to the heap as already inlined (as a speculative edge it got inlined even its caller was). Also just not adding an edge with non-NULL aux works for me - and at least I cannot think of anything smarter, I guess the inliner has to figure out it has already dealt with it. If it indeed can cause an assert failure in estimate_calls_size_and_time then I think we simply we need to force it not to "use_table" when it next comes around to the caller.
[Bug target/97127] FMA3 code transformation leads to slowdown on Skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97127
--- Comment #16 from Alexander Monakov ---
Mostly because prior to register allocation the compiler does not naturally see
that x = *mem + a*b will need an extra mov when both 'a' and 'b' are live (as
in that case registers allocated for them cannot be immediately reused for
'x').
(this is why RTL combine merges the two instructions, but on the isolated
testcase below we already have the combined form thanks to tree-TER)
Isolated testcase, by the way (gcc -O2 -mfma):
double f(double t, double a, double b, double c[], long i)
{
t = __builtin_fma(a, b, c[i]);
asm("" :: "x"(t), "x"(a), "x"(b));
return t;
}
[Bug c++/97197] With -O2, Incorrect -Werror=maybe-uninitialized thrown, leads to 'target_mem_ref' and 'dump_expr' in message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97197 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The this != check makes no sense, invoking a copy constructor on itself is just wrong and if the compiler isn't able to optimize that bogus check early enough, that is the reason why you get the warning. Just don't do that. The compiler bug is the lack of TARGET_MEM_REF support in the diagnostic of course.
[Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Latent issue fixed as well.
[Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d16b5975ca985cbe97698479fc38b6a636886978 commit r11-3460-gd16b5975ca985cbe97698479fc38b6a636886978 Author: Richard Biener Date: Fri Sep 25 11:13:13 2020 +0200 middle-end/96814 - fix VECTOR_BOOLEAN_TYPE_P CTOR RTL expansion The RTL expansion code for CTORs doesn't handle VECTOR_BOOLEAN_TYPE_P with bit-precision elements correctly as the testcase shows before the PR97085 fix. The following makes it do the correct thing (not 100% sure for CTOR of sub-vectors due to the lack of a testcase). The alternative would be to assert such CTORs do not happen (and also add IL verification for this). The GIMPLE FE needs a way to declare the VECTOR_BOOLEAN_TYPE_P vectors (thus the C FE needs that). 2020-09-25 Richard Biener PR middle-end/96814 * expr.c (store_constructor): Handle VECTOR_BOOLEAN_TYPE_P CTORs correctly. * gcc.target/i386/pr96814.c: New testcase.
[Bug c/97208] New: [gcc 10.2.0] Microblaze regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97208 Bug ID: 97208 Summary: [gcc 10.2.0] Microblaze regression Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: romain.naour at gmail dot com Target Milestone: --- Hello, Toolchains using gcc 10.2.0 targeting Microblaze architecture are not able to build a bootable Linux kernel 5.4.58 under Qemu (5.0.0). https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359542 (glibc) https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359544 (musl) https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359546 (uclibc-ng) Toolchain components versions: GCC 10.2 binutils 2.34 kernel headers 5.4.58 The same system boot as soon as gcc 9.3 is used. Best regards, Romain
[Bug target/97127] FMA3 code transformation leads to slowdown on Skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97127 --- Comment #15 from Michael_S --- (In reply to Hongtao.liu from comment #14) > > Still I don't understand why compiler does not compare the cost of full loop > > body after combining to the cost before combining and does not come to > > conclusion that combining increased the cost. > > As Richard says, GCC does not model CPU pipelines in such detail. I don't understand what "details" you have in mind. The costs of instructions that you quoted above looks fine. But for reason, I don't understand, compiler had chosen more costly "combined" code sequence over less costly, according to its own cost model, "RISCy" sequence.
[Bug c++/97202] GCC reports an error: expected unqualified-id before ‘short’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202 Marek Polacek changed: What|Removed |Added Target Milestone|11.0|---
[Bug c++/97202] GCC reports an error: expected unqualified-id before ‘short’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202 Marek Polacek changed: What|Removed |Added Keywords|rejects-valid |diagnostic Status|RESOLVED|ASSIGNED Last reconfirmed||2020-09-25 Summary|[11 Regression] GCC reports |GCC reports an error: |an error: expected |expected unqualified-id |unqualified-id before |before ‘short’ |‘short’ | Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- Actually, let me reopen this to improve the diagnostic.
[Bug c++/97202] [11 Regression] GCC reports an error: expected unqualified-id before ‘short’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202 Marek Polacek changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- This is C++20 DR 2237, disallow simple-template-id in cdtor: see [diff.cpp17.class]p2. Just the diagnostic we give is horrible ;(. Remove to make this work.
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 --- Comment #21 from Richard Biener --- (In reply to Kewen Lin from comment #18) > (In reply to Richard Biener from comment #10) > > (In reply to Kewen Lin from comment #9) > > > (In reply to Richard Biener from comment #8) > > > > (In reply to Kewen Lin from comment #7) > > > > > Two questions in mind, need to dig into it further: > > > > > 1) from the assembly of scalar/vector code, I don't see any stores > > > > > needed > > > > > into temp array d (array diff in pixel_sub_wxh), but when modeling we > > > > > consider the stores. > > > > > > > > Because when modeling they are still there. There's no good way around > > > > this. > > > > > > > > > > I noticed the stores get eliminated during FRE. Can we consider running > > > FRE > > > once just before SLP? a bad idea due to compilation time? > > > > Yeah, we already run FRE a lot and it is one of the more expensive passes. > > > > Note there's one point we could do better which is the embedded SESE FRE > > run from cunroll which is only run before we consider peeling an outer loop > > and thus not for the outermost unrolled/peeled code (but the question would > > be from where / up to what to apply FRE to). On x86_64 this would apply to > > the unvectorized but then unrolled outer loop from pixel_sub_wxh which feeds > > quite bad IL to the SLP pass (but that shouldn't matter too much, maybe it > > matters for costing though). > > By following this idea, to release the restriction on loop_outer > (loop_father) when setting the father_bbs, I can see FRE works as > expectedly. But it actually does the rpo_vn from cfun's entry to its exit. Yeah, that's the reason we do not do it. We could possibly restrict it to a containing loop, or if the containing loop is the whole function, restrict it to the original preheader block to the loop exits (which are no longer there, we'd need to pre-record those I think) > If it's taken as costly, we probably can guard it to take effects only when > all its inner loops are unrolled, for this case, all of its three loops are > unrolled. The original reason VN is done on unrolled bodies is to improve cost estimates on unrolling nests - since we do not unroll the non-existing outer loop of the outermost loop applying VN there for this reason is pointless and the reasoning is to simply wait for the next scheduled VN pass (which is too late for SLP) > Besides, when SLP happens, FRE gen the bit_field_ref and remove array d, but > for scalar codes it needs one more time dse run after cunroll to get array d > eliminated. I guess it's not costly? Can one pass be run or not controlled > by something in another pass? via global variable and add one parameter in > passes.def seems weird. If it's costly, probably we can go by factoring out > one routine to be called instead of running a pass, like do_rpo_vn? No, we don't have a good way to schedule passes from other passes. And yes, the way forward is to support key transforms on regions. Oh, and every pass that does memory alias analysis (DSE, DCE, VN, etc.) is costly. What we could eventually do is move the non-loop SLP pass later and run the loop SLP pass only on loop bodies (so overall every BB is just SLP vectorized once). The PUSH_INSERT_PASSES_WITHIN (pass_tree_no_loop) NEXT_PASS (pass_slp_vectorize); POP_INSERT_PASSES () pass would then be unconditional and only run on non-loop BBs. Note that SLP still leaves us with FRE opportunities so this will probably not solve the issue fully. Pass reorderings are also always tricky... (adding passes is easy but piling these up over the time is bad).
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 --- Comment #20 from Richard Biener --- (In reply to Kewen Lin from comment #19) > (In reply to rguent...@suse.de from comment #17) > > On Fri, 18 Sep 2020, linkw at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 > > > > > > --- Comment #15 from Kewen Lin --- > > > (In reply to rguent...@suse.de from comment #14) > > > > On Fri, 18 Sep 2020, linkw at gcc dot gnu.org wrote: > > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 > > > > > > > > > > --- Comment #13 from Kewen Lin --- > > > > > > 2) on Power, the conversion from unsigned char to unsigned short > > > > > > is nop > > > > > > conversion, when we counting scalar cost, it's counted, then add > > > > > > costs 32 > > > > > > totally onto scalar cost. Meanwhile, the conversion from unsigned > > > > > > short to > > > > > > signed short should be counted but it's not (need to check why > > > > > > further). > > > > > > > > > > UH to SH conversion is true when calling vect_nop_conversion_p, so > > > > > it's not > > > > > even put into the cost vector. > > > > > > > > > > tree_nop_conversion_p's comments saying: > > > > > > > > > > /* Return true iff conversion from INNER_TYPE to OUTER_TYPE generates > > > > >no instruction. */ > > > > > > > > > > I may miss something here, but UH to SH conversion does need one > > > > > explicit > > > > > extend instruction *extsh*, the precision/mode equality check looks > > > > > wrong for > > > > > this conversion. > > > > > > > > Well, it isn't a RTL predicate and it only needs extension because > > > > there's never a HImode pseudo but always SImode subregs. > > > > > > Thanks Richi! Should we take care of this case? or neglect this kind of > > > extension as "no instruction"? I was intent to handle it in target > > > specific > > > code, but it isn't recorded into cost vector while it seems too heavy to > > > do the > > > bb_info slp_instances revisits in finish_cost. > > > > I think it's not something we should handle on GIMPLE. > > Got it! For > > else if (vect_nop_conversion_p (stmt_info)) > continue; > > Is it a good idea to change it to call record_stmt_cost like the others? > 1) introduce one vect_cost_for_stmt enum type eg: nop_stmt > 2) builtin_vectorization_cost return zero for it by default as before. > 3) targets can adjust the cost according to its need I think this early-out was added for the case where there was no cost but the target costed it. So at least go back and look what target that was and see if it can be adjusted.
[Bug c++/97198] __is_constructible(int[], int) should return true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207 --- Comment #16 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7bfc4cd2c812a3197c09797796828459714f8849 commit r11-3459-g7bfc4cd2c812a3197c09797796828459714f8849 Author: Richard Biener Date: Fri Sep 25 13:59:15 2020 +0200 middle-end/97207 - implement move assign for auto_vec<> This implements the missing move assignment to make std::swap work on auto_vec<> 2020-09-25 Richard Biener PR middle-end/97207 * vec.h (auto_vec::operator=(auto_vec&&)): Implement.
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 --- Comment #19 from Kewen Lin --- (In reply to rguent...@suse.de from comment #17) > On Fri, 18 Sep 2020, linkw at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 > > > > --- Comment #15 from Kewen Lin --- > > (In reply to rguent...@suse.de from comment #14) > > > On Fri, 18 Sep 2020, linkw at gcc dot gnu.org wrote: > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 > > > > > > > > --- Comment #13 from Kewen Lin --- > > > > > 2) on Power, the conversion from unsigned char to unsigned short is > > > > > nop > > > > > conversion, when we counting scalar cost, it's counted, then add > > > > > costs 32 > > > > > totally onto scalar cost. Meanwhile, the conversion from unsigned > > > > > short to > > > > > signed short should be counted but it's not (need to check why > > > > > further). > > > > > > > > UH to SH conversion is true when calling vect_nop_conversion_p, so it's > > > > not > > > > even put into the cost vector. > > > > > > > > tree_nop_conversion_p's comments saying: > > > > > > > > /* Return true iff conversion from INNER_TYPE to OUTER_TYPE generates > > > >no instruction. */ > > > > > > > > I may miss something here, but UH to SH conversion does need one > > > > explicit > > > > extend instruction *extsh*, the precision/mode equality check looks > > > > wrong for > > > > this conversion. > > > > > > Well, it isn't a RTL predicate and it only needs extension because > > > there's never a HImode pseudo but always SImode subregs. > > > > Thanks Richi! Should we take care of this case? or neglect this kind of > > extension as "no instruction"? I was intent to handle it in target specific > > code, but it isn't recorded into cost vector while it seems too heavy to do > > the > > bb_info slp_instances revisits in finish_cost. > > I think it's not something we should handle on GIMPLE. Got it! For else if (vect_nop_conversion_p (stmt_info)) continue; Is it a good idea to change it to call record_stmt_cost like the others? 1) introduce one vect_cost_for_stmt enum type eg: nop_stmt 2) builtin_vectorization_cost return zero for it by default as before. 3) targets can adjust the cost according to its need
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #17 from Richard Biener --- Fixed then.
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 --- Comment #18 from Kewen Lin --- (In reply to Richard Biener from comment #10) > (In reply to Kewen Lin from comment #9) > > (In reply to Richard Biener from comment #8) > > > (In reply to Kewen Lin from comment #7) > > > > Two questions in mind, need to dig into it further: > > > > 1) from the assembly of scalar/vector code, I don't see any stores > > > > needed > > > > into temp array d (array diff in pixel_sub_wxh), but when modeling we > > > > consider the stores. > > > > > > Because when modeling they are still there. There's no good way around > > > this. > > > > > > > I noticed the stores get eliminated during FRE. Can we consider running FRE > > once just before SLP? a bad idea due to compilation time? > > Yeah, we already run FRE a lot and it is one of the more expensive passes. > > Note there's one point we could do better which is the embedded SESE FRE > run from cunroll which is only run before we consider peeling an outer loop > and thus not for the outermost unrolled/peeled code (but the question would > be from where / up to what to apply FRE to). On x86_64 this would apply to > the unvectorized but then unrolled outer loop from pixel_sub_wxh which feeds > quite bad IL to the SLP pass (but that shouldn't matter too much, maybe it > matters for costing though). By following this idea, to release the restriction on loop_outer (loop_father) when setting the father_bbs, I can see FRE works as expectedly. But it actually does the rpo_vn from cfun's entry to its exit. If it's taken as costly, we probably can guard it to take effects only when all its inner loops are unrolled, for this case, all of its three loops are unrolled. Besides, when SLP happens, FRE gen the bit_field_ref and remove array d, but for scalar codes it needs one more time dse run after cunroll to get array d eliminated. I guess it's not costly? Can one pass be run or not controlled by something in another pass? via global variable and add one parameter in passes.def seems weird. If it's costly, probably we can go by factoring out one routine to be called instead of running a pass, like do_rpo_vn?
[Bug tree-optimization/97199] ICE in process_bb at gcc/tree-ssa-sccvn.c:7250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97199 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed then.
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #15 from Tom de Vries ---
(In reply to Richard Biener from comment #9)
> diff --git a/gcc/vec.h b/gcc/vec.h
> index d73d865cff2..c0e577893a3 100644
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -1546,7 +1546,12 @@ public:
>this->m_vec = r.m_vec;
>r.m_vec = NULL;
> }
> - void operator= (auto_vec&&) = delete;
> + void operator= (auto_vec&& r)
> +{
> + this->release ();
> + this->m_vec = r.m_vec;
> + r.m_vec = NULL;
> +}
> };
>
>
>
> works for the vec.c test, Tom - can you check if it works for nvptx?
It does.
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #14 from Richard Biener ---
OK, adding explicit swap doesn't look worth the trouble (the object is just a
single pointer). Might be useful if we ever support std::move for auto_vec with N != 0. Which reminds me that still uses broken default
implementations.
I am testing the following, sorry for my limited C++ knowledge... (but
seriously I didn't expect a std::swap(auto_vec) user...)
diff --git a/gcc/vec.h b/gcc/vec.h
index d73d865cff2..d8c7cdac073 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1546,7 +1546,13 @@ public:
this->m_vec = r.m_vec;
r.m_vec = NULL;
}
- void operator= (auto_vec&&) = delete;
+ auto_vec& operator= (auto_vec&& r)
+{
+ this->release ();
+ this->m_vec = r.m_vec;
+ r.m_vec = NULL;
+ return *this;
+}
};
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #13 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> If you don't want to support assignment you can still support swapping:
>
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -1546,9 +1546,21 @@ public:
>this->m_vec = r.m_vec;
>r.m_vec = NULL;
> }
> +
>void operator= (auto_vec&&) = delete;
> +
> + void swap(auto_vec&& r)
> +{
> + std::swap(this->m_vec = r.m_vec);
Oops, copy error, that should be:
std::swap(this->m_vec, r.m_vec);
To add move assignment and swap:
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1546,9 +1546,26 @@ public:
this->m_vec = r.m_vec;
r.m_vec = NULL;
}
- void operator= (auto_vec&&) = delete;
+
+ auto_vec& operator= (auto_vec&& r)
+{
+ this->release();
+ this->swap(r);
+ return *this;
+}
+
+ void swap(auto_vec&& r)
+{
+ std::swap(this->m_vec, r.m_vec);
+}
};
+template
+void swap(auto_vec& l, auto_vec& r)
+{
+ l.swap(r);
+}
+
/* Allocate heap memory for pointer V and create the internal vector
with space for NELEMS elements. If NELEMS is 0, the internal
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #12 from Jonathan Wakely ---
(In reply to Richard Biener from comment #9)
> diff --git a/gcc/vec.h b/gcc/vec.h
> index d73d865cff2..c0e577893a3 100644
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -1546,7 +1546,12 @@ public:
>this->m_vec = r.m_vec;
>r.m_vec = NULL;
> }
> - void operator= (auto_vec&&) = delete;
> + void operator= (auto_vec&& r)
> +{
> + this->release ();
> + this->m_vec = r.m_vec;
> + r.m_vec = NULL;
> +}
> };
>
>
>
> works for the vec.c test, Tom - can you check if it works for nvptx?
Assignment operators should return a reference to *this, not void.
Don't break conventions without good reason.
I suggest adding move assignment *and* swap. Then swap(v1, v2) can be more
efficient than the generic std::swap(v1, v2) by swapping directly, instead of
move-constructing a temporary and then assigning twice.
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #11 from Jonathan Wakely ---
(In reply to rguent...@suse.de from comment #8)
> On Fri, 25 Sep 2020, redi at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
> >
> > --- Comment #7 from Jonathan Wakely ---
> > (In reply to Richard Biener from comment #4)
> > > That swap couldn't have worked before because auto_vec eventually
> > > contains a
> > > pointer into itself. So the patch has improved things from broken to
> > > rejected. Rejected because while there's a move CTOR now, std::swap isn't
> > > happy with just that.
> > >
> > > No idea why - Jonathan?
> >
> > Because swap requires assignment, not just construction.
> >
> > I don't see a libstdc++ bug here.
>
> But there is assignment? Just no move assignment?
No there isn't. You deleted the move assignment operator, so there's no
assignment at all.
Swap uses move assignment anyway.
> I guess swap
> is really special because clearly formerly
>
> {
> auto_vec a, b;
> a.safe_push (1);
> b = a;
> }
>
> would have caused a double-free. std::swap fixes this because, well,
> it swaps. Going to try implement move assignment then.
>
> Just wonder why when move assingment is not there it doesn't
> fall back to non-move assignment semantics (aka previous behavior)
Because you deleted it, that says you don't want assignment.
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #9 from Richard Biener ---
diff --git a/gcc/vec.h b/gcc/vec.h
index d73d865cff2..c0e577893a3 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1546,7 +1546,12 @@ public:
this->m_vec = r.m_vec;
r.m_vec = NULL;
}
- void operator= (auto_vec&&) = delete;
+ void operator= (auto_vec&& r)
+{
+ this->release ();
+ this->m_vec = r.m_vec;
+ r.m_vec = NULL;
+}
};
works for the vec.c test, Tom - can you check if it works for nvptx?
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #10 from Jonathan Wakely ---
If you don't want to support assignment you can still support swapping:
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1546,9 +1546,21 @@ public:
this->m_vec = r.m_vec;
r.m_vec = NULL;
}
+
void operator= (auto_vec&&) = delete;
+
+ void swap(auto_vec&& r)
+{
+ std::swap(this->m_vec = r.m_vec);
+}
};
+template
+void swap(auto_vec& l, auto_vec& r)
+{
+ l.swap(r);
+}
+
/* Allocate heap memory for pointer V and create the internal vector
with space for NELEMS elements. If NELEMS is 0, the internal
Then use swap(v1, v2) not std::swap(v1, v2)
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #8 from rguenther at suse dot de ---
On Fri, 25 Sep 2020, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
>
> --- Comment #7 from Jonathan Wakely ---
> (In reply to Richard Biener from comment #4)
> > That swap couldn't have worked before because auto_vec eventually contains a
> > pointer into itself. So the patch has improved things from broken to
> > rejected. Rejected because while there's a move CTOR now, std::swap isn't
> > happy with just that.
> >
> > No idea why - Jonathan?
>
> Because swap requires assignment, not just construction.
>
> I don't see a libstdc++ bug here.
But there is assignment? Just no move assignment? I guess swap
is really special because clearly formerly
{
auto_vec a, b;
a.safe_push (1);
b = a;
}
would have caused a double-free. std::swap fixes this because, well,
it swaps. Going to try implement move assignment then.
Just wonder why when move assingment is not there it doesn't
fall back to non-move assignment semantics (aka previous behavior)
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207 --- Comment #7 from Jonathan Wakely --- (In reply to Richard Biener from comment #4) > That swap couldn't have worked before because auto_vec eventually contains a > pointer into itself. So the patch has improved things from broken to > rejected. Rejected because while there's a move CTOR now, std::swap isn't > happy with just that. > > No idea why - Jonathan? Because swap requires assignment, not just construction. I don't see a libstdc++ bug here.
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207 --- Comment #6 from Richard Biener --- OK, so diff --git a/gcc/vec.c b/gcc/vec.c index a28899170ed..0cda3b96beb 100644 --- a/gcc/vec.c +++ b/gcc/vec.c @@ -560,6 +560,9 @@ vec_c_tests () test_qsort (); test_reverse (); test_auto_delete_vec (); + auto_vec a; + auto_vec b; + std::swap (a, b); } } // namespace selftest produces a similar error: /home/rguenther/src/gcc3/gcc/vec.c: In function 'void selftest::vec_c_tests()': /home/rguenther/src/gcc3/gcc/vec.c:565:18: error: no matching function for call to 'swap(auto_vec&, auto_vec&)' std::swap (a, b); ^ In file included from /usr/include/c++/7/bits/nested_exception.h:40:0, from /usr/include/c++/7/exception:143, from /usr/include/c++/7/new:40, from /home/rguenther/src/gcc3/gcc/system.h:236, from /home/rguenther/src/gcc3/gcc/vec.c:30: /usr/include/c++/7/bits/move.h:187:5: note: candidate: template typename std::enable_if >, std::is_move_constructible<_Tp>, std::is_move_assignable<_Tp> >::value>::type std::swap(_Tp&, _Tp&) swap(_Tp& __a, _Tp& __b) ^~~~ /usr/include/c++/7/bits/move.h:187:5: note: template argument deduction/substitution failed: /usr/include/c++/7/bits/move.h: In substitution of 'template typename std::enable_if >, std::is_move_constructible<_Tp>, std::is_move_assignable<_Tp> >::value>::type std::swap(_Tp&, _Tp&) [with _Tp = auto_vec]': /home/rguenther/src/gcc3/gcc/vec.c:565:18: required from here /usr/include/c++/7/bits/move.h:187:5: error: no type named 'type' in 'struct std::enable_if' /usr/include/c++/7/bits/move.h:210:5: note: candidate: template typename std::enable_if::value>::type std::swap(_Tp (&)[_Nm], _Tp (&)[_Nm]) swap(_Tp (&__a)[_Nm], _Tp (&__b)[_Nm]) ^~~~ /usr/include/c++/7/bits/move.h:210:5: note: template argument deduction/substitution failed: /home/rguenther/src/gcc3/gcc/vec.c:565:18: note: mismatched types '_Tp [_Nm]' and 'auto_vec' std::swap (a, b); ^ In file included from /usr/include/c++/7/utility:70:0, from /home/rguenther/src/gcc3/gcc/system.h:237, from /home/rguenther/src/gcc3/gcc/vec.c:30: /usr/include/c++/7/bits/stl_pair.h:495:5: note: candidate: template typename std::enable_if, std::__is_swappable<_T2> >::value>::type std::swap(std::pair<_T1, _T2>&, std::pair<_T1, _T2>&) swap(pair<_T1, _T2>& __x, pair<_T1, _T2>& __y) ^~~~ /usr/include/c++/7/bits/stl_pair.h:495:5: note: template argument deduction/substitution failed: /home/rguenther/src/gcc3/gcc/vec.c:565:18: note: 'auto_vec' is not derived from 'std::pair<_T1, _T2>' std::swap (a, b); ^ In file included from /usr/include/c++/7/utility:70:0, from /home/rguenther/src/gcc3/gcc/system.h:237, from /home/rguenther/src/gcc3/gcc/vec.c:30: /usr/include/c++/7/bits/stl_pair.h:503:5: note: candidate: template typename std::enable_if<(! std::__and_, std::__is_swappable<_T2> >::value)>::type std::swap(std::pair<_T1, _T2>&, std::pair<_T1, _T2>&) swap(pair<_T1, _T2>&, pair<_T1, _T2>&) = delete; ^~~~ /usr/include/c++/7/bits/stl_pair.h:503:5: note: template argument deduction/substitution failed: /home/rguenther/src/gcc3/gcc/vec.c:565:18: note: 'auto_vec' is not derived from 'std::pair<_T1, _T2>' std::swap (a, b); ^ make: *** [Makefile:1123: vec.o] Error 1 IMHO looks like a libstdc++ bug to me?
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207 --- Comment #5 from Richard Biener --- Maybe try implementing the deleted void operator= (auto_vec&&) = delete; but the diagnostic isn't really pointing to that ...
[Bug tree-optimization/97199] ICE in process_bb at gcc/tree-ssa-sccvn.c:7250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97199 --- Comment #5 from Martin Liška --- (In reply to Richard Biener from comment #4) > Fixed on trunk, not sure how important it is to backport. I wouldn't backport it. The strange options come from my periodic fuzzing and it took quite some time to find this issue.
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207 Richard Biener changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #4 from Richard Biener --- That swap couldn't have worked before because auto_vec eventually contains a pointer into itself. So the patch has improved things from broken to rejected. Rejected because while there's a move CTOR now, std::swap isn't happy with just that. No idea why - Jonathan?
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207 --- Comment #3 from Tom de Vries --- Created attachment 49271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49271=edit gzipped preprocessed source Reproduce: $ g++ -m64 -fno-PIE -c -O0 -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -fpreprocessed nvptx.c -Wno-implicit-fallthrough nvptx.c: In member function ‘void bb_sese::append(bb_sese*)’: /home/vries/nvptx/trunk/source-gcc/gcc/config/nvptx/nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’ std::swap (brackets, child->brackets); ^ ...
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207 --- Comment #2 from Tom de Vries --- Configure from build-gcc/config.log: ... $ /home/vries/nvptx/trunk/source-gcc/configure --target=nvptx-none --prefix= --enable-languages=c,c++,fortran --enable-werror --enable-checking=yes CC=gcc -m64 -Wl,-rpath,/i686-pc-linux-gnu/lib64 CXX=g++ -m64 -Wl,-rpath,/i686-pc-linux-gnu/lib64 --enable-linker-plugin-flags=CC=gcc\ -m32\ -Wl,-rpath,/i686-pc-linux-gnu/lib --enable-linker-plugin-configure-flags=--host=i686-pc-linux-gnu --with-sysroot=/nvptx-none --with-build-sysroot=/home/vries/nvptx/trunk/install/nvptx-none --with-build-time-tools=/home/vries/nvptx/trunk/install/nvptx-none/bin --disable-sjlj-exceptions --enable-newlib-io-long-long CFLAGS=-O0 -g CXXFLAGS=-O0 -g ...
[Bug target/97207] [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207 Tom de Vries changed: What|Removed |Added Target||nvptx CC||rguenth at gcc dot gnu.org --- Comment #1 from Tom de Vries --- Regression, started at: ... commit 4b9d61f79c0c0185a33048ae6cc72269cf7efa31 Author: Richard Biener Date: Thu Aug 6 14:50:56 2020 +0200 add move CTOR to auto_vec, use auto_vec for get_loop_exit_edges This adds a move CTOR to auto_vec and makes use of a auto_vec return value for get_loop_exit_edges denoting that lifetime management of the vector is handed to the caller. The move CTOR prompted the hash_table change because it appearantly makes the copy CTOR implicitely deleted (good) and hash-table expansion of the odr_enum_map which is hash_map where odr_enum has an auto_vec member triggers this. Not sure if there's a latent bug there before this (I think we're not invoking DTORs, but we're invoking copy-CTORs). ... The type bracket_vec_t is defined as: ... typedef auto_vec bracket_vec_t; ... so that does look at least related.
[Bug target/97207] New: [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207 Bug ID: 97207 Summary: [nvptx, build] nvptx.c:3539:38: error: no matching function for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’ Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Building trunk for nvptx on ubuntu 18.04.5 LTS with g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, I run into: ... src/gcc/config/nvptx/nvptx.c: In member function ‘void bb_sese: :append(bb_sese*)’: src/gcc/config/nvptx/nvptx.c:3539:38: error: no matching functi on for call to ‘swap(bracket_vec_t&, bracket_vec_t&)’ std::swap (brackets, child->brackets); ^ In file included from /usr/include/c++/7/bits/nested_exception.h:40:0, from /usr/include/c++/7/exception:143, from /usr/include/c++/7/ios:39, from /usr/include/c++/7/istream:38, from /usr/include/c++/7/sstream:38, from src/gcc/config/nvptx/nvptx.c:24: /usr/include/c++/7/bits/move.h:187:5: note: candidate: template typename std::enabl e_if >, std::is_move_constructible<_Tp>, std ::is_move_assignable<_Tp> >::value>::type std::swap(_Tp&, _Tp&) swap(_Tp& __a, _Tp& __b) ^~~~ /usr/include/c++/7/bits/move.h:187:5: note: template argument deduction/substitution failed: /usr/include/c++/7/bits/move.h: In substitution of ‘template typename std::enable_i f >, std::is_move_constructible<_Tp>, std::i s_move_assignable<_Tp> >::value>::type std::swap(_Tp&, _Tp&) [with _Tp = auto_vec]’: ...
[Bug c++/97197] With -O2, Incorrect -Werror=maybe-uninitialized thrown, leads to 'target_mem_ref' and 'dump_expr' in message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97197 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Patch posted.
[Bug tree-optimization/97199] ICE in process_bb at gcc/tree-ssa-sccvn.c:7250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97199 Richard Biener changed: What|Removed |Added Known to fail|11.0| Known to work||11.0 --- Comment #4 from Richard Biener --- Fixed on trunk, not sure how important it is to backport.
[Bug tree-optimization/97199] ICE in process_bb at gcc/tree-ssa-sccvn.c:7250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97199 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4dcc7f03b54087638e084ac69d40d7507fe83bd8 commit r11-3456-g4dcc7f03b54087638e084ac69d40d7507fe83bd8 Author: Richard Biener Date: Fri Sep 25 13:08:48 2020 +0200 tree-optimization/97199 - fix virtual operand update in if-conversion This fixes a corner case with virtual operand update in if-conversion by re-organizing the code to remove edges only after the last point we need virtual PHI operands to be available. 2020-09-25 Richard Biener PR tree-optimization/97199 * tree-if-conv.c (combine_blocks): Remove edges only after looking at virtual PHI args.
[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #44 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:8c775bf447e190024fa08c55e38db94dd013a393
commit r11-3455-g8c775bf447e190024fa08c55e38db94dd013a393
Author: Christophe Lyon
Date: Fri Sep 25 10:40:18 2020 +
testsuite: [aarch64] Fix aarch64/advsimd-intrinsics/v{trn,uzp,zip}_half.c
Since r11-3402 (g:65c9878641cbe0ed898aa7047b7b994e9d4a5bb1), the
vtrn_half, vuzp_half and vzip_half started failing with
vtrn_half.c:76:17: error: redeclaration of 'vector_float64x2' with no
linkage
vtrn_half.c:77:17: error: redeclaration of 'vector2_float64x2' with no
linkage
vtrn_half.c:80:17: error: redeclaration of 'vector_res_float64x2' with no
linkage
This is because r11-3402 now always declares float64x2 variables for
aarch64, leading to a duplicate declaration in these testcases.
The fix is simply to remove these now useless declarations.
These tests are skipped on arm*, so there is no impact on that target.
2020-09-25 Christophe Lyon
gcc/testsuite/
PR target/71233
* gcc.target/aarch64/advsimd-intrinsics/vtrn_half.c: Remove
declarations of vector, vector2, vector_res for float64x2 type.
* gcc.target/aarch64/advsimd-intrinsics/vuzp_half.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vzip_half.c: Likewise.
[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233 --- Comment #43 from CVS Commits --- The releases/gcc-8 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:26020c849802a03f7a0634636d752ffbc7729096 commit r8-10535-g26020c849802a03f7a0634636d752ffbc7729096 Author: Kyrylo Tkachov Date: Mon Oct 21 10:52:05 2019 + AArch64: Implement __rndr, __rndrrs intrinsics This patch implements the recently published[1] __rndr and __rndrrs intrinsics used to access the RNG in Armv8.5-A. The __rndrrs intrinsics can be used to reseed the generator too. They are guarded by the __ARM_FEATURE_RNG feature macro. A quirk with these intrinsics is that they store the random number in their pointer argument and return a status code if the generation succeeded. The instructions themselves write the CC flags indicating the success of the operation that we can then read with a CSET. Therefore this implementation makes use of the IGNORE indicator to the builtin expand machinery to avoid generating the CSET if its result is unused (the CC reg clobbering effect is still reflected in the pattern). I've checked that using unspec_volatile prevents undesirable CSEing of the instructions. [1] https://developer.arm.com/docs/101028/latest/data-processing-intrinsics gcc/ PR target/71233 * config/aarch64/aarch64.md (UNSPEC_RNDR, UNSPEC_RNDRRS): Define. (aarch64_rndr): New define_insn. (aarch64_rndrrs): Likewise. * config/aarch64/aarch64.h (AARCH64_ISA_RNG): Define. (TARGET_RNG): Likewise. (AARCH64_FL_RNG): Likewise. * config/aarch64/aarch64-option-extensions.def (rng): Define. * config/aarch64/aarch64-builtins.c (enum aarch64_builtins): Add AARCH64_BUILTIN_RNG_RNDR, AARCH64_BUILTIN_RNG_RNDRRS. (aarch64_init_rng_builtins): Define. (aarch64_init_builtins): Call aarch64_init_rng_builtins. (aarch64_expand_rng_builtin): Define. (aarch64_expand_builtin): Use IGNORE argument, handle RNG builtins. * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define __ARM_FEATURE_RNG when TARGET_RNG. * config/aarch64/arm_acle.h (__rndr, __rndrrs): Define. gcc/testsuite/ PR target/71233 * gcc.target/aarch64/acle/rng_1.c: New test.
[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233 --- Comment #42 from CVS Commits --- The releases/gcc-9 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:4fb606b503780b91ad79c203003dc41a32cfbab7 commit r9-8939-g4fb606b503780b91ad79c203003dc41a32cfbab7 Author: Kyrylo Tkachov Date: Mon Oct 21 10:52:05 2019 + Implement __rndr, __rndrrs intrinsics This patch implements the recently published[1] __rndr and __rndrrs intrinsics used to access the RNG in Armv8.5-A. The __rndrrs intrinsics can be used to reseed the generator too. They are guarded by the __ARM_FEATURE_RNG feature macro. A quirk with these intrinsics is that they store the random number in their pointer argument and return a status code if the generation succeeded. The instructions themselves write the CC flags indicating the success of the operation that we can then read with a CSET. Therefore this implementation makes use of the IGNORE indicator to the builtin expand machinery to avoid generating the CSET if its result is unused (the CC reg clobbering effect is still reflected in the pattern). I've checked that using unspec_volatile prevents undesirable CSEing of the instructions. [1] https://developer.arm.com/docs/101028/latest/data-processing-intrinsics gcc/ PR target/71233 * config/aarch64/aarch64.md (UNSPEC_RNDR, UNSPEC_RNDRRS): Define. (aarch64_rndr): New define_insn. (aarch64_rndrrs): Likewise. * config/aarch64/aarch64.h (AARCH64_ISA_RNG): Define. (TARGET_RNG): Likewise. * config/aarch64/aarch64-builtins.c (enum aarch64_builtins): Add AARCH64_BUILTIN_RNG_RNDR, AARCH64_BUILTIN_RNG_RNDRRS. (aarch64_init_rng_builtins): Define. (aarch64_init_builtins): Call aarch64_init_rng_builtins. (aarch64_expand_rng_builtin): Define. (aarch64_expand_builtin): Use IGNORE argument, handle RNG builtins. * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define __ARM_FEATURE_RNG when TARGET_RNG. * config/aarch64/arm_acle.h (__rndr, __rndrrs): Define. gcc/testsuite/ PR target/71233 * gcc.target/aarch64/acle/rng_1.c: New test.
[Bug c/97206] [11 Regression] internal compiler error: in composite_type, at c/c-typeck.c:447 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97206 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c/97206] [11 Regression] internal compiler error: in composite_type, at c/c-typeck.c:447 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97206 Martin Liška changed: What|Removed |Added Known to work||10.2.0 Last reconfirmed||2020-09-25 Summary|[11-regression] internal |[11 Regression] internal |compiler error: in |compiler error: in |composite_type, at |composite_type, at |c/c-typeck.c:447|c/c-typeck.c:447 since ||r11-3303-g6450f07388f9fe57 Status|UNCONFIRMED |NEW Known to fail||11.0 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with r11-3303-g6450f07388f9fe57.
[Bug tree-optimization/97199] ICE in process_bb at gcc/tree-ssa-sccvn.c:7250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97199
--- Comment #2 from Richard Biener ---
(gdb) p debug_gimple_stmt (phi)
.MEM_104 = PHI <(4), .MEM_97(41)>
so clearly bogus IL here. The issue is the virtual operand update in
if-conversion combine_blocks which does
/* We release virtual PHIs late because we have to propagate them
out using the current VUSE. The def might be the one used
after the loop. */
vphi = get_virtual_phi (bb);
if (vphi)
{
/* When there's just loads inside the loop a stray virtual
PHI merging the uses can appear, update last_vdef from
it. */
if (!last_vdef)
last_vdef = gimple_phi_arg_def (vphi, 0);
but this doesn't work since we already removed all edges which clears
the PHI arg defs.
[Bug c/97206] [11-regression] internal compiler error: in composite_type, at c/c-typeck.c:447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97206 --- Comment #1 from Sergei Trofimovich --- Testcase 2: something related happens to wavpack-5.3.2 package where gcc stopped typechecking array declarations: char *a(char *__restrict, int); __attribute__((__access__(__write_only__, 1))) char *a(char *, int); extern const char b[6]; extern const char b[]; $ gcc-10.2.0 -c a.c -o a.o $ gcc-11.0.0 -c a.c -o a.o a.c:4:19: error: conflicting type qualifiers for 'b' 4 | extern const char b[]; | ^ a.c:3:19: note: previous declaration of 'b' was here 3 | extern const char b[6]; | ^ Note: presence of seemingly unrelated 'a' declaration affects 'b' typechecking.
[Bug tree-optimization/97199] ICE in process_bb at gcc/tree-ssa-sccvn.c:7250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97199 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/97199] ICE in process_bb at gcc/tree-ssa-sccvn.c:7250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97199 Richard Biener changed: What|Removed |Added Known to fail||10.2.1, 11.0 Version|10.0|10.2.1 --- Comment #1 from Richard Biener --- Confirmed, I'll have a look.
[Bug testsuite/97204] [11 Regression] FAIL: gcc.target/i386/sse2-mmx-pinsrw.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97204 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug testsuite/97204] [11 Regression] FAIL: gcc.target/i386/sse2-mmx-pinsrw.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97204 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:499b63048acd5e9ffd3c04061b531f6bf851dc00 commit r11-3454-g499b63048acd5e9ffd3c04061b531f6bf851dc00 Author: Richard Biener Date: Fri Sep 25 11:43:43 2020 +0200 testsuite/97204 - fix gcc.target/i386/sse2-mmx-pinsrw.c This fixes the testcase writing to adjacent stack vars, exposed my IPA modref. 2020-09-25 Richard Biener PR testsuite/97204 * gcc.target/i386/sse2-mmx-pinsrw.c: Fix.
[Bug c/97206] New: [11-regression] internal compiler error: in composite_type, at c/c-typeck.c:447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97206
Bug ID: 97206
Summary: [11-regression] internal compiler error: in
composite_type, at c/c-typeck.c:447
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Originally observed on freetype-2.10.2 package.
Here is the minimal reproducer:
// x86_64-pc-linux-gnu-gcc -m32 -c -O2 bug.c -o a.o
void a(char *__restrict, const long *, unsigned)
__attribute__((__access__(__write_only__, 1)));
void a(char *, const long *, unsigned);
const char b[];
const char b[] = {};
$ ./xgcc -B. -c bug.c -o a.o
bug.c:6:1: internal compiler error: in composite_type, at c/c-typeck.c:447
6 | const char b[] = {};
| ^
0x44f412 composite_type(tree_node*, tree_node*)
../../gcc/gcc/c/c-typeck.c:447
0x426a0c finish_decl(tree_node*, unsigned int, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/c/c-decl.c:5356
0x4a04f0 c_parser_declaration_or_fndef
../../gcc/gcc/c/c-parser.c:2289
0x49f01b c_parser_external_declaration
../../gcc/gcc/c/c-parser.c:1777
0x49eb6a c_parser_translation_unit
../../gcc/gcc/c/c-parser.c:1650
0x4df8f5 c_parse_file()
../../gcc/gcc/c/c-parser.c:21821
0x5727e0 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ ./xgcc -B. -v
Reading specs from /home/slyfox/dev/git/gcc-native-quick-ggdb3/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-native-quick-ggdb3/gcc/xgcc
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick-ggdb3/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick-ggdb3/../gcc-native-quick-installed-ggdb3
--disable-nls --without-isl --disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O0 -ggdb3 ' CXXFLAGS='-O0 -ggdb3 ' --enable-valgrind-annotations
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200925 (experimental) (GCC)
[Bug tree-optimization/97204] [11 Regression] FAIL: gcc.target/i386/sse2-mmx-pinsrw.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97204
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords||wrong-code
Ever confirmed|0 |1
Last reconfirmed||2020-09-25
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |11.0
--- Comment #1 from Richard Biener ---
Value numbering stmt = _21 = MEM[(__m64 * {ref-all})];
ipa-modref: in sse2_test/572, call to test_pinsrw/570 does not clobber
MEM[(__m64 * {ref-all})] 0->0
ipa-modref: in sse2_test/572, call to test_pinsrw/570 does not clobber
MEM[(__m64 * {ref-all})] 0->0
Setting value number of _21 to { -218821384, 287834160 }
now the testcase seems to store outside of r and ck given we pass the address
of a single 'int' to test_pinsrw as 'r' but do
*(__m64 *) r = _m_pinsrw (*i, val, 0);
so I have a fix for the testcase.
[Bug c/97205] New: arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
Bug ID: 97205
Summary: arm: Compiler fails with an ICE for -O0 on Trunk and
GCC-10 for _Generic feature.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sripar01 at gcc dot gnu.org
Target Milestone: ---
Target: arm
Created attachment 49270
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49270=edit
testcase
Nested _Generic feature generating ICE with -O0 on GCC Trunk and GCC-10.
$arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/arm/pdtl/builds/fsf-trunk.2226/installed/rhe6x86_64/arm-none-eabi/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/arm/pdtl/builds/fsf-trunk.2226/installed/rhe6x86_64/arm-none-eabi/bin/../libexec/gcc/arm-none-eabi/11.0.0/lto-wrapper
Target: arm-none-eabi
Configured with:
/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/configure
--target=arm-none-eabi
--prefix=/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/build-arm-none-eabi/install//
--with-gmp=/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/build-arm-none-eabi/host-tools
--with-mpfr=/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/build-arm-none-eabi/host-tools
--with-mpc=/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/build-arm-none-eabi/host-tools
--with-isl=/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/build-arm-none-eabi/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++,fortran --with-newlib
--with-multilib-list=aprofile --with-pkgversion=fsf-trunk.2226
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200609 (experimental) (fsf-trunk.2226)
$ cat x.c
int a;
typedef __attribute__((aligned(2))) int x;
int fn1() {
x b = ({
_Generic(_Generic(fn1, default : a), int : _Generic(fn1, default : a));
});
return b;
}
$ arm-none-eabi-gcc x.c -O0 -c -Wall -Werror
during RTL pass: expand
x.c: In function 'fn1':
x.c:4:5: internal compiler error: in gen_movsi, at config/arm/arm.md:6364
4 | x b = ({
| ^
0x1516e1d gen_movsi(rtx_def*, rtx_def*)
/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/config/arm/arm.md:6364
0x925ddf insn_gen_fn::operator()(rtx_def*, rtx_def*) const
/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/recog.h:317
0x925ddf emit_move_insn_1(rtx_def*, rtx_def*)
/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/expr.c:3759
0x926872 emit_move_insn(rtx_def*, rtx_def*)
/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/expr.c:3929
0x92ef96 store_expr(tree_node*, rtx_def*, int, bool, bool)
/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/expr.c:6038
0x93172e expand_assignment(tree_node*, tree_node*, bool)
/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/expr.c:5588
0x7dd4bc expand_gimple_stmt_1
/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/cfgexpand.c:3751
0x7dd4bc expand_gimple_stmt
/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/cfgexpand.c:3847
0x7dfd75 expand_gimple_basic_block
/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/cfgexpand.c:5888
0x7e0c7e execute
/tmp/dgboter/bbs/rhev-vm5--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/cfgexpand.c:6572
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/97204] New: [11 Regression] FAIL: gcc.target/i386/sse2-mmx-pinsrw.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97204
Bug ID: 97204
Summary: [11 Regression] FAIL:
gcc.target/i386/sse2-mmx-pinsrw.c execution test
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
This fails due to IPA mod-ref. early FRE shows
--- a/sse2-mmx-pinsrw.c.036t.fre1 2020-09-25 11:24:23.379570162 +0200
+++ b/sse2-mmx-pinsrw.c.036t.fre1 2020-09-25 11:24:03.33558 +0200
@@ -343,7 +343,6 @@
unsigned int i.1_1;
int r.3_3;
int ck.4_4;
- vector(2) int _21;
long unsigned int _22;
long unsigned int _23;
short int * _24;
@@ -355,8 +354,7 @@
:
i.1_1 = (unsigned int) i_5;
test_pinsrw (, 4660, i.1_1, );
- _21 = MEM[(__m64 * {ref-all})];
- MEM[(__m64 * {ref-all})] = _21;
+ MEM[(__m64 * {ref-all})] = { -218821384, 287834160 };
if (i.1_1 <= 3)
goto ; [50.00%]
else
which has wrong values I think (but that should be unrelated to IPA modref)
[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97119 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Ali Bahrami --- > I added -flive-patching=inline-only-static as suggested by Martin. It didn't > alter the results I'm seeing. There is still a lot of .localalias in the > resulting objects. Still, the optimizations it is documented as preventing all > seem like the sort of things we wouldn't want for the core OS objects, so we > probably should add this. I've since compared the list of options disabled by -flive-patching=inline-only-static with the call sites of noninterposable_alias and the options that controlled their use. I'd initially done this to come up with additional options to try on top of -fno-ipa-icf that Ali had been using. This identified two more to try: -fdevirtualize -fipa-profile However, Ali found that disabling those doesn't help either. Any additional suggestions what else to try here? > I'm at a disadvantage here, as I don't fully understand how clone functions > and > .localalias symbols are related. From the gcc manpage, I gather that clones > are > copies made to do certain optimizations, such as elimination of constant > arguments. In contrast, foo, and foo.localalias seen to be references to a > single function, with the main different being that foo is global and > foo.localias is local. I'm not sure what the benefit of the local symbol is, > but since it references the same address, as the global, it's not what I would > call a clone. This is still an important issue, I believe: without fully understanding what those symbols are needed for and what the consequences would be of disabling their creation, it's hard to decide what to do. Going back to my initial hack (attached) of disabling .localalias* creation, what it does is exactly what happens on targets that don't define ASM_OUTPUT_DEF, i.e. don't support aliases. At least a testsuite run identified almost no impact (one failing test on Solaris/x86). Given that this is a supported configuration, I'd expect that this doesn't result in wrong code. Would a patch along those lines (properly controlled by an off-by-default option) be acceptable to move this forward?
[Bug target/97160] Regression from GCC 8 optimizing to sincos on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97160 Dave Love changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Dave Love --- Apologies; this isn't the compiler. It seems the glibc that Advanced Toolkit gcc 8 uses is responsible for the difference between that and 10. I tried to test that with LD_LIBRARY_PATH, but find you have to build with AT's ld64.so.2 to see the effect. It looks as though sincos in ppc64le glibc-2.17 is just sin+cos, though I can't immediately find my way in the source to check. I'd assumed it was optimized.
[Bug target/97203] [nvptx] 'illegal memory access was encountered' with 'omp simd'/SIMT and cexpf call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203 --- Comment #1 from Tobias Burnus --- Besides PR95654, see PR81778 and PR80053.
[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654 --- Comment #15 from Tobias Burnus --- See also PR97203 + PR97203, and PR80053. And the thread: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/thread.html#554054
[Bug gcov-profile/97193] [9/10/11 Regression] .gcno files are not written to same directory as the object file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97193 Martin Liška changed: What|Removed |Added Summary|.gcno files are not written |[9/10/11 Regression] .gcno |to same directory as the|files are not written to |object file |same directory as the ||object file Target Milestone|--- |9.4 Known to fail||10.2.0, 11.0 Keywords|documentation | Known to work|8.3.0 |8.4.0 --- Comment #4 from Martin Liška --- It's definitely a bug and it started with r9-1537-g1f2bb38a85710f65. *.gcno files should be mangled like the *.gcda files. I'm testing a patch.
[Bug libgomp/81778] libgomp.c/for-5.c failure on nvptx -- illegal memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #8 from Tobias Burnus --- See also PR95654 + PR97203, and PR80053
[Bug target/97203] New: [nvptx] 'illegal memory access was encountered' with 'omp simd'/SIMT and cexpf call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
Bug ID: 97203
Summary: [nvptx] 'illegal memory access was encountered' with
'omp simd'/SIMT and cexpf call
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: vries at gcc dot gnu.org
Target Milestone: ---
Target: nvptx
Created attachment 49269
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49269=edit
C testcase - compile with -fopenmp and "-O0", "-O1", and "-O1
-funsafe-math-optimizations"
My impression is that this is again (→ PR95654) related to SIMT going somehow
wrong, but I do not quite understand why.
The code uses 'omp simd ... reduction(…)' — using 'omp parallel do ...' instead
works.
The big program works at -O0, fails with -O1/-O2 but starts working again if
additionally -ffast-math is used. The fail is:
libgomp: cuCtxSynchronize error: invalid program counter
or
libgomp: cuCtxSynchronize error: unspecified launch failure (perhaps abort
was called)
The attached program is a vastly reduced version, which has a similar fail and
similar pattern, which may or may not have the same cause. – In any case:
It uses 'omp simd' and, hence, nvptx's SIMT and inside 'omp simd':
float cosArg = __builtin_cosf(expArg);
float sinArg = __builtin_sinf(expArg);
With with -O0 but also with -O1/-O2 -funsafe-math-optimizations it works and
the code contains with -funsafe-math-optimizations:
cos.approx.f32 %r73, %r75;
sin.approx.f32 %r72, %r75;
and with -O0 (and unsafe math disabled):
call (%value_in), cosf, (%out_arg1);
call (%value_in), sinf, (%out_arg1);
But with -O1/-O2 it fails with:
libgomp: cuCtxSynchronize error: an illegal memory access was encountered
here, the sin/cos was turned into BUILT_IN_SINCOSF and we end up with the code:
call cexpf, (%out_arg1, %out_arg2, %out_arg3);
I have no idea why 'call cosf/sinf' inside 'omp simd' works but 'call cexpf'
fails – nor whether that is indeed related to SIMT.
I think there are two issues. Mainly:
FIRST ISSUE: Why does it fail with 'cexpf'?
* * *
SECOND ISSUE: Missed optimization for BUILT_IN_SINCOSF:
if (optab_handler (sincos_optab, mode) != CODE_FOR_nothing)
...
else if (targetm.libc_has_function (function_sincos))
...
else
...
fn = builtin_decl_explicit (BUILT_IN_CEXPF);
Seems as if we do the latter. In newlib's ./newlib/libm/complex/cexpf.c:
cexpf(float complex z)
...
x = crealf(z);
y = cimagf(z);
r = expf(x);
w = r * cosf(y) + r * sinf(y) * I;
return w;
which is not really a performance boost compared to just calling sinf/cosf ...
Note that newlib does have newlib/libm/math/wf_sincos.c which does:
void sincosf(float x, float *sinx, float *cosx)
{
*sinx = sinf (x);
*cosx = cosf (x);
Which avoids a bunch of '*' and '+' and inparticular an 'expf' call. (Should be
still slower than directly calling sinf/cosf due to the call overhead, but much
better than cexpf, unless implemented in hardware.)
[Bug gcov-profile/48361] gcov freezes when using --all-blocks (-a) flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48361 --- Comment #19 from Martin Liška --- (In reply to Prasannanjaneyulu from comment #18) > Thank you @martin. I am not sure whether ubuntu 16.04 is compatible with gcc > 8.4.0. Our app. is currently built for ubuntu 16.04 and I don't know what > breaking changes it could bring if we upgrade gcc. I strongly recommend to update to a supported GCC. Note that in the meantime we've fixed many issues that can theoretically affect your application. > > Do you know any workaround other than disabling the whole branch coverage? No.
[Bug gcov-profile/48361] gcov freezes when using --all-blocks (-a) flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48361 --- Comment #18 from Prasannanjaneyulu --- Thank you @martin. I am not sure whether ubuntu 16.04 is compatible with gcc 8.4.0. Our app. is currently built for ubuntu 16.04 and I don't know what breaking changes it could bring if we upgrade gcc. Do you know any workaround other than disabling the whole branch coverage?
