[Bug target/100762] New: [mips+msa] ICE when comparing 64 bit vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100762
Bug ID: 100762
Summary: [mips+msa] ICE when comparing 64 bit vectors
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
In MIPS with MSA enabled on GCC 10.2.1, any comparison operation on 64-bit
vectors results in an ICE.
Test case:
typedef int i32x2 __attribute__((__vector_size__(8)));
i32x2 cmp(i32x2 a, i32x2 b) {
return a >= b;
}
$ mips64el-linux-gnuabi64-gcc-10 -march=loongson3a -mmsa -c -o test.o test.c
mips64el-linux-gnuabi64-gcc-10 -march=loongson3a -mmsa -c -o test.o test2.c
during RTL pass: expand
test.c: In function 'cmp':
test.c:4:12: internal compiler error: in mips_expand_vector_init, at
config/mips/mips.c:22076
4 | return a >= b;
| ~~^~~~
0x7f420202dd09 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
This is with GCC 10.2.1-6 from Debian:
$ mips64el-linux-gnuabi64-gcc-10 --version
mips64el-linux-gnuabi64-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug target/100761] New: [mips+msa] ICE when using __builtin_convertvector to convert from u8x8 to u8x16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100761
Bug ID: 100761
Summary: [mips+msa] ICE when using __builtin_convertvector to
convert from u8x8 to u8x16
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
I'm seeing an ICE from MIPS with MSA enabled when attempting to use
__builtin_convertvector to convert a vector of 8 unsigned 8-bit integers to 8
unsigned 16-bit integers.
Here is a reduced test case, courtesy of C-Reduce:
typedef char a;
typedef short b;
typedef struct {
a c __attribute__((__vector_size__(8)));
} d;
d e;
void f() {
b g __attribute__((__vector_size__(16))) (
__builtin_convertvector(e.c, __typeof__(g)));
}
$ mips64el-linux-gnuabi64-g++-10 -march=loongson3a -mmsa -c -o test.o test.c
during RTL pass: expand
test.c: In function 'void f()':
test.c:8:5: internal compiler error: in mips_expand_vec_unpack, at
config/mips/mips.c:21757
8 | b g __attribute__((__vector_size__(16))) (
| ^
0x7fed0d1f9d09 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
This is with GCC 10.2.1-6 from Debian:
$ mips64el-linux-gnuabi64-g++-10 --version
mips64el-linux-gnuabi64-g++-10 (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Original code is at
https://github.com/simd-everywhere/simde/blob/7d0e2aca9458f760d7196b94bfdcf83b2178ea24/simde/x86/sse.h#L1046,
SIMDE_CONVERT_VECTOR_ is defined at
https://github.com/simd-everywhere/simde/blob/7d0e2aca9458f760d7196b94bfdcf83b2178ea24/simde/simde-common.h#L292-L296
[Bug target/97248] [mips] unrecognizable insn when left shifting uint64 vector by scalar with MSA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97248
--- Comment #1 from Evan Nemerson ---
SImilar issue with right shift:
typedef long a;
typedef struct {
a b __attribute__((__vector_size__(64)));
} c;
void d() {
int e;
c f, g;
f.b = g.b >> e;
}
$ mips64el-linux-gnuabi64-g++-10 -march=loongson3a -mmsa -o test test.cpp
test.cpp: In function 'void d()':
test.cpp:9:1: error: unrecognizable insn:
9 | }
| ^
(insn 30 29 31 2 (set (reg:DI 216)
(subreg:DI (mem/c:SI (reg/f:DI 189 virtual-stack-vars) [1 e+0 S4 A32])
0)) "test.cpp":8:13 -1
(nil))
during RTL pass: vregs
test.cpp:9:1: internal compiler error: in extract_insn, at recog.c:2294
0x7f567e543d09 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug other/100759] [12 regression] ICE for g++.dg/torture/pr81360.C after r12-1039 at gcc/options-save.c:13626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100759 --- Comment #1 from seurer at gcc dot gnu.org --- actually, there are a bunch of failures from this revision: FAIL: g++.dg/torture/pr81360.C -Os (internal compiler error) FAIL: g++.dg/torture/pr81360.C -Os (internal compiler error) FAIL: g++.dg/torture/pr81360.C -Os (test for excess errors) FAIL: g++.dg/torture/pr81360.C -Os (test for excess errors) FAIL: gcc.dg/Warray-bounds-57.c (internal compiler error) FAIL: gcc.dg/Warray-bounds-57.c (internal compiler error) FAIL: gcc.dg/Warray-bounds-57.c (test for excess errors) FAIL: gcc.dg/Warray-bounds-57.c (test for excess errors) FAIL: gcc.dg/pr92860-2.c (test for warnings, line 12) FAIL: gcc.dg/pr92860-2.c (test for warnings, line 12) FAIL: gcc.dg/pr92860-2.c (test for warnings, line 9) FAIL: gcc.dg/pr92860-2.c (test for warnings, line 9) FAIL: gcc.dg/pr92860-2.c (internal compiler error) FAIL: gcc.dg/pr92860-2.c (internal compiler error) FAIL: gcc.dg/pr92860-2.c (test for excess errors) FAIL: gcc.dg/pr92860-2.c (test for excess errors)
[Bug target/100760] New: [mips + msa] ICE: maximum number of generated reload insns per insn achieved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100760
Bug ID: 100760
Summary: [mips + msa] ICE: maximum number of generated reload
insns per insn achieved
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Created attachment 50869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50869=edit
preprocessed, un-reduced reproducer
I'm getting an ICE when attempting to compile some code on MIPS with MSA which
works on other architectures, and on MIPS without MSA. Here is a reduced test
case courtesy of C-Reduce:
typedef int a;
void b() { a __attribute__((__vector_size__(8))) c{1, 1}; }
Compile with `mips64el-linux-gnuabi64-g++-10 -march=loongson3a -mmsa -o test
test.c`
I've also attached a pre-processed copy of the original, non-reduced code. The
original is at
https://github.com/simd-everywhere/simde/blob/7d0e2aca9458f760d7196b94bfdcf83b2178ea24/simde/arm/neon/cmla_rot90.h#L50-L52
(SIMDE_SHUFFLE_VECTOR_ is defined at
https://github.com/simd-everywhere/simde/blob/7d0e2aca9458f760d7196b94bfdcf83b2178ea24/simde/simde-common.h#L278-L281)
This is with 10.2.1-6 from Debian:
/usr/bin/mips64el-linux-gnuabi64-gcc-10 --version
mips64el-linux-gnuabi64-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug middle-end/100755] Error with fortran object (v11.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755 --- Comment #5 from afernandez at odyhpc dot com --- I just tried -std=legacy but it made no difference.
[Bug other/100759] New: [12 regression] ICE for g++.dg/torture/pr81360.C after r12-1039 at gcc/options-save.c:13626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100759 Bug ID: 100759 Summary: [12 regression] ICE for g++.dg/torture/pr81360.C after r12-1039 at gcc/options-save.c:13626 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e, r12-1039 make -k check-gcc RUNTESTFLAGS="dg-torture.exp=g++.dg/torture/pr81360.C" FAIL: g++.dg/torture/pr81360.C -Os (internal compiler error) FAIL: g++.dg/torture/pr81360.C -Os (test for excess errors) # of expected passes6 # of unexpected failures2 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr81360.C -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -Os -fno-early-inlining -S -o pr81360.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr81360.C:67:10: internal compiler error: 'global_options' are modified in local context 0x10dca0ab cl_optimization_compare(gcc_options*, gcc_options*) /home/seurer/gcc/git/build/gcc-test/gcc/options-save.c:13626 0x10790b7b handle_optimize_attribute /home/seurer/gcc/git/gcc-test/gcc/c-family/c-attribs.c:5419 0x106dc64f decl_attributes(tree_node**, tree_node*, int, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/attribs.c:723 0x103cf18b cplus_decl_attributes(tree_node**, tree_node*, int) /home/seurer/gcc/git/gcc-test/gcc/cp/decl2.c:1600 0x1039b163 grokfndecl /home/seurer/gcc/git/gcc-test/gcc/cp/decl.c:10150 0x103a284b grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*, decl_context, int, tree_node**) /home/seurer/gcc/git/gcc-test/gcc/cp/decl.c:13996 0x103a75ff start_function(cp_decl_specifier_seq*, cp_declarator const*, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/cp/decl.c:16931 0x10554d4b cp_parser_function_definition_from_specifiers_and_declarator /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:30001 0x10554d4b cp_parser_init_declarator /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:21691 0x1051a35f cp_parser_simple_declaration /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:14472 0x1055d2a3 cp_parser_declaration /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:14169 0x1055bf9f cp_parser_translation_unit /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:4942 0x1055bf9f c_parse_file() /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:45425 0x107606fb c_common_parse_file() /home/seurer/gcc/git/gcc-test/gcc/c-family/c-opts.c:1219 commit ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e Author: Martin Liska Date: Wed Mar 10 15:12:31 2021 +0100 Improve global state for options.
[Bug middle-end/100755] Error with fortran object (v11.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755 --- Comment #4 from Dominique d'Humieres --- > If I'm understanding correctly and this is an extension being deprecated, > is there any option to push the compilation with gcc11.1 through? Did you try -std=legcy?
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #20 from Jakub Jelinek --- Yeah, that is likely what happens, I'll debug tomorrow.
[Bug middle-end/100755] Error with fortran object (v11.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755 --- Comment #3 from afernandez at odyhpc dot com --- Sorry for the delay. The system is AArch64 and running CentOS8.3. I have 2 GCC installations, one is 8.3.1 and the second is 11.1.0. NCEPLIBS builds with the former but not with the second. The 1st step is with cmake cd /opt/prae sudo git clone https://github.com/NOAA-EMC/NCEPLIBS cd /opt/prae/NCEPLIBS sudo mkdir -p build && cd build sudo /usr/local/bin/cmake -DCMAKE_INSTALL_PREFIX=/opt/prae/NCEP -DCMAKE_C_COMPILER=/opt/prae/openmpi/bin/mpicc -DCMAKE_Fortran_COMPILER=/opt/prae/openmpi/bin/mpif90 -DCMAKE_INSTALL_PREFIX=/opt/prae/NCEP -DCMAKE_PREFIX_PATH=/opt/prae/netcdf -DNetCDF_INCLUDE_DIRS=/opt/prae/netcdf/include -DNetCDF_LIBRARIES=/opt/prae/netcdf/lib /opt/prae/NCEPLIBS Then, it fails when invoking make. I also tried adding the flag "-fdefault-integer-8" but it didn't change anything. If I'm understanding correctly and this is an extension being deprecated, is there any option to push the compilation with gcc11.1 through? I'm not the developer so even if they agreed to make the necessary changes, it might take some time. Thanks.
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 --- Comment #3 from anlauf at gcc dot gnu.org --- The following patch seems to fix the issue: diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c index 6d38ea78273..7eeef554c0f 100644 --- a/gcc/fortran/trans-array.c +++ b/gcc/fortran/trans-array.c @@ -4718,8 +4718,9 @@ done: /* For optional arguments, only check bounds if the argument is present. */ - if (expr->symtree->n.sym->attr.optional - || expr->symtree->n.sym->attr.not_always_present) + if ((expr->symtree->n.sym->attr.optional + || expr->symtree->n.sym->attr.not_always_present) + && expr->symtree->n.sym->attr.dummy) tmp = build3_v (COND_EXPR, gfc_conv_expr_present (expr->symtree->n.sym), tmp, build_empty_stmt (input_location)); If I understand the code correctly, the issue arises since we try to generate runtime checks for a compiler generated temporary that is not a dummy, thus hitting the assert in gfc_conv_expr_present.
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 --- Comment #15 from Jonathan Wakely --- Fixed downstream in my fork: https://gitlab.com/jonathan-wakely/gcc/-/commit/18d78721bf3afaed243252a01a4f4909c17531b2
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #19 from Alexander Monakov --- Ah, does the issue arise because foo._omp_fn.0 is (before the patch) callable in two contexts, in one it's called from host and should be 'omp target entrypoint', and in the other it's called from offloaded code and bears 'omp declare target'? If so, I think omp-expand code should make 'omp target entrypoint' prevail over 'omp declare target'?
[Bug fortran/100551] [11/12 Regression] Passing return value of intrinsic to class(*) dummy argument can cause segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12 and on 11-branch. Closing. Thanks for the report!
[Bug fortran/100551] [11/12 Regression] Passing return value of intrinsic to class(*) dummy argument can cause segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:de55a48960d2f08266cba1222e233507015dd620 commit r11-8469-gde55a48960d2f08266cba1222e233507015dd620 Author: Harald Anlauf Date: Sun May 23 20:51:14 2021 +0200 Fortran: fix passing return value to class(*) dummy argument gcc/fortran/ChangeLog: PR fortran/100551 * trans-expr.c (gfc_conv_procedure_call): Adjust check for implicit conversion of actual argument to an unlimited polymorphic procedure argument. gcc/testsuite/ChangeLog: PR fortran/100551 * gfortran.dg/pr100551.f90: New test. (cherry picked from commit fe03f4fc9548b3fdbff3c8284a994feaa7d6307d)
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #18 from Tobias Burnus --- I think the problem is: create_omp_child_function(omp_context*, bool) ... 1916 DECL_ATTRIBUTES (decl) = DECL_ATTRIBUTES (current_function_decl); The code removes then 'omp declare simd' but not 'omp declare target' - hence, the value is kept.
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #17 from Alexander Monakov --- Yes, I'd agree normally it's present in the offload table, but ideally if you're trying to stub out the call, it should not be present in the offload table. I think Tobias is saying that on GIMPLE this function does not have 'omp target entrypoint' attribute attached to it? If so, that's causing a problem, because the backend will not synthesize the corresponding PTX .global function. Each function named in the offload table should be 'omp target entrypoint'.
[Bug fortran/92065] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #30 from anlauf at gcc dot gnu.org --- Adding Paul.
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #16 from Jakub Jelinek --- (In reply to Alexander Monakov from comment #14) > I would break in gdb on cuModuleGetFunction and > > x/s $rdx > > to print the failing symbol (it's the third argument to the function). > > It seems the "inner" entrypoint (which your patch attempted to nullify) is > still registered in offload tables, so the plugin takes its name from the > offload table and attempts to look it up in the offloaded code? Thread 1 "target-41.exe" hit Breakpoint 1, 0x766de530 in cuModuleGetFunction () from /lib64/libcuda.so.1 (gdb) x/1s $rdx 0x477780: "foo$_omp_fn$0" Isn't that symbol in the offload tables normally though or do we treat it there differently?
[Bug c++/96555] "template argument involves template parameter(s)" with dot or arrow operator in partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96555 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Last reconfirmed||2021-05-25
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #15 from Jakub Jelinek --- (In reply to Tobias Burnus from comment #13) > (In reply to Tobias Burnus from comment #9) > > not found name: 'test_d_normal._omp_fn.0.kd' > > I think the problem is the following: > > (a) working: > foo() > #pragma target > bar() > > Here, 'foo._omp_fn.0' as as fndecl attribute: 'omp target entrypoint' > > (b) failing: > foo() > #pragma target > foo() > while here 'foo._omp_fn.0' has 'omp declare target' which does not make > sense. > > I think we need in omp_discover_declare_target_tgt_fn_r a similar handling > for > 'omp declare target entrypoint' as we do for 'omp declare target host'. Sure, but I thought that would be fixed with the #c12 patch. The only place where those "omp target entrypoint" functions should be referenced are the arguments of the GOMP_target_ext function (the second one), and I've swapped that for the NULL pointer.
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #14 from Alexander Monakov --- I would break in gdb on cuModuleGetFunction and x/s $rdx to print the failing symbol (it's the third argument to the function). It seems the "inner" entrypoint (which your patch attempted to nullify) is still registered in offload tables, so the plugin takes its name from the offload table and attempts to look it up in the offloaded code?
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 --- Comment #11 from ripero84 at gmail dot com --- Thank you very much for the information and your help.
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #13 from Tobias Burnus --- (In reply to Tobias Burnus from comment #9) > not found name: 'test_d_normal._omp_fn.0.kd' I think the problem is the following: (a) working: foo() #pragma target bar() Here, 'foo._omp_fn.0' as as fndecl attribute: 'omp target entrypoint' (b) failing: foo() #pragma target foo() while here 'foo._omp_fn.0' has 'omp declare target' which does not make sense. I think we need in omp_discover_declare_target_tgt_fn_r a similar handling for 'omp declare target entrypoint' as we do for 'omp declare target host'.
[Bug libstdc++/96088] Range insertion into unordered_map is less effective than a loop with insertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088 François Dumont changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from François Dumont --- Fix with this commit: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2c43f5ec9db163696de8691eb529df06c4999bcc libstdc++: Limit allocation on iterator insertion in Hashtable [PR 96088] When inserting into unordered_multiset or unordered_multimap first instantiate the node to store and compute the hash code from it to avoid a potential intermediate key_type instantiation. When inserting into unordered_set or unordered_map check if invoking the hash functor with container key_type is noexcept and invoking the same hash functor with key part of the iterator value_type can throw. In this case create a temporary key_type instance at Hashtable level and use it to compute the hash code. This temporary instance is moved to the final storage location if needed. libstdc++-v3/ChangeLog: PR libstdc++/96088 * include/bits/hashtable_policy.h (_Select2nd): New. (_NodeBuilder<>): New. (_ReuseOrAllocNode<>::operator()): Use variadic template args. (_AllocNode<>::operator()): Likewise. * include/bits/hashtable.h (_Hashtable<>::__node_builder_t): New. (_Hashtable<>::_M_insert_unique<>(_Kt&&, _Arg&&, const _NodeGenerator&)): New. (_Hashtable<>::_S_forward_key): New. (_Hashtable<>::_M_insert): Use latter. (_Hashtable<>::_M_insert(const_iterator, _Arg&&, const _NodeGenerator&, false_type)): Instantiate node first, compute hash code second. * testsuite/23_containers/unordered_map/96088.cc: New test. * testsuite/23_containers/unordered_multimap/96088.cc: New test. * testsuite/23_containers/unordered_multiset/96088.cc: New test. * testsuite/23_containers/unordered_set/96088.cc: New test. * testsuite/util/replacement_memory_operators.h (counter::_M_increment): New. (counter::_M_decrement): New. (counter::reset()): New.
[Bug fortran/100724] -fwhole-program breaks module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 --- Comment #6 from Jan Hubicka --- > Could the manual entry for -fwhole-program just be amended to clarify that > it's > a fallback for when a linker plugin isn't available for -flto. That may be > what it was intended to say, but it's not clear to me. I used -fwhole-program > because it seemed to fit my case exactly. It can be also used in non-lto if your program has only one source file and FE is not producing duplicated decls... Honza
[Bug middle-end/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 --- Comment #9 from Martin Sebor --- (In reply to John David Anglin from comment #5) > Breakpoint 1, attr_access::from_mode_char ( > c=) > at ../../gcc/gcc/attribs.h:304 > 304 gcc_unreachable (); This error says that is null. c comes from the code below: #1 0x40a8311c in init_attr_rdwr_indices (rwm=0x83fffdff14e0, attrs=0x83fffdf1b9b0) at ../../gcc/gcc/attribs.c:2146 mode = TREE_VALUE (mode); if (TREE_CODE (mode) != STRING_CST) continue; gcc_assert (TREE_CODE (mode) == STRING_CST); for (const char *m = TREE_STRING_POINTER (mode); *m; ) Either TREE_STRING_POINTER (mode) is null or mode is set to null after one of the calls to strtoul() later in the function.
[Bug middle-end/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 --- Comment #8 from Martin Sebor --- The plus character should always be followed by a nonempty string. John, can you please attach a translation unit to see if by chance I can reproduce with a cross-compiler? In parallel, I wonder if there's something funny about snprintf on HP-UX. Does the snprintf call added in r12-930 do the right thing (i.e., append a nonempty string to spec)?
[Bug middle-end/100755] Error with fortran object (v11.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Possibly related: PR100283. Note that this is more likely an ice-on-invalid, as the specific intrinsics min0/max accept only default integers as argument. (F2018 table 16.3). 127_8 is not of default integer kind. Accepting non-default integers is an extension.
[Bug c++/100716] member function template parameter not printed in candidate list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100716 --- Comment #2 from Matthias Kretz (Vir) --- I'd like to revise my opinion above. dump_template_decl should never print the template parameter list of functions. I.e. it should be 'template f()' not 'template f()'. Because it's also declared without the template parameter list, independent of whether the template parameter is deducible from the function arguments or not. That means the -fno-pretty-templates output needs to be fixed and the 'T = T' part needs to disappear.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #8 from Gejoe --- (In reply to Martin Liška from comment #6) > Yes, __gcov_reset is supposed to be called at the beginning when an > application wants to start > profiling. Again, you don't need to call it manually. But reset comes into a picture where something has happened already and then the result needs to be cleared, isn't it ? At the application start, applying a reset would not make sense I think. gcov_reset would be sensible only after a gcov_dump , isn't it ? Let me know if I miss the actual design/flow of these functions. Thanks !
[Bug middle-end/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Richard Biener from comment #3)
> > Possibly a dup of PR100727?
>
> I think it is unrelated.
>
> The problem is the fix for PR 100619, sets the attributes to be "+" but the
> code in attribs.c, skip over the '+' but does not check if it is the end of
> the string:
This patch might fix the ICE (sorry for the tab to spaces):
diff --git a/gcc/attribs.c b/gcc/attribs.c
index ebc0783c439..4adbe9fed5e 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -2140,7 +2140,10 @@ init_attr_rdwr_indices (rdwr_map *rwm, tree attrs)
/* Skip the internal-only plus sign. */
if (*m == '+')
- ++m;
+ {
+ ++m;
+ continue;
+ }
acc.str = m;
acc.mode = acc.from_mode_char (*m);
[Bug c/100758] New: __builtin_cpu_supports does not (always) detect "sse2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758 Bug ID: 100758 Summary: __builtin_cpu_supports does not (always) detect "sse2" Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gcc at eckner dot net Target Milestone: --- Host: i686 Target: i686 Created attachment 50868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50868=edit test.c: probe for sse2 I use the attached snippet to detect, whether the cpu supports sse2. This works most of the time, but fails to detect sse2 on two machines, which actually support sse2 (according to /proc/cpuinfo). The affected machines run archlinux32. /proc/cpuinfo shows: processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 15 model name : VIA Nano U3400@800MHz stepping: 10 cpu MHz : 798.016 cache size : 2048 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush acpi mmx fxsr sse sse2 ss tm syscall nx lm constant_tsc arch_perfmon rep_good cpuid pni monitor vmx est tm2 ssse3 cx16 xtpr sse4_1 popcnt rng rng_en ace ace_en ace2 phe phe_en pmm pmm_en lahf_lm tpr_shadow vnmi vpid ida vmx flags : vnmi tsc_offset vtpr bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips: 1596.53 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: and processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 13 model name : VIA C7-D Processor 1800MHz stepping: 0 cpu MHz : 1596.326 cache size : 128 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx cpuid pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips: 3193.67 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 32 bits virtual power management: respectively. On these machines, the output is "sse2: 0" instead of some value unequal 0. Regards, Erich P.S.: I hope, I reported this in the correct category. Please let me know, if I did not.
[Bug middle-end/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-25 Component|target |middle-end Ever confirmed|0 |1 --- Comment #6 from Andrew Pinski --- (In reply to Richard Biener from comment #3) > Possibly a dup of PR100727? I think it is unrelated. The problem is the fix for PR 100619, sets the attributes to be "+" but the code in attribs.c, skip over the '+' but does not check if it is the end of the string: /* Skip the internal-only plus sign. */ if (*m == '+') ++m; acc.str = m; acc.mode = acc.from_mode_char (*m);
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #12 from Jakub Jelinek ---
With incremental
--- gcc/omp-offload.c.jj2021-05-25 13:43:01.341137265 +0200
+++ gcc/omp-offload.c 2021-05-25 20:07:01.934506823 +0200
@@ -2696,8 +2696,16 @@ pass_omp_target_link::execute (function
{
gimple_stmt_iterator gsi;
for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
- if (walk_gimple_stmt (, NULL, find_link_var_op, NULL))
- gimple_regimplify_operands (gsi_stmt (gsi), );
+ {
+ if (gimple_call_builtin_p (gsi_stmt (gsi), BUILT_IN_GOMP_TARGET))
+ {
+ /* Nullify the second argument of __builtin_GOMP_target_ext. */
+ gimple_call_set_arg (gsi_stmt (gsi), 1, null_pointer_node);
+ update_stmt (gsi_stmt (gsi));
+ }
+ if (walk_gimple_stmt (, NULL, find_link_var_op, NULL))
+ gimple_regimplify_operands (gsi_stmt (gsi), );
+ }
}
return 0;
I see it fail with
Linking
Link complete: 0.00ms
Link log info: 240 bytes gmem, 1414 bytes cmem[3]
libgomp: cuModuleGetFunction error: named symbol not found
libgomp: Cannot map target functions or variables (expected 9, have 4294967295)
(target-41.c with GOMP_DEBUG=1), but it is unclear from that which named symbol
wasn't found.
Any idea how to troubleshoot what is missing?
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
Jakub Jelinek changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek ---
Using asm ("exit;"); instead of __builtin_unreachable (); doesn't help.
My current suspicion is that it is about taking address of the function that is
marked as PTX kernel entry point (functions with "omp target entrypoint"
attribute on the compiler side).
So maybe we need on the compiler side fold __builtin_GOMP_target_ext to
__builtin_unreachable or something similar or at least nullify the kernel
pointer argument in there.
[Bug target/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 --- Comment #5 from John David Anglin --- Breakpoint 1, attr_access::from_mode_char ( c=) at ../../gcc/gcc/attribs.h:304 304 gcc_unreachable (); (gdb) bt #0 attr_access::from_mode_char ( c=) at ../../gcc/gcc/attribs.h:304 #1 0x40a8311c in init_attr_rdwr_indices (rwm=0x83fffdff14e0, attrs=0x83fffdf1b9b0) at ../../gcc/gcc/attribs.c:2146 #2 0x40d1e554 in warn_parm_array_mismatch (origloc=2147484671, fndecl=0x83fffdf1b9b0, newparms=0x7ae4b8) at ../../gcc/gcc/c-family/c-warn.c:3369 #3 0x40b5ebc0 in c_parser_declaration_or_fndef ( parser=0x83fffdff14e0, fndef_ok=128, static_assert_ok=false, empty_ok=true, nested=false, start_attr_ok=false, objc_foreach_object_declaration=0x40887f48 , omp_declare_simd_clauses=..., have_attrs=false, attrs=0x83fffdf1d700, oacc_routine_data=0x42f7501f , fallthru_attr_p=0x83fffdff17a0) at ../../gcc/gcc/c/c-parser.c:2342 #4 0x40b5cb98 in c_parser_external_declaration ( parser=0x83fffdff14e0) at ../../gcc/gcc/c/c-parser.c:1777 #5 0x40b5c240 in c_parser_translation_unit (parser=0x83fffdff14e0) at ../../gcc/gcc/c/c-parser.c:1650 #6 0x40bc644c in c_parse_file () at ../../gcc/gcc/c/c-parser.c:21994 #7 0x40cafd10 in c_common_parse_file () at ../../gcc/gcc/c-family/c-opts.c:1219 #8 0x417db87c in compile_file () at ../../gcc/gcc/toplev.c:457 #9 0x417e26e8 in do_compile () at ../../gcc/gcc/toplev.c:2203 #10 0x417e2e68 in toplev::main (this=0x83fffdff14e0, argc=-2147482625, argv=0x7ae4b8) at ../../gcc/gcc/toplev.c:2342 #11 0x42abbee4 in main (argc=-2147482625, argv=0x83fffdf1b9b0) at ../../gcc/gcc/main.c:39 (gdb) frame 1 #1 0x40a8311c in init_attr_rdwr_indices (rwm=0x83fffdff14e0, attrs=0x83fffdf1b9b0) at ../../gcc/gcc/attribs.c:2146 2146 acc.mode = acc.from_mode_char (*m); (gdb) p *m $2 = 0 '\000'
[Bug target/100626] [11/12 Regression] ICE Segmentation fault (during RTL pass: split1) since r11-165-geb72dc663e9070b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target|x86_64-linux-gnu|x86 |i?86-linux-gnu | --- Comment #8 from Uroš Bizjak --- Fixed.
[Bug c++/100731] [11/12 Regression] GCC 11 fails to build using GCC 4.8 because of missing includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- I plan to add the std:: qualifications, but committed the above patch because it works likely everywhere and has been tested already.
[Bug target/100626] [11/12 Regression] ICE Segmentation fault (during RTL pass: split1) since r11-165-geb72dc663e9070b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:6be2c12e37b167890d68587086a2186358b64c02 commit r11-8468-g6be2c12e37b167890d68587086a2186358b64c02 Author: Uros Bizjak Date: Tue May 18 15:45:54 2021 +0200 i386: Fix split_double_mode with paradoxical subreg [PR100626] split_double_mode calls simplify_gen_subreg, which fails for the high half of the paradoxical subreg. Return temporary register instead of NULL RTX in this case. 2021-05-18 Uroš Bizjak gcc/ PR target/100626 * config/i386/i386-expand.c (split_double_mode): Return temporary register when simplify_gen_subreg fails with the high half od the paradoxical subreg. (cherry picked from commit d39fbed75810fc7478842503ecb0268b85dc9c2e)
[Bug c++/100731] [11/12 Regression] GCC 11 fails to build using GCC 4.8 because of missing includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731 --- Comment #9 from Jonathan Wakely --- r230324 changed the dependency for std::to_string from _GLIBCXX_USE_C99 to _GLIBCXX_USE_C99_STDIO, which means it's enabled for more targets (you don't need the full C99 math library, for example!) That change is present in GCC 6. And r272186 removed the _GLIBCXX_C99_STDIO dependency for std::to_string, so it's always defined now. That's in GCC 10.
[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757 --- Comment #2 from Alex Coplan --- Could be, I'm bisecting it now...
[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #1 from Christophe Lyon --- Maybe that's related to my recent MVE patches?
[Bug c++/100731] [11/12 Regression] GCC 11 fails to build using GCC 4.8 because of missing includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731 --- Comment #8 from Harald van Dijk --- I take it that means there's no need for me to continue with what Richard asked me to do? At any rate, it looks like this fix won't be enough for GCC 12, but that's an issue with the environment, not GCC 12. In !_GLIBCXX_USE_C99 environments, there is always going to be valid C++11 code that will be rejected and it looks like GCC 12 started using at least one std::to_string that relies on C99 in the underlying C library. If C++11 is a bootstrap requirement, that's fair enough, that means I need to update my environment at some point before GCC 12 will be released.
[Bug target/100757] New: arm: ICE (unrecognizable insn) with MVE VPSELQ_S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757
Bug ID: 100757
Summary: arm: ICE (unrecognizable insn) with MVE VPSELQ_S
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
This appears to be a recent regression on the trunk:
$ gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: arm-eabi
Configured with: /home/alecop01/toolchain/src/gcc/configure
--prefix=/data_sdb/toolchain/cc1s/arm --enable-languages=c,c++
--disable-bootstrap --target=arm-eabi
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210525 (experimental) (GCC)
$ cat test.c
extern int a[];
int n;
void foo(int x, _Bool b) {
for (int i = 0; i < n; i++)
a[i] = x || b;
}
$ gcc/xgcc -B gcc -c test.c -march=armv8.1-m.main+mve -mfloat-abi=hard -O
-ftree-vectorize -mtune=cortex-a55
test.c: In function ‘foo’:
test.c:6:1: error: unrecognizable insn:
6 | }
| ^
(insn 44 43 45 6 (set (reg:V4SI 131 [ vect_patt_4.10 ])
(unspec:V4SI [
(reg:V4SI 149)
(reg:V4SI 150)
(reg:V4SI 148 [ mask__2.9 ])
] VPSELQ_S)) -1
(nil))
during RTL pass: vregs
test.c:6:1: internal compiler error: in extract_insn, at recog.c:2770
0x5e9fc6 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:108
0x5e9fe5 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:116
0xc770c7 extract_insn(rtx_insn*)
/home/alecop01/toolchain/src/gcc/gcc/recog.c:2770
0x9aa78a instantiate_virtual_regs_in_insn
/home/alecop01/toolchain/src/gcc/gcc/function.c:1609
0x9aa78a instantiate_virtual_regs
/home/alecop01/toolchain/src/gcc/gcc/function.c:1983
0x9aa78a execute
/home/alecop01/toolchain/src/gcc/gcc/function.c:2032
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 --- Comment #9 from Iain Sandoe --- JFTR the Apple OSS folks comment: "I checked with the clang team — it appears this was an unintentional consequence of an upstream change: https://reviews.llvm.org/D75203. This difference between debug vs non-debug asm has been noticed upstream and the new assembly optimization has been disabled (for now) in https://reviews.llvm.org/D94542 already. You should be able to avoid this issue with clang-1205 by adding in the `-mllvm -x86-pad-for-align=false` flags to the build. I confirmed this resolved the issue for me with the small reproducer. " however, that means we will need to do some configury checks to decide if this fix needs to be applied or not (and maybe that would best be deferred until we see what version of Xcode contains a fix).
[Bug tree-optimization/100756] New: vect: Superfluous epilog created on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100756
Bug ID: 100756
Summary: vect: Superfluous epilog created on s390x
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rdapp at linux dot ibm.com
Target Milestone: ---
Since g:d846f225c25c5885250c303c8d118caa08c447ab we create an epilog loop on
s390 for the following test case:
/* { dg-do compile } */
/* { dg-options "-O3 -mzarch -march=z13" } */
/* { dg-require-effective-target s390_vx } */
int
foo (int * restrict a, int n)
{
int i, result = 0;
for (i = 0; i < n * 4; i++)
result += a[i];
return result;
}
vec.c:10:17: note: epilog loop required
The following check in
tree-vect-loop.c:vect_need_peeling_or_partial_vectors_p() is now true:
|| ((tree_ctz (LOOP_VINFO_NITERS (loop_vinfo))
< (unsigned) exact_log2 (const_vf))
We now have LOOP_VINFO_NITERS (loop_vinfo) = _15 > 0 ? (unsigned int) _15 : 1
as compared to (unsigned int) _15 before. tree_ctz() returns 0 for the
conditional and 2 before which did not trigger the epilog requirement.
may_be_zero is _15 > 0 so it looks to me like we rather want to check the
not-may_be_zero part of niter for alignment. Not sure if this is the right/safe
thing to do, though.
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #10 from Jakub Jelinek --- I didn't have the nvidia binary module loaded and cuda installed when doing the light testing, now I've installed that and see FAIL: libgomp.c/../libgomp.c-c++-common/for-3.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/for-9.c execution test XPASS: libgomp.c/../libgomp.c-c++-common/pr96390.c (test for excess errors) FAIL: libgomp.c/../libgomp.c-c++-common/pr96390.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/target-41.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/target-42.c execution test fail. target-41.c and -42.c FAIL with the same error as for-3.c, libgomp: cuLaunchKernel error: too many resources requested for launch I'm puzzled about that message though, it really shouldn't request too many resources, it should spawn a single thread doing a very simple kernel. Maybe the __builtin_unreachable (); calls are the culprit? I didn't know if I should use __builtin_trap (), __builtin_abort () and __builtin_unreachable () is what has been used in task.c.
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #9 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #8) > Lightly tested patch. Just quick manually testing "for-3.c" (I tried -O0 and -O3): * With nvptx offloading, it compiles + links – but at run time, I get on two systems: libgomp: cuLaunchKernel error: too many resources requested for launch and, on the third system, a SEGFAULT – which sounds as if it could be the same issue: #0 memcpy () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:145 #1 0x763b2552 in ?? () from /usr/lib/x86_64-linux-gnu/libcuda.so.1 when executing libgomp/plugin/plugin-nvptx.c:2004 2004 r = CUDA_CALL_NOCHECK (cuLaunchKernel, function, teams, 1, 1, * For amdgcn, I get at startup: ... GCN debug: Released kernel dispatch: 0x7eb350 GCN debug: Copying 6000 bytes from host (0x7730c0) to device 0 (0x7ffeed8194d0) GCN warning: Could not find symbol for kernel in the code object Runtime message: HSA_STATUS_ERROR_INVALID_SYMBOL_NAME: There is no symbol with the given name. not found name: 'test_d_normal._omp_fn.0.kd' ... not found name: 'test_d_ds128_normal._omp_fn.0.kd' not found name: 'test_ds_normal._omp_fn.0.kd' ... [The .kd" comes from plugin/plugin-gcn.c's: sprintf (buf, "%s.kd", kernel->name); ] (I am now doing a full bootstrap now to ensure that that wasn't due to the incremental build.)
[Bug fortran/100755] Error with fortran object (v11.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2021-05-25 CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Please provide full steps to build the library? What target are you on? Please paste gcc --version
[Bug fortran/100755] New: Error with fortran object (v11.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755 Bug ID: 100755 Summary: Error with fortran object (v11.1.0) Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: afernandez at odyhpc dot com Target Milestone: --- Hello, I'm trying to compile NCEPLIBS (https://github.com/NOAA-EMC/NCEPLIBS) with 11.1.0 and getting the following error: $sudo make -- Build files have been written to: /opt/praetorium/NCEPLIBS/build [centos@ip-172-31-20-40 build]$ sudo make [ 0%] Built target prep2deploy [ 0%] Creating directories for 'w3nco' [ 1%] Performing download step (git clone) for 'w3nco' Cloning into 'nceplibs-w3nco'... HEAD is now at 068435b Merge pull request #16 from NOAA-EMC/gcc-10-settable-flags [ 2%] Performing update step for 'w3nco' [ 3%] No patch step for 'w3nco' [ 3%] Performing configure step for 'w3nco' -- The C compiler identification is GNU 11.1.0 -- The Fortran compiler identification is GNU 11.1.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /opt/praetorium/openmpi/bin/mpicc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Check for working Fortran compiler: /opt/praetorium/openmpi/bin/mpif90 - skipped -- Checking whether /opt/praetorium/openmpi/bin/mpif90 supports Fortran 90 -- Checking whether /opt/praetorium/openmpi/bin/mpif90 supports Fortran 90 - yes -- Setting build type to 'Release' as none was specified. -- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project: OPENMP -- Build files have been written to: /opt/praetorium/NCEPLIBS/build/w3nco/src/w3nco-build [ 4%] Performing build step for 'w3nco' Scanning dependencies of target w3nco_4_f [ 1%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/aea.f.o [ 1%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/errexit.f.o [ 1%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/errmsg.f.o [ 2%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/fparsei.f.o [ 2%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/fparser.f.o [ 2%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/gbytec.f.o [ 2%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/gbyte.f.o [ 3%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/gbytesc.f.o [ 3%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/gbytes.f.o [ 3%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getbit.f.o [ 4%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgb1.f.o [ 4%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgb1re.f.o [ 4%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgb1r.f.o [ 5%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgb1s.f.o [ 5%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbe.f.o [ 5%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbeh.f.o [ 5%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbem.f.o [ 6%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbemh.f.o [ 6%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbemn.f.o [ 6%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbemp.f.o [ 7%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbep.f.o [ 7%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbex.f.o [ 7%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbexm.f.o [ 8%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgb.f.o [ 8%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbh.f.o [ 8%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbm.f.o [ 8%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbmh.f.o [ 9%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbmp.f.o [ 9%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgbp.f.o [ 9%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgi.f.o [ 10%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/getgir.f.o [ 10%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/gtbits.f.o [ 10%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/idsdef.f.o [ 11%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/instrument.f.o [ 11%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/iw3jdn.f.o [ 11%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/iw3pds.f.o [ 11%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/iw3unp29.f.o [ 12%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/ixgb.f.o [ 12%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/lengds.f.o [ 12%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/makwmo.f.o [ 13%] Building Fortran object src/CMakeFiles/w3nco_4_f.dir/mkfldsep.f.o [ 13%] Building Fortran object
[Bug c++/100666] [9/10/11/12 Regression] warning: ignoring return value of 'constexpr _Tp&& std::forward(typename std::remove_reference<_Tp>::type&) [with _Tp = std::nullptr_t; ...]', declared with at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100666 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ad52d89808a947264397e920d7483090d4108f7b commit r12-1043-gad52d89808a947264397e920d7483090d4108f7b Author: Jakub Jelinek Date: Tue May 25 17:24:38 2021 +0200 c++: Avoid -Wunused-value false positives on nullptr passed to ellipsis [PR100666] When passing expressions with decltype(nullptr) type with side-effects to ellipsis, we pass (void *)0 instead, but for the side-effects evaluate them on the lhs of a COMPOUND_EXPR. Unfortunately that means we warn about it if the expression is a call to nodiscard marked function, even when the result is really used, just needs to be transformed. Fixed by adding a warning_sentinel. 2021-05-25 Jakub Jelinek PR c++/100666 * call.c (convert_arg_to_ellipsis): For expressions with NULLPTR_TYPE and side-effects, temporarily disable -Wunused-result warning when building COMPOUND_EXPR. * g++.dg/cpp1z/nodiscard8.C: New test. * g++.dg/cpp1z/nodiscard9.C: New test.
[Bug c++/100754] New: Order of multiple inheritance can lead to illegal code jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100754
Bug ID: 100754
Summary: Order of multiple inheritance can lead to illegal code
jump
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mgaron at pleora dot com
Target Milestone: ---
First time filing a bug, sorry for anything wrong I might be doing.
Experienced with microblaze gcc v8.2.0, v9.2.0, on our existing code base. I
made a simpler example program for sake of debugging.
Simple Base class, with pure virtual function. Compiled in its own shared
library:
class Base {
public:
Base(int value);
virtual ~Base() {}
int GetValue(void);
protected:
virtual int ModInt(int value) = 0;
private:
int value;
};
When used to create a derived class with multiple inheritance, the code
generated seems to be wrong when the base class is specified after some other
interface:
This class too is compiled in its own shared library.
#include
class ILocalInterface {
public:
virtual ~ILocalInterface() {}
virtual void PrintMsg(void) = 0;
};
class Derived
: public ILocalInterface, public Base {// This leads to a program
crash!
//: public Base, public ILocalInterface { // This works fine...
public:
Derived(int value);
~Derived() {}
// ILocalInterface
void PrintMsg(void) override;
protected:
// Base.
int ModifyInt(int value) override;
};
Used as-is in some test application, any call to ModInt() will cause an illegal
instruction or segfault error.
I created a dump of the .o file and got this:
0128 <_ZN7Derived9ModifyIntEi>:
int Derived::ModifyInt(int value) {
128: 3021ffdcaddik r1, r1, -36
...
01a4 <_ZThn4_N7Derived9ModifyIntEi>:
// ILocalInterface
void PrintMsg(void) override;
protected:
// Base.
int ModifyInt(int value) override;
1a4: 30a5fffcaddik r5, r5, -4
1a8: b000imm 0
1a8: R_MICROBLAZE_GOT_64$LTHUNK2
1ac: e994lwi r12, r20, 0
1b0: 98086000bra r12
_ZThn4_N7Derived9ModifyIntEi symbol does get call appropriately, but it
computes the address to jump to (_ZN7Derived9ModifyIntEi) based on an offset in
the GOT. r20 is the register that holds the GOT for microblaze. When called,
r20 has the value of the GOT of the Base.so library, while it should have the
value of the Derived.so library.
All other compilers I tried (arm64, arm32, x86_64) issue a simple local jump
relative to the PC (2 instructions). Microblaze does support such jump. So in
effect, this might have better to do with the Microblaze backend than the C++
frontend. Let me know if I should modify the affected component.
Also, swapping the order of the interfaces in the declaration of the Derived
class, no such assembly as above is created. Neither is it the case with simple
inheritance.
To me it looks highly suspicious that microblaze generates different code based
on the order of inheritance. Also that the faulty code looks nothing like the
other compiler backends.
Will be happy to provide any assistance, further tests, patch trials, etc.
[Bug c++/100731] [11/12 Regression] GCC 11 fails to build using GCC 4.8 because of missing includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7a5e9a58fbe27d8b8f04cd18bc6e1dd736e3cd12 commit r12-1041-g7a5e9a58fbe27d8b8f04cd18bc6e1dd736e3cd12 Author: Jakub Jelinek Date: Tue May 25 16:44:35 2021 +0200 c++tools: Include for exit [PR100731] This TU uses exit, but doesn't include or and relies on some other header to include it indirectly, which apparently doesn't happen on reporter's host. The other headers aren't guarded either and we rely on a compiler capable of C++11, so maybe we can rely on being around unconditionally. 2021-05-25 Jakub Jelinek PR bootstrap/100731 * server.cc: Include .
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #8 from Jakub Jelinek --- Created attachment 50867 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50867=edit gcc12-pr100573.patch Lightly tested patch.
[Bug target/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 John David Anglin changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from John David Anglin --- This ICE was introduced by the following commit: commit eb2a917fa0779b689f09ac8d8c41b0456facbe62 (HEAD) Author: Martin Sebor Date: Wed May 19 16:13:13 2021 -0600 PR c/100619 - ICE on a VLA parameter with too many dimensions gcc/c-family/ChangeLog: PR c/100619 * c-attribs.c (build_attr_access_from_parms): Handle arbitrarily many bounds.
[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 --- Comment #42 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e commit r12-1039-gebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e Author: Martin Liska Date: Wed Mar 10 15:12:31 2021 +0100 Improve global state for options. gcc/c-family/ChangeLog: PR tree-optimization/92860 PR target/99592 * c-attribs.c (handle_optimize_attribute): Save target node before calling parse_optimize_options and save it in case it changes. * c-pragma.c (handle_pragma_target): Similarly for pragma. (handle_pragma_pop_options): Likewise here. gcc/ChangeLog: PR tree-optimization/92860 PR target/99592 * optc-save-gen.awk: Remove exceptions.
[Bug target/99592] arm: internal compiler error using arm_neon.h with -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592 --- Comment #12 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e commit r12-1039-gebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e Author: Martin Liska Date: Wed Mar 10 15:12:31 2021 +0100 Improve global state for options. gcc/c-family/ChangeLog: PR tree-optimization/92860 PR target/99592 * c-attribs.c (handle_optimize_attribute): Save target node before calling parse_optimize_options and save it in case it changes. * c-pragma.c (handle_pragma_target): Similarly for pragma. (handle_pragma_pop_options): Likewise here. gcc/ChangeLog: PR tree-optimization/92860 PR target/99592 * optc-save-gen.awk: Remove exceptions.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #7 from Martin Liška --- > Looking at line 25, it doesn't show the line is hit (by giving 'r' character > during a.out run) nor are the counter values reset for the other lines. The > count of 4,3,2 are seen for some lines because of a previous a.out run. Yes, because once you can __gcov_dump, any profile is saved later.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #6 from Martin Liška --- > So, I understand that __gcov_dump could be used only after doing all the > testing with the application ,i.e- towards the end to get the > profile/coverage info. Am I right? Yes, and you don't need to call it manually. Profile automatically saved when an application exits. > > Resetting run-time counters - does that mean it would not get reflected in > .gcda files or the .c.gcov file contents created by gcov (assuming that the > application a.out is still on run )? Yes, __gcov_reset is supposed to be called at the beginning when an application wants to start profiling. Again, you don't need to call it manually.
[Bug target/99960] MVE: Wrong code storing V2DI vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99960 Alex Coplan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Alex Coplan --- Fixed.
[Bug target/99960] MVE: Wrong code storing V2DI vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99960 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Alex Coplan : https://gcc.gnu.org/g:59eb00c08db6683f6a69e3b9fd2743f00e187951 commit r10-9867-g59eb00c08db6683f6a69e3b9fd2743f00e187951 Author: Alex Coplan Date: Mon May 10 09:46:45 2021 +0100 arm: Fix wrong code with MVE V2DImode loads and stores [PR99960] As the PR shows, we currently miscompile V2DImode loads and stores for MVE. We're currently using 64-bit loads/stores, but need to be using 128-bit vector loads and stores. Fixed thusly. Some intrinsics tests were checking that we (incorrectly) used the 64-bit loads/stores: these have been updated. gcc/ChangeLog: PR target/99960 * config/arm/mve.md (*mve_mov): Simplify output code. Use vldrw.u32 and vstrw.32 for V2D[IF]mode loads and stores. gcc/testsuite/ChangeLog: PR target/99960 * gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_s64.c: Update now that we're (correctly) using full 128-bit vector loads/stores. * gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_u64.c: Likewise. * gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_z_s64.c: Likewise. * gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_z_u64.c: Likewise. * gcc.target/arm/mve/intrinsics/vuninitializedq_int.c: Likewise. * gcc.target/arm/mve/intrinsics/vuninitializedq_int1.c: Likewise. (cherry picked from commit 7596c762137f26f495b53ec93471273887832e31)
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751
--- Comment #5 from Gejoe ---
Running the program:
./a.out
g
When g is passed, return value is 8
When
is passed, return value is 0
r
When r is passed, return value is 8
When
is passed, return value is 0
<< the program is still running, waiting for next character entry>>
Now if we see the sample-prog.c.gcov file , it shows :
-: 16:do {
-: 17:
4: 18:c = getchar();
4: 19:result = isalnum(c);
4: 20:printf("When %c is passed, return value is %d\n", c,
result);
-: 21:
4: 22:if(c == 'g')
2: 23:__gcov_dump();
2: 24:else if(c == 'r')
#: 25:__gcov_reset();
-: 26:
3: 27:}while(c != 'c');
Looking at line 25, it doesn't show the line is hit (by giving 'r' character
during a.out run) nor are the counter values reset for the other lines. The
count of 4,3,2 are seen for some lines because of a previous a.out run.
[Bug c++/100710] static_cast to derived* of base* pointing to non-static data member of base type not rejected in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100710 --- Comment #1 from Jonathan Wakely --- Confirmed. Not a regression.
[Bug c++/100710] static_cast to derived* of base* pointing to non-static data member of base type not rejected in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100710 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-05-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug libgomp/100753] New: Implement in_reduction clause on target construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100753 Bug ID: 100753 Summary: Implement in_reduction clause on target construct Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- I think we have two cases. One is in_reduction clause on synchronous target (i.e. without nowait clause), I think that is implementable just by calling GOMP_task_reduction_remap on all map clause addresses that use the in_reduction identifier as base expression and making sure map clause isn't thrown away for them when the original list item is declare target to - the in_reduction clause acts as a privatization clause on the target task. Plus add map(always, tofrom: item) clause. The much harder case is target with nowait clause. Right now task reductions are implemented by having privatized arrays with one element per thread. But for async target the host threads can be doing something else and can update those private copies. So I think for nowait in_reduction(...) we need to create new host private copies for those (initialized with the reduction initializers), map them to device and when the target task is over, map them back from device and at that point combine them into the remapped private reduction var. That will probably mean a new callback invoked from GOMP_PLUGIN_target_task_completion ?
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #4 from Gejoe --- (In reply to Martin Liška from comment #3) > > For the second time and then onwards, __gcov_dump() invocation (by giving > > 'g' character during the a.out run) doesn't happen. > > Yes, one can call __gcov_dump only once per run. So, I understand that __gcov_dump could be used only after doing all the testing with the application ,i.e- towards the end to get the profile/coverage info. Am I right? > > Another thing is that, __gcov_reset() also doesn't appear to work. I tried > > giving the character 'r' during the run of the program but couldn't see the > > counters getting reset to 0 in the sample-prog.gcov file. The previous > > values of lines covered were there. > > No, __gcov_reset resets run-time counters (profile collected so far during > an application run). If you want to clear profile, then simply remove .gcda > files. Resetting run-time counters - does that mean it would not get reflected in .gcda files or the .c.gcov file contents created by gcov (assuming that the application a.out is still on run )?
[Bug fortran/100724] -fwhole-program breaks module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 --- Comment #5 from Dave Love --- Thanks for the explanation. Could the manual entry for -fwhole-program just be amended to clarify that it's a fallback for when a linker plugin isn't available for -flto. That may be what it was intended to say, but it's not clear to me. I used -fwhole-program because it seemed to fit my case exactly.
[Bug target/100711] Miss optimization for pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711 --- Comment #5 from Segher Boessenkool --- (In reply to Hongtao.liu from comment #4) > > Even w/ canonical RTL, i think a combine splitter is also needed here, the > > canonical RTL only helps combine/forwprop to match more possibility but > > won't split patterns by itselies. > > I was wrong, i thought combine only support n->1 combining, but actually > pass_combine also support 3->2 combining which means a define_split is not > needed here. ->1 and ->2, yes. But note that combine can often split RTL without having an explicit define_split; and also note the opposite, combine does not always pick the best spot to split, "manual" help (a define_split) can be needed for good results.
[Bug target/97969] [9/10/11/12 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #25 from Przemyslaw Wirkus --- Yes, it was applied to GCC 11 (then trunk) but we were waiting for GCC 11 release so I can backport at least to GCC 10. After backport I guess we can close this PR. PS: Updated "known to work/fail". Cheers!
[Bug target/97969] [9/10/11/12 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #24 from Richard Biener --- So is this now fixed on trunk and the GCC 11 branch? Please update the summary and known-to-work/fail accordingly,
[Bug target/97969] [9/10/11/12 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 Przemyslaw Wirkus changed: What|Removed |Added CC||przemyslaw.wirkus at arm dot com --- Comment #23 from Przemyslaw Wirkus --- Just a follow up after GCC 11 release. I've locally backported to gcc-10 branch (without any change to original patches) PR97969 and following PR98722 & PR98777 patches. Commits apply cleanly without changes. Built and regression tested on: * arm-none-eabi and * aarch64-none-linux-gnu cross toolchains. There were no issues and no regressions (all OK). I've asked on mailing list for official backport approval.
[Bug c++/100752] [11/12 Regression] error: cannot call member function ‘void S::f()’ without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100752 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libgomp/100747] Possibly Wrong Permissions in "liboffloadmic"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100747 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/100727] [12 Regression] Recent change to WITH_SIZE_EXPR handling breaks mn10300-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100727 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug libgomp/100747] Possibly Wrong Permissions in "liboffloadmic"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100747 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:2c3202e6f8a95362384022edf5d93839682df5ba commit r12-1034-g2c3202e6f8a95362384022edf5d93839682df5ba Author: Richard Biener Date: Tue May 25 11:11:27 2021 +0200 libgomp/100747 - fix permission of configure scripts Added executable bits. 2021-05-25 Richard Biener PR libgomp/100747 liboffloadmic/ * configure: Make executable. * plugin/configure: Likewise.
[Bug tree-optimization/100727] [12 Regression] Recent change to WITH_SIZE_EXPR handling breaks mn10300-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100727 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:316bdb2e8970a461f2ae1a7183262d18a72adab3 commit r12-1032-g316bdb2e8970a461f2ae1a7183262d18a72adab3 Author: Richard Biener Date: Tue May 25 10:21:41 2021 +0200 middle-end/100727 - fix call expansion with WITH_SIZE_EXPR arg call expansion used the result of get_base_address to switch between ABIs - with get_base_address now never returning NULL we have to re-instantiate the check in a more explicit way. This also adjusts mark_addressable to skip WITH_SIZE_EXPRs, consistent with how build_fold_addr_expr handles it. 2021-05-25 Richard Biener PR middle-end/100727 * calls.c (initialize_argument_information): Explicitely test for WITH_SIZE_EXPR. * gimple-expr.c (mark_addressable): Skip outer WITH_SIZE_EXPR.
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #13 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3a81735c1c8cea4323dcb912b7a8879b54aa3bc0 commit r12-1031-g3a81735c1c8cea4323dcb912b7a8879b54aa3bc0 Author: Jakub Jelinek Date: Tue May 25 11:07:01 2021 +0200 openmp: Fix reduction clause handling on teams distribute simd [PR99928] When a directive isn't combined with worksharing-loop, it takes much simpler clause splitting path for reduction, and that one was missing handling of teams when combined with simd. 2021-05-25 Jakub Jelinek PR middle-end/99928 gcc/c-family/ * c-omp.c (c_omp_split_clauses): Copy reduction to teams when teams is combined with simd and not with taskloop or for. gcc/testsuite/ * c-c++-common/gomp/pr99928-8.c: Remove xfails from omp teams r21 and r28 checks. * c-c++-common/gomp/pr99928-9.c: Likewise. * c-c++-common/gomp/pr99928-10.c: Likewise. libgomp/ * testsuite/libgomp.c-c++-common/reduction-17.c: New test.
[Bug c++/100752] [11/12 Regression] error: cannot call member function ‘void S::f()’ without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100752 Jonathan Wakely changed: What|Removed |Added Known to work||10.3.0 Target Milestone|--- |11.2 Known to fail||11.1.0, 12.0
[Bug c++/52869] [DR 1207] "this" not being allowed in noexcept clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869 --- Comment #21 from Jonathan Wakely --- Oh dear. It started to fail with r11-289. I've created Bug 100752.
[Bug c++/100752] New: [11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100752
Bug ID: 100752
Summary: [11/12 Regression]
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
As noted in Bug 52869 comment 20, this has started to fail:
struct S
{
void f() noexcept {}
S () noexcept(noexcept(f())) { f(); return *this; }
};
noex.C:4:32: error: cannot call member function ‘void S::f()’ without object
4 | S () noexcept(noexcept(f())) { f(); return *this; }
|^
It started with r11-289:
c++: Use of 'this' in parameter declaration [PR90748]
We were incorrectly accepting the use of 'this' at parse time and then
crashing when we tried to instantiate it. It is invalid because 'this' is
not in scope until after the function-cv-quals. So let's hoist setting
current_class_ptr up from cp_parser_late_return_type_opt into
cp_parser_direct_declarator where it can work for noexcept as well.
PR c++/90748
* parser.c (inject_parm_decls): Set current_class_ptr here.
(cp_parser_direct_declarator): And here.
(cp_parser_late_return_type_opt): Not here.
(cp_parser_noexcept_specification_opt): Nor here.
(cp_parser_exception_specification_opt)
(cp_parser_late_noexcept_specifier): Remove unneeded parameters.
[Bug libgomp/100747] Possibly Wrong Permissions in "liboffloadmic"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100747 --- Comment #3 from Jakub Jelinek --- I think the configure scripts during build are run through $(SHELL) $$s/$$module_srcdir/configure ... from the toplevel makefile, so it doesn't care if it has executable permissions or not. Doesn't hurt to change the permissions of course.
[Bug libgomp/100747] Possibly Wrong Permissions in "liboffloadmic"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100747 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- I'll fix.
[Bug target/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 --- Comment #3 from Richard Biener --- Possibly a dup of PR100727?
[Bug tree-optimization/100727] [12 Regression] Recent change to WITH_SIZE_EXPR handling breaks mn10300-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100727
--- Comment #3 from Richard Biener ---
So it's fixed with
diff --git a/gcc/calls.c b/gcc/calls.c
index f3da1839dc5..74a5070605e 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -2397,6 +2397,7 @@ initialize_argument_information (int num_actuals
ATTRIBUTE_UNUSED,
already in memory, instead of making a copy. Likewise if we want
to make the copy in the callee instead of the caller. */
if ((call_from_thunk_p || callee_copies)
+ && TREE_CODE (args[i].tree_value) != WITH_SIZE_EXPR
&& (base = get_base_address (args[i].tree_value))
&& TREE_CODE (base) != SSA_NAME
&& (!DECL_P (base) || MEM_P (DECL_RTL (base
where the get_base_address change lets WITH_SIZE_EXPR through now but not
before. The only obvious followon difference is that we then do
mark_addressable (args[i].tree_value);
...
args[i].tree_value = build_fold_addr_expr_loc (loc,
args[i].tree_value);
type = TREE_TYPE (args[i].tree_value);
unchanged is that we pass the argument by reference and that the target
requests callee_copies.
Now, this is variadic args, so maybe the callee_copies thing doesn't apply
and/or the varargs setup code now is inconsistent - in the end it's an
ABI change.
So given get_base_address only ever returned NULL for WITH_SIZE_EXPR
and clearly the !base check switches between ABIs we have to make the
WITH_SIZE_EXPR check explicit.
I'm also testing the additional (but then not needed)
diff --git a/gcc/gimple-expr.c b/gcc/gimple-expr.c
index b8c732b632a..c3211795d33 100644
--- a/gcc/gimple-expr.c
+++ b/gcc/gimple-expr.c
@@ -900,6 +900,8 @@ flush_mark_addressable_queue ()
void
mark_addressable (tree x)
{
+ if (TREE_CODE (x) == WITH_SIZE_EXPR)
+x = TREE_OPERAND (x, 0);
while (handled_component_p (x))
x = TREE_OPERAND (x, 0);
if (TREE_CODE (x) == MEM_REF
[Bug tree-optimization/100519] [11 Regression] ICE in insert_stmt_after, at tree-ssa-reassoc.c:1452
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100519 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||11.1.0 Known to work||11.1.1 Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/100492] [10/11 Regression] wrong code at -O3 (generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100492 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:9b3852d998bd4ae68f51311441feea13103971e3 commit r11-8462-g9b3852d998bd4ae68f51311441feea13103971e3 Author: Richard Biener Date: Mon May 10 11:37:27 2021 +0200 tree-optimization/100492 - avoid irreducible regions in loop distribution When we distribute away a condition we rely on the ability to change it to either 1 != 0 or 0 != 0 depending on the direction of the exit branch in the respective loop. But when the loop contains an irreducible sub-region then for the conditions inside this this fails and can lead to infinite loops being generated. Avoid distibuting loops with irreducible sub-regions. 2021-05-10 Richard Biener PR tree-optimization/100492 * tree-loop-distribution.c (find_seed_stmts_for_distribution): Find nothing when the loop contains an irreducible region. * gcc.dg/torture/pr100492.c: New testcase. (cherry picked from commit 60af2db18013a0339302928ba98fee893ccc1957)
[Bug tree-optimization/100519] [11 Regression] ICE in insert_stmt_after, at tree-ssa-reassoc.c:1452
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100519 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:edd7bbe0e96a0d45d6ae142c5809ef1cae6c0999 commit r11-8465-gedd7bbe0e96a0d45d6ae142c5809ef1cae6c0999 Author: Richard Biener Date: Tue May 11 14:59:59 2021 +0200 tree-optimization/100519 - avoid reassociating asm goto defs This splits can_associate_p into checks for SSA defs and checks for the type so it can be called from is_reassociable_op to catch cases not catched by the earlier fix. 2021-05-11 Richard Biener PR tree-optimization/100519 * tree-ssa-reassoc.c (can_associate_p): Split into... (can_associate_op_p): ... this (can_associate_type_p): ... and this. (is_reassociable_op): Call can_associate_op_p. (break_up_subtract_bb): Call the appropriate predicates. (reassociate_bb): Likewise. * gcc.dg/torture/pr100519.c: New testcase. (cherry picked from commit cd36bbb2281ada10b5e1df143ecf64b88cdb8119)
[Bug ipa/100513] [10/11 Regression] ICE: Segmentation fault (in lookup_page_table_entry) for bootstrap-O3 since r11-6411-gae99b315ba5b9e1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513 --- Comment #26 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:d0a8a95003e7763ece4886e771f71385966e229b commit r11-8464-gd0a8a95003e7763ece4886e771f71385966e229b Author: Richard Biener Date: Tue May 11 13:23:45 2021 +0200 ipa/100513 - fix SSA_NAME_DEF_STMT corruption in IPA param manip This fixes unintended clobbering of SSA_NAME_DEF_STMT of the cloned/inlined from SSA name during IPA parameter manipulation of call stmt LHSs. gimple_call_set_lhs adjusts SSA_NAME_DEF_STMT of the lhs to the stmt being modified but when ipa_param_body_adjustments::modify_call_stmt is called the cloning/inlining process has not yet remapped the stmts operands to the copy variants but they are still original. 2021-05-11 Richard Biener PR ipa/100513 * ipa-param-manipulation.c (ipa_param_body_adjustments::modify_call_stmt): Avoid altering SSA_NAME_DEF_STMT by adjusting the calls LHS via gimple_call_lhs_ptr. (cherry picked from commit 7e0fe7761da9255c9342788956c37b426875d872)
[Bug tree-optimization/100509] [9/10/11 Regression] ICE at -O3: in fold_convert_loc with variable (attribute) alias of different types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100509 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:3870fe246f442d795ef2270c74f56dda9d0be26c commit r11-8463-g3870fe246f442d795ef2270c74f56dda9d0be26c Author: Richard Biener Date: Tue May 11 10:58:35 2021 +0200 middle-end/100509 - avoid folding constant to aggregate type When folding a constant initializer looking through aliases to incompatible types can lead to us trying to fold a constant to an aggregate type which can't work. Simply avoid trying to constant fold non-register typed symbols. 2021-05-11 Richard Biener PR middle-end/100509 * gimple-fold.c (fold_gimple_assign): Only call get_symbol_constant_value on register type symbols. * gcc.dg/pr100509.c: New testcase. (cherry picked from commit ca8e8301180fa71de1a76769fc038df2ab85dfeb)
[Bug c++/100731] [11/12 Regression] GCC 11 fails to build using GCC 4.8 because of missing includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731 --- Comment #6 from Harald van Dijk --- (In reply to rguent...@suse.de from comment #5) > At this point a minimal fix is prefered - in principle the file > should be a valid source to any C++ 11 capable host compiler, not > just GCC. The maintainer is on leave but we do want the build to > be fixed. Now, since the file already includes csingal/cstring and > cstdarg I'd say using the C++ wrapper to C includes and qualifying > the calls would be consistent with existing use (thus not including > stdlib.h but cstdlib). The minimal fix is the other one, to change the headers to <*.h>, as none of the calls to library functions in the file are std::-qualified. :) Alright, I'll send a patch for that once I'm able to test that the same problem is still present on master and that the same fix is sufficient to get things working.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 Martin Liška changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-May/571 ||152.html Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-05-25 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- > For the second time and then onwards, __gcov_dump() invocation (by giving > 'g' character during the a.out run) doesn't happen. Yes, one can call __gcov_dump only once per run. > > Another thing is that, __gcov_reset() also doesn't appear to work. I tried > giving the character 'r' during the run of the program but couldn't see the > counters getting reset to 0 in the sample-prog.gcov file. The previous > values of lines covered were there. No, __gcov_reset resets run-time counters (profile collected so far during an application run). If you want to clear profile, then simply remove .gcda files. I've just send documentation improvement for it: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571152.html
[Bug c++/100731] [11/12 Regression] GCC 11 fails to build using GCC 4.8 because of missing includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731 --- Comment #5 from rguenther at suse dot de --- On Tue, 25 May 2021, harald at gigawatt dot nl wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731 > > --- Comment #4 from Harald van Dijk --- > (In reply to Richard Biener from comment #3) > > Yes, including is enough to get the build to pass. My last point in > comment #2, however, means that that leaves things in an inconsistent state > and > that the right fix depends on what the project wants. There are basically two > options that look equally reasonable to me: adding an include of > (and, although not required to fix the build, ) and adding std:: > qualifiers to everything that needs it, or adding an include of > (and > ) and changing the other existing includes to <*.h>. Happy to > send a patch for whichever of these is preferred. At this point a minimal fix is prefered - in principle the file should be a valid source to any C++ 11 capable host compiler, not just GCC. The maintainer is on leave but we do want the build to be fixed. Now, since the file already includes csingal/cstring and cstdarg I'd say using the C++ wrapper to C includes and qualifying the calls would be consistent with existing use (thus not including stdlib.h but cstdlib).
[Bug c++/100731] [11/12 Regression] GCC 11 fails to build using GCC 4.8 because of missing includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731 --- Comment #4 from Harald van Dijk --- (In reply to Richard Biener from comment #3) Yes, including is enough to get the build to pass. My last point in comment #2, however, means that that leaves things in an inconsistent state and that the right fix depends on what the project wants. There are basically two options that look equally reasonable to me: adding an include of (and, although not required to fix the build, ) and adding std:: qualifiers to everything that needs it, or adding an include of (and ) and changing the other existing includes to <*.h>. Happy to send a patch for whichever of these is preferred.
[Bug testsuite/100749] [12 regression] gcc.dg/pch/valid-1.c fails after r12-949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug libgomp/100747] Possibly Wrong Permissions in "liboffloadmic"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100747 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|other |libgomp Target||intelmic CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-05-25 --- Comment #1 from Richard Biener --- eh, means nobody tests those ...
[Bug c++/52869] [DR 1207] "this" not being allowed in noexcept clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
Sven Suursoho changed:
What|Removed |Added
CC||spam+gcc at alt dot ee
--- Comment #20 from Sven Suursoho ---
Seems some variant of this bug has returned with g++-11 (but not in g++-10)
$ cat s.cpp
struct S
{
void f() noexcept {}
S () noexcept(noexcept(f())) { f(); return *this; }
};
$ g++-11 -Wall -Werror -std=c++2a -c s.cpp
s.cpp:4:31: error: cannot call member function 'void S::f()' without object
4 | S () noexcept(noexcept(f())) { f(); return *this; }
| ~^~
$ cat s.cpp
struct S
{
void f() noexcept {}
S () noexcept(noexcept(this->f())) { f(); return *this; }
};
$ g++-11 -Wall -Werror -std=c++2a -c s.cpp
s.cpp:4:30: error: invalid use of 'this' at top level
4 | S () noexcept(noexcept(this->f())) { f(); return *this; }
| ^~~~
$ cat workaround.cpp
struct S
{
void f() noexcept {}
auto g() noexcept(noexcept(this->f())) -> S& { f(); return *this; }
};
$ g++-11 -Wall -Werror -std=c++2a -c workaround.cpp
$ g++-11 -v
Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.1.0/libexec/gcc/x86_64-apple-darwin19/11.1.0/lto-wrapper
Target: x86_64-apple-darwin19
Configured with: ../configure --prefix=/usr/local/Cellar/gcc/11.1.0
--libdir=/usr/local/Cellar/gcc/11.1.0/lib/gcc/11 --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran,d
--program-suffix=-11 --with-gmp=/usr/local/opt/gmp
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc
--with-isl=/usr/local/opt/isl --with-pkgversion='Homebrew GCC 11.1.0'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--enable-libphobos --build=x86_64-apple-darwin19 --with-system-zlib
--disable-multilib --with-native-system-header-dir=/usr/include
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.1.0 (Homebrew GCC 11.1.0)
~ $ uname -a
Darwin home.local 19.6.0 Darwin Kernel Version 19.6.0: Mon Apr 12 20:57:45 PDT
2021; root:xnu-6153.141.28.1~1/RELEASE_X86_64 x86_64
[Bug other/100735] -fno-trampolines doc wrongly implies it affects C, C++ etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100735 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org Last reconfirmed||2021-05-25 --- Comment #3 from Eric Botcazou --- > The GCC manual's documentation of -fno-trampolines was apparently written > from an Ada point of view. However, when I read it I understandably mistook > it to say that -fno-trampolines also works for C, C++, etc. It doesn't: it > is silently ignored for these languages, and I assume for any language other > than Ada. Patches were posted to make it work in C but didn't make it apparently.
[Bug tree-optimization/80740] Aliasing with the return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80740 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-25 Ever confirmed|0 |1 CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Confirmed.
