[Bug target/101235] [11/12 Regression] Fails to bootstrap with binutils 2.32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101235 Kewen Lin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Kewen Lin --- (In reply to Segher Boessenkool from comment #4) > (In reply to Kewen Lin from comment #3) > > Will backport the fix after 2021 July 7th (two weeks since it's into trunk) > > if this isn't urgent meanwhile got the backport approval. > > The reason to not backport immediately is because you end up with a > royal mess if your patch causes regressions. A week is normally > plenty: there will be lots of test results that can give you > confidence things work. > > If a patch caused build failures, we want that fixed as soon as > possible, because we will not have test results at all otherwise :-) Thanks for the note. I thought this is one partial build issue (the build can still work with newer binutils) so tried to be conservative. Built successfully with latest releases/gcc-11, also bootstrapped and regress-tested on releases/gcc-11 (with newer binutils for regression testing of coz.). Should be fixed on gcc-11.
[Bug target/101235] [11/12 Regression] Fails to bootstrap with binutils 2.32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101235 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:f6306457ee386a9cae9b08e35ce160af0566b9f9 commit r11-8661-gf6306457ee386a9cae9b08e35ce160af0566b9f9 Author: Kewen Lin Date: Tue Jun 22 23:09:30 2021 -0500 rs6000: Fix typos in float128 ISA3.1 support The recent float128 ISA3.1 support (r12-1340) has some typos, it makes the libgcc build fail if it's with one binutils (assembler) which doesn't support Power10 insns. The error looks like: Error: invalid switch -mpower10 Error: unrecognized option -mpower10 ... [...libgcc/shared-object.mk:14: float128-p10.o] Error 1 What this patch does are: - fix test target typo libgcc_cv_powerpc_3_1_float128_hw (written wrongly as libgcc_cv_powerpc_float128_hw, so it's going to build ISA3.1 stuffs just when detecting ISA3.0). - fix test used for libgcc_cv_powerpc_3_1_float128_hw check. - fix test option used for libgcc_cv_powerpc_3_1_float128_hw check. - remove the ISA3.1 related contents from t-float128-hw. - add new macro FLOAT128_HW_INSNS_ISA3_1 to differentiate ISA3.1 content from ISA3.0 part in ifunc support. Bootstrapped/regtested on: - powerpc64le-linux-gnu P10 - powerpc64le-linux-gnu P9 (w/i and w/o p10 supported as) - powerpc64-linux-gnu P8 (w/i and w/o p10 supported as) libgcc/ChangeLog: PR target/101235 * configure: Regenerate. * configure.ac (test for libgcc_cv_powerpc_3_1_float128_hw): Fix typos among the name, CFLAGS and the test. * config/rs6000/t-float128-hw (fp128_3_1_hw_funcs, fp128_3_1_hw_src, fp128_3_1_hw_static_obj, fp128_3_1_hw_shared_obj, fp128_3_1_hw_obj): Remove. * config/rs6000/t-float128-p10-hw (FLOAT128_HW_INSNS): Append macro FLOAT128_HW_INSNS_ISA3_1. (FP128_3_1_CFLAGS_HW): Fix option typo. * config/rs6000/float128-ifunc.c (SW_OR_HW_ISA3_1): Guard this with FLOAT128_HW_INSNS_ISA3_1. (__floattikf_resolve): Likewise. (__floatuntikf_resolve): Likewise. (__fixkfti_resolve): Likewise. (__fixunskfti_resolve): Likewise. (__floattikf): Likewise. (__floatuntikf): Likewise. (__fixkfti): Likewise. (__fixunskfti): Likewise. (cherry picked from commit 47749c43acb460ac8f410ee599616d1860ee5a35)
[Bug fortran/100917] Bind(c): errors handling long double real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917 --- Comment #5 from sandra at gcc dot gnu.org --- Here's a related problem: the GFC descriptor representation can't distinguish between CHARACTER(kind=ucs4, len=1) and CHARACTER(kind=c_char, len=4) because all it has is elem_len == 4.
[Bug fortran/25714] concat of strings create an extra temporary variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25714 --- Comment #8 from Tobias Schlüter --- No more temporary FAICT https://godbolt.org/z/o8fYE1nej If written as a proper function: function c(a, b) character(2) :: c character(1) :: a character(1) :: b c = a//b end we get: c_: pushrbx mov r9, rcx mov rbx, rdi mov rcx, rdx mov r8d, 1 mov edx, 1 mov edi, 2 sub rsp, 16 lea rsi, [rsp+14] call_gfortran_concat_string movzx eax, WORD PTR [rsp+14] mov WORD PTR [rbx], ax add rsp, 16 pop rbx ret ... and likewise for the original testcase.
[Bug ipa/95859] [10/11/12 regression] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859 Tobias Schlüter changed: What|Removed |Added Known to work||10.3.0, 11.1.0 --- Comment #15 from Tobias Schlüter --- Seems to be fixed also on ARM64 in 10.3, 11.1
[Bug target/101248] [AVX512] The upper bits of FIXUPIMMS{S,D} should come from src1 not dest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101248 --- Comment #2 from Hongtao.liu --- (In reply to Hongtao.liu from comment #0) > currently the pattern is defined as > > (define_insn "avx512f_sfixupimm_mask" > [(set (match_operand:VF_128 0 "register_operand" "=v") > (vec_merge:VF_128 > (vec_merge:VF_128 > (unspec:VF_128 > [(match_operand:VF_128 1 "register_operand" "0") > (match_operand:VF_128 2 "register_operand" "v") > (match_operand: 3 > "" > "") > (match_operand:SI 4 "const_0_to_255_operand")] > UNSPEC_FIXUPIMM) > (match_dup 2) The is refined pattern, original pattern has match_dup 1 here.
[Bug target/101248] [AVX512] The upper bits of FIXUPIMMS{S,D} should come from src1 not dest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101248 --- Comment #1 from Hongtao.liu --- src1 here means operands[2], dest here means operand[0] or operands[1].
[Bug target/101248] New: [AVX512] The upper bits of FIXUPIMMS{S,D} should come from src1 not dest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101248
Bug ID: 101248
Summary: [AVX512] The upper bits of FIXUPIMMS{S,D} should come
from src1 not dest.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Target: x86_64-*-* i?86-*-*
currently the pattern is defined as
(define_insn "avx512f_sfixupimm_mask"
[(set (match_operand:VF_128 0 "register_operand" "=v")
(vec_merge:VF_128
(vec_merge:VF_128
(unspec:VF_128
[(match_operand:VF_128 1 "register_operand" "0")
(match_operand:VF_128 2 "register_operand" "v")
(match_operand: 3
"" "")
(match_operand:SI 4 "const_0_to_255_operand")]
UNSPEC_FIXUPIMM)
(match_dup 2)
(const_int 1))
(match_dup 1)
(match_operand: 5 "register_operand" "Yk")))]
"TARGET_AVX512F"
"vfixupimm\t{%4, %3, %2,
%0%{%5%}|%0%{%5%}, %2, %3, %4}";
[(set_attr "prefix" "evex")
(set_attr "mode" "")])
when mask is 1, current GCC will optimize
movl$-1, %eax
kmovw %eax, %k2
vfixupimmpd $0, %xmm2, %xmm1, %xmm0{%k2}
to
vfixupimmsd $0, %xmm3, %xmm1, %xmm0
But the upper 32 bits of vfixupimmsd should come from src1 not dest which means
the upper optimization is wrong.
[Bug c++/101247] New: ICE when using static constexpr bool defined in base-class in derived class constructor requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101247
Bug ID: 101247
Summary: ICE when using static constexpr bool defined in
base-class in derived class constructor
requires-clause
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lewissbaker.opensource at gmail dot com
Target Milestone: ---
Compiling the following code with GCC trunk and flags: -std=c++20
```
template
struct in_place_type_t {};
template
inline constexpr in_place_type_t in_place_type;
template
inline constexpr bool outer_helper_v = true;
template
struct foo {
struct type;
template
static constexpr bool helper_v = outer_helper_v;
};
template
struct foo::type {
template
requires helper_v
type(in_place_type_t) {}
};
int main() {
foo::type x(in_place_type);
}
```
results in an internal compiler-error
```
: In substitution of 'template requires helper_v
foo::type::type(in_place_type_t) [with U = {int}]':
:26:40: required from here
:21:18: internal compiler error: tree check: accessed elt 1 of
'tree_vec' with 0 elts in tsubst_pack_expansion, at cp/pt.c:13084
21 | requires helper_v
| ^~~
0x1d4c179 internal_error(char const*, ...)
???:0
0x685746 tree_vec_elt_check_failed(int, int, char const*, int, char const*)
???:0
0x99e0bc tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
???:0
0x9afa62 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0x9b064b tsubst_argument_pack(tree_node*, tree_node*, int, tree_node*)
???:0
0x9afa04 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0x983ebd tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x7abcda constraints_satisfied_p(tree_node*, tree_node*)
???:0
0x9c26c3 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0x74abc9 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0x74c8c0 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0x8611c8 build_aggr_init(tree_node*, tree_node*, int, int)
???:0
0x81f0d9 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x94f36d c_parse_file()
???:0
0xad2922 c_common_parse_file()
???:0
```
See https://godbolt.org/z/ebnxfsMs9 for an example.
[Bug target/101241] Internal compiler error from MathFunctions.h in the eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101241 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2021-06-28 Ever confirmed|0 |1 --- Comment #9 from Andrew Pinski --- (In reply to Raymond Langer from comment #8) > releases/gcc-11.1.0-303-ge86ad5ad01 This does not make sense. object ge86ad5ad01 does not exist in origin/releases/gcc-11 branch at all. You are going to have to report this to the Clear Linux OS folks.
[Bug target/101241] Internal compiler error from MathFunctions.h in the eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101241 --- Comment #8 from Raymond Langer --- I didn't configure gcc myself. I run gcc in a Clean Linux docker container: docker run -it clearlinux /bin/bash In the docker container, I run: swupd bundle-add c-basic gcc --version gcc (Clear Linux OS for Intel Architecture) 11.1.1 20210617 releases/gcc-11.1.0-303-ge86ad5ad01 Copyright (C) 2021 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. The uploaded file does not compile with: g++ -c a-eigen_bug.ii -Ofast
[Bug target/101241] Internal compiler error from MathFunctions.h in the eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101241 --- Comment #7 from Andrew Pinski --- How did you configure GCC? Also what revision is your 11.1.1 at?
[Bug tree-optimization/101242] Segfault in SLP vectorizor after g:2ad71efb5de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101242 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from David Binderman --- Created attachment 51078 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51078=edit gzipped C++ source code I also see this with -O3 with the attached C++ code.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 74765, which changed state. Bug 74765 Summary: missing uninitialized warning (parenthesis, TREE_NO_WARNING abuse) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74765 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/74765] missing uninitialized warning (parenthesis, TREE_NO_WARNING abuse)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74765 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Known to fail|11.0|11.1.0 Status|ASSIGNED|RESOLVED --- Comment #9 from Martin Sebor --- Fixed in GCC 12.0.
[Bug c++/74762] [9/10/11 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762 --- Comment #21 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:40c64c9ea565230817f08b5e66a30a1c94ec880c commit r12-1861-g40c64c9ea565230817f08b5e66a30a1c94ec880c Author: Martin Sebor Date: Mon Jun 28 15:14:50 2021 -0600 Regression tests for TREE_NO_WARNING enhancement to warning groups [PR74765, PR74762]. PR middle-end/74765 - missing uninitialized warning (parenthesis, TREE_NO_WARNING abuse) PR middle-end/74762 - [9/10/11/12 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING) gcc/testsuite/ChangeLog: * g++.dg/uninit-pr74762.C: New test. * g++.dg/warn/uninit-pr74765.C: Same.
[Bug c++/74765] missing uninitialized warning (parenthesis, TREE_NO_WARNING abuse)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74765 --- Comment #8 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:40c64c9ea565230817f08b5e66a30a1c94ec880c commit r12-1861-g40c64c9ea565230817f08b5e66a30a1c94ec880c Author: Martin Sebor Date: Mon Jun 28 15:14:50 2021 -0600 Regression tests for TREE_NO_WARNING enhancement to warning groups [PR74765, PR74762]. PR middle-end/74765 - missing uninitialized warning (parenthesis, TREE_NO_WARNING abuse) PR middle-end/74762 - [9/10/11/12 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING) gcc/testsuite/ChangeLog: * g++.dg/uninit-pr74762.C: New test. * g++.dg/warn/uninit-pr74765.C: Same.
[Bug go/101246] gccgo cross-compiler targeting arm fails to build with gcc 11. Missing structs in runtime.inc. Using uclibc-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101246 --- Comment #4 from Lance Fredrickson --- Created attachment 51077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51077=edit runtime.inc oops, I've attached runtime.inc
[Bug go/101246] gccgo cross-compiler targeting arm fails to build with gcc 11. Missing structs in runtime.inc. Using uclibc-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101246 --- Comment #3 from Ian Lance Taylor --- Thanks, but I am hoping to see not the build log, but rather the contents of the generated file TARGET/libgo/runtime.inc, around lines 1357 and 1360. Thanks.
[Bug go/101246] gccgo cross-compiler targeting arm fails to build with gcc 11. Missing structs in runtime.inc. Using uclibc-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101246 --- Comment #2 from Lance Fredrickson --- echo timestamp > unicode.s-gox f="runtime.o"; if test ! -f $f; then f="./.libs/runtime.o"; fi; /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/bin/objcopy -j .go_export $f runtime.s-gox.tmp; /bin/bash ../../../libgo/mvifdiff.sh runtime.s-gox.tmp `echo runtime.s-gox | sed -e 's/s-gox/gox/'` /bin/bash ../../../libgo/mkruntimeinc.sh /bin/bash ../../../libgo/mvifdiff.sh tmp-runtime.inc runtime.inc echo timestamp > s-runtime-inc /home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-11.1.0/build/./gcc/xgcc -B/home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-11.1.0/build/./gcc/ -B/opt/tomatoware/arm-soft-mmc/arm-tomato ware-linux-uclibcgnueabi/bin/ -B/opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/lib/ -isystem /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include -isystem /opt/tomatoware/arm-soft-mmc/arm-tomatoware-li nux-uclibcgnueabi/sys-include-DHAVE_CONFIG_H -I. -I../../../libgo -I ../../../libgo/runtime -I../../../libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexceptions -fnon-call-exceptions -Wall -Wextra -Wwr ite-strings -Wcast-qual -Werror -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../libgo/../libgcc -I ../../../libgo/../libbacktrace -I ../../gcc/include -fPIC -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_ BITS=64 -O2 -g0 -DNDEBUG -MT runtime/libgobegin_a-go-main.o -MD -MP -MF runtime/.deps/libgobegin_a-go-main.Tpo -c -o runtime/libgobegin_a-go-main.o `test -f 'runtime/go-main.c' || echo '../../../libgo/'`runtime/go-main.c /home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-11.1.0/build/./gcc/xgcc -B/home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-11.1.0/build/./gcc/ -B/opt/tomatoware/arm-soft-mmc/arm-tomato ware-linux-uclibcgnueabi/bin/ -B/opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/lib/ -isystem /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include -isystem /opt/tomatoware/arm-soft-mmc/arm-tomatoware-li nux-uclibcgnueabi/sys-include-DHAVE_CONFIG_H -I. -I../../../libgo -I ../../../libgo/runtime -I../../../libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexceptions -fnon-call-exceptions -Wall -Wextra -Wwr ite-strings -Wcast-qual -Werror -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../libgo/../libgcc -I ../../../libgo/../libbacktrace -I ../../gcc/include -fPIC -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_ BITS=64 -O2 -g0 -DNDEBUG -MT runtime/libgolibbegin_a-go-libmain.o -MD -MP -MF runtime/.deps/libgolibbegin_a-go-libmain.Tpo -c -o runtime/libgolibbegin_a-go-libmain.o `test -f 'runtime/go-libmain.c' || echo '../../../libgo/'`runtime/go- libmain.c depbase=`echo runtime/aeshash.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/bash ./libtool --tag=CC --mode=compile /home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-11.1.0/build/./gcc/xgcc -B/home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-11.1.0/build/. /gcc/ -B/opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/bin/ -B/opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/lib/ -isystem /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include -isystem /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/sys-include -DHAVE_CONFIG_H -I. -I../../../libgo -I ../../../libgo/runtime -I../../../libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexcep tions -fnon-call-exceptions -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../libgo/../libgcc -I ../../../libgo/../libbacktrace -I ../../gcc/include -D_LARGEFILE_SOU RCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -DNDEBUG -MT runtime/aeshash.lo -MD -MP -MF $depbase.Tpo -c -o runtime/aeshash.lo ../../../libgo/runtime/aeshash.c &&\ mv -f $depbase.Tpo $depbase.Plo depbase=`echo runtime/go-assert.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/bash ./libtool --tag=CC --mode=compile /home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-11.1.0/build/./gcc/xgcc -B/home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-11.1.0/build/. /gcc/ -B/opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/bin/ -B/opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/lib/ -isystem /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include -isystem /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/sys-include -DHAVE_CONFIG_H -I. -I../../../libgo -I ../../../libgo/runtime -I../../../libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexcep tions -fnon-call-exceptions -Wall -Wextra -Wwrite-strings
[Bug c++/101194] [9/10/11/12 Regression] aggregate init requires default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101194
--- Comment #2 from Patrick Palka ---
Reduced rejects-valid testcase:
struct nodefault {
constexpr nodefault(int) { }
};
constexpr nodefault x[1] = { nodefault{0} };
constexpr nodefault y = x[0];
We started rejecting this testcase even earlier, after r7-2520.
[Bug c++/99251] [11 Regression] inconsistent -Wnonnull warning behaviour with dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251 Bug 99251 depends on bug 74762, which changed state. Bug 74762 Summary: [9/10/11 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 74762, which changed state. Bug 74762 Summary: [9/10/11 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/74762] [9/10/11 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |missing uninitialized |missing uninitialized |warning (C++, parenthesized |warning (C++, parenthesized |expr, TREE_NO_WARNING) |expr, TREE_NO_WARNING) Known to fail|11.0|11.1.0 Status|ASSIGNED|RESOLVED Target Milestone|9.5 |12.0 --- Comment #20 from Martin Sebor --- Yes, this was indeed resolved by r12-1804 and related. One of the last patches in the series (yet to be committed) adds a test for this to the test suite: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571984.html
[Bug middle-end/99959] [9/10/11/12 Regression] missing -Wuninitialized for an esra variable with TREE_NO_WARNING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99959 --- Comment #4 from Martin Sebor --- No, that change (r12-1805 and related) doesn't affect these cases (and wasn't expected to; the warning is still suppressed in the esra pass).
[Bug tree-optimization/89976] [9/10/11/12 Regression] missing -Wuninitialized for struct member due to sra and TREE_NO_WARNING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89976 --- Comment #7 from Martin Sebor --- No, that change (r12-1804 and related) doesn't affect these cases (and wasn't expected to).
[Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101219
--- Comment #3 from Martin Sebor ---
The code fails in the assert below where binfo is null. The full stack trace
follows. The difference is that before r12-1804 warn_for_null_address() would
return without doing anything because TREE_NO_WARNING(op) was 1. r12-1804
changed the TREE_NO_WARNING(op) test to warning_suppressed_p (op,
OPT_Waddress)) which returns false. The no-warning bit on OP is also clear so
something has caused it to not be set. Possibly a subtle difference in the
location value. Whatever has caused the change, it seems like the root cause
of the ICE is something else (unless the front end somehow relies on the
no-warning bit to also mean something else than just "disable warnings").
bool
perform_or_defer_access_check (tree binfo, tree decl, tree diag_decl,
tsubst_flags_t complain,
access_failure_info *afi)
{
int i;
deferred_access *ptr;
deferred_access_check *chk;
/* Exit if we are in a context that no access checking is performed. */
if (deferred_access_no_check)
return true;
gcc_assert (TREE_CODE (binfo) == TREE_BINFO);
0x1717bc8 crash_signal
/ssd/src/gcc/master/gcc/toplev.c:328
0xdf00fb perform_or_defer_access_check(tree_node*, tree_node*, tree_node*, int,
access_failure_info*)
/ssd/src/gcc/master/gcc/cp/semantics.c:490
0xdf6a7d finish_non_static_data_member(tree_node*, tree_node*, tree_node*)
/ssd/src/gcc/master/gcc/cp/semantics.c:2208
0xda8762 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/ssd/src/gcc/master/gcc/cp/pt.c:20568
0xd5d6cc instantiate_non_dependent_expr_internal(tree_node*, int)
/ssd/src/gcc/master/gcc/cp/pt.c:6323
0xad622f fold_non_dependent_expr_template
/ssd/src/gcc/master/gcc/cp/constexpr.c:7604
0xad6585 fold_non_dependent_expr(tree_node*, int, bool, tree_node*)
/ssd/src/gcc/master/gcc/cp/constexpr.c:7661
0xbda7c4 fold_for_warn(tree_node*)
/ssd/src/gcc/master/gcc/cp/expr.c:409
0xe67e56 warn_for_null_address
/ssd/src/gcc/master/gcc/cp/typeck.c:4453
0xe6a880 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
/ssd/src/gcc/master/gcc/cp/typeck.c:5169
0xe6b0ff cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
/ssd/src/gcc/master/gcc/cp/typeck.c:5357
0xa59d4c build_new_op_1
/ssd/src/gcc/master/gcc/cp/call.c:6760
0xa59e57 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/ssd/src/gcc/master/gcc/cp/call.c:6806
0xe6774c build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
/ssd/src/gcc/master/gcc/cp/typeck.c:4330
0xcd6d2c cp_parser_binary_expression
/ssd/src/gcc/master/gcc/cp/parser.c:10023
0xcd7229 cp_parser_assignment_expression
/ssd/src/gcc/master/gcc/cp/parser.c:10163
0xcd7608 cp_parser_expression
/ssd/src/gcc/master/gcc/cp/parser.c:10331
0xcdb75c cp_parser_expression_statement
/ssd/src/gcc/master/gcc/cp/parser.c:12075
0xcdafe1 cp_parser_statement
/ssd/src/gcc/master/gcc/cp/parser.c:11871
0xcdbd17 cp_parser_statement_seq_opt
/ssd/src/gcc/master/gcc/cp/parser.c:12223
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #15 from Iain Sandoe --- @dave Perhaps you could post the patch at C#12 for review (it would be useful to get this cleared)
[Bug libstdc++/80196] fenv_t not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80196 --- Comment #9 from Andreas K. Huettel --- (In reply to Andreas K. Huettel from comment #8) > Created attachment 51076 [details] > full build log, xz-compressed ^ Build log for a failure with * --host=riscv32-unknown-linux-gnu * --target=riscv32-unknown-linux-gnu * --build=x86_64-pc-linux-gnu (Gentoo crossdev build of a native riscv32 compiler)
[Bug libstdc++/80196] fenv_t not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80196 Andreas K. Huettel changed: What|Removed |Added CC||dilfridge at gentoo dot org --- Comment #8 from Andreas K. Huettel --- Created attachment 51076 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51076=edit full build log, xz-compressed
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 Andreas K. Huettel changed: What|Removed |Added CC||dilfridge at gentoo dot org --- Comment #14 from Andreas K. Huettel --- also seen with * --host=riscv32-unknown-linux-gnu * --target=riscv32-unknown-linux-gnu * --build=x86_64-pc-linux-gnu (building a native riscv32 gcc using Gentoo's crossdev)
[Bug c/23144] [9/10/11/12 Regression] invalid parameter forward declarations not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23144 Joseph S. Myers changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #27 from Joseph S. Myers --- *** Bug 101212 has been marked as a duplicate of this bug. ***
[Bug c/101212] forward declaration of parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101212 Joseph S. Myers changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Joseph S. Myers --- See the first example in bug 23144. *** This bug has been marked as a duplicate of bug 23144 ***
[Bug go/101246] gccgo cross-compiler targeting arm fails to build with gcc 11. Missing structs in runtime.inc. Using uclibc-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101246 --- Comment #1 from Ian Lance Taylor --- Yes, runtime.inc is a generated file. Can you post the lines around the errors? These look like fields in a struct type, and I'd like to know which type it is. Thanks.
[Bug tree-optimization/101186] predictable comparison of integer variables not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101186 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #6 from Jeffrey A. Law --- I wonder why we don't unswitch the loop twice to pull both conditionals out. If we were to do that, the a != 0 loop versions can be removed because they'll do nothing other than increase the loop counter. The a==0 variant will just have the printf and increment of b.
[Bug go/101246] New: gccgo cross-compiler targeting arm fails to build with gcc 11. Missing structs in runtime.inc. Using uclibc-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101246 Bug ID: 101246 Summary: gccgo cross-compiler targeting arm fails to build with gcc 11. Missing structs in runtime.inc. Using uclibc-ng Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: lancethepants at gmail dot com CC: cmang at google dot com Target Milestone: --- I've recently run into an issue building a go cross-compiler on x86_64 targeting an arm embedded device (Netgear R7000 router) starting with gcc 11. I was previously able to build the cross-compiler (c,c++,go) under gcc 9 & 10, but am getting the errors listed at the bottom. armv7 cortexa9 cpu (no fpu) uclibc-ng (latest) kernel 2.6.36.4. I don't think the old kernel is an issue because the same errors arise if I use kernel 5.12. I tried building with glibc, and it does work then. So I think the issue is with uclibc-ng. So I did use uclibc-ng with gcc 9 & 10 with success, but for some reason with gcc 11 I am now running into this issue. My untrained eyes think it may be as easy as a couple missing structs within runtime.inc. Is runtime.inc generated? because it doesn't appear in unconfigured source I've notices. thanks, Lance Build Errors In file included from ../../../libgo/runtime/runtime.h:105, from ../../../libgo/runtime/go-main.c:17: ./runtime.inc:1357:29: error: field ‘__state’ has incomplete type 1357 | struct ___mbstate_t __state; | ^~~ ./runtime.inc:1360:33: error: field ‘__lock’ has incomplete type 1360 | struct _pthread_mutex_t __lock; |
[Bug bootstrap/101245] New: Bootstrap fails for a combined tree with --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101245 Bug ID: 101245 Summary: Bootstrap fails for a combined tree with --enable-shared Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: christoph.hoeger at celeraone dot com Target Milestone: --- Created attachment 51075 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51075=edit Reproduction build script I tried to bootstrap gcc 11.1.0 with binutils 2.36.1 in a combined tree and the build fails in stage2 when building libiberty. The failure stems from as not finding its shared libraries (opcode and bfd). The RPATH is set wrong: ➜ test2 readelf -d build/prev-gas/.libs/lt-as-new | grep RPATH 0x000f (RPATH) Library rpath: [/home/choeger/c1/scratch/gcc-combined/test2/build/opcodes/.libs:/home/choeger/c1/scratch/gcc-combined/test2/build/bfd/.libs:/usr/local/lib] ➜ test2 As you can see, the RPATH is not reset to the prev- directories. ➜ test2 build/prev-gas/as-new /home/choeger/c1/scratch/gcc-combined/test2/build/prev-gas/.libs/lt-as-new: error while loading shared libraries: libopcodes-2.36.1.so: cannot open shared object file: No such file or directory Find attached a script to reproduce the issue.
[Bug c++/101243] Coroutine lambda capture is destroyed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101243 --- Comment #2 from Iain Sandoe --- (In reply to Victor Burckel from comment #1) > May be similar to > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401 I agree this is likely to be a duplicate ( I am in the process of reviewing coros bugs)
[Bug c++/101241] Internal compiler error from MathFunctions.h in the eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101241 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Can't reproduce with -Ofast -ffast-math -march=haswell either.
[Bug tree-optimization/101242] Segfault in SLP vectorizor after g:2ad71efb5de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101242 --- Comment #3 from Martin Jambor --- Profiled LTO bootstrap also fails with a segfault with the same backtrace.
[Bug ipa/93385] [10/11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 Martin Jambor changed: What|Removed |Added Summary|[10/11/12 Regression] wrong |[10/11 Regression] wrong |code with u128 modulo at|code with u128 modulo at |-O2 -fno-dce -fno-ipa-cp|-O2 -fno-dce -fno-ipa-cp |-fno-tree-dce |-fno-tree-dce --- Comment #47 from Martin Jambor --- Fixed on master. Given the size of the fix, it is clearly not suitable for backporting. This bug is likely to remain unfixed on GCC 10 and 11, which however should not hurt anybody who does not explicitly disable DCE. (An unappealing but realistic alternative is to add the bail out from comment #11 to those branches.)
[Bug c/98892] FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98892 --- Comment #4 from Jim Wilson --- It turns out that -fmessage-length=0 doesn't work which is odd. I suspect a latent bug in the diagnostic code. I tried -fmessage-length=128, which should work as that is longer than the error line, and does work for this failure, but that causes a different line to fail. Turns out that there is a test that emits a 2.3KB error message. To make the entire testcase work, I need a -fmessage-length value longer than the longest error message, so the smallest power of 2 that works is -fmessage-length=4096 which seems too stupid to submit as a patch.
[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228 Thomas Rodgers changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rodgertq at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #9 from Thomas Rodgers --- Yes (I already reviewed it when it arrived upstream). It is probably also safe to backport to GCC-11 since there's no ABI or ABI stability concerns. I will have a go at applying *just* this patch (I don't want to commit to trying a full rebase against upstream at this point).
[Bug c++/101241] Internal compiler error from MathFunctions.h in the eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101241 --- Comment #5 from Raymond Langer --- Using only -Ofast doesn't work either: g++ -c a-eigen_bug.ii -Ofast
[Bug c++/101241] Internal compiler error from MathFunctions.h in the eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101241 --- Comment #4 from Raymond Langer --- (In reply to Marek Polacek from comment #3) > I cannot reproduce this: > > $ xg++ -c a-eigen_bug.ii -O3 -ffast-math -march=haswell > compiles. Yes, g++ -c a-eigen_bug.ii -O3 -ffast-math -march=haswell compiles. However, -Ofast does not work together with -ffast-math: g++ -c a-eigen_bug.ii -Ofast -ffast-math -march=haswell
[Bug target/98784] [9/10/11/12 Regression] problematic build of uClibc with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 --- Comment #14 from YannSionneau --- Created attachment 51074 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51074=edit non-working uClibc-ng build This is a build of uClibc-ng that does not allow normal Linux booting. You can boot to a shell by doing init=/bin/sh but any command you type (like ls) would run the command and then crash the system because init (in fact the shell, the parent of the forked command) gets killed. This might be related to issue in signal handling since the parent is supposed to receive a SIGCHILD signal when its child exits. Difference with previous attachment is just that the follow buildroot patch is not applied to gcc: https://git.buildroot.net/buildroot/commit/?id=4d16e6f5324f0285f51bfbb5a3503584f3b3ad12
[Bug target/98784] [9/10/11/12 Regression] problematic build of uClibc with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 --- Comment #13 from YannSionneau --- Created attachment 51073 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51073=edit working uClibc build This is a working libc build, that allows to boot Linux, run init, daemons and get to usual shell prompt.
[Bug c++/58487] Missed return value optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58487
Antony Polukhin changed:
What|Removed |Added
CC||antoshkka at gmail dot com
--- Comment #3 from Antony Polukhin ---
Minimized example, move constructor should not be called:
struct A {
A() = default;
A(A&&);
};
A test() {
if (true) {
A a;
return a;
} else {
return A{};
}
}
Godbolt playground: https://godbolt.org/z/4Pzq83WWY
[Bug c++/58050] No return value optimization when calling static function through unnamed temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58050 Antony Polukhin changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #1 from Antony Polukhin --- This was fixed in GCC-10.1 https://godbolt.org/z/b4ohfnK3x
[Bug ipa/93385] [10/11/12 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #46 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:2902991a6b61d473f7cb996a2b80eef4a90f8eda commit r12-1848-g2902991a6b61d473f7cb996a2b80eef4a90f8eda Author: Martin Jambor Date: Mon Jun 28 18:20:00 2021 +0200 ipa-sra: Introduce a mini-DCE to tree-inline.c (PR 93385) I was asked by Richi to split my fix for PR 93385 for easier review into IPA-SRA materialization refactoring and the actual DCE addition. This is the second part that actually contains the DCE of statements that IPA-SRA should not leave behind because they can have problematic side effects, even if they are useless, so that we do not depend on tree-dce to remove them for correctness. The patch fixes the problem by doing a def-use walk when materializing clones, marking which statements should not be copied and which SSA_NAMEs do not need to be computed because eventually they would be DCEd. We do this on the original function body and tree-inline simply does not copy statements which are "dead." The only complication is removing dead argument calls because that needs to be communicated to callee redirection code using the infrastructure introduced by the previous patch. I added all testcases of the original patch to this one, although some probably test behavior introduced in the previous patch. gcc/ChangeLog: 2021-05-12 Martin Jambor PR ipa/93385 * ipa-param-manipulation.h (class ipa_param_body_adjustments): New members m_dead_stmts and m_dead_ssas. * ipa-param-manipulation.c (ipa_param_body_adjustments::mark_dead_statements): New function. (ipa_param_body_adjustments::common_initialization): Call it on all removed but not split parameters. (ipa_param_body_adjustments::ipa_param_body_adjustments): Initialize new mwmbers. (ipa_param_body_adjustments::modify_call_stmt): Remove arguments that are dead. * tree-inline.c (remap_gimple_stmt): Do not copy dead statements, reset dead debug statements. (copy_phis_for_bb): Do not copy dead PHI nodes. gcc/testsuite/ChangeLog: 2021-03-22 Martin Jambor PR ipa/93385 * gcc.dg/ipa/pr93385.c: New test. * gcc.dg/ipa/ipa-sra-23.c: Likewise. * gcc.dg/ipa/ipa-sra-24.c: Likewise. * g++.dg/ipa/ipa-sra-4.C: Likewise.
[Bug ipa/93385] [10/11/12 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #45 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:87467f45e831e8e943efdae8920453741986d355 commit r12-1847-g87467f45e831e8e943efdae8920453741986d355 Author: Martin Jambor Date: Mon Jun 28 18:20:00 2021 +0200 ipa-sra: Restructure how cloning and call redirection communicate (PR 93385) I was asked by Richi to split my fix for PR 93385 for easier review into IPA-SRA materialization refactoring and the actual DCE addition. Fortunately it was mostly natural except for a temporary weird condition in ipa_param_body_adjustments::modify_call_stmt. Additionally. In addition to the patch I posted previously, this one also deallocated the newly added summary in toplev::finalize and fixes a mistakenly uninitialized field. This is the first part which basically replaces performed_splits in clone_info and the code which generates it, keeps it up-to-date and consumes it with new edge summaries which are much nicer. It simply contains 1) a mapping from the original argument indices to the actual indices in the call statement as it is now, 2) information needed to identify arguments representing pass-through IPA-SRA splits with which have been added to the call arguments in place of an original argument/reference and 3) a delta to the index where va_args may start - so basically directly all the information that the consumer of performed_splits had to compute and we also do not need the weird dummy declarations. The main disadvantage is that the information has to be created (and kept up-to-date) for all call graph edges associated with the given statement from all clones (including inline clones) of the clone where splitting or removal happened first. But all of this happens during clone materialization so the only effect on WPA memory consumption is the removal of a pointer from clone_info. The statement modification code also has to know the statement from the original function in order to be able to locate the edge summaries which at this point are still keyed to these. However, the code is already quite heavily dependant on how things are structured in tree-inline.c and in order to fix bugs like these it probably has to be. The subsequent patch needs this new information to be able to remove arguments from calls during materialization and communicate this information to the call redirection. gcc/ChangeLog: 2021-05-17 Martin Jambor PR ipa/93385 * symtab-clones.h (clone_info): Removed member param_adjustments. * ipa-param-manipulation.h: Adjust initial comment to reflect how we deal with pass-through splits now. (ipa_param_performed_split): Removed. (ipa_param_adjustments::modify_call): Adjusted parameters. (class ipa_param_body_adjustments): Adjusted parameters of register_replacement, modify_gimple_stmt and modify_call_stmt. (ipa_verify_edge_has_no_modifications): Declare. (ipa_edge_modifications_finalize): Declare. * cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Remove performed_splits processing, pas only edge to padjs->modify_call, check that call arguments were not modified if they should not have been. * cgraphclones.c (cgraph_node::create_clone): Do not copy performed splits. * ipa-param-manipulation.c (struct pass_through_split_map): New type. (ipa_edge_modification_info): Likewise. (ipa_edge_modification_sum): Likewise. (ipa_edge_modifications): New edge summary. (ipa_verify_edge_has_no_modifications): New function. (transitive_split_p): Removed. (transitive_split_map): Likewise. (init_transitive_splits): Likewise. (ipa_param_adjustments::modify_call): Adjusted to use the new edge summary instead of performed_splits. (ipa_param_body_adjustments::register_replacement): Drop dummy parameter, set base_index of the created ipa_param_body_replacement. (phi_arg_will_live_p): New function. (ipa_param_body_adjustments::common_initialization): Do not create IPA_SRA dummy decls. (simple_tree_swap_info): Removed. (remap_split_decl_to_dummy): Likewise. (record_argument_state_1): New function. (record_argument_state): Likewise. (ipa_param_body_adjustments::modify_call_stmt): New parameter orig_stmt. Do not work with dummy decls, save necessary info about changes to ipa_edge_modifications. (ipa_param_body_adjustments::modify_gimple_stmt): New parameter orig_stmt, pass
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
--- Comment #30 from Vincent Lefèvre ---
(In reply to Matthias Kretz (Vir) from comment #29)
> Right. But if that's the case wouldn't a warning about the unexpected
> promotion be useful? (which -Wsign-compare happens to provide)
Yes, and FYI, there were such platform-dependent bugs in GNU MPFR in the past
involving additions or subtractions (not comparisons). I added the following in
its README.dev file:
--
Avoid mixing signed and unsigned integer types, as this can lead signed
types to be automatically converted into unsigned types (usual arithmetic
conversions). If such a signed type contains a negative value, the result
may be incorrect on some platforms. With MPFR 2.x, this problem could
arise with mpfr_exp_t, which is signed, and mpfr_prec_t (mp_prec_t),
which was unsigned (it is now signed), meaning that in general, a cast
of a mpfr_prec_t to a mpfr_exp_t was needed.
Note that such bugs are difficult to detect because they may depend on
the platform (e.g., on LP64, 32-bit unsigned int + 64-bit long will give
a signed type, but on ILP32, 32-bit int + 32-bit unsigned long will give
an unsigned type, which may not be what is expected), but also on the
input values. So, do not rely on tests very much. However, if a test
works on 32 bits but fails on 64 bits in the extended exponent range
(or conversely), the cause may be related to the integer types (e.g. a
signness problem or an integer overflow due to different type sizes).
For instance, in MPFR, such issues were fixed in r1992 and r5588.
An example that will fail with 32-bit int and long:
long long umd(void)
{
long a = 1;
unsigned int b = 2;
return a - b;
}
--
So a warning for such operations would also be useful. But I'm not sure about
potential issues with false positives...
[Bug c++/101241] Internal compiler error from MathFunctions.h in the eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101241 --- Comment #3 from Marek Polacek --- I cannot reproduce this: $ xg++ -c a-eigen_bug.ii -O3 -ffast-math -march=haswell compiles.
[Bug libstdc++/97088] 17_intro/names.cc and experimental/names.cc fail with --disable-libstdcxx-pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:75f948f089cebfd00913635264e20610d0f2 commit r12-1845-g75f948f089cebfd00913635264e20610d0f2 Author: Jonathan Wakely Date: Mon Jun 28 15:13:34 2021 +0100 libstdc++: Fix backwards logic in 17_intro/names.cc test [PR 97088] I meant to undef the names that clash with newlib headers for newlib, but I only undef'd them for non-newlib targets. This means they still cause errors for newlib, and aren't tested for other targets. This fixes the test to check those names for non-newlib targets, and to undef them to avoid errors for newlib. libstdc++-v3/ChangeLog: PR libstdc++/97088 * testsuite/17_intro/names.cc: Fix #if condition for names used by newlib headers.
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470 --- Comment #29 from Matthias Kretz (Vir) --- (In reply to Vincent Lefèvre from comment #28) > (In reply to Matthias Kretz (Vir) from comment #27) > > Fair enough. But how can the compiler be certain that the developer realized > > u and u % 100 is unsigned? Maybe when (s)he wrote the code the expectation > > was for the RHS to be within [-99..99]. > > Indeed. (I never use % when its LHS can be either positive or negative, so > that I didn't think about this case.) FWIW, personally I could use a warning whenever I use % on variables that can potentially be negative. Because my mental model of % N is that I get a result in [0..N-1]. I tried to fix it but my head is stubborn. ;) > Now, the cause of the bug in such a case would be that the user messed up > with the signedness of u, not because he forgot about the promotion rule. > This is something rather different. Right. But if that's the case wouldn't a warning about the unexpected promotion be useful? (which -Wsign-compare happens to provide) To reduce the noise, I won't argue this point any further and let whoever actually implements a fix for the PR decide. :)
[Bug c++/101241] Internal compiler error from MathFunctions.h in the eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101241 --- Comment #2 from Raymond Langer --- Created attachment 51072 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51072=edit preprocessed output
[Bug libstdc++/101231] _CachedPosition::_M_get() should not return {} when range adapter does not model forward_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101231 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-28 Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470 --- Comment #28 from Vincent Lefèvre --- (In reply to Matthias Kretz (Vir) from comment #27) > Fair enough. But how can the compiler be certain that the developer realized > u and u % 100 is unsigned? Maybe when (s)he wrote the code the expectation > was for the RHS to be within [-99..99]. Indeed. (I never use % when its LHS can be either positive or negative, so that I didn't think about this case.) Now, the cause of the bug in such a case would be that the user messed up with the signedness of u, not because he forgot about the promotion rule. This is something rather different.
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470 --- Comment #27 from Matthias Kretz (Vir) --- (In reply to Vincent Lefèvre from comment #26) > But if I understand Piotr Engelking's point, UINT_MAX + 1 + s is not in the > range 0..SHRT_MAX mentioned above, thus cannot be equal to u % 100. Said > otherwise, the promotion has no visible effect here (if s is negative, then > the comparison will be false, as if promotion did not occur), so that there > is no need to warn. Fair enough. But how can the compiler be certain that the developer realized u and u % 100 is unsigned? Maybe when (s)he wrote the code the expectation was for the RHS to be within [-99..99]. > That said, this is very specific code, and it might not be worth to handle > it. And IMHO, this is more than what this PR is about. I tend to agree. It's a slightly different problem and IMHO not a 100% obvious false positive. I believe this PR should be about dropping the warning where signed -> unsigned promotion or implicit conversion cannot change the value because the value range of the signed variable is limited to values >= 0.
[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223 --- Comment #7 from Andrew Macleod --- I think this is our old friend 1-bit signed overflow. for 1 signed bit values, varying is [-1, 0] range-op::build_lt checks to see if UB - 1 overflows, and if it does, then the result is undefined. wi::sub sets the overflow flag for 0 - 1 with 1 bit signed... so the comparison ends up being undefined, and we then make incorrect choices because we think we can. I think we need to, yet again, special case 1-bit signed values here, and probably in build_gt as well.
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470 --- Comment #26 from Vincent Lefèvre --- (In reply to Matthias Kretz (Vir) from comment #25) > (In reply to Piotr Engelking from comment #24) > > It would be nice if the compiler noticed that rhs is always within > > 0..SHRT_MAX, so the comparison is not surprisingly affected by integer ^^^ > > promotion. > > The problem is the LHS which can be negative and has to be promoted to > `unsigned int`. This promotion changes the value from s to UINT_MAX + 1 + s. > I don't think this example is a case where -Wsign-compare should be silent. But if I understand Piotr Engelking's point, UINT_MAX + 1 + s is not in the range 0..SHRT_MAX mentioned above, thus cannot be equal to u % 100. Said otherwise, the promotion has no visible effect here (if s is negative, then the comparison will be false, as if promotion did not occur), so that there is no need to warn. That said, this is very specific code, and it might not be worth to handle it. And IMHO, this is more than what this PR is about.
[Bug c++/101241] Internal compiler error from MathFunctions.h in the eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101241 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Can you provide the preprocessed source? Use -save-temps to get it.
[Bug libgomp/100753] Implement in_reduction clause on target construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100753 --- Comment #2 from Tobias Burnus --- Additionally missing: Fortran support.
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470 --- Comment #25 from Matthias Kretz (Vir) --- (In reply to Piotr Engelking from comment #24) > It would be nice if the compiler noticed that rhs is always within > 0..SHRT_MAX, so the comparison is not surprisingly affected by integer > promotion. The problem is the LHS which can be negative and has to be promoted to `unsigned int`. This promotion changes the value from s to UINT_MAX + 1 + s. I don't think this example is a case where -Wsign-compare should be silent.
[Bug c++/101244] Wrong path in coroutine returning ternary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101244 --- Comment #1 from Victor Burckel --- If ternary is not put in the co_return part but split into assignement return, the compiler crashes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101149
[Bug c++/101244] New: Wrong path in coroutine returning ternary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101244
Bug ID: 101244
Summary: Wrong path in coroutine returning ternary
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: victor.burckel at gmail dot com
Target Milestone: ---
In a coroutine returning a ternary expression with co_await, the co_await part
seems to be evaluated whatever the result of the condition:
See it on godbolt, I added a check of coro.done in the resume operation to
avoid a crash in the clang part as the coroutine is voluntarily resumed one
extra time
https://godbolt.org/z/vzGKoP8d3
#include
#include
#include
#ifdef __clang__
namespace std::experimental {
using std::coroutine_handle;
using std::coroutine_traits;
} // namespace std::experimental
#endif
struct task {
struct promise_type;
using handle_type = std::coroutine_handle;
struct promise_type {
auto initial_suspend() noexcept { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_value(int v) noexcept { value = v; }
task get_return_object() noexcept {
return task{handle_type::from_promise(*this)};
}
void unhandled_exception() noexcept {}
int value{};
};
task(handle_type h) : h{h} {}
~task() {
if (h) {
fmt::print("destroying coroutine\n");
h.destroy();
fmt::print("coroutine destroyed\n");
}
}
bool await_ready() const noexcept { return false; }
bool await_suspend(std::coroutine_handle<>) noexcept {
h.resume();
return true;
}
int await_resume() noexcept { return h.promise().value; }
void resume() {
if (!h.done()) h.resume();
}
handle_type h;
};
struct S {
S() { fmt::print("S::S()\n"); }
S(const S&) { fmt::print("S::S(const S&)\n"); }
S(S&&) { fmt::print("S::S(S&&)\n"); }
~S() { fmt::print("S::~S()\n"); }
};
task g(S) {
fmt::print("in g()\n");
co_return 1;
}
task f(bool b) {
fmt::print("calling g()\n");
co_return b ? co_await g(S{}) : 2;
}
int main() {
auto task = f(false);
fmt::print("resuming f\n");
task.resume();
fmt::print("resuming f\n");
task.resume();
}
Gcc outputs
resuming f
calling g()
S::S()
S::S(S&&)
in g()
resuming f
destroying coroutine
S::~S()
coroutine destroyed
S::~S()
destroying coroutine
coroutine destroyed
While clang outputs
resuming f
calling g()
resuming f
destroying coroutine
coroutine destroyed
[Bug c++/101243] Coroutine lambda capture is destroyed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101243 --- Comment #1 from Victor Burckel --- May be similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401
[Bug c++/101243] New: Coroutine lambda capture is destroyed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101243
Bug ID: 101243
Summary: Coroutine lambda capture is destroyed twice
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: victor.burckel at gmail dot com
Target Milestone: ---
In a corourtine expecting a std::function parameter, passing a
temporary lambda with a capture results in the capture being destroyed twice:
See it on gldbolt, gcc vs clang outputs
https://godbolt.org/z/jx9Yh5cqM
#include
#include
#include
#ifdef __clang__
namespace std::experimental {
using std::coroutine_handle;
using std::coroutine_traits;
} // namespace std::experimental
#endif
struct task {
struct promise_type;
using handle_type = std::coroutine_handle;
struct promise_type {
auto initial_suspend() noexcept { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_void() noexcept {}
task get_return_object() noexcept {
return task{handle_type::from_promise(*this)};
}
void unhandled_exception() noexcept {}
};
task(handle_type h) : h{h} {}
~task() {
if (h) {
fmt::print("destroying coroutine\n");
h.destroy();
fmt::print("coroutine destroyed\n");
}
}
bool await_ready() const noexcept { return false; }
bool await_suspend(std::coroutine_handle<>) noexcept {
h.resume();
return true;
}
void await_resume() noexcept {}
void resume() { h.resume(); }
handle_type h;
};
struct S {
S() { fmt::print("S::S()\n"); }
S(const S&) { fmt::print("S::S(const S&)\n"); }
S(S&&) { fmt::print("S::S(S&&)\n"); }
~S() { fmt::print("S::~S()\n"); }
};
task g(std::function) {
fmt::print("in g()\n");
co_return;
}
task f() {
fmt::print("calling g()\n");
co_await g([s=S{}] {});
fmt::print("g called\n");
}
int main() {
auto task = f();
fmt::print("resuming f\n");
task.resume();
fmt::print("resuming f\n");
task.resume();
}
Gcc outputs:
resuming f
calling g()
S::S()
S::S(S&&)
in g()
resuming f
destroying coroutine
S::~S()
coroutine destroyed
S::~S()
S::~S()
g called
destroying coroutine
coroutine destroyed
While clang outputs:
resuming f
calling g()
S::S()
S::S(S&&)
in g()
resuming f
destroying coroutine
S::~S()
coroutine destroyed
S::~S()
g called
destroying coroutine
coroutine destroyed
[Bug tree-optimization/101242] Segfault in SLP vectorizor after g:2ad71efb5de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101242 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|Segfault in SLP vectorizor |Segfault in SLP vectorizor |after 2ad71efb5de |after g:2ad71efb5de Status|UNCONFIRMED |NEW Last reconfirmed||2021-06-28 CC||marxin at gcc dot gnu.org Target Milestone|--- |12.0 --- Comment #2 from Martin Liška --- Confirmed.
[Bug tree-optimization/101242] Segfault in SLP vectorizor after 2ad71efb5de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101242
--- Comment #1 from Martin Jambor ---
For the reference, this is the backtrace:
mjambor@virgil:/tmp/bbb$ ~/gcc/trunk/inst/bin/gcc -S -Ofast test.i
during GIMPLE pass: slp
test.i: In function ‘check_su3’:
test.i:11:5: internal compiler error: Segmentation fault
11 | int check_su3() {
| ^
0x12ad5a0 crash_signal
/home/mjambor/gcc/trunk/src/gcc/toplev.c:327
0x162643d vec<_stmt_vec_info*, va_heap, vl_embed>::iterate(unsigned int,
_stmt_vec_info**) const
/home/mjambor/gcc/trunk/src/gcc/vec.h:932
0x1625168 vec<_stmt_vec_info*, va_heap, vl_ptr>::iterate(unsigned int,
_stmt_vec_info**) const
/home/mjambor/gcc/trunk/src/gcc/vec.h:1698
0x166d14d vect_optimize_slp(vec_info*)
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:3992
0x1672d1e vect_slp_analyze_bb_1
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:5621
0x1673111 vect_slp_region
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:5708
0x1673bba vect_slp_bbs
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:5858
0x1674063 vect_slp_function(function*)
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:5944
0x168f92b execute
/home/mjambor/gcc/trunk/src/gcc/tree-vectorizer.c:1445
Please submit a full bug report...
[Bug tree-optimization/101242] New: Segfault in SLP vectorizor after 2ad71efb5de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101242
Bug ID: 101242
Summary: Segfault in SLP vectorizor after 2ad71efb5de
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
Since commit 2ad71efb5de (fix BB reduc permute elide with life stmts), the
following testcase (reduced from 433.milc) ICEs for me when compiled at -Ofast
(on x86_64-linux with generic march):
typedef struct {
double real;
double imag;
} complex;
typedef struct {
complex e[3][3];
} su3_matrix;
su3_matrix check_su3_c;
double check_su3_ar, check_su3_ari, check_su3_max;
int arireturn();
int check_su3() {
check_su3_ar = check_su3_c.e[0][0].real * check_su3_c.e[1][0].real +
check_su3_c.e[0][0].imag * check_su3_c.e[1][0].imag +
check_su3_c.e[0][1].real * check_su3_c.e[1][1].real +
check_su3_c.e[0][1].imag * check_su3_c.e[1][1].imag +
check_su3_c.e[0][2].real * check_su3_c.e[1][2].real +
check_su3_c.e[0][2].imag * check_su3_c.e[1][2].imag;
check_su3_max = check_su3_c.e[0][0].real * check_su3_c.e[2][0].real +
check_su3_c.e[0][0].imag * check_su3_c.e[2][0].imag +
check_su3_c.e[0][1].real * check_su3_c.e[2][1].real +
check_su3_c.e[0][1].imag * check_su3_c.e[2][1].imag +
check_su3_c.e[0][2].real * check_su3_c.e[2][2].real +
check_su3_c.e[0][2].imag * check_su3_c.e[2][2].imag;
check_su3_ari = check_su3_ar;
if (check_su3_ari)
check_su3_max = check_su3_c.e[1][0].real * check_su3_c.e[2][0].real +
check_su3_c.e[1][0].imag * check_su3_c.e[2][0].imag +
check_su3_c.e[1][1].real * check_su3_c.e[2][1].real +
check_su3_c.e[1][1].imag * check_su3_c.e[2][1].imag +
check_su3_c.e[1][2].real * check_su3_c.e[2][2].real +
check_su3_c.e[1][2].imag * check_su3_c.e[2][2].imag;
if (check_su3_max)
arireturn();
return 0;
}
[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228 Jonathan Wakely changed: What|Removed |Added Resolution|MOVED |--- Status|RESOLVED|NEW CC||rodgertq at gcc dot gnu.org --- Comment #8 from Jonathan Wakely --- Tom, it looks like that fix landed upstream after our last sync. Should we use it?
[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101236 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=50921 Status|ASSIGNED|RESOLVED --- Comment #7 from Jonathan Wakely --- Fixed to accept the bad code.
[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101236 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b7a89c041aa1d67654f1ba7b2839e221c3e14748 commit r12-1844-gb7a89c041aa1d67654f1ba7b2839e221c3e14748 Author: Jonathan Wakely Date: Mon Jun 28 12:59:19 2021 +0100 libstdc++: Allow unique_ptr::operator[] [PR 101236] PR libstdc++/101236 shows that LLVM depends on being able to use unique_ptr::operator[] when T is incomplete. This is undefined, but previously worked with libstdc++. When I added the conditional noexcept to that operator we started to diagnose the incomplete type. This change restores support for that case, by making the noexcept condition check that the type is complete before checking whether indexing on the pointer can throw. A workaround for PR c++/101239 is needed to avoid a bogus error where G++ fails to do SFINAE on the ill-formed p[n] expression and gets an ICE. Instead of checking that the p[n] expression is valid in the trailing-return-type, we only check that the element_type is complete. libstdc++-v3/ChangeLog: PR libstdc++/101236 * include/bits/unique_ptr.h (unique_ptr::operator[]): Fail gracefully if element_type is incomplete. * testsuite/20_util/unique_ptr/cons/incomplete.cc: Clarify that the standard doesn't require this test to work for array types. * testsuite/20_util/unique_ptr/lwg2762.cc: Check that incomplete types can be used with array specialization. * testsuite/20_util/unique_ptr/101236.cc: New test.
[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b7a89c041aa1d67654f1ba7b2839e221c3e14748 commit r12-1844-gb7a89c041aa1d67654f1ba7b2839e221c3e14748 Author: Jonathan Wakely Date: Mon Jun 28 12:59:19 2021 +0100 libstdc++: Allow unique_ptr::operator[] [PR 101236] PR libstdc++/101236 shows that LLVM depends on being able to use unique_ptr::operator[] when T is incomplete. This is undefined, but previously worked with libstdc++. When I added the conditional noexcept to that operator we started to diagnose the incomplete type. This change restores support for that case, by making the noexcept condition check that the type is complete before checking whether indexing on the pointer can throw. A workaround for PR c++/101239 is needed to avoid a bogus error where G++ fails to do SFINAE on the ill-formed p[n] expression and gets an ICE. Instead of checking that the p[n] expression is valid in the trailing-return-type, we only check that the element_type is complete. libstdc++-v3/ChangeLog: PR libstdc++/101236 * include/bits/unique_ptr.h (unique_ptr::operator[]): Fail gracefully if element_type is incomplete. * testsuite/20_util/unique_ptr/cons/incomplete.cc: Clarify that the standard doesn't require this test to work for array types. * testsuite/20_util/unique_ptr/lwg2762.cc: Check that incomplete types can be used with array specialization. * testsuite/20_util/unique_ptr/101236.cc: New test.
[Bug c++/101241] New: Internal compiler error from MathFunctions.h in the eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101241
Bug ID: 101241
Summary: Internal compiler error from MathFunctions.h in the
eigen library
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: r.langer at itv dot rwth-aachen.de
Target Milestone: ---
I used a docker image of Clean Linux (version 34790) and installed gcc 11.1.1
with:
swupd bundle-add c-basic wget
The following commands produce the error:
wget https://gitlab.com/libeigen/eigen/-/archive/3.4-rc1/eigen-3.4-rc1.tar.bz2
tar -xf eigen-3.4-rc1.tar.bz2
printf "#include \n int main(int,char const*[]){}\n" >
eigen_bug.cpp
g++ eigen_bug.cpp -Ieigen-3.4-rc1/ -Ofast -ffast-math
Expected output from the last command:
In file included from eigen-3.4-rc1/Eigen/Core:171,
from eigen_bug.cpp:1:
eigen-3.4-rc1/Eigen/src/Core/MathFunctions.h:1036:71: internal compiler error:
in maybe_default_option, at opts.c:332
1036 | template<> EIGEN_TMP_NOOPT_ATTRIB bool isnan_impl(const long double& x)
{ return __builtin_isnan(x); }
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
Piotr Engelking changed:
What|Removed |Added
CC||inkerman42 at gmail dot com
--- Comment #24 from Piotr Engelking ---
Created attachment 51071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51071=edit
not useful -Wsign-compare warning involving % operator
Another case where the feature would be useful:
extern int
f(short s, unsigned int u)
{
return s == u % 100;
}
It would be nice if the compiler noticed that rhs is always within 0..SHRT_MAX,
so the comparison is not surprisingly affected by integer promotion.
[Bug driver/93645] Support Clang 12 --ld-path=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645 --- Comment #10 from Martin Liška --- I replied here: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573823.html
[Bug c++/101240] New: [missed optimization] Transitivity of less-than and less-or-equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101240
Bug ID: 101240
Summary: [missed optimization] Transitivity of less-than and
less-or-equal
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kyrylo.bohdanenko at gmail dot com
Target Milestone: ---
Consider the following C++ code
#define ALWAYS_TRUE(x) do { if (x) __builtin_unreachable(); } while (false)
int divide(int a, int b) {
ALWAYS_TRUE(a == b);
return a / b;
}
void test_array(unsigned ()[3]) {
ALWAYS_TRUE(a[0] < a[1] && a[1] < a[2]);
return a[0] < a[2];
}
The first function is optimiozed away:
divide(int, int):
mov eax, 1
ret
While the second still does the comparison:
test_array(unsigned int (&) [3]):
mov eax, DWORD PTR [rdi+8]
cmp DWORD PTR [rdi], eax
setbal
ret
It would be nice if GCC could deduce that
a < b && b < c --> a < c
And optimize that second function (provided no other UB is involved)
[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101236 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Resolution|INVALID |--- --- Comment #5 from Jonathan Wakely --- I have a working workaround. The LLVM code is undefined, but we can make it work.
[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228 Pilar Latiesa changed: What|Removed |Added CC||pilarlatiesa at gmail dot com --- Comment #7 from Pilar Latiesa --- This appears to be fixed upstream: https://reviews.llvm.org/D87380
[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223 --- Comment #6 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #5) > d is not an automatic variable, so is zero initialized. Whoops. Sorry for the noise.
[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- d is not an automatic variable, so is zero initialized.
[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223 --- Comment #4 from Aldy Hernandez --- d is used before being defined. Isn't this entire test bogus?
[Bug c++/101233] ICE when using ::ranges::v3::to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101233 --- Comment #4 from 欢乐的0403 <475647575 at qq dot com> --- Good, looking forward to it being fixed.
[Bug c++/101233] ICE when using ::ranges::v3::to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101233 Martin Liška changed: What|Removed |Added Status|WAITING |NEW Keywords||ice-on-valid-code CC||jason at gcc dot gnu.org --- Comment #3 from Martin Liška --- Then let's mark it as ICE on valid code.
[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101236
Jonathan Wakely changed:
What|Removed |Added
Depends on||101239
--- Comment #4 from Jonathan Wakely ---
I tried this workaround in unique_ptr so that the undefined LLVM code would
"work" as before:
--- a/libstdc++-v3/include/bits/unique_ptr.h
+++ b/libstdc++-v3/include/bits/unique_ptr.h
@@ -491,6 +491,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
= __and_< is_base_of<_Tp, _Up>,
__not_, __remove_cv<_Up>>> >;
+ template
+ static constexpr auto
+ _S_nothrow_deref(_Ptr __p = _Ptr(), size_t __n = 0)
+ -> decltype(noexcept(__p[__n]))
+ { return noexcept(__p[__n]); }
+
+ template
+ static constexpr bool
+ _S_nothrow_deref(...)
+ { return noexcept(__p[__n]); }
+
public:
using pointer = typename __uniq_ptr_impl<_Tp, _Dp>::pointer;
using element_type = _Tp;
@@ -654,8 +665,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/// Access an element of owned array.
typename std::add_lvalue_reference::type
- operator[](size_t __i) const
- noexcept(noexcept(std::declval()[std::declval()]))
+ operator[](size_t __i) const noexcept(_S_nothrow_deref())
{
__glibcxx_assert(get() != pointer());
return get()[__i];
But this gets an ICE, see PR 101239
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239
[Bug 101239] "Internal compiler error: Error reporting routines re-entered." in
size_in_bytes_loc
[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-06-28
--- Comment #1 from Jonathan Wakely ---
This slight variation using noexcept in the trailing-return-type was
rejects-valid in 4.7 but is ice-on-valid-code from 4.8 onwards (with the same
ICE):
template
struct Blerk
{
template
static constexpr auto
type(Ptr p = Ptr(), int n = 0)
-> decltype(noexcept(p[n]))
{ return false; }
template
static constexpr int
type(...)
{ return 1; }
decltype(type()) f() const;
};
struct S;
extern Blerk p;
auto s = p.f();
struct S { };
[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101236 --- Comment #3 from Martin Liška --- All right, thanks Jonathan. I've just created LLVM bug for it: https://bugs.llvm.org/show_bug.cgi?id=50921
[Bug c++/101239] New: "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239
Bug ID: 101239
Summary: "Internal compiler error: Error reporting routines
re-entered." in size_in_bytes_loc
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This valid code produces an ICE:
template
struct Blerk
{
template
static constexpr auto
type(Ptr p = Ptr(), int n = 0)
-> decltype(p[n])
{ return false; }
template
static constexpr int
type(...)
{ return 1; }
decltype(type()) f() const;
};
struct S;
extern Blerk p;
auto s = p.f();
struct S { };
ice.C: In substitution of 'template static constexpr decltype (p[n])
Blerk::type(Ptr, int) [with Ptr = S (*)[]]':
ice.C:15:20: required from 'struct Blerk'
ice.C:20:11: required from here
ice.C:7:18: error: invalid use of array with unspecified bounds
7 | -> decltype(p[n])
| ~^
ice.C: In instantiation of 'struct Blerk':
ice.C:20:11: required from here
ice.C:15:20: error: call of overloaded 'type()' is ambiguous
15 | decltype(type()) f() const;
|^~
'
Internal compiler error: Error reporting routines re-entered.
0x138c3fd size_in_bytes_loc(unsigned int, tree_node const*)
/home/jwakely/src/gcc/gcc/gcc/tree.c:3486
0x138c3fd size_in_bytes_loc(unsigned int, tree_node const*)
/home/jwakely/src/gcc/gcc/gcc/tree.c:3474
0xb5b6ec pointer_int_sum(unsigned int, tree_code, tree_node*, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/c-family/c-common.c:3301
0xb3b078 cp_build_array_ref(unsigned int, tree_node*, tree_node*, int)
/home/jwakely/src/gcc/gcc/gcc/cp/typeck.c:3708
0x8f2036 build_new_op_1
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6743
0x8f25ad build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6772
0xb295df build_x_array_ref(unsigned int, tree_node*, tree_node*, int)
/home/jwakely/src/gcc/gcc/gcc/cp/typeck.c:4385
0xaa51b4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:19874
0xac2677 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:16119
0x9b0580 dump_template_bindings
/home/jwakely/src/gcc/gcc/gcc/cp/error.c:482
0x9a9ba7 dump_substitution
/home/jwakely/src/gcc/gcc/gcc/cp/error.c:1638
0x9a9ba7 dump_substitution
/home/jwakely/src/gcc/gcc/gcc/cp/error.c:1630
0x9a9ba7 dump_function_decl
/home/jwakely/src/gcc/gcc/gcc/cp/error.c:1796
0x9b1a18 decl_to_string
/home/jwakely/src/gcc/gcc/gcc/cp/error.c:3216
0x9b1a18 cp_printer
/home/jwakely/src/gcc/gcc/gcc/cp/error.c:4389
0x1c6ed6c pp_format(pretty_printer*, text_info*)
/home/jwakely/src/gcc/gcc/gcc/pretty-print.c:1475
0x1c52850 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/jwakely/src/gcc/gcc/gcc/diagnostic.c:1275
0x1c556b7 diagnostic_impl
/home/jwakely/src/gcc/gcc/gcc/diagnostic.c:1437
0x1c556b7 inform(unsigned int, char const*, ...)
/home/jwakely/src/gcc/gcc/gcc/diagnostic.c:1516
0x8e1cb6 print_z_candidate
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:3782
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/101235] [11/12 Regression] Fails to bootstrap with binutils 2.32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101235 --- Comment #4 from Segher Boessenkool --- (In reply to Kewen Lin from comment #3) > Will backport the fix after 2021 July 7th (two weeks since it's into trunk) > if this isn't urgent meanwhile got the backport approval. The reason to not backport immediately is because you end up with a royal mess if your patch causes regressions. A week is normally plenty: there will be lots of test results that can give you confidence things work. If a patch caused build failures, we want that fixed as soon as possible, because we will not have test results at all otherwise :-)
[Bug c++/101233] ICE when using ::ranges::v3::to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101233 --- Comment #2 from 欢乐的0403 <475647575 at qq dot com> --- This stumps me. I don't know if the code is valid or not. But these code compiles: v | ::ranges::v3::to; v | ::ranges::v3::to_vector; So I guess the code is more likely to be valid?
[Bug middle-end/101237] HONOR_SIGNED_ZEROS (element_mode (t)) should be moved to just HONOR_SIGNED_ZEROS (t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101237 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-28 --- Comment #1 from Andrew Pinski --- Looks like when HONOR_SIGNED_ZEROS of tree was added in r5-5768, a grep was done on HONOR_SIGNED_ZEROS but for TYPE_MODE and had missed the grep on element_mode . Mine.
[Bug tree-optimization/101229] [11 Regression] ICE on valid code with -O3 only: in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101229 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||12.0 Known to fail||11.1.0 Target Milestone|--- |11.2 Summary|ICE on valid code with -O3 |[11 Regression] ICE on |only: in|valid code with -O3 only: |vect_get_vec_defs_for_opera |in |nd, at |vect_get_vec_defs_for_opera |tree-vect-stmts.c:1450 |nd, at ||tree-vect-stmts.c:1450
[Bug tree-optimization/101229] ICE on valid code with -O3 only: in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101229 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f80c4eaca0805bc9e68ed944519519c3dd1c12e1 commit r12-1840-gf80c4eaca0805bc9e68ed944519519c3dd1c12e1 Author: Richard Biener Date: Mon Jun 28 11:05:46 2021 +0200 tree-optimization/101229 - fix vectorizer SLP hybrid detection with PHIs This fixes the missing handling of PHIs in gimple_walk_op which causes the new vectorizer SLP hybrid detection scheme to fail. 2021-06-28 Richard Biener PR tree-optimization/101229 * gimple-walk.c (gimple_walk_op): Handle PHIs. * gcc.dg/torture/pr101229.c: New testcase.
[Bug driver/101238] New: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101238 Bug ID: 101238 Summary: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- Created attachment 51070 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51070=edit Use -D__USE_MINGW_ACCESS when compiling the driver. Summary: one needs to add CXXFLAGS+=-D__USE_MINGW_ACCESS to config/mh-mingw so that the driver finds executables on Windows. This is already fixed in GCC 11, but not in GCC 10. More details: GCC 10 driver is compiled with g++ without-D__USE_MINGW_ACCESS on MinGW. That option is only added to CFLAGS, but not CXXFLAGS. Consequently, the driver will not find executables such as cc1, because access(,X_OK) will always return an error on Windows, as access() on Windows does not check for executability anymore. With __USE_MINGW_ACCESS, MinGW will use its own implementation of access() which for X_OK behaves the same as R_OK. I've tested the (trivial) attached patch and it resolved the issue on my system as expected.
[Bug middle-end/101237] New: HONOR_SIGNED_ZEROS (element_mode (t)) should be moved to just HONOR_SIGNED_ZEROS (t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101237 Bug ID: 101237 Summary: HONOR_SIGNED_ZEROS (element_mode (t)) should be moved to just HONOR_SIGNED_ZEROS (t) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- This was found really because I copied the code from fold-const.c to match.pd and there was a requested change as HONOR_SIGNED_ZEROS now handles tree types too. See https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573811.html from a quick grep I find: fold-const.c: || HONOR_SIGNED_ZEROS (element_mode (type)) fold-const.c:&& !HONOR_SIGNED_ZEROS (element_mode (type)) fold-const.c: && !HONOR_SIGNED_ZEROS (element_mode (type))) fold-const.c: && !HONOR_SIGNED_ZEROS (element_mode (type))) fold-const.c: if (!HONOR_SIGNED_ZEROS (element_mode (type)) fold-const.c: if (!HONOR_SIGNED_ZEROS (element_mode (type)) fold-const.c: if (!HONOR_SIGNED_ZEROS (element_mode (type)) fold-const.c: && !HONOR_SIGNED_ZEROS (element_mode (arg0)) fold-const.c: && !HONOR_SIGNED_ZEROS (element_mode (arg0)) fold-const.c: && !HONOR_SIGNED_ZEROS (element_mode (arg0)) fold-const.c: && !HONOR_SIGNED_ZEROS (element_mode (op1))) fold-const.c: && !HONOR_SIGNED_ZEROS (element_mode (op2))) fold-const.c: if (!HONOR_SIGNED_ZEROS (element_mode (type)))
[Bug libgomp/100753] Implement in_reduction clause on target construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100753 --- Comment #1 from Jakub Jelinek --- Partly implemented in r12-1768-g7619d33471c10fe3d149dcbb701d99ed3dd23528 In particular the in_reduction without nowait is implemented and for nowait there is a hack - presence of in_reduction acts as if nowait wasn't present. That is hopefully valid, but certainly not desirable state, so extra work is needed to make it work efficiently.
[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101236 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Jonathan Wakely --- You can use incomplete types with std::unique_ptr but the array specialization, std::unique_ptr, requires T to be a complete type. See [unique.ptr.runtime.general] p3 in the C++ standard. That requirement has been there since std::unique_ptr was added in C++11. So the code is invalid. LLVM needs to ensure the type is complete, or not use std::unique_ptr there.
[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228 --- Comment #6 from Jonathan Wakely --- There's no easy solution. Intel contributed the PSTL headers with a dependency on TBB task.h header, then deprecated that header in a later TBB release. You need to either use an older TBB, or suppress the warning. There is a plan to add an OpenMP backend to PSTL, which will remove the TBB dependency, but it's not ready yet.
