[Bug tree-optimization/95199] Remove extra variable created for memory reference in loop vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199
--- Comment #3 from Richard Biener ---
Btw, there's already vinfo->ivexpr_map to aid simplifying the IL to a point
where IVOPTs can eliminate redundant IVs. Eliminating them in the vectorizer
is more complicated because of all the code for the IV update code generation.
There's also late FRE which in theory could eliminate them (if we'd run it
in iterative mode). But of course the idea is to eliminate dups before
or in IVOPTs because it certainly affects IVOPTs decisions.
So I think we should try to enhance IVOPTs here. For the reduced testcase
below it already works so I believe it has sth to do with SVE
internal functions for scatter/gather?
void __GIMPLE (ssa,startwith("fix_loops"))
foo (double * a, double m, int inc_x, int inc_y)
{
int i;
int iy;
int ix;
double * b;
long unsigned int _1;
long unsigned int _2;
double * _3;
long unsigned int _4;
long unsigned int _5;
double * _6;
__BB(2):
goto __BB4;
__BB(3):
_1 = (long unsigned int) ix_7;
_2 = _1 * 8ul;
_3 = a_11(D) + _2;
__MEM (_3) = m_17(D);
_4 = (long unsigned int) iy_8;
_5 = _4 * 8ul;
_6 = a_11(D) + _5;
__MEM (_6) = m_17(D);
ix_21 = ix_7 + inc_x_20(D);
iy_22 = iy_8 + inc_x_20(D);
i_23 = i_9 + 1;
goto __BB4;
__BB(4,loop_header(1)):
ix_7 = __PHI (__BB2: 0, __BB3: ix_21);
iy_8 = __PHI (__BB2: 0, __BB3: iy_22);
i_9 = __PHI (__BB2: 0, __BB3: i_23);
if (i_9 <= 999)
goto __BB3;
else
goto __BB5;
__BB(5):
return;
}
[Bug target/90811] [nvptx] ptxas error on OpenMP offloaded code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811 --- Comment #23 from CVS Commits --- The master branch has been updated by Kito Cheng : https://gcc.gnu.org/g:dfa4fcdba374ed44d4aa1a22b2738f3f5c5b37af commit r11-508-gdfa4fcdba374ed44d4aa1a22b2738f3f5c5b37af Author: Kito Cheng Date: Tue Apr 14 14:53:19 2020 +0800 Fix alignment for local variable [PR90811] - The alignment for local variable was adjust during estimate_stack_frame_size, however it seems wrong spot to adjust that, expand phase will adjust that but it little too late to some gimple optimization, which rely on certain target hooks need to check alignment, forwprop is an example for that, result of simplify_builtin_call rely on the alignment on some target like ARM or RISC-V. - Exclude static local var and hard register var in the process of alignment adjustment. - This patch fix gfortran.dg/pr45636.f90 for arm and riscv. - Regression test on riscv32/riscv64 and x86_64-linux-gnu, no new fail introduced. gcc/ChangeLog PR target/90811 * Makefile.in (OBJS): Add adjust-alignment.o. * adjust-alignment.c (pass_data_adjust_alignment): New. (pass_adjust_alignment): New. (pass_adjust_alignment::execute): New. (make_pass_adjust_alignment): New. * tree-pass.h (make_pass_adjust_alignment): New. * passes.def: Add pass_adjust_alignment.
[Bug c/95141] [8/9/10/11 Regression] Incorrect integer overflow warning message for bitand expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95141 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4a88caf21a0a85129f6c985ca13ba3eb54ff5366 commit r11-509-g4a88caf21a0a85129f6c985ca13ba3eb54ff5366 Author: Richard Biener Date: Tue May 19 07:58:33 2020 +0200 c/95141 - fix bogus integer overflow warning This fixes an integer overflow warning that ultimatively happens because of TREE_OVERFLOW propagating through transforms and the existing guard against this, 375 if (TREE_OVERFLOW_P (ret) 376 && !TREE_OVERFLOW_P (op0) 377 && !TREE_OVERFLOW_P (op1)) 378 overflow_warning (EXPR_LOC_OR_LOC (expr, input_location, being insufficient. Rather than trying to use sth like walk_tree to exhaustively walk operands (with the possibility of introducing quadraticness when folding larger expressions recursively) the following amends the above with an ad-hoc test for a binary op0 with a possibly constant op1. 2020-05-30 Richard Biener PR c/95141 gcc/c * c-fold.c (c_fully_fold_internal): Enhance guard on overflow_warning. gcc/testsuite * gcc.dg/pr95141.c: New testcase.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643 Richard Biener changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] Wrong |Wrong error message with|error message with unsigned |unsigned char a = uchar&512 |char a = uchar&512 Known to work||11.0 Known to fail||10.1.0 --- Comment #28 from Richard Biener --- Fixed on trunk sofar.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643 Richard Biener changed: What|Removed |Added Known to work|11.0| Summary|[8/9/10 Regression] Wrong |[8/9/10/11 Regression] |error message with unsigned |Wrong error message with |char a = uchar&512 |unsigned char a = uchar&512 --- Comment #29 from Richard Biener --- Sorry, wrong bug...
[Bug c/95141] [8/9/10 Regression] Incorrect integer overflow warning message for bitand expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95141 Richard Biener changed: What|Removed |Added Known to fail||10.1.0 Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |Incorrect integer overflow |Incorrect integer overflow |warning message for bitand |warning message for bitand |expression |expression Known to work||11.0 --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug target/92658] x86 lacks vector extend / truncate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658 --- Comment #17 from Hongtao.liu --- Created attachment 48570 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48570&action=edit 0001-Add-missing-vector-truncmn2-expanders-PR92658.patch Seems there're only truncmn2 for truncate, not expander for us_truncate and ss_truncate, am i missing?
[Bug c++/95229] New: ice in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229
Bug ID: 95229
Summary: ice in mark_jump_label_1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ code:
struct a {
unsigned long b;
unsigned long c;
};
class {
public:
a d;
} e;
struct f {
unsigned g;
unsigned h;
int i();
};
int f::i() {
e.d.b += g;
e.d.c += h;
}
compiled with recent gcc trunk and compiler flag -O3 -march=native,
I get
$ /home/dcb/gcc/results/bin/gcc -c -O3 -march=native bug609.cc
bug609.cc: In member function ‘int f::i()’:
bug609.cc:17:1: warning: no return statement in function returning non-void
[-Wreturn-type]
17 | }
| ^
during RTL pass: expand
bug609.cc:17:1: internal compiler error: Segmentation fault
0xf4bbb9 crash_signal(int)
../../trunk.git/gcc/toplev.c:328
0xd5878a mark_jump_label_1(rtx_def*, rtx_insn*, bool, bool)
../../trunk.git/gcc/jump.c:1087
0xd588b0 mark_jump_label_1(rtx_def*, rtx_insn*, bool, bool)
../../trunk.git/gcc/jump.c:1211
0xd588b0 mark_jump_label_1(rtx_def*, rtx_insn*, bool, bool)
../../trunk.git/gcc/jump.c:1211
The bug first seems to occur on today's gcc. Yesterdays seems fine:
/home/dcb/gcc/results.20200519/bin/gcc
/home/dcb/gcc/results.20200520/bin/gcc
during RTL pass: expand
...
Native is x86_64, AMD FX(tm)-8350, Piledriver, bdver2.
[Bug tree-optimization/95230] New: Failure to optimize bit-scatter pattern to and 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95230
Bug ID: 95230
Summary: Failure to optimize bit-scatter pattern to and 1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
uint32_t scatter(uint32_t val)
{
uint32_t res = 0;
uint32_t off = 0;
for (uint32_t I = 0; I < 32; ++I)
if (1 & (1 << I))
res |= (val & (1 << off++)) << I;
return res;
}
This can be optimized to `return val & 1;`. LLVM does this transformation, but
GCC does not. There is a more generic optimization that looks like it can be
done using something else than `1` as the left operand of the `&` in the `if`.
[Bug tree-optimization/95231] New: [11 Regression] error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type of the since r11-451-gfe168751c5c1c517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95231
Bug ID: 95231
Summary: [11 Regression] error: the first argument of a
‘vec_cond_expr’ must be of a boolean vector type of
the since r11-451-gfe168751c5c1c517
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
I see the following ICE:
$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/vector-compare.C
-O3 -fnon-call-exceptions
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/vector-compare.C: In
function ‘int main()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/vector-compare.C:36:1:
error: unsupported operation or type for vector comparison returning a boolean
36 | }
| ^
vector(4) float
vector(4) float
_25 = _13 > _23;
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/vector-compare.C:36:1:
error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type
of the same number of elements as the result
vector(4) int
bool
_24 = VEC_COND_EXPR <_25, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/vector-compare.C:36:1:
error: unsupported operation or type for vector comparison returning a boolean
vector(4) float
vector(4) float
_29 = _26 > _27;
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/vector-compare.C:36:1:
error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type
of the same number of elements as the result
vector(4) int
bool
_28 = VEC_COND_EXPR <_29, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/vector-compare.C:36:1:
error: unsupported operation or type for vector comparison returning a boolean
vector(4) float
vector(4) float
_33 = _30 > _31;
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/vector-compare.C:36:1:
error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type
of the same number of elements as the result
vector(4) int
bool
_32 = VEC_COND_EXPR <_33, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/vector-compare.C:36:1:
error: unsupported operation or type for vector comparison returning a boolean
vector(4) float
vector(4) float
_37 = _34 > _35;
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/vector-compare.C:36:1:
error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type
of the same number of elements as the result
vector(4) int
bool
_36 = VEC_COND_EXPR <_37, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
during GIMPLE pass: einline
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/vector-compare.C:36:1:
internal compiler error: verify_gimple failed
0x10f8d61 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5461
0xfd4e7f execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1985
0xfd5c2e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2039
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/95231] [11 Regression] error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type of the since r11-451-gfe168751c5c1c517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95231 Martin Liška changed: What|Removed |Added Known to fail||11.0 Ever confirmed|0 |1 Priority|P3 |P1 Status|UNCONFIRMED |NEW Known to work||10.1.0 Last reconfirmed||2020-05-20 Target Milestone|--- |11.0
[Bug middle-end/95229] ice in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229 Andrew Pinski changed: What|Removed |Added Component|c++ |middle-end --- Comment #1 from Andrew Pinski --- >Native is x86_64, AMD FX(tm)-8350, Piledriver, bdver2. Can you add -v and provide the full output as -march=native is not really helpfull.
[Bug c++/95232] New: [11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r11-283-gf315d1477d5164cb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95232
Bug ID: 95232
Summary: [11 Regression] ICE in make_ssa_name_fn, at
tree-ssanames.c:279 since r11-283-gf315d1477d5164cb
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
I see the following ICE:
$ cat para.ii
template
void foo(T argc) {}
template
int tmain(T argc) {
typedef double (*chunk_t)[argc[0][0]];
#pragma omp parallel
{
foo(argc);
chunk_t var;(void)var[0][0];
}
return 0;
}
int global;
int main (int argc, char **argv) {
int a[argc];
#pragma omp parallel shared(global, a) default(none)
foo(a[1]), a[1] = global;
#pragma omp parallel private(global, a) default(none)
#pragma omp parallel shared(global, a) default(none)
foo(a[1]), a[1] = global;
#pragma omp parallel shared(global, a) default(none)
#pragma omp parallel shared(global, a) default(none)
foo(a[1]), a[1] = global;
return tmain(argv);
}
$ g++ para.ii -ftrapv -fnon-call-exceptions -Os -fsanitize=undefined -c
during IPA pass: inline
para.ii: In function ‘int main(int, char**)’:
para.ii:31:15: internal compiler error: in make_ssa_name_fn, at
tree-ssanames.c:279
31 | return tmain(argv);
| ~^~
0x82fa3b make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
/home/marxin/Programming/gcc/gcc/tree-ssanames.c:279
0x112d344 make_ssa_name
/home/marxin/Programming/gcc/gcc/tree-ssanames.h:115
0x112d344 remap_ssa_name
/home/marxin/Programming/gcc/gcc/tree-inline.c:258
0x11305ef copy_tree_body_r(tree_node**, int*, void*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:1252
0x1389633 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:11956
0x112b7ce remap_type_1
/home/marxin/Programming/gcc/gcc/tree-inline.c:619
0x112bc19 remap_type(tree_node*, copy_body_data*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:736
0x112b8a1 remap_type_1
/home/marxin/Programming/gcc/gcc/tree-inline.c:555
0x112bc19 remap_type(tree_node*, copy_body_data*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:736
0x112b294 remap_type_1
/home/marxin/Programming/gcc/gcc/tree-inline.c:448
0x112bc19 remap_type(tree_node*, copy_body_data*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:736
0x112bd1f remap_decl(tree_node*, copy_body_data*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:400
0x112c5ec remap_decls
/home/marxin/Programming/gcc/gcc/tree-inline.c:785
0x112e3ba remap_block
/home/marxin/Programming/gcc/gcc/tree-inline.c:843
0x112e465 remap_blocks
/home/marxin/Programming/gcc/gcc/tree-inline.c:865
0x11378f6 expand_call_inline
/home/marxin/Programming/gcc/gcc/tree-inline.c:4963
0x11385f9 gimple_expand_calls_inline
/home/marxin/Programming/gcc/gcc/tree-inline.c:5277
0x11385f9 optimize_inline_calls(tree_node*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:5450
0xe98b23 inline_transform(cgraph_node*)
/home/marxin/Programming/gcc/gcc/ipa-inline-transform.c:736
0xfd779a execute_one_ipa_transform_pass
/home/marxin/Programming/gcc/gcc/passes.c:2233
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/95232] [11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r11-283-gf315d1477d5164cb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95232 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||10.0 Last reconfirmed||2020-05-20 Known to fail||11.0 Ever confirmed|0 |1 Target Milestone|--- |11.0
[Bug middle-end/95229] ice in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229 --- Comment #2 from David Binderman --- Using built-in specs. COLLECT_GCC=/home/dcb/gcc/results/bin/gcc Target: x86_64-pc-linux-gnu Configured with: ../trunk.git/configure --prefix=/home/dcb/gcc/results.20200520 --disable-bootstrap --disable-multilib --disable-werror --enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20200520 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-O3' '-w' '-march=native' /home/dcb/gcc/results.20200520/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1plus -quiet -v -D_GNU_SOURCE /home/dcb/gcc/foundBugs/bug609.cc -march=bdver2 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mfma4 -mxop -mbmi -mno-sgx -mno-bmi2 -mno-pconfig -mno-wbnoinvd -mtbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mf16c -mno-fsgsbase -mno-rdsee d -mprfchw -mno-adx -mfxsr -mxsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx5 12vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b -mno- waitpkg -mno-cldemote -mno-ptwrite -mno-avx512bf16 -mno-enqcmd -mno-avx512vp2intersect -mno-serialize -mno-tsxldtrk --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2 -quiet -dumpbase bug609.cc -auxbase bug609 -O3 -w -version -o /tmp/ccmaYNdH.s GNU C++14 (GCC) version 11.0.0 20200520 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version Clang 10.0.0 (Fedora 10.0.0-1.fc32), GMP version 6.1.2, MPFR version 4.0.2-p7, M PC version 1.1.0, isl version isl-0.16.1-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/home/dcb/gcc/results.20200520/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/dcb/gcc/results.20200520/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0 /home/dcb/gcc/results.20200520/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-pc-linux- gnu /home/dcb/gcc/results.20200520/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward /home/dcb/gcc/results.20200520/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include /usr/local/include /home/dcb/gcc/results.20200520/include /home/dcb/gcc/results.20200520/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include-fixed /usr/include End of search list. GNU C++14 (GCC) version 11.0.0 20200520 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version Clang 10.0.0 (Fedora 10.0.0-1.fc32), GMP version 6.1.2, MPFR version 4.0.2-p7, M PC version 1.1.0, isl version isl-0.16.1-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 37a65bc431cc6a404e564314c7e7906a during RTL pass: expand LzmaBench.cpp: In member function ‘LONG CEncoderInfo::Decode(UInt32)’: LzmaBench.cpp:651:1: internal compiler error: Segmentation fault 0xf4bbb9 crash_signal(int) ../../trunk.git/gcc/toplev.c:328 0xd5878a mark_jump_label_1(rtx_def*, rtx_insn*, bool, bool) ../../trunk.git/gcc/jump.c:1087 0xd588b0 mark_jump_label_1(rtx_def*, rtx_insn*, bool, bool) ../../trunk.git/gcc/jump.c:1211 0xd588b0 mark_jump_label_1(rtx_def*, rtx_insn*, bool, bool) ../../trunk.git/gcc/jump.c:1211
[Bug c++/95233] New: Failure to compile regression in GCC 10.1 and 11 trunk with C++ 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95233 Bug ID: 95233 Summary: Failure to compile regression in GCC 10.1 and 11 trunk with C++ 20 Product: gcc Version: c++-concepts Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: s_gccbugzilla at nedprod dot com Target Milestone: --- Reported originally at https://github.com/ned14/outcome/issues/225 Works on GCC 9.3 with -std=c++2a -O3 -DNDEBUG -fconcepts: https://godbolt.org/z/cRyrj- Works on GCC trunk with -std=c++17 -O3 -DNDEBUG -fconcepts: https://godbolt.org/z/T3c88K Works on clang trunk with -std=c++20 -O3 -DNDEBUG: https://godbolt.org/z/ahbRsA Fails on GCC trunk with -std=c++20 -O3 -DNDEBUG: https://godbolt.org/z/NBdpqx (It also fails with the same error on GCC 10.1. The cause is switching into C++ 20, or using a GCC newer than 9.3 which works fine in C++ 20. GCC 10 and trunk work fine in C++ 17 with Concepts forced on) In file included from /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/bits/move.h:57, from /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/bits/nested_exception.h:40, from /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/exception:148, from /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/new:41, from /opt/compiler-explorer/libs/outcome/single-header/outcome.hpp:1008, from :1: /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/type_traits: In instantiation of 'constexpr outcome_v2_cdb9621d::basic_result::basic_result(T&&, outcome_v2_cdb9621d::basic_result::value_converting_constructor_tag) [with T = const outcome_v2_cdb9621d::basic_result >&; R = std::filesystem::__cxx11::path; S = std::error_code; NoValuePolicy = outcome_v2_cdb9621d::policy::error_code_throw_as_system_error]': /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/type_traits:901:30: required from 'struct std::__is_constructible_impl >, const outcome_v2_cdb9621d::basic_result >&>' /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/type_traits:906:12: required from 'struct std::is_constructible >, const outcome_v2_cdb9621d::basic_result >&>' /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/type_traits:3105:38: required from 'constexpr const bool std::is_constructible_v >, const outcome_v2_cdb9621d::basic_result >&>' /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/concepts:139:30: required from 'struct std::iterator_traits > >' /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/bits/fs_path.h:88:11: required by substitution of 'template using __is_path_iter_src = std::__and_::type, char>, std::is_same::type, char8_t>, std::is_same::type, wchar_t>, std::is_same::type, char16_t>, std::is_same::type, char32_t> >, std::is_base_of > [with _Iter = outcome_v2_cdb9621d::basic_result >; _Iter_traits = std::iterator_traits > >]' /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/bits/fs_path.h:95:5: [ skipping 13 instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ] /opt/compiler-explorer/libs/outcome/single-header/outcome.hpp:4248:3: required from 'constexpr outcome_v2_cdb9621d::basic_result::basic_result(T&&, outcome_v2_cdb9621d::basic_result::value_converting_constructor_tag) [with T = const outcome_v2_cdb9621d::basic_result >&; R = std::filesystem::__cxx11::path; S = std::error_code; NoValuePolicy = outcome_v2_cdb9621d::policy::error_code_throw_as_system_error]' /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/type_traits:1239:4: required from 'struct std::__is_trivially_copy_constructible_impl >, true>' /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/type_traits:1244:12: required from 'struct std::is_trivially_copy_constructible > >' /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/type_traits:3131:43: required from 'constexpr const bool std::is_trivially_copy_constructible_v > >' /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/optional:659:11: required from 'class std::optional > >' :10:57: required from here /opt/compiler-explorer/libs/outcome/single-header/outcome.hpp:4249:13: required by the constraints of 'template template requires outcome_v2_cdb9621d::basic_result::predicate::enable_value_converting_constructor constexpr outcome_v2_cdb9621d::basic_result::basic_result(T&&, outcome_v2_cdb9621d::basic_result::value_converting_constructor_tag)' /opt/compiler-explorer/gcc-trunk-20200512/include/c++/11.0.0/type_traits:901:30: error: the value of 'outcome_v2_cdb9621d::basic_result >::predicate::enable_value_converting_constructor >&>' is not usable in a constant expression 901 | : public __bool_constant<__is_constructible(_Tp, _Args...)> |
[Bug target/94591] [8/9/10/11 Regression] Assembler messages: Error: operand mismatch -- `rev64 v0.2d,v0.2d' (or `rev32 v0.2s,v0.2s')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94591 Alex Coplan changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org --- Comment #5 from Alex Coplan --- Re-opening to track backporting progress.
[Bug middle-end/95229] ice in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229 --- Comment #3 from Martin Liška --- Reproduced with -march=znver1. It breaks quite some SPEC benchmarks.
[Bug tree-optimization/95230] Failure to optimize bit-scatter pattern to and 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95230 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- I think the problem is: 1 & (1 << I) != 0 is not being transformed to I == 0 if I had the range of (0..31) Once that happens, we could split the loop into I != 0 (1..31) and I == 0 cases and the I != 0 case becomes empty. Etc.
[Bug middle-end/95229] [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||11.0 Keywords||needs-bisection Summary|ice in mark_jump_label_1|[11 Regression] in ||mark_jump_label_1 Last reconfirmed||2020-05-20 Target Milestone|--- |11.0 Status|UNCONFIRMED |NEW Blocks||26163 Known to work||10.1.0 Version|unknown |11.0 CC||marxin at gcc dot gnu.org 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 c++/95233] Failure to compile regression in GCC 10.1 and 11 trunk with C++ 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95233 Richard Biener changed: What|Removed |Added Version|c++-concepts|10.1.0 Keywords||build --- Comment #1 from Richard Biener --- That's building libstdc++ parts?
[Bug tree-optimization/95231] [11 Regression] error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type of the since r11-451-gfe168751c5c1c517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95231 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Oops.
[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910 --- Comment #9 from Martin Liška --- (In reply to Rafael Avila de Espindola from comment #8) > I can confirm that the proposed patch fixes the issue for me. > > Thank you so much! I thank you for the bug report. We had the regression since the very beginning!
[Bug target/95234] New: [11 Regression] 416.gamess Miscompare of exam29.out since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95234 Bug ID: 95234 Summary: [11 Regression] 416.gamess Miscompare of exam29.out since r11-455-g94f687bd9ae37ece Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: uros at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-linux-gnu Since the revision I see a miscompare for -Ofast -march=znver2 -g. runspec --config=spec2006 --size=test --iterations=1 --no-reportable --action run --tune=peak 416.gamess -D 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 c++/86142] hard error for bad delete-expression in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86142 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.0 Version|unknown |9.3.0
[Bug target/95235] New: Failure to properly optimize out register use in bit-twiddling code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95235
Bug ID: 95235
Summary: Failure to properly optimize out register use in
bit-twiddling code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int a, int b)
{
return ((a & 1) != 0) != (b != 0);
}
With -O3, GCC outputs this :
f(int, int):
test esi, esi
setne al
xor edi, eax
mov eax, edi
and eax, 1
ret
GCC should be able of outputting this instead :
f(int, int):
test esi, esi
setne al
xor eax, edi
and eax, 1
ret
But it does not do so.
[Bug c++/95233] Failure to compile regression in GCC 10.1 and 11 trunk with C++ 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95233 Jonathan Wakely changed: What|Removed |Added Keywords|build | --- Comment #2 from Jonathan Wakely --- No, building user code.
[Bug c++/95233] Failure to compile regression in GCC 10.1 and 11 trunk with C++ 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95233 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-05-20 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- Please add preprocessed code, not links to external sites, as requested by https://gcc.gnu.org/bugs/
[Bug target/95234] [11 Regression] 416.gamess Miscompare of exam29.out since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95234 --- Comment #1 from Martin Liška --- Changed object files: objfolderdiff.py /tmp/good-objects/ /tmp/bad-objects/ 26/ 151: dgeev.o: different 27/ 151: dmulti.fppized.o: different 46/ 151: eigen.fppized.o: different 56/ 151: grd2b.o: different 81/ 151: loccd.fppized.o: different 88/ 151: mcqdpt.fppized.o: different 102/ 151: mthlib.fppized.o: different 118/ 151: prplib.fppized.o: different 129/ 151: scflib.fppized.o: different 138/ 151: symorb.fppized.o: different 150/ 151: zmatrx.fppized.o: different
[Bug c++/95233] Failure to compile regression in GCC 10.1 and 11 trunk with C++ 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95233 --- Comment #4 from Jonathan Wakely --- Without looking into properly, it's possibly a dup of PR 93983.
[Bug target/94959] Wrong code gen for MVE intrinsics vldrbq_s32 which fails with assembler `Error: lo register required`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94959 --- Comment #1 from CVS Commits --- The master branch has been updated by SRINATH PARVATHANENI : https://gcc.gnu.org/g:d91524d5b117077b2f143e8aa3698ec585dafba6 commit r11-514-gd91524d5b117077b2f143e8aa3698ec585dafba6 Author: Srinath Parvathaneni Date: Wed May 20 10:17:22 2020 +0100 [ARM]: Fix the wrong code-gen generated by MVE vector load/store intrinsics (PR94959). Few MVE intrinsics like vldrbq_s32, vldrhq_s32 etc., the assembler instructions generated by current compiler are wrong. eg: vldrbq_s32 generates an assembly instructions `vldrb.s32 q0,[ip]`. But as per Arm-arm second argument in above instructions must also be a low register (<= r7). This patch fixes this issue by creating a new predicate "mve_memory_operand" and constraint "Ux" which allows low registers as arguments to the generated instructions depending on the mode of the argument. A new constraint "Ul" is created to handle loading to PC-relative addressing modes for vector store/load intrinsiscs. All the corresponding MVE intrinsic generating wrong code-gen as vldrbq_s32 are modified in this patch. gcc/ChangeLog: 2020-05-20 Srinath Parvathaneni Andre Vieira PR target/94959 * config/arm/arm-protos.h (arm_mode_base_reg_class): Function declaration. (mve_vector_mem_operand): Likewise. * config/arm/arm.c (thumb2_legitimate_address_p): For MVE target check the load from memory to a core register is legitimate for give mode. (mve_vector_mem_operand): Define function. (arm_print_operand): Modify comment. (arm_mode_base_reg_class): Define. * config/arm/arm.h (MODE_BASE_REG_CLASS): Modify to add check for TARGET_HAVE_MVE and expand to arm_mode_base_reg_class on TRUE. * config/arm/constraints.md (Ux): Likewise. (Ul): Likewise. * config/arm/mve.md (mve_mov): Replace constraint Us with Ux and also add support for missing Vector Store Register and Vector Load Register. Add a new alternative to support load from memory to PC (or label) in vector store/load. (mve_vstrbq_): Modify constraint Us to Ux. (mve_vldrbq_): Modify constriant Us to Ux, predicate to mve_memory_operand and also modify the MVE instructions to emit. (mve_vldrbq_z_): Modify constraint Us to Ux. (mve_vldrhq_fv8hf): Modify constriant Us to Ux, predicate to mve_memory_operand and also modify the MVE instructions to emit. (mve_vldrhq_): Modify constriant Us to Ux, predicate to mve_memory_operand and also modify the MVE instructions to emit. (mve_vldrhq_z_fv8hf): Likewise. (mve_vldrhq_z_): Likewise. (mve_vldrwq_fv4sf): Likewise. (mve_vldrwq_v4si): Likewise. (mve_vldrwq_z_fv4sf): Likewise. (mve_vldrwq_z_v4si): Likewise. (mve_vld1q_f): Modify constriant Us to Ux. (mve_vld1q_): Likewise. (mve_vstrhq_fv8hf): Modify constriant Us to Ux, predicate to mve_memory_operand. (mve_vstrhq_p_fv8hf): Modify constriant Us to Ux, predicate to mve_memory_operand and also modify the MVE instructions to emit. (mve_vstrhq_p_): Likewise. (mve_vstrhq_): Modify constriant Us to Ux, predicate to mve_memory_operand. (mve_vstrwq_fv4sf): Modify constriant Us to Ux. (mve_vstrwq_p_fv4sf): Modify constriant Us to Ux and also modify the MVE instructions to emit. (mve_vstrwq_p_v4si): Likewise. (mve_vstrwq_v4si): Likewise.Modify constriant Us to Ux. * config/arm/predicates.md (mve_memory_operand): Define. gcc/testsuite/ChangeLog: 2020-05-20 Srinath Parvathaneni PR target/94959 * gcc.target/arm/mve/intrinsics/mve_vector_float2.c: Modify. * gcc.target/arm/mve/intrinsics/mve_vldr.c: New test. * gcc.target/arm/mve/intrinsics/mve_vldr_z.c: Likewise. * gcc.target/arm/mve/intrinsics/mve_vstr.c: Likewise. * gcc.target/arm/mve/intrinsics/mve_vstr_p.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_f16.c: Modify. * gcc.target/arm/mve/intrinsics/vld1q_f32.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_s16.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_s32.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_s8.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_u16.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_u32.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_u8.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_z_f16.c: Likewise. * gcc
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #6 from Iain Sandoe --- r11-511 + this patch builds a stage1 debug compiler OK for me (issue reported on irc).
[Bug target/95235] Failure to properly optimize out register use in bit-twiddling code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95235 Richard Biener changed: What|Removed |Added Target||x86_64-*-* i?86-*-* --- Comment #1 from Richard Biener --- That's indeed odd.
[Bug target/95234] [11 Regression] 416.gamess Miscompare of exam29.out since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95234 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 --- Comment #2 from Richard Biener --- Maybe related to the recent avx_fma testsuite fails? (anyone bisected those?)
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org, ||uros at gcc dot gnu.org Summary|[11 Regression] FAIL: |[11 Regression] FAIL: |gcc.target/i386/fma_run_dou |gcc.target/i386/fma_run_dou |ble_1.c execution test |ble_1.c execution test ||since ||r11-455-g94f687bd9ae37ece --- Comment #3 from Martin Liška --- Started with r11-455-g94f687bd9ae37ece.
[Bug fortran/95214] ICE on assumed-rank character array with select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95214 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-20 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r10-2912-g70570ec192745095, it was rejected before the revision.
[Bug middle-end/95236] New: OMP 'GOMP_MAP_STRUCT': a structure is more than the sum of all its fields?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95236 Bug ID: 95236 Summary: OMP 'GOMP_MAP_STRUCT': a structure is more than the sum of all its fields? Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openacc, openmp Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org Target Milestone: --- Created attachment 48571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48571&action=edit 'itu_.c' ..., and the answer (technically) may easily be "yes", considering ABI-mandated padding, for example. But: is that user friendly? Consider the test case I'm attaching, where 'struct s' consists of fields 'a', 'b', which both get mapped -- yet, 's' itself isn't considered to be. At the user level, should a structure equal the sum of all its fields, or "do we have to be complicated"? I have not fully thought that through, just noticed this when looking into something else. I also have not verified OpenMP behavior.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #13 from Iain Sandoe --- Created attachment 48572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48572&action=edit fix for most of the UBSAN fails Most of the UBSAN fails are from a single cause; I reused the built DTOR tree on both resume and destroy edges from the await. There is a single remaining UBSAN fail (which is unrelated). I don't expect this to make any difference to the initial reported fail.
[Bug middle-end/95208] missed switch optimization as bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95208 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-05-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Looking at the dump files, we select a jump table: switch (c_2(D)) [67.00%], case 33 ... 35: [33.00%], case 37 ... 39: [33.00%], case 42 ... 63: [33.00%], case 65 ... 91: [33.00%], case 93 ... 95: [33.00%], case 97 ... 126: [33.00%]> ;; GIMPLE switch case clusters: JT(values:88 comparisons:12 range:94 density: 12.77%):33-126 We prefer a smaller number of clusters (in this case) one because we don't have to build a decision tree on top of them. In this case one can't handle all in of bit test as the range of values is >= 64.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #14 from Martin Liška --- The original problem: test.cc:3749:5: runtime error: member call on misaligned address 0x41b58ab3 for type 'struct awaiter', which requires 8 byte alignment 0x41b58ab3: note: pointer points here @Iain: How do you allocate the awaiter object? @Rafael: Can you please append output with: export UBSAN_OPTIONS="print_stacktrace=1"
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #4 from Uroš Bizjak --- (In reply to Martin Liška from comment #3) > Started with r11-455-g94f687bd9ae37ece. It is not obvious from the referred patch what is going wrong here. Unfortunately, I have no FMA capable machine, can someone please isolate one small test that fails?
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #5 from Martin Liška --- Sure, doing that.
[Bug libgcc/91695] [X86] get_available_features only sets FEATURE_GFNI and FEATURE_VPCLMULQDQ when avx512_usable is true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91695 --- Comment #2 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:1e46a443f25d26816536c0c480211714b123a1d5 commit r11-516-g1e46a443f25d26816536c0c480211714b123a1d5 Author: H.J. Lu Date: Tue May 19 18:55:08 2020 -0700 x86: Update VPCLMULQDQ check Update VPCLMULQDQ check to support processors with AVX version of VPCLMULQDQ. PR target/91695 * config/i386/cpuinfo.c (get_available_features): Fix VPCLMULQDQ check.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #15 from Iain Sandoe --- (In reply to Martin Liška from comment #14) > The original problem: > > test.cc:3749:5: runtime error: member call on misaligned address > 0x41b58ab3 for type 'struct awaiter', which requires 8 byte alignment > 0x41b58ab3: note: pointer points here > > > @Iain: How do you allocate the awaiter object? The coro frame is laid out according to the types determined for the objects it contains (the awaiter types are known at the point it's laid out). It just uses the 'normal' struct building rules. Awaiters are most often initialised from return values from some promise method, but they can also be local vars or parms - perhaps I slipped up there. I have a thought that I might be failing to copy across excess alignment applied (which I will look at later). ^^^ these are things on my TO-LOOK-AT list. > > @Rafael: Can you please append output with: > export UBSAN_OPTIONS="print_stacktrace=1"
[Bug tree-optimization/95171] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95171 Bug 95171 depends on bug 95231, which changed state. Bug 95231 Summary: [11 Regression] error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type of the since r11-451-gfe168751c5c1c517 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95231 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/95231] [11 Regression] error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type of the since r11-451-gfe168751c5c1c517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95231 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/95231] [11 Regression] error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type of the since r11-451-gfe168751c5c1c517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95231 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:130bb4c79295487c5fc203103d80e3b754640eb4 commit r11-518-g130bb4c79295487c5fc203103d80e3b754640eb4 Author: Richard Biener Date: Wed May 20 11:00:57 2020 +0200 middle-end/95231 - revert parts of PR95171 I mistook the opportunity to also "fix" the [VEC_]COND_EXPR case for PR95171 but I was wrong in that it doesn't need the fix and in the actual fix as well. The following just reverts that part. 2020-05-20 Richard Biener PR middle-end/95231 * tree-inline.c (remap_gimple_stmt): Revert adjusting COND_EXPR and VEC_COND_EXPR for a -fnon-call-exception boundary. * g++.dg/other/pr95231.C: New testcase.
[Bug demangler/85304] Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85304 Trupti Pardeshi changed: What|Removed |Added CC||trupti_pardeshi@persistent. ||co.in --- Comment #3 from Trupti Pardeshi --- Hi, May I know whether this bug is fixed? And if fixed, in which version of binutils this fix has gone? Any heads up will be appreciated. Thanks in advance. Best Regards,
[Bug target/95219] [11 Regression] FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95219 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b2f26af32b5b031fce761aa090de9476a53e6e5a commit r11-519-gb2f26af32b5b031fce761aa090de9476a53e6e5a Author: Richard Biener Date: Wed May 20 09:22:58 2020 +0200 tree-optimization/95219 - improve IV selection for induction This improves code generation with SSE2 for the testcase by making sure to only generate a single IV when the group size is a multiple of the vector size. It also adjusts the testcase which was passing before. 2020-05-20 Richard Biener PR tree-optimization/95219 * tree-vect-loop.c (vectorizable_induction): Reduce group_size before computing the number of required IVs. * gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c: Adjust.
[Bug target/95219] [11 Regression] FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95219 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug target/95229] [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229 Richard Biener changed: What|Removed |Added Target||x86_64-*-* i?86-*-* CC||uros at gcc dot gnu.org Component|middle-end |target --- Comment #4 from Richard Biener --- Program received signal SIGSEGV, Segmentation fault. 0x013747bd in mark_jump_label_1 (x=0x0, insn=0x76ac8b80, in_mem=false, is_target=false) at ../../src/trunk/gcc/jump.c:1087 1087 RTX_CODE code = GET_CODE (x); (gdb) p debug_rtx (insn) (insn 9 8 10 2 (set (reg:V2DI 91 [ vect__3.9 ]) (zero_extend:V2DI (vec_select:V2SI (nil) (parallel [ (const_int 0 [0]) (const_int 1 [0x1]) ] "z.c":15:12 -1 (nil)) the vec_select has a NULL operand somehow. We're expanding from vect__3.9_16 = (vector(2) long unsigned int) vect__2.8_15; so likely Uros change or it triggers a bogus expand helper or forwprop does not properly constrain itself. I'll debug a bit.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218
--- Comment #6 from Uroš Bizjak ---
I think I found the issue.
Before the patch, we had:
(insn 375 373 2574 7 (parallel [
(set (reg:V4DF 21 xmm1 [orig:1681 vect__45.441 ] [1681])
(neg:V4DF (mem/c:V4DF (plus:DI (reg/f:DI 7 sp)
(const_int 160 [0xa0])) [3 %sfp+-1184 S32 A256])))
(use (reg:V4DF 20 xmm0 [3332]))
]) "fma_1.h":20:10 1487 {*negv4df2}
(nil))
after the patch, reload is free to create:
(insn 375 3216 2578 7 (parallel [
(set (reg:V4DF 21 xmm1 [orig:1681 vect__45.441 ] [1681])
(neg:V4DF (reg:V4DF 20 xmm0 [3332])))
(use (mem/c:V4DF (plus:DI (reg/f:DI 7 sp)
(const_int 160 [0xa0])) [3 %sfp+-1184 S32 A256]))
]) "fma_1.h":20:10 1487 {*negv4df2}
(nil))
which postreload pass does not like, and simply deletes it:
deleting insn with uid = 375.
Just like that. No substitution whatsoever.
So, is there some limitation with (use) RTX, so we can't have memory here?
[Bug target/95229] [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229
--- Comment #5 from Richard Biener ---
Built by
#5 0x020c4504 in gen_rtx_fmt_ee_stat (code=VEC_SELECT,
mode=E_V2SImode, arg0=0x0, arg1=0x76ad92e0) at ./genrtl.h:49
#6 0x0211e242 in gen_sse4_1_zero_extendv2siv2di2 (
operand0=0x76ada4f8, operand1=0x0) at insn-emit.c:40857
#7 0x02207aa7 in gen_zero_extendv2siv2di2 (operand0=0x76ada4f8,
operand1=0x76ada4c8) at ../../src/trunk/gcc/config/i386/sse.md:18012
#8 0x010cfe31 in insn_gen_fn::operator() (
this=0x3230928 , a0=0x76ada4f8, a1=0x76ada4c8)
at ../../src/trunk/gcc/recog.h:317
#9 0x014aed21 in maybe_gen_insn (icode=CODE_FOR_zero_extendv2siv2di2,
nops=2, ops=0x7fffa8d0) at ../../src/trunk/gcc/optabs.c:7444
#10 0x014a3c7d in maybe_emit_unop_insn (
icode=CODE_FOR_zero_extendv2siv2di2, target=0x76ada4f8,
--Type for more, q to quit, c to continue without paging--
op0=0x76ada4c8, code=ZERO_EXTEND) at ../../src/trunk/gcc/optabs.c:3597
#11 0x014a3d7f in emit_unop_insn (icode=CODE_FOR_zero_extendv2siv2di2,
target=0x76ada4f8, op0=0x76ada4c8, code=ZERO_EXTEND)
at ../../src/trunk/gcc/optabs.c:3621
#12 0x01098d45 in convert_move (to=0x76ada4f8,
from=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:260
#13 0x0109bc1e in convert_modes (mode=E_V2DImode, oldmode=E_V2SImode,
x=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:737
#14 0x0109b220 in convert_to_mode (mode=E_V2DImode, x=0x76ada4c8,
unsignedp=1) at ../../src/trunk/gcc/expr.c:662
#15 0x010bae75 in expand_expr_real_2 (ops=0x7fffb600, target=0x0,
tmode=E_VOIDmode, modifier=EXPAND_NORMAL)
at ../../src/trunk/gcc/expr.c:8665
frame #7 looks OK while #6 is bogus. Context:
18009 if (!MEM_P (operands[1]))
18010 {
18011 operands[1] = simplify_subreg (V4SImode, operands[1], V2SImode,
0);
18012 emit_insn (gen_sse4_1_v2siv2di2 (operands[0],
operands[1]));
18013 DONE;
simplify_subreg returns NULL. It is originally (reg:V2SI 90 [ vect__2.8 ]).
Should that be simplify_gen_subreg?
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #7 from Uroš Bizjak --- Ooh, yes :( '(use X)' Represents the use of the value of X. It indicates that the value in X at this point in the program is needed, even though it may not be apparent why this is so. Therefore, the compiler will not attempt to delete previous instructions whose only effect is to store a value in X. X must be a 'reg' expression. Partial revert is in works.
[Bug target/95229] [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229
--- Comment #6 from Richard Biener ---
(In reply to Richard Biener from comment #5)
> Built by
>
> #5 0x020c4504 in gen_rtx_fmt_ee_stat (code=VEC_SELECT,
> mode=E_V2SImode, arg0=0x0, arg1=0x76ad92e0) at ./genrtl.h:49
> #6 0x0211e242 in gen_sse4_1_zero_extendv2siv2di2 (
> operand0=0x76ada4f8, operand1=0x0) at insn-emit.c:40857
> #7 0x02207aa7 in gen_zero_extendv2siv2di2 (operand0=0x76ada4f8,
> operand1=0x76ada4c8) at ../../src/trunk/gcc/config/i386/sse.md:18012
> #8 0x010cfe31 in insn_gen_fn::operator() (
> this=0x3230928 , a0=0x76ada4f8, a1=0x76ada4c8)
> at ../../src/trunk/gcc/recog.h:317
> #9 0x014aed21 in maybe_gen_insn
> (icode=CODE_FOR_zero_extendv2siv2di2,
> nops=2, ops=0x7fffa8d0) at ../../src/trunk/gcc/optabs.c:7444
> #10 0x014a3c7d in maybe_emit_unop_insn (
> icode=CODE_FOR_zero_extendv2siv2di2, target=0x76ada4f8,
> --Type for more, q to quit, c to continue without paging--
> op0=0x76ada4c8, code=ZERO_EXTEND) at
> ../../src/trunk/gcc/optabs.c:3597
> #11 0x014a3d7f in emit_unop_insn
> (icode=CODE_FOR_zero_extendv2siv2di2,
> target=0x76ada4f8, op0=0x76ada4c8, code=ZERO_EXTEND)
> at ../../src/trunk/gcc/optabs.c:3621
> #12 0x01098d45 in convert_move (to=0x76ada4f8,
> from=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:260
> #13 0x0109bc1e in convert_modes (mode=E_V2DImode,
> oldmode=E_V2SImode,
> x=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:737
> #14 0x0109b220 in convert_to_mode (mode=E_V2DImode,
> x=0x76ada4c8,
> unsignedp=1) at ../../src/trunk/gcc/expr.c:662
> #15 0x010bae75 in expand_expr_real_2 (ops=0x7fffb600,
> target=0x0,
> tmode=E_VOIDmode, modifier=EXPAND_NORMAL)
> at ../../src/trunk/gcc/expr.c:8665
>
> frame #7 looks OK while #6 is bogus. Context:
>
> 18009 if (!MEM_P (operands[1]))
> 18010 {
> 18011 operands[1] = simplify_subreg (V4SImode, operands[1],
> V2SImode, 0);
> 18012 emit_insn (gen_sse4_1_v2siv2di2 (operands[0],
> operands[1]));
> 18013 DONE;
>
> simplify_subreg returns NULL. It is originally (reg:V2SI 90 [ vect__2.8 ]).
> Should that be simplify_gen_subreg?
That fixes the testcase. But simplify_subreg is used in a lot more places
so leaving to Uros to match up with expectations.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218
--- Comment #8 from Martin Liška ---
There's partially reduced test-case:
$ cat fma.i
double res_test0101[] = {
-3,1, 17,51,109, 197, 321, 487, 701, 969, 1297,
1691, 2157, 2701, 3329, 4047, 4861, 5777, 6801, 7939, 9197, 10581,
12097, 13751, 15549, 17497, 19601, 21867, 24301, 26909, 29697, 32671};
double res_test0110[] = {3, -1, -17,-51,-109, -197, -321,
-487, -701, -969, -1297, -1691, -2157, -2701,
-3329, -4047, -4861, -5777, -6801, -7939, -9197,
-10581, -12097, -13751, -15549, -17497, -19601,
-21867,
-24301, -26909, -29697, -32671};
extern void abort() __attribute__(()) __attribute__(());
static __inline int __get_cpuid(unsigned int __leaf, unsigned int *__eax,
unsigned int *__ebx, unsigned int *__ecx,
unsigned int *__edx) {
__asm__("cpuid\n\t"
: "=a"(*__eax), "=b"(*__ebx), "=c"(*__ecx), "=d"(*__edx)
: "0"(__leaf));
}
static void fma_test();
int main() {
unsigned int eax, ebx, ecx, edx;
if (!__get_cpuid(1, &eax, &ebx, &ecx, &edx)) 0;
if (ecx & (1 << 12)) fma_test();
return 0;
}
double m1[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32};
double m2[] = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33};
double m3[] = {3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34};
double m4[32];
int test_fails = 0;
void compare_result(double *res) {
int i;
int good = 1;
i = 0;
for (i; i < 32; i++)
if (m4[i] != res[i])
if (good) good = 0;
if (!good) test_fails = 1;
}
static void fma_test() {
double __trans_tmp_3;
double __trans_tmp_2;
double __trans_tmp_1;
int i;
for (i = 0; i < 32; i++) m4[i] = 0;
i = 0;
for (i; i < 32; i++) {
double a = m1[i];
double b = m2[i];
double c = m3[i];
__trans_tmp_1 = ((a * b) - c) * a - b;
m4[i] = __trans_tmp_1;
}
compare_result(res_test0101);
i = 0;
for (i; i < 32; i++) {
{
double a = m1[i];
double b = m2[i];
double c = m3[i];
__trans_tmp_3 = -((a * b) - c) * a + b;
}
m4[i] = __trans_tmp_3;
}
compare_result(res_test0110);
i = 0;
for (i; i < 32; i++) {
double a = m1[i];
double b = m2[i];
double c = m3[i];
__trans_tmp_2 = -((a * b) - c) * a - b;
m4[i] = __trans_tmp_2;
}
if (test_fails) abort();
}
$ gcc -O3 -Wno-attributes -mfpmath=sse -mfma fma.i && ./a.out
Aborted (core dumped)
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 Uroš Bizjak changed: What|Removed |Added CC||law at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #9 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #7) > Ooh, yes :( > > '(use X)' > Represents the use of the value of X. It indicates that the value > in X at this point in the program is needed, even though it may not > be apparent why this is so. Therefore, the compiler will not > attempt to delete previous instructions whose only effect is to > store a value in X. X must be a 'reg' expression. > > Partial revert is in works. Actually, no. The above applies to single (use ...) RTX, not (use ...) as part of a parallel. There are plenty of uses of memory_operands in i386.md: (define_insn "fix_truncdi_i387" [(set (match_operand:DI 0 "nonimmediate_operand" "=m") (fix:DI (match_operand 1 "register_operand" "f"))) (use (match_operand:HI 2 "memory_operand" "m")) (use (match_operand:HI 3 "memory_operand" "m")) (clobber (match_scratch:XF 4 "=&f"))] Let's ask experts.
[Bug target/95237] New: LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237
Bug ID: 95237
Summary: LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL
gcc.target/i386/pr69454-2.c
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
The testcase and a few others now ICEs on x86_64 with -m32 since
LOCAL_DECL_ALIGNMENT with -mpreferred-stack-boundary=2 shrinks alignment
of 'long long' from 8 to 4.
/home/rguenther/src/trunk/gcc/testsuite/gcc.target/i386/pr69454-2.c: In
function 'fn1':^M
/home/rguenther/src/trunk/gcc/testsuite/gcc.target/i386/pr69454-2.c:7:6:
internal compiler error: in execute, at adjust-alignment.c:73^M
0x216245b execute^M
../../src/trunk/gcc/adjust-alignment.c:73^M
Please submit a full bug report,^M
this was a latent wrong-code bug before if you consider
typedef __UINTPTR_TYPE__ uintptr_t;
void __attribute__((noipa)) foo (long long *p, uintptr_t a)
{
if ((uintptr_t)p & (a-1))
__builtin_abort ();
}
int main()
{
long long x;
uintptr_t a = __alignof__(x);
foo(&x, a);
return 0;
}
and the frame of main not being aligned to 8 bytes.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #10 from rguenther at suse dot de --- On Wed, 20 May 2020, ubizjak at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 > > Uroš Bizjak changed: > >What|Removed |Added > > CC||law at gcc dot gnu.org, >||rsandifo at gcc dot gnu.org > > --- Comment #9 from Uroš Bizjak --- > (In reply to Uroš Bizjak from comment #7) > > Ooh, yes :( > > > > '(use X)' > > Represents the use of the value of X. It indicates that the value > > in X at this point in the program is needed, even though it may not > > be apparent why this is so. Therefore, the compiler will not > > attempt to delete previous instructions whose only effect is to > > store a value in X. X must be a 'reg' expression. > > > > Partial revert is in works. > > Actually, no. The above applies to single (use ...) RTX, not (use ...) as part > of a parallel. There are plenty of uses of memory_operands in i386.md: > > (define_insn "fix_truncdi_i387" > [(set (match_operand:DI 0 "nonimmediate_operand" "=m") > (fix:DI (match_operand 1 "register_operand" "f"))) >(use (match_operand:HI 2 "memory_operand" "m")) >(use (match_operand:HI 3 "memory_operand" "m")) >(clobber (match_scratch:XF 4 "=&f"))] > > Let's ask experts. The question is what should the (use ...) do? Allow the splitter to use its contents? I guess that's reasonable interpretation though I thought (use ...) apply only to register liveness computation and not to memory. But what do I know about RTL ;)
[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
kal.conley at dectris dot com changed:
What|Removed |Added
CC||kal.conley at dectris dot com
--- Comment #6 from kal.conley at dectris dot com ---
We are hitting this warning too with:
#include
#include
int main() {
std::vector inputs(2);
std::vector outputs{inputs.begin(), inputs.end()};
outputs.back() = 1;
return 0;
}
Regards,
Kal
[Bug target/95238] New: [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238
Bug ID: 95238
Summary: [11 Regression] Invalid *pushsi2_rex64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
Target Milestone: ---
Target: x86-64
In 64-bit mode, we can only push 16-bit or 64-bit memory/register.
commit 75514d157e9e28616c6de4e8c2740d8c87b6857d
Author: Uros Bizjak
Date: Fri May 15 16:22:19 2020 +0200
i386: Allow SI, DI and TImode pushes from XMM registers
Also change XMM register constraint from "x" to "v" in FP push insns.
added
+;; For TARGET_64BIT we always round up to 8 bytes.
+(define_insn "*pushsi2_rex64"
+ [(set (match_operand:SI 0 "push_operand" "=X,X")
+ (match_operand:SI 1 "nonmemory_no_elim_operand" "ri,*v"))]
+ "TARGET_64BIT"
+ "@
+ push{q}\t%q1
+ #"
+ [(set_attr "type" "push,multi")
+ (set_attr "mode" "DI")])
The "i" constraint should be "n" since symbolic constant is invalid for PIC
or PIE.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #11 from Richard Biener --- Note a 'use' is not something that needs to be preserved, so (define_insn_and_split "*2" [(set (match_operand:VF 0 "register_operand" "=x,v") (absneg:VF (match_operand:VF 1 "vector_operand" "%0,v"))) (use (match_operand:VF 2 "vector_operand" "xBm,vm"))] "TARGET_SSE" "#" "&& reload_completed" [(set (match_dup 0) (:VF (match_dup 1) (match_dup 2)))] "" [(set_attr "isa" "noavx,avx")]) doesn't make much sense (before reload). To me, that is. Why do we go that obfuscated way at all? I think a clean solution is to use an UNSPEC here (well, "clean"...).
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 --- Comment #1 from H.J. Lu --- The "i" constraint shouldn't be used for flag_pic since symbolic constant leads to writable text in 32-bit mode and invalid in 64-bit mode.
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #7 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:610ae2dbbf98a291782cb05c0fb31e056193e5e2 commit r11-522-g610ae2dbbf98a291782cb05c0fb31e056193e5e2 Author: Patrick Palka Date: Wed May 20 09:15:48 2020 -0400 c++: spec_hasher and TYPENAME_TYPE resolution [PR95223] After enabling sanitization of the specialization tables, we are triggering one of the hash table sanity checks in the below testcase. The reason is that when looking up the specialization j in the type_specializations table, the sanity check finds that the existing entry j::m> compares equal to j but hashes differently. The discrepancy is due to structural_comptypes looking through TYPENAME_TYPEs (via resolve_typename_type), something which iterative_hash_template_arg doesn't do. So the TYPENAME_TYPE n::m is considered equal to int, but the hashes of these two template arguments are different. It seems wrong for the result of a specialization table lookup to depend on the current scope, so this patch makes structural_comptypes avoid calling resolve_typename_type when comparing_specializations. In order for the below testcase to deterministically trigger the sanitization error without this patch, we also need to fix the location of the call to hash_table::verify within hash_table::find_with_hash. gcc/ChangeLog: PR c++/95223 * hash-table.h (hash_table::find_with_hash): Move up the call to hash_table::verify. gcc/cp/ChangeLog: PR c++/95223 * typeck.c (structural_comptypes): Don't perform context-dependent resolution of TYPENAME_TYPEs when comparing_specializations. gcc/testsuite/ChangeLog: PR c++/95223 * g++.dg/template/typename23.C: New test.
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug target/95229] [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229 --- Comment #7 from Uroš Bizjak --- (In reply to Richard Biener from comment #6) > That fixes the testcase. But simplify_subreg is used in a lot more places > so leaving to Uros to match up with expectations. Oh, yes... We don't have hard regs here, so all should be changed to simplify_gen_subregs. I have a patch.
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #7 from CVS Commits --- The master branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:eb069ae8819c3a84d7f78becc5501e21ee3a9554 commit r11-524-geb069ae8819c3a84d7f78becc5501e21ee3a9554 Author: Mark Eggleston Date: Thu May 7 08:02:02 2020 +0100 Fortran : ProcPtr function results: 'ppr@' in error message PR39695 The value 'ppr@' is set in the name of result symbol, the actual name of the symbol is in the procedure name symbol pointed to by the result symbol's namespace (ns). When reporting errors for symbols that have the proc_pointer attribute check whether the result attribute is set and set the name accordingly. 2020-05-20 Mark Eggleston gcc/fortran/ PR fortran/39695 * resolve.c (resolve_fl_procedure): Set name depending on whether the result attribute is set. For PROCEDURE/RESULT conflict use the name in sym->ns->proc_name->name. * symbol.c (gfc_add_type): Add check for function and result attributes use sym->ns->proc_name->name if both are set. Where the symbol cannot have a type use the name in sym->ns->proc_name->name. 2020-05-20 Mark Eggleston gcc/testsuite/ PR fortran/39695 * gfortran.dg/pr39695_1.f90: New test. * gfortran.dg/pr39695_2.f90: New test. * gfortran.dg/pr39695_3.f90: New test. * gfortran.dg/pr39695_4.f90: New test.
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Patrick Palka --- Thanks for the reports. This should now hopefully be fixed with r11-522.
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 --- Comment #2 from Uroš Bizjak --- (In reply to H.J. Lu from comment #1) > The "i" constraint shouldn't be used for flag_pic since symbolic constant > leads to writable text in 32-bit mode and invalid in 64-bit mode. Just a typo. "i" should be changed back to "e".
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #12 from Uroš Bizjak --- (In reply to Richard Biener from comment #11) > Note a 'use' is not something that needs to be preserved, so > > (define_insn_and_split "*2" > [(set (match_operand:VF 0 "register_operand" "=x,v") > (absneg:VF > (match_operand:VF 1 "vector_operand" "%0,v"))) >(use (match_operand:VF 2 "vector_operand" "xBm,vm"))] > "TARGET_SSE" > "#" > "&& reload_completed" > [(set (match_dup 0) > (:VF (match_dup 1) (match_dup 2)))] > "" > [(set_attr "isa" "noavx,avx")]) > > doesn't make much sense (before reload). To me, that is. Why do > we go that obfuscated way at all? I think a clean solution is to > use an UNSPEC here (well, "clean"...). The reason for this approach was, that combine still processes the pattern as abs/nop. Please see how *nabstf2_1 is defined.
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:8358ac9bbc57d6986c9bd5dd17c0331a60114f45 commit r10-8160-g8358ac9bbc57d6986c9bd5dd17c0331a60114f45 Author: Mark Eggleston Date: Thu May 7 08:02:02 2020 +0100 Fortran : ProcPtr function results: 'ppr@' in error message PR39695 The value 'ppr@' is set in the name of result symbol, the actual name of the symbol is in the procedure name symbol pointed to by the result symbol's namespace (ns). When reporting errors for symbols that have the proc_pointer attribute check whether the result attribute is set and set the name accordingly. Backported from master. 2020-05-20 Mark Eggleston gcc/fortran/ PR fortran/39695 * resolve.c (resolve_fl_procedure): Set name depending on whether the result attribute is set. For PROCEDURE/RESULT conflict use the name in sym->ns->proc_name->name. * symbol.c (gfc_add_type): Add check for function and result attributes use sym->ns->proc_name->name if both are set. Where the symbol cannot have a type use the name in sym->ns->proc_name->name. 2020-05-20 Mark Eggleston gcc/testsuite/ PR fortran/39695 * gfortran.dg/pr39695_1.f90: New test. * gfortran.dg/pr39695_2.f90: New test. * gfortran.dg/pr39695_3.f90: New test. * gfortran.dg/pr39695_4.f90: New test. (cherry picked from commit eb069ae8819c3a84d7f78becc5501e21ee3a9554)
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- So perhaps pre-reload splitter of that into the UNSPEC form?
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 Uroš Bizjak changed: What|Removed |Added CC|uros at gcc dot gnu.org| --- Comment #14 from Uroš Bizjak --- Its interesting to note, that only *some* of insns with memory uses get removed.
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:7c9bfd404691e5dac7e32830ae6d9726ccf59683 commit r9-8608-g7c9bfd404691e5dac7e32830ae6d9726ccf59683 Author: Mark Eggleston Date: Thu May 7 08:02:02 2020 +0100 Fortran : ProcPtr function results: 'ppr@' in error message PR39695 The value 'ppr@' is set in the name of result symbol, the actual name of the symbol is in the procedure name symbol pointed to by the result symbol's namespace (ns). When reporting errors for symbols that have the proc_pointer attribute check whether the result attribute is set and set the name accordingly. Backported from master. 2020-05-20 Mark Eggleston gcc/fortran/ PR fortran/39695 * resolve.c (resolve_fl_procedure): Set name depending on whether the result attribute is set. For PROCEDURE/RESULT conflict use the name in sym->ns->proc_name->name. * symbol.c (gfc_add_type): Add check for function and result attributes use sym->ns->proc_name->name if both are set. Where the symbol cannot have a type use the name in sym->ns->proc_name->name. 2020-05-20 Mark Eggleston gcc/testsuite/ PR fortran/39695 * gfortran.dg/pr39695_1.f90: New test. * gfortran.dg/pr39695_2.f90: New test. * gfortran.dg/pr39695_3.f90: New test. * gfortran.dg/pr39695_4.f90: New test. (cherry picked from commit eb069ae8819c3a84d7f78becc5501e21ee3a9554)
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 --- Comment #3 from H.J. Lu --- (In reply to Uroš Bizjak from comment #2) > (In reply to H.J. Lu from comment #1) > > The "i" constraint shouldn't be used for flag_pic since symbolic constant > > leads to writable text in 32-bit mode and invalid in 64-bit mode. > > Just a typo. "i" should be changed back to "e". There are other "ri" in push patterns. The 32 bit linker won't complain but will add DT_TEXTREL for "push $symbol" when generating shared object.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #15 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #13) > So perhaps pre-reload splitter of that into the UNSPEC form? Vector insns should be able to use pre-reload splitter, but scalar instructions depend on post-reload splitter, because they are split in a different way, depending on a register set of allocated register (FP, XMM or even integer). So, it really needs to be a post-reload splitter.
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 --- Comment #4 from Uroš Bizjak --- (In reply to H.J. Lu from comment #3) > (In reply to Uroš Bizjak from comment #2) > > (In reply to H.J. Lu from comment #1) > > > The "i" constraint shouldn't be used for flag_pic since symbolic constant > > > leads to writable text in 32-bit mode and invalid in 64-bit mode. > > > > Just a typo. "i" should be changed back to "e". > > There are other "ri" in push patterns. The 32 bit linker won't complain > but will add DT_TEXTREL for "push $symbol" when generating shared object. (define_insn "*push2" [(set (match_operand:DWI 0 "push_operand" "=<,<") (match_operand:DWI 1 "general_no_elim_operand" "riF*o,*v"))] This will never match symbol, so "i" can be "n" as well. ;; For TARGET_64BIT we always round up to 8 bytes. (define_insn "*pushsi2_rex64" [(set (match_operand:SI 0 "push_operand" "=X,X") (match_operand:SI 1 "nonmemory_no_elim_operand" "re,*v"))] This is changed to "e", as was before. (define_insn "*pushsi2" [(set (match_operand:SI 0 "push_operand" "=<,<") (match_operand:SI 1 "general_no_elim_operand" "ri*m,*v"))] This was "i" before my patch. (define_insn "*push2_prologue" [(set (match_operand:W 0 "push_operand" "=<") (match_operand:W 1 "general_no_elim_operand" "r*m")) This one is in effect "e".
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:15e518600a9ef82b55d2ec75d8d41d767132f475 commit r8-10261-g15e518600a9ef82b55d2ec75d8d41d767132f475 Author: Mark Eggleston Date: Thu May 7 08:02:02 2020 +0100 Fortran : ProcPtr function results: 'ppr@' in error message PR39695 The value 'ppr@' is set in the name of result symbol, the actual name of the symbol is in the procedure name symbol pointed to by the result symbol's namespace (ns). When reporting errors for symbols that have the proc_pointer attribute check whether the result attribute is set and set the name accordingly. Backport from master. 2020-05-20 Mark Eggleston gcc/fortran/ PR fortran/39695 * resolve.c (resolve_fl_procedure): Set name depending on whether the result attribute is set. For PROCEDURE/RESULT conflict use the name in sym->ns->proc_name->name. * symbol.c (gfc_add_type): Add check for function and result attributes use sym->ns->proc_name->name if both are set. Where the symbol cannot have a type use the name in sym->ns->proc_name->name. 2020-05-20 Mark Eggleston gcc/testsuite/ PR fortran/39695 * gfortran.dg/pr39695_1.f90: New test. * gfortran.dg/pr39695_2.f90: New test. * gfortran.dg/pr39695_3.f90: New test. * gfortran.dg/pr39695_4.f90: New test. (cherry picked from commit eb069ae8819c3a84d7f78becc5501e21ee3a9554)
[Bug fortran/20585] [meta-bug] Fortran 2003 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 39695, which changed state. Bug 39695 Summary: [F03] ProcPtr function results: wrong name in error message https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 markeggleston at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from markeggleston at gcc dot gnu.org --- Committed to master and backported.
[Bug tree-optimization/94335] [10/11 Regression] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
Martin Sebor changed:
What|Removed |Added
Known to fail||10.1.0, 11.0
Blocks||88443
Summary|False positive |[10/11 Regression] False
|-Wstringop-overflow warning |positive
|with -O2|-Wstringop-overflow warning
||with -O2
--- Comment #7 from Martin Sebor ---
Thanks for the small test case! The warning for reference is:
pr94335-c6.C: In function ‘int main()’:
pr94335-c6.C:8:20: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
8 | outputs.back() = 1;
| ~~~^~~
In file included from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:46,
from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/vector:64,
from pr94335-c6.C:3:
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:115:41:
note: at offset 0 to an object with size 0 allocated by ‘operator new’ here
115 | return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
| ~~^~~
The warning in this case is actually due to a different problem, this one in
the warning infrastructure itself. The relevant IL the warning works with
(-fdump-tree-strlen) is below:
main ()
{
...
unsigned char * _48;
...
unsigned char * _59;
...
[local count: 1073741825]:
...
_59 = operator new (2);
[local count: 1073007519]:
outputs.D.19139._M_impl.D.18482._M_start = _59;
_48 = _59 + 2;
...
MEM[(value_type &)_48 + 18446744073709551615] = 1; <<< warning here
(18446744073709551615 == -2)
...
}
To determine the size of what _48 points to the warning code calls the
compute_objsize() function. It returns zero because of a design limitation: it
returns the size of the remaining space in the object (i.e., the full size of
the pointed-to object minus the offset, which is 2 in this case). The caller
has no way to increase the size it gets back by its negative offset (the large
number which is -2).
I have a rewritten the function to avoid this (and other problems with it) and
expect to have a fix for GCC 11, and possibly even for GCC 10.2.
Since this is a different problem than the originally reported bug I don't want
to use it to track it. Feel free to open a separate bug for it.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-05-20 Status|UNCONFIRMED |NEW --- Comment #5 from H.J. Lu --- (In reply to Uroš Bizjak from comment #4) > > (define_insn "*pushsi2" > [(set (match_operand:SI 0 "push_operand" "=<,<") > (match_operand:SI 1 "general_no_elim_operand" "ri*m,*v"))] > > This was "i" before my patch. This may generate DT_TEXTREL for "push $symbol" when generating shared object
[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 Ever confirmed|0 |1 Last reconfirmed||2020-05-20 --- Comment #1 from H.J. Lu --- FAIL: c-c++-common/gomp/declare-variant-5.c (internal compiler error) FAIL: c-c++-common/gomp/declare-variant-5.c (internal compiler error) FAIL: c-c++-common/gomp/declare-variant-5.c (internal compiler error) FAIL: c-c++-common/gomp/declare-variant-5.c (test for excess errors) FAIL: c-c++-common/gomp/declare-variant-5.c (test for excess errors) FAIL: c-c++-common/gomp/declare-variant-5.c (test for excess errors) FAIL: gcc.target/i386/pr69454-2.c (internal compiler error) FAIL: gcc.target/i386/pr69454-2.c (test for excess errors) FAIL: gcc.target/i386/stackalign/longlong-1.c -mno-stackrealign (internal compiler error) FAIL: gcc.target/i386/stackalign/longlong-1.c -mno-stackrealign (test for excess errors) FAIL: gcc.target/i386/stackalign/longlong-1.c -mstackrealign (internal compiler error) FAIL: gcc.target/i386/stackalign/longlong-1.c -mstackrealign (test for excess errors)
[Bug c/95239] New: Unable to ignore -Wattribute-warning in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95239
Bug ID: 95239
Summary: Unable to ignore -Wattribute-warning in macro
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Created attachment 48573
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48573&action=edit
Test case
I'm trying to create a macro which evaluates an expression while ignoring
warnings generated by the warning attribute. Basically, a slightly simplified
version of what I want is:
#define IGNORE_WARNING_ATTR(expr) (__extension__({ \
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wattribute-warning\"") \
int tmp = expr; \
_Pragma("GCC diagnostic pop") \
tmp; \
}))
However, when I use it I still see the warning.
If I don't use a macro, but instead just do
int c = (__extension__({
_Pragma("GCC diagnostic push")
_Pragma("GCC diagnostic ignored \"-Wattribute-warning\"")
int tmp = foo(argc);
_Pragma("GCC diagnostic pop")
tmp;
}));
It works as intended; no warning.
If I use the macro version and preprocess the source file first, then compile
the preprocessed file separately, it works.
If I compile with g++ it works.
Using the attached test case, I get:
$ gcc -E -o warn-pp.c warn.c && gcc -o warn warn-pp.c
$ g++ -o warn warn.c
$ gcc -o warn warn.c
warn.c: In function ‘main’:
warn.c:23:31: warning: call to ‘foo’ declared with attribute warning: Calling
foo [-Wattribute-warning]
23 | int b = IGNORE_WARNING_ATTR(foo(argc));
| ^
warn.c:4:15: note: in definition of macro ‘IGNORE_WARNING_ATTR’
4 | int tmp = expr; \
| ^~~~
[Bug analyzer/95240] New: calloc() false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95240 Bug ID: 95240 Summary: calloc() false positives Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: gcc.gnu.org at andred dot net Target Milestone: --- Host: x86_64-linux-gnu Target: x86_64-linux-gnu Build: x86_64-linux-gnu Created attachment 48574 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48574&action=edit testcase Test with: gcc-10 (Debian 10.1.0-2) 10.1.0 (same behaviour with gcc 10.0) With the attached, I get a false positive: gcc-10 -Os -fanalyzer -fdiagnostics-path-format=separate-events t.c -o t t.c: In function ‘initActiveTroubleArray’: t.c:13:35: warning: leak of ‘’ [CWE-401] [-Wanalyzer-malloc-leak] 13 | return activeTroubleArray ? 0 : 1; |~~~^~~ t.c:12:26: note: (1) allocated here 12 | activeTroubleArray = calloc (1, 1); | ^ t.c:13:35: note: (2) ‘’ leaks here; was allocated at (1) 13 | return activeTroubleArray ? 0 : 1; |~~~^~~ The warning goes away in either of the following cases: * use malloc() instead of calloc() and change nothing else * remove the test in initActiveTroubleArray() and change nothing else * declare activeTroubleArray as void * and change nothing else (note that the warning is triggered when using anything but void * - standard types like char, long, etc, but also when using struct, enum etc.)
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 --- Comment #6 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:2cf6f31527c6d8dd2cc96f4efe8ff70d60d5fb44 commit r11-527-g2cf6f31527c6d8dd2cc96f4efe8ff70d60d5fb44 Author: Uros Bizjak Date: Wed May 20 18:57:32 2020 +0200 i386: Fix *pushsi2_rex64 constraints [PR95238] 2020-05-20 Uroš Bizjak gcc/ChangeLog: PR target/95238 * config/i386/i386.md (*pushsi2_rex64): Use "e" constraint instead of "i".
[Bug target/95229] [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229 --- Comment #8 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:3872a519c8fa65318efa1b481d331ef91b3ff044 commit r11-528-g3872a519c8fa65318efa1b481d331ef91b3ff044 Author: Uros Bizjak Date: Wed May 20 19:00:39 2020 +0200 i386: Fix zero/sign extend expanders [PR95229] 2020-05-20 Uroš Bizjak gcc/ChangeLog: PR target/95229 * config/i386/sse.md (v8qiv8hi2): Use simplify_gen_subreg instead of simplify_subreg. (v8qiv8si2): Ditto. (v4qiv4si2): Ditto. (v4hiv4si2): Ditto. (v8qiv8di2): Ditto. (v4qiv4di2): Ditto. (v2qiv2di2): Ditto. (v4hiv4di2): Ditto. (v2hiv2di2): Ditto. (v2siv2di2): Ditto. gcc/testsuite/ChangeLog: PR target/95229 * g++.target/i386/pr95229.C: New test.
[Bug c++/95241] New: internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95241
Bug ID: 95241
Summary: internal compiler error: tree check: expected
integer_cst, have range_expr in to_wide, at
tree.h:5900
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tab.debugteam at gmail dot com
Target Milestone: ---
Following c++ code:
```
struct Fragment
{
int offset;
int length;
constexpr Fragment(
int _offset,
int _length)
: offset(_offset), length(_length)
{
}
constexpr Fragment() :
Fragment(0, 1) { }
};
struct Field {
Fragment fragments[3];
constexpr
Field(int offset, int length)
: fragments{Fragment(offset, length)}
{
}
};
int main()
{
auto field = Field(0, 1);
return 0;
}
```
fails to compile with gcc 10.1 (https://godbolt.org/z/tyPB6V) and later with
error message:
```
: In function 'int main()':
:28:28: in 'constexpr' expansion of 'Field(0, 1)'
:28:28: internal compiler error: tree check: expected integer_cst, have
range_expr in to_wide, at tree.h:5900
28 | auto field = Field(0, 1);
|^
```
First spotted on gcc 10.1: https://godbolt.org/z/tyPB6V, but it's also
reproducible on latest gcc available on compiler explorer (version 11.0.0
20200511): https://godbolt.org/z/qWivJC.
I'm unable to reproduce it on gcc 9.3: https://godbolt.org/z/C2QqxA.
[Bug c++/95241] [10/11 Regression] internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95241 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |10.2 Summary|internal compiler error:|[10/11 Regression] internal |tree check: expected|compiler error: tree check: |integer_cst, have |expected integer_cst, have |range_expr in to_wide, at |range_expr in to_wide, at |tree.h:5900 |tree.h:5900 Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-20 CC||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Keywords||ice-on-valid-code --- Comment #1 from Marek Polacek --- Confirmed, started with r10-7556-g37244b217a7329792f4ec48027f63cf5010b0ea8
[Bug c++/94553] Revise [basic.scope.declarative]/4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553 --- Comment #4 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:2a8565fa1182ed326721a50c700f9f5275355d40 commit r11-529-g2a8565fa1182ed326721a50c700f9f5275355d40 Author: Marek Polacek Date: Tue May 19 23:53:28 2020 -0400 c++: Implement DR 2289, Uniqueness of structured binding names [PR94553] DR 2289 clarified that since structured bindings have no C compatibility implications, they should be unique in their declarative region, see [basic.scope.declarative]/4.2. The duplicate_decls hunk is the gist of the patch, but that alone would not be enough to detect the 'A' case: cp_parser_decomposition_declaration uses 13968 tree decl2 = start_decl (declarator, &decl_specs, SD_INITIALIZED, 13969NULL_TREE, NULL_TREE, &elt_pushed_scope); to create the 'A' VAR_DECL but in this start_decl's grokdeclarator we don't do fit_decomposition_lang_decl because the declarator kind is not cdk_decomp, so then when start_decl calls maybe_push_decl, the decl 'A' isn't DECL_DECOMPOSITION_P and we don't detect this case. So I needed a way to signal to start_decl that it should fit_decomposition_lang_decl. In this patch, I'm adding SD_DECOMPOSITION flag to say that the variable is initialized and it should also be marked as DECL_DECOMPOSITION_P. DR 2289 PR c++/94553 * cp-tree.h (SD_DECOMPOSITION): New flag. * decl.c (duplicate_decls): Make sure a structured binding is unique in its declarative region. (start_decl): If INITIALIZED is SD_DECOMPOSITION, call fit_decomposition_lang_decl. (grokdeclarator): Compare INITIALIZED directly to SD_* flags. * parser.c (cp_parser_decomposition_declaration): Pass SD_DECOMPOSITION to start_decl. * g++.dg/cpp1z/decomp52.C: New test.
[Bug c++/94553] Revise [basic.scope.declarative]/4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553 --- Comment #5 from Marek Polacek --- The structured binding part is now fixed, but the variable template part isn't yet, so not closing.
[Bug c++/95241] [10/11 Regression] internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95241 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/95242] New: [10 Regression] spurious "warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]" on comparisons with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242
Bug ID: 95242
Summary: [10 Regression] spurious "warning: zero as null
pointer constant [-Wzero-as-null-pointer-constant]" on
comparisons with -std=c++2a
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at mattwhitlock dot name
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
/* BEGIN bug.cpp */
#include
#include
bool bug(std::chrono::milliseconds lhs, std::chrono::milliseconds rhs) {
return lhs < rhs; // spurious "warning: zero as null pointer constant"
}
bool bug(std::string::const_iterator lhs, std::string::const_iterator rhs) {
return lhs < rhs; // spurious "warning: zero as null pointer constant"
}
/* END bug.cpp */
$ g++ -std=c++2a -Wzero-as-null-pointer-constant -c bug.cpp
bug.cpp: In function 'bool bug(std::chrono::milliseconds,
std::chrono::milliseconds)':
bug.cpp:5:15: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
5 | return lhs < rhs; // spurious "warning: zero as null pointer constant"
| ^~~
bug.cpp: In function 'bool
bug(std::__cxx11::basic_string::const_iterator,
std::__cxx11::basic_string::const_iterator)':
bug.cpp:9:15: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
9 | return lhs < rhs; // spurious "warning: zero as null pointer constant"
| ^~~
$ g++ --version | head -n1
g++ (Gentoo 10.1.0 p1) 10.1.0
The bug is not present in G++ 9.3, and it also is not present in G++ 10.1 in
-std=c++17 (or earlier) mode. This leads me to believe it may be related to the
new three-way comparison operator functionality.
[Bug libgomp/95243] New: libgomp documentation should specify GCC Runtime Library Exception license as applicable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95243 Bug ID: 95243 Summary: libgomp documentation should specify GCC Runtime Library Exception license as applicable Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: brentd42 at hotmail dot com CC: jakub at gcc dot gnu.org Target Milestone: --- >From an inspection of the code base, it appears that libgomp uses the GPL v3 license with the GCC Runtime Library exception. However, the libgomp documentation page (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/libgomp/Copying.html#Copying) lists only GPL v3 and not the exception. Conversely, libstc++ specifies the GCC Runtime Library exception license (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/libstdc++/manual/manual/license.html#manual.intro.status.license.gpl) as expected. Similarly to libstc++, could the libgomp documentation be updated to specify the GCC Runtime Library exception license as applicable?
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #9 from Dmitry G. Dyachenko --- (In reply to Patrick Palka from comment #8) > Thanks for the reports. This should now hopefully be fixed with r11-522. r11-526 PASS for me. Thanks
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #10 from Bill Seurer --- It works for me, too, now. Thanks!
[Bug bootstrap/95244] New: GCC 10 no longer builds on RHEL5 [trivial patch]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95244
Bug ID: 95244
Summary: GCC 10 no longer builds on RHEL5 [trivial patch]
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: lopresti at gmail dot com
Target Milestone: ---
I still compile GCC on Red Hat Enterprise Linux 5. It is an EoL platform, so
maybe you do not care... But the only problem (introduced with GCC 10) is the
lack of O_CLOEXEC. The following patch fixes my build:
diff --git a/libsanitizer/sanitizer_common/sanitizer_posix.cpp
b/libsanitizer/sanitizer_common/sanitizer_posix.cpp
index d890a3a3177..6ba525d1811 100644
--- a/libsanitizer/sanitizer_common/sanitizer_posix.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_posix.cpp
@@ -347,8 +347,14 @@ int GetNamedMappingFd(const char *name, uptr size, int
*flags) {
CHECK(internal_strlen(name) < sizeof(shmname) - 10);
internal_snprintf(shmname, sizeof(shmname), "/dev/shm/%zu [%s]",
internal_getpid(), name);
+#if defined O_CLOEXEC
int fd = ReserveStandardFds(
internal_open(shmname, O_RDWR | O_CREAT | O_TRUNC | O_CLOEXEC,
S_IRWXU));
+#else
+ int fd = ReserveStandardFds(
+ internal_open(shmname, O_RDWR | O_CREAT | O_TRUNC, S_IRWXU));
+ fcntl(fd, F_SETFD, FD_CLOEXEC);
+#endif
I would be happy to make this a pull request if there is any chance it would
get accepted. Thanks.
[Bug libstdc++/95245] New: std::sort copies custom comparator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95245
Bug ID: 95245
Summary: std::sort copies custom comparator
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.bell.ia at gmail dot com
Target Milestone: ---
std::sort copies a custom comparator numerous times. If the comparator copy is
expensive, it makes the sort very slow. Of course, making the comparator cheap
to copy is an easy fix, but it took me by surprise that the algorithm copied my
comparator at all. Other c++ library implementations don't have this
limitation. I found this on version 7.5, but I believe the same behavior is in
GCC 10.1. The following program exhibits the issue:
#include
#include
#include
#include
int main()
{
struct comp
{
comp(int i)
{
v.resize(i);
std::iota(v.begin(), v.end(), 0);
}
comp(const comp& c) : v(c.v)
{
std::cerr << "Copy ctor!\n";
}
comp(comp&& c) : v(std::move(c.v))
{
std::cerr << "Move ctor!\n";
}
bool operator()(size_t p1, size_t p2)
{
return p1 < p2;
}
// Vector is just here to cause an expensive copy and slow the sort,
// but it could,
// for example, be a cache that is used in the comparison.
std::vector v;
};
std::vector s(500);
std::iota(s.begin(), s.end(), 0);
std::random_shuffle(s.begin(), s.end());
std::sort(s.begin(), s.end(), comp(200));
return 0;
}
[Bug bootstrap/95005] zstd.h not found if installed in non-system prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95005 --- Comment #7 from Michael Kuhn --- Took me a while, sorry. I have just sent the patch to the list.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #16 from Rafael Avila de Espindola ---
> @Rafael: Can you please append output with:
> export UBSAN_OPTIONS="print_stacktrace=1"
I also added halt_on_error=1:abort_on_error=1:
It is
../tests/unit/coroutines_test.cc:11:5: runtime error: member call on misaligned
address 0x41b58ab3 for type 'struct awaiter', which requires 8 byte
alignment
0x41b58ab3: note: pointer points here
Reactor stalled for 261 ms on shard 0.
Backtrace:
/lib64/libasan.so.6+0x00045bad
...
#0 0xf3605a in main::{lambda()#1}::operator()() const [clone .actor]
../tests/unit/coroutines_test.cc:11
#1 0xf3b20b in std::__n4861::coroutine_handle::resume() const
/usr/include/c++/10/coroutine:126
#2 0xf3b5ed in
seastar::internal::coroutine_traits_base<>::promise_type::run_and_dispose()
../include/seastar/core/coroutine.hh:104
#3 0x11c8892 in seastar::reactor::run_tasks(seastar::reactor::task_queue&)
../src/core/reactor.cc:2151
#4 0x11cc8db in seastar::reactor::run_some_tasks()
../src/core/reactor.cc:2566
#5 0x11d1aa0 in seastar::reactor::run() ../src/core/reactor.cc:2721
#6 0xf4ef5e in seastar::app_template::run_deprecated(int, char**,
std::function&&) ../src/core/app-template.cc:202
#7 0xf4cf00 in seastar::app_template::run(int, char**,
std::function ()>&&) ../src/core/app-template.cc:115
#8 0xf4d3fa in seastar::app_template::run(int, char**,
std::function ()>&&) ../src/core/app-template.cc:130
#9 0xf36a70 in main ../tests/unit/coroutines_test.cc:8
#10 0x7fac0533d041 in __libc_start_main (/lib64/libc.so.6+0x27041)
#11 0xf3466d in _start
(/home/espindola/scylla/scylla/seastar/build-dbg/tests/unit/coroutines_test+0xf3466d)
I will try to reduce the test to not need seastar.
