[Bug target/97323] [10/11 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3 --- Comment #1 from Richard Biener --- works on x86_64-linux
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 Richard Biener changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Richard Biener --- it works for me with GCC 11
[Bug rtl-optimization/97326] [11 Regression] s390: ICE in do_store_flag after 10843f830350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97326 Richard Biener changed: What|Removed |Added Target||s390 Target Milestone|--- |11.0
[Bug middle-end/97326] [11 Regression] s390: ICE in do_store_flag after 10843f830350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97326 Richard Biener changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Keywords||ice-on-valid-code Component|rtl-optimization|middle-end --- Comment #1 from Richard Biener --- More fallout.
[Bug target/97327] -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327 James Greenhalgh changed: What|Removed |Added Ever confirmed|0 |1 CC||jgreenhalgh at gcc dot gnu.org Last reconfirmed||2020-10-08 Status|UNCONFIRMED |NEW
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #6 from Jan Hubicka --- Hi, the following patch should let us to pinpoint the wrong disambiguation. With -fdump-tree-all-details we should also see the difference in dump file. Honza diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def index cf8775b2b66..07946a85ecc 100644 --- a/gcc/dbgcnt.def +++ b/gcc/dbgcnt.def @@ -171,6 +171,7 @@ DEBUG_COUNTER (if_after_reload) DEBUG_COUNTER (if_conversion) DEBUG_COUNTER (if_conversion_tree) DEBUG_COUNTER (ipa_cp_bits) +DEBUG_COUNTER (ipa_mod_ref) DEBUG_COUNTER (ipa_sra_params) DEBUG_COUNTER (ipa_sra_retvalues) DEBUG_COUNTER (ira_move) diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c index 97dc4ac8814..ba208604c30 100644 --- a/gcc/tree-ssa-alias.c +++ b/gcc/tree-ssa-alias.c @@ -2470,6 +2470,9 @@ modref_may_conflict (const gimple *stmt, if (tt->every_base) return true; + if (!dbg_cnt (ipa_mod_ref)) +return true; + base_set = ao_ref_base_alias_set (ref); ref_set = ao_ref_alias_set (ref);
Re: [Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
Hi, the following patch should let us to pinpoint the wrong disambiguation. With -fdump-tree-all-details we should also see the difference in dump file. Honza diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def index cf8775b2b66..07946a85ecc 100644 --- a/gcc/dbgcnt.def +++ b/gcc/dbgcnt.def @@ -171,6 +171,7 @@ DEBUG_COUNTER (if_after_reload) DEBUG_COUNTER (if_conversion) DEBUG_COUNTER (if_conversion_tree) DEBUG_COUNTER (ipa_cp_bits) +DEBUG_COUNTER (ipa_mod_ref) DEBUG_COUNTER (ipa_sra_params) DEBUG_COUNTER (ipa_sra_retvalues) DEBUG_COUNTER (ira_move) diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c index 97dc4ac8814..ba208604c30 100644 --- a/gcc/tree-ssa-alias.c +++ b/gcc/tree-ssa-alias.c @@ -2470,6 +2470,9 @@ modref_may_conflict (const gimple *stmt, if (tt->every_base) return true; + if (!dbg_cnt (ipa_mod_ref)) +return true; + base_set = ao_ref_base_alias_set (ref); ref_set = ao_ref_alias_set (ref);
[Bug c/97330] New: ice for stmt with wrong VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97330 Bug ID: 97330 Summary: ice for stmt with wrong VUSE Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 49328 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49328&action=edit C source code Sometime between 20201007 and 20201008, the attached code has broken. $ /home/dcb/gcc/results/bin/gcc -c -O2 -w /home/dcb/gcc/foundBugs/bug647.c auprocess.c: In function ‘rcm_1’: auprocess.c:1275:17: error: stmt with wrong VUSE # VUSE <.MEM_34(D)> n_39 = el_35(D)->nextSample; expected .MEM_33 during GIMPLE pass: sink auprocess.c:1275:17: internal compiler error: verify_ssa failed 0xf02e86 verify_ssa(bool, bool) ../../trunk.git/gcc/tree-ssa.c:1208 0xbcd9c1 execute_function_todo(function*, void*) ../../trunk.git/gcc/passes.c:1999 0xbcc211 execute_todo(unsigned int) ../../trunk.git/gcc/passes.c:2046 I'll have a go at reducing the code.
[Bug libgomp/97331] New: [nvptx] Provide GCN_NUM_TEAMS/GCN_NUM_THREADS equivalent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97331
Bug ID: 97331
Summary: [nvptx] Provide GCN_NUM_TEAMS/GCN_NUM_THREADS
equivalent
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
When looking at the gcn plugin, there are a number of environment variables
that set/limit launch dimensions:
...
$ grep getenv libgomp/plugin/plugin-gcn.c | grep NUM
const char *x = secure_getenv ("GCN_NUM_TEAMS");
x = secure_getenv ("GCN_NUM_GANGS");
const char *z = secure_getenv ("GCN_NUM_THREADS");
z = secure_getenv ("GCN_NUM_WORKERS");
...
It would be nice to have similar ones for nvptx.
[Bug libgomp/97331] [nvptx] Provide GCN_NUM_TEAMS/GCN_NUM_THREADS equivalent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97331
--- Comment #1 from Jakub Jelinek ---
The OpenMP 5.1 way is OMP_{NUM_THREADS,...}_DEV_{0,1,2,...} etc., but we aren't
there yet.
[Bug c/97330] ice for stmt with wrong VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97330
--- Comment #1 from David Binderman ---
Reduced code is:
typedef int a;
typedef char b;
int c;
void d(e, f, dst, g, avail, h) int e;
b *f, *dst;
a g, avail;
int h;
{
b i = *f;
if (e)
goto j;
while (avail) {
*dst = i;
j:
avail -= c;
}
}
[Bug libgomp/97332] New: [gcn] GCN_NUM_GANGS/GCN_NUM_WORKERS override compile-time constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97332 Bug ID: 97332 Summary: [gcn] GCN_NUM_GANGS/GCN_NUM_WORKERS override compile-time constants Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- In openacc programs, dimensions are either dynamic or hardcoded. If the dimensions are hardcoded, and there are builtins returning the size of these dimensions, the builtins are folded in fold_internal_goacc_dim. Changing the dimensions in the plugin then invalidates the folding. I'm guessing this should be fixed, or at least documented in the plugin (with perhaps even a warning).
[Bug libgomp/81802] Report cuLaunchKernel launch dimensions in GOMP_OFFLOAD_run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81802 --- Comment #1 from CVS Commits --- The master branch has been updated by Tom de Vries : https://gcc.gnu.org/g:7345ef6c2a197d0a2581c67838b7ba1650dfad30 commit r11-3715-g7345ef6c2a197d0a2581c67838b7ba1650dfad30 Author: Tom de Vries Date: Thu Oct 8 08:22:39 2020 +0200 [libgomp, nvptx] Report launch dimensions in GOMP_OFFLOAD_run Using this patch, when using GOMP_DEBUG=1 and launching a kernel in GOMP_OFFLOAD_run (used by the omp implementation), we see the kernel launch dimensions: ... GOMP_OFFLOAD_run: kernel main$_omp_fn$0: \ launch [(teams: 1), 1, 1] [(lanes: 32), (threads: 1), 1] ... Build on x86_64-linux with nvptx accelerator, tested libgomp. libgomp/ChangeLog: 2020-10-08 Tom de Vries PR libgomp/81802 * plugin/plugin-nvptx.c (GOMP_OFFLOAD_run): Report launch dimensions.
[Bug c/97330] ice for stmt with wrong VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97330
--- Comment #2 from David Binderman ---
Flags -Werror=implicit-int and -Werror=old-style-definition seem useful.
Here is another reduced test case:
int a, b, d;
char c, e;
void f(void) {
char g = c;
if (b)
goto h;
while (d) {
e = c;
h:
d -= a;
}
}
[Bug libgomp/81802] Report cuLaunchKernel launch dimensions in GOMP_OFFLOAD_run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81802 Tom de Vries changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Tom de Vries --- Marking resolved-fixed.
[Bug sanitizer/97294] ASAN "dynamic-stack-buffer-overflow" false positive with OpenMP reduction to std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97294 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:273b30c8e93f043f65a04e0ff2ec305b311e98fa commit r11-3716-g273b30c8e93f043f65a04e0ff2ec305b311e98fa Author: Jakub Jelinek Date: Thu Oct 8 11:10:34 2020 +0200 openmp: Set cfun->calls_alloca when needed in OpenMP outlined regions [PR97294] The following testcase FAILs, because we don't mark the child OpenMP function as cfun->calls_alloca when it does call alloca. When optimizing, during DCE we reset those flags and recompute them again, but with -O0 DCE is not performed. Fixed by calling notice_special_calls when moving insns to the child function. cfun->calls_alloca is normally set during gimplification and most of the alloca calls omp-low.c does go through the gimplifier, but one spot didn't and built the gcall directly, so that one needs to set calls_alloca too. 2020-10-08 Jakub Jelinek PR sanitizer/97294 * tree-cfg.c (move_block_to_fn): Call notice_special_calls on call stmts being moved into dest_cfun. * omp-low.c (lower_rec_input_clauses): Set cfun->calls_alloca when adding __builtin_alloca_with_align call without gimplification. * gcc.dg/asan/pr97294.c: New test.
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315 --- Comment #11 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:214d514fafcd78cd54e4a4aa9ae08c89abf9cc57 commit r11-3717-g214d514fafcd78cd54e4a4aa9ae08c89abf9cc57 Author: Aldy Hernandez Date: Thu Oct 8 11:15:23 2020 +0200 Fix PR97315 (part 1 of 2) gcc/ChangeLog: PR tree-optimization/97315 * gimple-ssa-evrp.c (hybrid_folder::choose_value): Removes the trap and instead annotates the listing. gcc/testsuite/ChangeLog: * gcc.dg/pr97315-1.c: New test.
[Bug tree-optimization/97333] New: [gimple_can_duplicate_bb_p == false, tree-ssa-threadupdate] ICE in duplicate_block, at cfghooks.c:1093
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97333
Bug ID: 97333
Summary: [gimple_can_duplicate_bb_p == false,
tree-ssa-threadupdate] ICE in duplicate_block, at
cfghooks.c:1093
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
With this patch:
...
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index 406441751a9..b9168755155 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -6213,7 +6213,7 @@ gimple_split_block_before_cond_jump (basic_block bb)
static bool
gimple_can_duplicate_bb_p (const_basic_block bb ATTRIBUTE_UNUSED)
{
- return true;
+ return false;
}
/* Create a duplicate of the basic block BB. NOTE: This does not
...
we run into:
...
spawn -ignore SIGHUP
/dev/shm/tdevries/data/master/2020-10-07T08-04-46-02-00-c475cfa435b/build/gcc/xgcc
-B/dev/shm/tdevries/data/master/2020-10-07T08-04-46-02-00-c475cfa435b/build/gcc/
-fdiagnostics-plain-output -O1 -w -c -o 20041018-1.o
/labs/tdevries/gcc/src/gcc/testsuite/gcc.c-torture/compile/20041018-1.c^M
during GIMPLE pass: dom^M
/labs/tdevries/gcc/src/gcc/testsuite/gcc.c-torture/compile/20041018-1.c: In
function 'foo':^M
/labs/tdevries/gcc/src/gcc/testsuite/gcc.c-torture/compile/20041018-1.c:2:1:
internal compiler error: in duplicate_block, at cfghooks.c:1093^M
0xbfebaf duplicate_block(basic_block_def*, edge_def*, basic_block_def*,
copy_bb_data*)^M
/labs/tdevries/gcc/src/gcc/cfghooks.c:1093^M
0x16d794b create_block_for_threading^M
/labs/tdevries/gcc/src/gcc/tree-ssa-threadupdate.c:342^M
0x16d90e7 ssa_create_duplicates(redirection_data**, ssa_local_info_t*)^M
/labs/tdevries/gcc/src/gcc/tree-ssa-threadupdate.c:1130^M
0x16dfe86 void hash_table::traverse_noresize(ssa_local_info_t*)^M
/labs/tdevries/gcc/src/gcc/hash-table.h:1081^M
0x16df31a void hash_table::traverse(ssa_local_info_t*)^M
/labs/tdevries/gcc/src/gcc/hash-table.h:1102^M
0x16d9dff thread_block_1^M
/labs/tdevries/gcc/src/gcc/tree-ssa-threadupdate.c:1495^M
0x16d9ee5 thread_block^M
/labs/tdevries/gcc/src/gcc/tree-ssa-threadupdate.c:1539^M
0x16da3d7 thread_through_loop_header^M
/labs/tdevries/gcc/src/gcc/tree-ssa-threadupdate.c:1781^M
0x16dc767 thread_through_all_blocks(bool)^M
/labs/tdevries/gcc/src/gcc/tree-ssa-threadupdate.c:2667^M
0x15522d2 execute^M
/labs/tdevries/gcc/src/gcc/tree-ssa-dom.c:776^M
...
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315 --- Comment #12 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:91ae6930ed4a87d7b8e25e10378388b3f0dc1729 commit r11-3718-g91ae6930ed4a87d7b8e25e10378388b3f0dc1729 Author: Aldy Hernandez Date: Thu Oct 8 11:33:30 2020 +0200 Fix PR97315 (part 2 of 2) gcc/ChangeLog: PR tree-optimization/97315 * range-op.cc (value_range_with_overflow): Change any non-overflow calculation in which both bounds are overflow/underflow to be undefined. gcc/testsuite/ChangeLog: * gcc.dg/pr97315-2.c: New test.
[Bug tree-optimization/97333] [gimple_can_duplicate_bb_p == false, tree-ssa-threadupdate] ICE in duplicate_block, at cfghooks.c:1093
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97333 Richard Biener changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #1 from Richard Biener --- Looks like the jump threading code fails to check can_duplicate_block_p () (because well, on GIMPLE we can duplicate all blocks).
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Aldy Hernandez --- Fixed.
[Bug tree-optimization/97325] [11 Regression] wrong code with __builtin_ffs() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97325 --- Comment #5 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:9489806fa258b90b02b55804e61e9eb748724ce7 commit r11-3719-g9489806fa258b90b02b55804e61e9eb748724ce7 Author: Aldy Hernandez Date: Thu Oct 8 11:41:00 2020 +0200 Fix PR97325. gcc/ChangeLog: PR tree-optimization/97325 * gimple-range.cc (gimple_ranger::range_of_builtin_call): Handle negative numbers in __builtin_ffs and __builtin_popcount.
[Bug tree-optimization/97325] [11 Regression] wrong code with __builtin_ffs() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97325 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Aldy Hernandez --- Fixed.
[Bug tree-optimization/97334] New: inefficient vectorization of gcc.dg/vect/bb-slp-pr65935.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97334
Bug ID: 97334
Summary: inefficient vectorization of
gcc.dg/vect/bb-slp-pr65935.c
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: ---
For
void rephase (void)
{
int i,j,k,dir;
struct site *s;
for(i=0,s=lattice;ilink[dir].e[j][k].real *= s->phase[dir];
s->link[dir].e[j][k].imag *= s->phase[dir];
}
where SLP faces unrolled j and k loops we fail to vectorize the
loads of { s->link[dir].e[j][k].real, s->link[dir].e[j][k].imag }
because SLP discovery rejects the s->phase[dir] load:
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
note: Build SLP for _59 = s_8->phase[dir_80];
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
missed: Build SLP failed: unvectorizable statement _59 = s_8->phase[dir_80];
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
note: Building vector operands from scalars
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
note: Build SLP for _59 = s_8->phase[dir_80];
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
missed: Build SLP failed: unvectorizable statement _59 = s_8->phase[dir_80];
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
note: Building vector operands from scalars
and then ends up building the multiplication operands from scalars:
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
note: node 0x4a36cb0 (max_nunits=2, refcnt=2)
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
note:stmt 0 _60 = _58 * _59;
..
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
note:children 0x4931310 0x4a6e690
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
note: node (external) 0x4931310 (max_nunits=1, refcnt=1)
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
note:{ _58, _59, _59, _59, _59, _59, _59, _59, _59, _59, _59, _59, _59,
_59, _59, _59, _59, _59 }
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
note: node (external) 0x4a6e690 (max_nunits=1, refcnt=1)
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c:28:30:
note:{ _59, _62, _65, _68, _71, _74, _82, _86, _89, _92, _95, _98,
_106, _110, _113, _116, _119, _122 }
[Bug tree-optimization/97334] inefficient vectorization of gcc.dg/vect/bb-slp-pr65935.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97334 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-10-08 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Blocks||53947 Keywords||missed-optimization --- Comment #1 from Richard Biener --- I will look into this Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[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 #2 from Tom de Vries ---
Minimal version (without inlining sinf code from newlib):
...
/* { dg-additional-options "-lm -foffload=-lm" } */
#define N 1
int
main (void) {
float k[N];
float res;
for (int i = 0; i < N; i++)
k[i] = 300;
#pragma omp target map(to:k) map(from:res)
{
float sum = 0.0;
#pragma omp simd reduction(+:sum)
for (int i = 0; i < N; i++)
sum += __builtin_sinf (k[i]);
res = sum;
}
return 0;
}
...
[Bug target/97322] [11 regression] ICE in int_mode_for_mode, at stor-layout.c:404 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f18eeb6b958acd5e1590ca4a73231486b749be9b commit r11-3720-gf18eeb6b958acd5e1590ca4a73231486b749be9b Author: Jakub Jelinek Date: Thu Oct 8 11:56:15 2020 +0200 arm: Fix ICE on glibc compilation after my DIVMOD optimization [PR97322] The arm target hook for divmod wasn't prepared to handle constants passed to the function. 2020-10-08 Jakub Jelinek PR target/97322 * config/arm/arm.c (arm_expand_divmod_libfunc): Pass mode instead of GET_MODE (op0) or GET_MODE (op1) to emit_library_call_value. * gcc.dg/pr97322.c: New test.
[Bug target/97322] [11 regression] ICE in int_mode_for_mode, at stor-layout.c:404 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug sanitizer/97294] ASAN "dynamic-stack-buffer-overflow" false positive with OpenMP reduction to std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97294 --- Comment #5 from Jakub Jelinek --- Fixed for 11+ so far.
[Bug target/97323] [10/11 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW CC|kyrylo.tkachov at arm dot com | Last reconfirmed||2020-10-08 Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- confirmed on trunk with the extra checking enabled
[Bug middle-end/97326] [11 Regression] s390: ICE in do_store_flag after 10843f830350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97326 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-10-08 Status|UNCONFIRMED |NEW
[Bug tree-optimization/97330] [11 Regression] ice for stmt with wrong VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97330 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Component|c |tree-optimization Ever confirmed|0 |1 Last reconfirmed||2020-10-08 Status|UNCONFIRMED |ASSIGNED Summary|ice for stmt with wrong |[11 Regression] ice for |VUSE|stmt with wrong VUSE Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Mine.
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 --- Comment #7 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:afb198ee3729c29c8e681aedc656f55f4afe4053 commit r11-3721-gafb198ee3729c29c8e681aedc656f55f4afe4053 Author: Christophe Lyon Date: Mon Oct 5 13:11:07 2020 + arm: [MVE[ Add vqdmlashq intrinsics (PR target/96914) This patch adds: vqdmlashq_m_n_s16 vqdmlashq_m_n_s32 vqdmlashq_m_n_s8 vqdmlashq_n_s16 vqdmlashq_n_s32 vqdmlashq_n_s8 2020-10-08 Christophe Lyon gcc/ PR target/96914 * config/arm/arm_mve.h (vqdmlashq, vqdmlashq_m): Define. * config/arm/arm_mve_builtins.def (vqdmlashq_n_s) (vqdmlashq_m_n_s,): New. * config/arm/unspecs.md (VQDMLASHQ_N_S, VQDMLASHQ_M_N_S): New unspecs. * config/arm/iterators.md (VQDMLASHQ_N_S, VQDMLASHQ_M_N_S): New attributes. (VQDMLASHQ_N): New iterator. * config/arm/mve.md (mve_vqdmlashq_n_, mve_vqdmlashq_m_n_s): New patterns. gcc/testsuite/ PR target/96914 * gcc.target/arm/mve/intrinsics/vqdmlashq_m_n_s16.c: New test. * gcc.target/arm/mve/intrinsics/vqdmlashq_m_n_s32.c: New test. * gcc.target/arm/mve/intrinsics/vqdmlashq_m_n_s8.c: New test. * gcc.target/arm/mve/intrinsics/vqdmlashq_n_s16.c: New test. * gcc.target/arm/mve/intrinsics/vqdmlashq_n_s32.c: New test. * gcc.target/arm/mve/intrinsics/vqdmlashq_n_s8.c: New test.
[Bug libgomp/97332] [gcn] GCN_NUM_GANGS/GCN_NUM_WORKERS override compile-time constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97332 Andrew Stubbs changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-10-08 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Stubbs --- At the point the overrides are applied (run_kernel) the code only knows what dimensions were selected at runtime, not how those figures were arrived at. It then prints (with GCN_DEBUG set) the "launch attributes" and "launch actuals". To fix this the overrides will have to applied much earlier, and independently for OpenACC (gcn_exec) and OpenMP (parse_target_attributes). That or the automatic balancing be applied later. Or perhaps the original attributes be stored for later inspection (but GOMP_kernel_launch_attributes is defined by libgomp). The "attributes" and "actuals" will need to be overhauled. Probably get_group_size can be removed. It ought to be doable though.
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 --- Comment #8 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:237f12da4124b91503646b099a8282aa6b251ef9 commit r11-3722-g237f12da4124b91503646b099a8282aa6b251ef9 Author: Christophe Lyon Date: Tue Oct 6 07:36:31 2020 + arm: [MVE] Remove illegal intrinsics (PR target/96914) A few MVE intrinsics had an unsigned variant implement while they are supported by the hardware. This patch removes them: __arm_vqrdmlashq_n_u8 __arm_vqrdmlahq_n_u8 __arm_vqdmlahq_n_u8 __arm_vqrdmlashq_n_u16 __arm_vqrdmlahq_n_u16 __arm_vqdmlahq_n_u16 __arm_vqrdmlashq_n_u32 __arm_vqrdmlahq_n_u32 __arm_vqdmlahq_n_u32 __arm_vmlaldavaxq_p_u32 __arm_vmlaldavaxq_p_u16 2020-10-08 Christophe Lyon gcc/ PR target/96914 * config/arm/arm_mve.h (vqrdmlashq_n_u8, vqrdmlashq_n_u16) (vqrdmlashq_n_u32, vqrdmlahq_n_u8, vqrdmlahq_n_u16) (vqrdmlahq_n_u32, vqdmlahq_n_u8, vqdmlahq_n_u16, vqdmlahq_n_u32) (vmlaldavaxq_p_u16, vmlaldavaxq_p_u32): Remove. * config/arm/arm_mve_builtins.def (vqrdmlashq_n_u, vqrdmlahq_n_u) (vqdmlahq_n_u, vmlaldavaxq_p_u): Remove. * config/arm/unspecs.md (VQDMLAHQ_N_U, VQRDMLAHQ_N_U) (VQRDMLASHQ_N_U) (VMLALDAVAXQ_P_U): Remove unspecs. * config/arm/iterators.md (VQDMLAHQ_N_U, VQRDMLAHQ_N_U) (VQRDMLASHQ_N_U, VMLALDAVAXQ_P_U): Remove attributes. (VQDMLAHQ_N, VQRDMLAHQ_N, VQRDMLASHQ_N, VMLALDAVAXQ_P): Remove unsigned variants from iterators. * config/arm/mve.md (mve_vqdmlahq_n_) (mve_vqrdmlahq_n_) (mve_vqrdmlashq_n_, mve_vmlaldavaxq_p_): Update comment. gcc/testsuite/ PR target/96914 * gcc.target/arm/mve/intrinsics/vmlaldavaxq_p_u16.c: Remove. * gcc.target/arm/mve/intrinsics/vmlaldavaxq_p_u32.c: Remove. * gcc.target/arm/mve/intrinsics/vqdmlahq_n_u16.c: Remove. * gcc.target/arm/mve/intrinsics/vqdmlahq_n_u32.c: Remove. * gcc.target/arm/mve/intrinsics/vqdmlahq_n_u8.c: Remove. * gcc.target/arm/mve/intrinsics/vqrdmlahq_n_u16.c: Remove. * gcc.target/arm/mve/intrinsics/vqrdmlahq_n_u32.c: Remove. * gcc.target/arm/mve/intrinsics/vqrdmlahq_n_u8.c: Remove. * gcc.target/arm/mve/intrinsics/vqrdmlashq_n_u16.c: Remove. * gcc.target/arm/mve/intrinsics/vqrdmlashq_n_u32.c: Remove. * gcc.target/arm/mve/intrinsics/vqrdmlashq_n_u8.c: Remove.
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #7 from Martin Liška ---
Ok, I've just installed the patch with the debug counter.
I can reproduce it with first bad value with --param=lto-partitions=1:
-fdbg-cnt=ipa_mod_ref:16848
and the difference comes from dealII.ltrans0.ltrans.137t.pre:
distribute_dofs (struct DoFHandler * const this, const struct FiniteElement &
ff, const unsigned int offset):
GOOD:
[local count: 410235502]:
# __n_981 = PHI <__n_979(163), __n_978(162)>
# __tmp$_M_p_984 = PHI <_980(163), _977(162)>
_982 = (unsigned int) __n_981;
_983 = 1 << _982;
_985 = *__tmp$_M_p_984;
_986 = _983 | _985;
*__tmp$_M_p_984 = _986;
operator++ (&cell);
_25 = BIT_FIELD_REF ;
if (_25 != -1)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 365109597]:
pretmp_2354 = MEM[(int *)&cell + 12B];
goto ; [100.00%]
[local count: 50703262]:
# next_free_dof_577 = PHI
this_6(D)->used_dofs = next_free_dof_577;
MEM[(struct _Bvector_impl_data *)&tmp] ={v} {CLOBBER};
MEM[(struct __as_base &)&tmp] ={v} {CLOBBER};
BAD:
[local count: 410235502]:
# __n_981 = PHI <__n_979(163), __n_978(162)>
# __tmp$_M_p_984 = PHI <_980(163), _977(162)>
_982 = (unsigned int) __n_981;
_983 = 1 << _982;
_985 = *__tmp$_M_p_984;
_986 = _983 | _985;
*__tmp$_M_p_984 = _986;
operator++ (&cell);
_25 = BIT_FIELD_REF ;
if (_25 != -1)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 50703262]:
# next_free_dof_577 = PHI
this_6(D)->used_dofs = next_free_dof_577;
MEM[(struct _Bvector_impl_data *)&tmp] ={v} {CLOBBER};
MEM[(struct __as_base &)&tmp] ={v} {CLOBBER};
[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97335 Martin Liška changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97292 Status|UNCONFIRMED |NEW Known to work||10.2.0 Blocks||26163 Known to fail||11.0 Last reconfirmed||2020-10-08 Ever confirmed|0 |1 Target Milestone|--- |11.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug ipa/97335] New: [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97335 Bug ID: 97335 Summary: [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: ---
[Bug middle-end/97336] New: False positive -Wstring-compare warning for strncmp()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97336
Bug ID: 97336
Summary: False positive -Wstring-compare warning for strncmp()
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: franke at computer dot org
Target Milestone: ---
Testcase:
$ uname -srvmo
CYGWIN_NT-10.0 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
$ cygcheck -f /usr/bin/gcc
gcc-core-10.2.0-1
$ gcc --version
gcc (GCC) 10.2.0
...
$ cat test.c
int f(const char * p, int n)
{
char buf[10] = {0, };
int i;
for (i = 0; i < (int)sizeof(buf)-1 && i < n; i++)
buf[i] = p[i];
if (!__builtin_strncmp(buf, "12345", 5)
&& (i == 5 || buf[5] == ' '))
return 1;
return 0;
}
$ gcc -Wstring-compare -O2 -c test.c
test.c: In function ‘f’:
test.c:7:8: warning: ‘__builtin_strncmp’ of strings of length 0 and 5 and bound
of 5 evaluates to nonzero [-Wstring-compare]
7 | if (!__builtin_strncmp(buf, "12345", 5)
|^~
Apparently it is assumed that the copy loop is never executed.
Any of the following single line changes removes the warning:
{
- char buf[10] = {0, };
+ char buf[10]; __builtin_memset(buf, 0, sizeof(buf));
int i;
if (!__builtin_strncmp(buf, "12345", 5)
- && (i == 5 || buf[5] == ' '))
+ && (buf[5] == ' ' || i == 5))
return 1;
if (!__builtin_strncmp(buf, "12345", 5)
- && (i == 5 || buf[5] == ' '))
+ && (!buf[5] || buf[5] == ' '))
return 1;
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Well for GCC 11 we provide: gcc: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead cc1: error: bad value (‘sdfdsf’) for ‘-mtune=’ switch cc1: note: valid arguments to ‘-mtune=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client icelake-server cascadelake tigerlake cooperlake sapphirerapids alderlake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 btver1 btver2 generic native So -mcpu is deprecated and we print valid values for -mtune argument. Fixed on master with r11-2755-ga7bbb5b1b1eb09db.
[Bug c++/97328] [10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328 Martin Liška changed: What|Removed |Added Target Milestone|--- |10.3 Known to work||9.3.0 Known to fail||10.2.0, 11.0
[Bug c++/97328] [10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-10-08 Status|UNCONFIRMED |NEW Summary|[ICE] internal compiler |[10/11 Regression] ICE in |error: in |verify_ctor_sanity, at |verify_ctor_sanity, at |cp/constexpr.c:3995 since |cp/constexpr.c:3995 |r10-7313-gb599bf9d6d1e180d CC||marxin at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r10-7313-gb599bf9d6d1e180d.
[Bug tree-optimization/97330] [11 Regression] ice for stmt with wrong VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97330 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Just for the record, started with r11-3705-gdae673abd37d4004.
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #8 from Martin Liška --- Created attachment 49329 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49329&action=edit Good PRE dump file
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #9 from Martin Liška --- Created attachment 49330 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49330&action=edit Bad PRE dump file
[Bug tree-optimization/97330] [11 Regression] ice for stmt with wrong VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97330 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:629e0547af33221a925f38757b52a9284148b68a commit r11-3726-g629e0547af33221a925f38757b52a9284148b68a Author: Richard Biener Date: Thu Oct 8 13:18:57 2020 +0200 tree-optimization/97330 - fix bad load sinking This fixes bad placement of sunk loads. 2020-10-08 Richard Biener PR tree-optimization/97330 * tree-ssa-sink.c (statement_sink_location): Avoid skipping PHIs when they dominate the insert location. * gcc.dg/torture/pr97330-1.c: New testcase. * gcc.dg/torture/pr97330-2.c: Likewise.
[Bug tree-optimization/97330] [11 Regression] ice for stmt with wrong VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97330 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #10 from Martin Liška --- Good PRE dump file with details: https://drive.google.com/file/d/114AAhbNKeiJ7w3FYOcumdpnnMCNvdjiy/view?usp=sharing Bad PRE dump file with details: https://drive.google.com/file/d/14_dV-FYSe1j0Sx-zIc8d_6ypuFcmPnZl/view?usp=sharing
[Bug gcov-profile/90439] [GCOV] multiple expression across different lines in if statement is inconsistent when the body is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90439 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #1 from Sunil Kumar --- I have a query. Will this issue is applicable for GCC 7.4.0 ?
[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97335 --- Comment #1 from Martin Liška --- With -O3 -g -flto=16 --param=lto-partitions=1, the first bad binary is with -fdbg-cnt=ipa_mod_ref:1046. It seems a misc tool fails with: ./ldecod_r -i BuckBunny.264 -o BuckBunny.yuv Setting Default Parameters... Parsing Configfile decoder.cfg - JM 17.1 (FRExt) - -- Input H.264 bitstream : BuckBunny.264 Output decoded YUV : BuckBunny.yuv Input reference file : test_rec.yuv -- POC must = frame# or field# for SNRs to be correct -- Frame POC Pic# QPSnrY SnrU SnrV Y:U:V Time(ms) -- Input reference file : test_rec.yuv does not exist SNR values are not available 0(IDR)0 028 4:2:0 0 2( P )4 131 4:2:0 0 1( b )2 231 4:2:0 0 3( I )6 228 4:2:0 0 6( P ) 12 428 4:2:0 0 mb_qp_delta is out of range PRE dump files: https://drive.google.com/file/d/1GzqkYP4PRtXVkVbvGGJUukz8-9ay-uMy/view?usp=sharing
[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 #3 from Tom de Vries ---
[ Note, this is with GOMP_NVPTX_JIT=-O0. ]
In sinf, we have:
...
45:return -__kernel_cosf(y[0],y[1]);
...
which translates to:
...
.loc 1 45 12
ld.f32 %r67,[%frame+4];
ld.f32 %r65,[%frame];
{
.param .f32 %value_in;
.param .f32 %out_arg1;
st.param.f32 [%out_arg1],%r65;
.param .f32 %out_arg2;
st.param.f32 [%out_arg2],%r67;
call (%value_in),__kernel_cosf,(%out_arg1,%out_arg2);
ld.param.f32 %r68,[%value_in];
}
.loc 1 45 11
neg.f32 %r37,%r68;
...
If I place (using GOMP_NVPTX_PTXRW) a trap before the first load:
...
.loc 1 45 12
+trap
ld.f32 %r67,[%frame+4];
...
I get:
...
libgomp: cuCtxSynchronize error: an illegal instruction was encountered
...
If I place it after the first load, I get:
...
libgomp: cuCtxSynchronize error: an illegal memory access was encountered
...
[Bug c++/97328] [10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug go/92564] libgo regression in runtime test resulting in SIGSEGV on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92564 --- Comment #3 from boger at gcc dot gnu.org --- Yes, I tried the value of 0x8 and the test passed. In the issue Ian mentioned that 0x10 was the default on x86. If we want the same default on x86 and ppc64 then 0x10 would work since the value I tested with is smaller.
[Bug libstdc++/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 Jonathan Wakely changed: What|Removed |Added Target||i386-pc-solaris2.11 CC||ro at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-10-08 --- Comment #10 from Jonathan Wakely --- Looks like this is still failing for solaris 11: https://gcc.gnu.org/pipermail/gcc-testresults/2020-October/610818.html
[Bug libstdc++/70358] Several 26_numerics/random/binomial_distribution/operators etc. tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70358 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-10-08 Target Milestone|5.5 |--- Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Rainer, what's the status of this one? Are those tests still UNSUPPORTED, or now PASSing?
[Bug libstdc++/82584] div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-10-08 Status|UNCONFIRMED |NEW
[Bug libstdc++/86402] Several targets missing AC_DEFINE(_GLIBCXX_USE_RANDOM_TR1) in crossconfig.m4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86402 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-10-08 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 --- Comment #9 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:5a448362da6133c3b16ffdb0c795b657af7fa5a4 commit r11-3730-g5a448362da6133c3b16ffdb0c795b657af7fa5a4 Author: Christophe Lyon Date: Mon Oct 5 09:52:59 2020 + arm: [MVE] Add missing __arm_vcvtnq_u32_f32 intrinsic (PR 96914) __arm_vcvtnq_u32_f32 was missing from arm_mve.h, although the s32_f32 and [su]16_f16 versions were present. This patch adds the missing version and testcase, which are cut-and-paste from the other versions. 2020-10-08 Christophe Lyon gcc/ PR target/96914 * config/arm/arm_mve.h (__arm_vcvtnq_u32_f32): New. gcc/testsuite/ PR target/96914 * gcc.target/arm/mve/intrinsics/vcvtnq_u32_f32.c: New test.
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Christophe Lyon --- Fixed on trunk
[Bug libstdc++/82584] div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jonathan Wakely --- This is user error. [rand.dist.samp.discrete] p2 says: > Moreover, the following relation shall hold: 0 < S = w0 + · · · + wn−1 . So there must be at least one non-zero weight. I'll add an assertion.
[Bug gcov-profile/90439] [GCOV] multiple expression across different lines in if statement is inconsistent when the body is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90439 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Yes, it behaves the same also in GCC 7.x.
[Bug libstdc++/82584] div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b2a96bf9dce41ee777b1669e4a8b4c6df3ff3613 commit r11-3731-gb2a96bf9dce41ee777b1669e4a8b4c6df3ff3613 Author: Jonathan Wakely Date: Thu Oct 8 15:14:58 2020 +0100 libstdc++: Add assertions for preconditions in sampling distributions [PR 82584] These three distributions all require 0 < S where S is the sum of the weights. When the sum is zero there's an undefined FP division by zero. Add assertions to help users diagnose the problem. libstdc++-v3/ChangeLog: PR libstdc++/82584 * include/bits/random.tcc (discrete_distribution::param_type::_M_initialize) (piecewise_constant_distribution::param_type::_M_initialize) (piecewise_linear_distribution::param_type::_M_initialize): Add assertions for positive sums.. * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line.
[Bug libstdc++/82584] div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- $ g++11 rando.cc -D_GLIBCXX_ASSERTIONS $ ./a.out /home/jwakely/gcc/11/include/c++/11.0.0/bits/random.tcc:2633: void std::discrete_distribution<_IntType>::param_type::_M_initialize() [with _IntType = int]: Assertion '__sum > 0' failed. Aborted (core dumped)
[Bug target/96313] [AArch64] vqmovun* return types should be unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:7d177b142dcbe841124fe023cb592914d4200e57 commit r10-8868-g7d177b142dcbe841124fe023cb592914d4200e57 Author: Kyrylo Tkachov Date: Wed Sep 30 12:00:20 2020 +0100 PR target/96313 AArch64: vqmovun* return types should be unsigned In this PR we have the wrong return type for some intrinsics. It should be unsigned, but we implement it as signed. Fix this by adjusting the type qualifiers used when creating the builtins and fixing the type in the arm_neon.h intrinsic. With the adjustment in qualifiers we now don't need to cast the result when returning. Bootstrapped and tested on aarch64-none-linux-gnu. gcc/ PR target/96313 * config/aarch64/aarch64-simd-builtins.def (sqmovun): Use UNOPUS qualifiers. * config/aarch64/arm_neon.h (vqmovun_s16): Adjust builtin call. Remove unnecessary result cast. (vqmovun_s32): Likewise. (vqmovun_s64): Likewise. (vqmovunh_s16): Likewise. Fix return type. (vqmovuns_s32): Likewise. (vqmovund_s64): Likewise. gcc/testsuite/ PR target/96313 * gcc.target/aarch64/pr96313.c: New test. * gcc.target/aarch64/scalar_intrinsics.c (test_vqmovunh_s16): Adjust return type. (test_vqmovuns_s32): Likewise. (test_vqmovund_s64): Likewise. (cherry picked from commit 135b043196b5575c690ef1e07bcbb49bf037c3a2)
[Bug target/97150] [AArch64] 2nd parameter of unsigned Neon scalar shift intrinsics should be signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97150 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:11af9c329ae528abb8c69ae8fae96a0f3fc6ed87 commit r10-8869-g11af9c329ae528abb8c69ae8fae96a0f3fc6ed87 Author: Kyrylo Tkachov Date: Wed Sep 30 12:01:23 2020 +0100 PR target/97150 AArch64: 2nd parameter of unsigned Neon scalar shift intrinsics should be signed In this PR the second argument to the intrinsics should be signed but we use an unsigned one erroneously. The corresponding builtins are already using the correct types so it's just a matter of correcting the signatures in arm_neon.h gcc/ PR target/97150 * config/aarch64/arm_neon.h (vqrshlb_u8): Make second argument signed. (vqrshlh_u16): Likewise. (vqrshls_u32): Likewise. (vqrshld_u64): Likewise. (vqshlb_u8): Likewise. (vqshlh_u16): Likewise. (vqshls_u32): Likewise. (vqshld_u64): Likewise. (vshld_u64): Likewise. gcc/testsuite/ PR target/97150 * gcc.target/aarch64/pr97150.c: New test. (cherry picked from commit 2d8fbebdb1eaca8de557ab3052535a8e4b8f8972)
[Bug other/97309] Improve documentation of -fallow-store-data-races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309 --- Comment #2 from CVS Commits --- The master branch has been updated by Qing Zhao : https://gcc.gnu.org/g:baf4750feaa6a5fa502ae7bc0b90f31640af6f47 commit r11-3732-gbaf4750feaa6a5fa502ae7bc0b90f31640af6f47 Author: qing zhao Date: Thu Oct 8 17:01:07 2020 +0200 Improve documentation of -fallow-store-data-races 2020-10-08 John Henning gcc/ PR other/97309 * doc/invoke.texi: Improve documentation of -fallow-store-data-races.
[Bug other/97309] Improve documentation of -fallow-store-data-races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from qinzhao at gcc dot gnu.org --- fixed.
[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 #4 from Tom de Vries --- So, I think calling functions from simd code is atm not supported for nvptx. Stack variables in simd code are mapped on a per-thread stack rather than on the usual per-warp stack. The functions are compiled with the usual per-warp stack, so calling those functions from simd might mean the different lanes are gonna disagree about what the value in a stack variable should be. Having said that, for the example in comment 2, there only should be one thread executing the call, so this doesn't explain the illegal memory access.
[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97335 --- Comment #2 from Martin Liška --- With the current master (g:3e1123e52f8eca2650efa0bc81768792d328961f) one needs only one IPA modref transform to trigger the wrong code: -fdbg-cnt=ipa_mod_ref:778-778 where one needs to copy the input file to benchspec/CPU/525.x264_r/build/build_peak_gcc7-m64. folder: cp ../../../525.x264_r/data/test/input/BuckBunny.264 . One can see the difference in PRE dump file.
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #11 from Martin Liška --- (In reply to Tamar Christina from comment #0) > With just -Ofast the benchmark doesn't seem to ever terminate until it is > eventually killed. > Can't reproduce the stuck without -flto.
[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97335 --- Comment #3 from Martin Liška --- One needs -flto here.
[Bug tree-optimization/97317] [11 Regression] ICE in verify_range, at value-range.cc:369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317 --- Comment #3 from Andrew Macleod --- Created attachment 49331 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49331&action=edit patch to calculate negative side properly This is actually due to not handling a cast very well when the precision of the RHS is only 1 greater than the precision of the LHS. lhs = (cast) RHS we calculate the value of RHS by treating LHS as an unsigned, and 1) adding in all the ranges of LHS as positive ranges 2) adding in all the LHS values as negative values 3) filling in all the other ranges in RHS between those negative and positive values. ie, all the various upper bits in RHS can be on or off... THe code breaks down when the precision of the RHS is off by one. when calculating those negative values in 3), there wasn't a expectation that the sign bit *is* basically the entire range, so when it was trying to calculate the range o fthose bits, it was trying to create a nonsensical range. This patch fixes that particular problem, but further examination shows we arent producing ranges as good as we could.. so I will continue delving into it.
[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 #5 from Tom de Vries --- FWIW, another aspect here is convergence (as usual). Looking at the SASS code for main$_omp_fn$0$impl, I don't find evidence for the usual divergence/convergence ops (SSY/SYNC), which might mean that the following shfl is executed in divergent mode, so, even if we would not get the memory access error, we would not get correct results.
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #12 from Tamar Christina --- (In reply to Martin Liška from comment #11) > (In reply to Tamar Christina from comment #0) > > With just -Ofast the benchmark doesn't seem to ever terminate until it is > > eventually killed. > > > > Can't reproduce the stuck without -flto. You're right, had the timeout set too low in the CI. it does work without lto. Sorry about that.
[Bug testsuite/97337] New: new test case gcc.dg/pr97315-1.c fails with excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97337 Bug ID: 97337 Summary: new test case gcc.dg/pr97315-1.c fails with excess errors Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:214d514fafcd78cd54e4a4aa9ae08c89abf9cc57, r11-3717 make -k check-gcc RUNTESTFLAGS=dg.exp=gcc.dg/pr97315-1.c FAIL: gcc.dg/pr97315-1.c (test for excess errors) # of unexpected failures1 Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:6:23: error: empty enum is invalid /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:8:3: error: unknown type name 'tree_code' /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:11:3: error: unknown type name 'tree_base' /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:13:8: error: unknown type name 'tree_code_class' /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:15:28: error: unknown type name 'tree_code' /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:15:44: error: unknown type name 'tree_code' /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:22:51: error: request for member 'code' in something not a structure or union /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:23:38: error: request for member 'code' in something not a structure or union /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:25:12: warning: implicit declaration of function 'tree_check3' [-Wimplicit-function-declaration]
[Bug target/96313] [AArch64] vqmovun* return types should be unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:18d980d94f8d7187ce30bf23ddd365fa54189c36 commit r9-8982-g18d980d94f8d7187ce30bf23ddd365fa54189c36 Author: Kyrylo Tkachov Date: Wed Sep 30 12:00:20 2020 +0100 PR target/96313 AArch64: vqmovun* return types should be unsigned In this PR we have the wrong return type for some intrinsics. It should be unsigned, but we implement it as signed. Fix this by adjusting the type qualifiers used when creating the builtins and fixing the type in the arm_neon.h intrinsic. With the adjustment in qualifiers we now don't need to cast the result when returning. Bootstrapped and tested on aarch64-none-linux-gnu. gcc/ PR target/96313 * config/aarch64/aarch64-simd-builtins.def (sqmovun): Use UNOPUS qualifiers. * config/aarch64/arm_neon.h (vqmovun_s16): Adjust builtin call. Remove unnecessary result cast. (vqmovun_s32): Likewise. (vqmovun_s64): Likewise. (vqmovunh_s16): Likewise. Fix return type. (vqmovuns_s32): Likewise. (vqmovund_s64): Likewise. gcc/testsuite/ PR target/96313 * gcc.target/aarch64/pr96313.c: New test. * gcc.target/aarch64/scalar_intrinsics.c (test_vqmovunh_s16): Adjust return type. (test_vqmovuns_s32): Likewise. (test_vqmovund_s64): Likewise. (cherry picked from commit 135b043196b5575c690ef1e07bcbb49bf037c3a2) (cherry picked from commit 7d177b142dcbe841124fe023cb592914d4200e57)
[Bug target/97150] [AArch64] 2nd parameter of unsigned Neon scalar shift intrinsics should be signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97150 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:d5c6ea22fe6db1ee19a178941a8c7f8ff5d0538c commit r9-8983-gd5c6ea22fe6db1ee19a178941a8c7f8ff5d0538c Author: Kyrylo Tkachov Date: Wed Sep 30 12:01:23 2020 +0100 PR target/97150 AArch64: 2nd parameter of unsigned Neon scalar shift intrinsics should be signed In this PR the second argument to the intrinsics should be signed but we use an unsigned one erroneously. The corresponding builtins are already using the correct types so it's just a matter of correcting the signatures in arm_neon.h gcc/ PR target/97150 * config/aarch64/arm_neon.h (vqrshlb_u8): Make second argument signed. (vqrshlh_u16): Likewise. (vqrshls_u32): Likewise. (vqrshld_u64): Likewise. (vqshlb_u8): Likewise. (vqshlh_u16): Likewise. (vqshls_u32): Likewise. (vqshld_u64): Likewise. (vshld_u64): Likewise. gcc/testsuite/ PR target/97150 * gcc.target/aarch64/pr97150.c: New test. (cherry picked from commit 2d8fbebdb1eaca8de557ab3052535a8e4b8f8972) (cherry picked from commit 11af9c329ae528abb8c69ae8fae96a0f3fc6ed87)
[Bug target/97338] New: [nvptx] Convergence checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97338
Bug ID: 97338
Summary: [nvptx] Convergence checking
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
With ptx, we have insns that need to be executed in convergent mode, that is,
all threads in the warp active.
We can unfortunately not enforce this, but we could check it, which could help
pinpoint problems.
A ptx insn:
...
vote.ballot.b32 %rbla, 1;
...
gives us the regmask of active threads, so we could check:
...
{
.reg .u32 %rwarp_active_mask;
vote.ballot.b32 %rwarp_active_mask, 1;
.reg .pred %pconvergent;
setp.eq.u32 %pconvergent,%rwarp_active_mask,-1;
@ ! %pconvergent trap;
}
...
[Bug tree-optimization/97317] [11 Regression] ICE in verify_range, at value-range.cc:369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from David Binderman --- I see this one also. I am reducing some C++ code from a build of the qt3 package on x86_64 linux.
[Bug libstdc++/97339] New: std::async sometimes prevents std::current_exception from working properly in the terminate handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97339
Bug ID: 97339
Summary: std::async sometimes prevents std::current_exception
from working properly in the terminate handler
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
If std::async is called with a noexcept function that throws an exception and
contains a catch block which catches exceptions of a different type,
std::current_exception returns an empty exception pointer when called from the
terminate handler.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)
$ cat y.cpp
#include
#include
void term_handler() {
auto e = std::current_exception();
if (e)
std::cout << "Died with exception" << std::endl;
else
std::cout << "Died without exception" << std::endl;
std::abort();
}
void bar() noexcept {
try {
throw "";
}
catch (int) { }
}
int main() {
std::set_terminate(&term_handler);
std::async(std::launch::async, &bar).get();
}
$ g++ y.cpp -pthread
$ ./a.out
Died without exception
Aborted (core dumped)
$
This happens regardless of whether launch::async or launch::deferred is used,
but does not happen if the function is called directly or is run by a
std::thread.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #3 from Kip Warner --- Martin, is -mcpu deprecated for all architectures or just x86?
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- -m* options are target specific, so each target can and often does have its own. -mcpu= is deprecated just on x86, but many other targets don't even have -mcpu= and never had, etc. On the other side, some targets like powerpc do use -mcpu= where other targets use -march= instead, or some have even more complicated handling (arm/aarch64).
[Bug c++/97340] New: Spurious rejection of member variable template of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97340
Bug ID: 97340
Summary: Spurious rejection of member variable template of
reference type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: herring at lanl dot gov
Target Milestone: ---
In many recent versions of GCC, the following valid code
struct A {
template
static constexpr const int &x=0;
};
template
struct B {
static constexpr int y=A::template x;
};
template struct B<>;
produces
error: ''indirect_ref' not supported by dump_decl' is not a
template [-fpermissive]
7 | static constexpr int y=A::template x;
| ^~
The 'template' after '::' here is unnecessary; removing it avoids the error,
but the error also appears if A is a class template (so that it's necessary to
write "A::template x"). Making A::x not be a reference also avoids the
error, as does referring to it from a non-templated context.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #5 from Kip Warner --- The reason I asked is because of that inconsistency in the -mcpu usage on targets. Thanks for clarifying.
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d4ec0a15afb7538247206aa9936071544fd860f8 commit r10-8870-gd4ec0a15afb7538247206aa9936071544fd860f8 Author: Harald Anlauf Date: Sun Oct 4 20:24:29 2020 +0200 PR fortran/97272 - Wrong answer from MAXLOC with character arg The optional KIND argument to the MINLOC/MAXLOC intrinsic must not be passed to the library function, as the kind conversion of the result is treated explicitly elsewhere. gcc/fortran/ChangeLog: PR fortran/97272 * trans-intrinsic.c (strip_kind_from_actual): Helper function for removal of KIND argument. (gfc_conv_intrinsic_minmaxloc): Ignore KIND argument here, as it is treated elsewhere. gcc/testsuite/ChangeLog: PR fortran/97272 * gfortran.dg/pr97272.f90: New test. (cherry picked from commit 35d2c6b6e8a7448a84abbf967feeb78a29117014)
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #6 from Jakub Jelinek --- There is no consistency. Targets that have all of -march=, -mcpu= and -mtune=: aarch64, arm, cris, i386 (-mcpu= deprecated and treated as -mtune=), m68k Targets that have just -march= and -mtune=: gcn, mips, riscv, s390 Targets that have just -march= and -mcpu=: csky, iq2000, nds32 Targets that have just -mcpu= and -mtune=: alpha, arc, rs6000, sparc, visium Targets that have just -mcpu=: bfin, frv, m32c, microblaze, msp430, rl78, rx, tilegx, tilepro Targets that have just -mtune=: ia64, mn10300 Targets that have just -march=: c6x, nios2, pa
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #7 from Kip Warner --- I understand what you mean from a maintainer's standpoint. But from a user's standpoint, that's an inconsistency.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #8 from Jakub Jelinek --- Except for native supported on a subset of the architectures, no values are the same, so this is highly target specific anyway. And yes, were it designed all now, we'd use the same options, but some of these choices are 33 years old, others 10, 20, 30 etc., so it is difficult to adjust it now without breaking stuff too much.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #9 from Kip Warner --- Yup. Agreed.
[Bug c++/97340] Spurious rejection of member variable template of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97340 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-10-08 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed.
[Bug target/96313] [AArch64] vqmovun* return types should be unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313 --- Comment #9 from CVS Commits --- The releases/gcc-8 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:7f8115b305f1a1a2ddec4f59bc08a3415359dda6 commit r8-10575-g7f8115b305f1a1a2ddec4f59bc08a3415359dda6 Author: Kyrylo Tkachov Date: Wed Sep 30 12:00:20 2020 +0100 PR target/96313 AArch64: vqmovun* return types should be unsigned In this PR we have the wrong return type for some intrinsics. It should be unsigned, but we implement it as signed. Fix this by adjusting the type qualifiers used when creating the builtins and fixing the type in the arm_neon.h intrinsic. With the adjustment in qualifiers we now don't need to cast the result when returning. Bootstrapped and tested on aarch64-none-linux-gnu. gcc/ PR target/96313 * config/aarch64/aarch64-simd-builtins.def (sqmovun): Use UNOPUS qualifiers. * config/aarch64/arm_neon.h (vqmovun_s16): Adjust builtin call. Remove unnecessary result cast. (vqmovun_s32): Likewise. (vqmovun_s64): Likewise. (vqmovunh_s16): Likewise. Fix return type. (vqmovuns_s32): Likewise. (vqmovund_s64): Likewise. gcc/testsuite/ PR target/96313 * gcc.target/aarch64/pr96313.c: New test. * gcc.target/aarch64/scalar_intrinsics.c (test_vqmovunh_s16): Adjust return type. (test_vqmovuns_s32): Likewise. (test_vqmovund_s64): Likewise. (cherry picked from commit 135b043196b5575c690ef1e07bcbb49bf037c3a2) (cherry picked from commit 7d177b142dcbe841124fe023cb592914d4200e57) (cherry picked from commit 18d980d94f8d7187ce30bf23ddd365fa54189c36)
[Bug target/97150] [AArch64] 2nd parameter of unsigned Neon scalar shift intrinsics should be signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97150 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:311183d74e4f3fd5a37749cfbb0960e655e715fb commit r8-10576-g311183d74e4f3fd5a37749cfbb0960e655e715fb Author: Kyrylo Tkachov Date: Wed Sep 30 12:01:23 2020 +0100 PR target/97150 AArch64: 2nd parameter of unsigned Neon scalar shift intrinsics should be signed In this PR the second argument to the intrinsics should be signed but we use an unsigned one erroneously. The corresponding builtins are already using the correct types so it's just a matter of correcting the signatures in arm_neon.h gcc/ PR target/97150 * config/aarch64/arm_neon.h (vqrshlb_u8): Make second argument signed. (vqrshlh_u16): Likewise. (vqrshls_u32): Likewise. (vqrshld_u64): Likewise. (vqshlb_u8): Likewise. (vqshlh_u16): Likewise. (vqshls_u32): Likewise. (vqshld_u64): Likewise. (vshld_u64): Likewise. gcc/testsuite/ PR target/97150 * gcc.target/aarch64/pr97150.c: New test. (cherry picked from commit 2d8fbebdb1eaca8de557ab3052535a8e4b8f8972) (cherry picked from commit 11af9c329ae528abb8c69ae8fae96a0f3fc6ed87) (cherry picked from commit d5c6ea22fe6db1ee19a178941a8c7f8ff5d0538c)
[Bug target/97150] [AArch64] 2nd parameter of unsigned Neon scalar shift intrinsics should be signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97150 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from ktkachov at gcc dot gnu.org --- Fixed on GCC 8.5 onwards.
[Bug target/96313] [AArch64] vqmovun* return types should be unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from ktkachov at gcc dot gnu.org --- Fixed on GCC 8.5 onwards.
[Bug middle-end/97336] False positive -Wstring-compare warning for strncmp()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97336
Martin Sebor changed:
What|Removed |Added
Resolution|--- |INVALID
CC||msebor at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Martin Sebor ---
The warning works as intended: unless n > 4, the strncmp call will return
nonzero because the length of buf is less than 5. GCC partially unrolls the
loop and the first iteration of it is what triggers the warning. It disappears
when the buffer is cleared with memset only because GCC (as a limitation) loses
track of the length of the string in buf after that. Handling the case when n
is zero or less (e.g., via if (n <= 0) return 0;) does as well.
The IL that leads up to the warning can be seen in the output of the
-fdump-tree-dom4 option (below).
f (const char * p, int n)
{
sizetype ivtmp.6;
int i;
char buf[10];
char _3;
_Bool _4;
_Bool _5;
_Bool _6;
int _7;
int _10;
char prephitmp_20;
int _21;
unsigned int _25;
char pretmp_33;
[local count: 118111600]:
buf = ""; <<< strlen(buf) == 0
if (n_15(D) > 0)
goto ; [89.00%]
else
goto ; [11.00%]
...
[local count: 12992276]: <<< n == 0
_21 = __builtin_strncmp (&buf, "12345", 5); <<< warning here
if (_21 == 0) <<< folded to false
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 6496138]:
# prephitmp_20 = PHI <0(4)>
[local count: 95940523]:
goto ; [100.00%]
[local count: 105119324]:
_7 = __builtin_strncmp (&buf, "12345", 5);<<< second strncmp call
if (_7 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 52559662]:
if (i_19 == 5)
goto ; [23.93%]
else
goto ; [76.07%]
[local count: 40175661]:
pretmp_33 = buf[5];
if (pretmp_33 == 32)
goto ; [25.01%]
else
goto ; [74.99%]
[local count: 118111600]:
# _10 = PHI <1(9), 0(6), 1(8)>
buf ={v} {CLOBBER};
return _10;
}
Rewriting the code in a way that avoids the loop (e.g., by using memcpy
instead) also avoids the warning.
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #13 from Jan Hubicka --- OK, I can reproduce it even though the propagation happens in different function in dom rather than pre. The callee is again the operator++ so I start to suspect aliasing violation there. I get: ipa-modref: in build_patches.constprop/375859, call to operator++/33005 does not clobber MEM [(struct DoFCellAccessor *)&active_cell] 6->6 parameter of call is &active_cell so we disambiguate param0 with while the summary for ipa-modref stores: Limits: 32 bases, 16 refs Base 0: alias set 11 Ref 0: alias set 13 access: Parm 0 param offset:64 offset:32 size:32 max_size:32 access: Parm 0 param offset:64 offset:0 size:32 max_size:32 So this really seems that the alias set 6 is not conflicting with alias sets 11 or 13. Honza
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #14 from Jan Hubicka ---
So this really seems that the alias set 6 is not conflicting with alias sets
11 or 13. active_cell is
struct active_cell_iterator active_cell;
and the code around seems SRA injected
MEM[(struct TriaRawIterator *)&active_cell] ={v} {CLOBBER};
MEM [(struct DoFCellAccessor *)&active_cell] =
cell$dof_handler_253;
MEM [(struct DoFCellAccessor *)&active_cell + 8B] =
cell$8$present_level_242;
MEM [(struct DoFCellAccessor *)&active_cell + 12B] =
cell$8$present_index_245;
MEM [(struct DoFCellAccessor *)&active_cell +
16B] = cell$8$tria_244;
operator++ (&active_cell);
MEM[(struct TriaRawIterator *)&D.17355].accessor = MEM[(const struct
TriaRawIterator &)&active_cell].accessor;
and we CSE is acrss the call
Honza
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #15 from Jan Hubicka --- So it seems that problem is that store in operator++ is TriaObjectAcessor while read is DoFCellAccessor. I am however not sure where the type puning happens :(
[Bug libgomp/97212] [OpenMP] 'depend' clause with 'target nowait' (!) + 'task' does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97212 --- Comment #2 from Jakub Jelinek --- I believe the testcase is invalid. As the explicit task doesn't have if(false) clause, the task isn't undeferred, so it is up to the implementation whether it waits for its completion or just continues (defers it). And there is no task synchronization point before the if (sum != N) __builtin_abort (); statement, so if the implementation decides to defer it, then there is no guarantee it completes before that statement. Without the target nowait task gcc wouldn't defer it because there is just an implicit parallel region rather than explicit (e.g. if you add parallel num_threads(1) around most of main and change target nowait to task, you'd get the same behavior), but in order to support async target tasks we do create intentionally a team and thus defer the task. So, the testcase needs something like #pragma omp taskwait or taskwait with depend or add if(false) to the task.
[Bug c++/96805] [10/11 Regression] ICE: Segmentation fault in instantiate_template / pop_nested_class()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
