[Bug target/92473] test pr92324-2.c fails on arm and aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92473 --- Comment #5 from Richard Biener --- Author: rguenth Date: Wed Nov 13 08:04:31 2019 New Revision: 278113 URL: https://gcc.gnu.org/viewcvs?rev=278113&root=gcc&view=rev Log: 2019-11-13 Richard Biener PR tree-optimization/92473 * tree-vect-loop.c (vect_create_epilog_for_reduction): Perform direct optab reduction in the correct type. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug libgomp/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92305
--- Comment #15 from Tobias Burnus ---
The mentioned patch (for a related case but not relevant for this bug) is now
committed as r278114, see
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00990.html
Regarding the issue in this bug: Janne pointed out that
powerpc64le-unknown-linux-gnu is LE and (segher:)
"it is obviously ELFv2 code" / "so, it's LE". Which means the endian issue is
not the problem.
The data type matches caller and callee as far as I debugged (looking at the
source code and debug_tree). (Namely, all Boolean arguments are one-byte
types.) New hypothesis:
00:28 < segher> there are only 8 integer argument registers; everything after
that goes in memory
00:28 < segher> in your testcase, two things are passed via memory
00:29 < segher> those are of course suspicious, but it could be something else
entirely that is going wrong
I created a C test case, which is very similar (esp. on -O0
-fdump-tree-optimized level, Fortran has more of insn in the -fdump-rtl-expand)
and the C one works. Maybe it helps someone to understand the issue better; it
didn't help me so far. – Fortran example is in Comment 9, C example is here:
#include
#include
void callee(double aa, double bb, void *c_aptr, void *c_bptr, double **aptr,
double **bptr, bool _aa, bool _bb, bool _c_aptr, bool _c_bptr) {
if (!_c_aptr | !_c_bptr) abort();
}
void caller() {
double aa, bb;
void *c_aptr, *c_bptr;
double *aptr, *bptr;
callee (aa, bb, c_aptr, c_bptr, &aptr, &bptr, true, true, true, true);
}
int main() {
caller();
return 0;
}
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055 --- Comment #9 from Georg-Johann Lay --- Author: gjl Date: Wed Nov 13 08:18:35 2019 New Revision: 278115 URL: https://gcc.gnu.org/viewcvs?rev=278115&root=gcc&view=rev Log: PR target/92055 * config/avr/t-avr (avr-mcus): Do not depend on $(srcdir)/config/avr/t-multilib. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/t-avr
[Bug c/92479] missing warnings for unreachable codes with -Wunreachable-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479 --- Comment #3 from tangyixuan --- (In reply to Andrew Pinski from comment #1) > The code for Wunreachable-code was removed a long time ago (around 5-10 > years ago). Thanks for your time, Andrew. I didn't notice that the -Wunreachable-code is ignored by GCC now. Maybe the other flag could do this.
[Bug target/92492] New: [AVX512F] Icc generate much better code for loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92492
Bug ID: 92492
Summary: [AVX512F] Icc generate much better code for loop
vectorization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com
Target Milestone: ---
Target: i386, x86-64
Created attachment 47231
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47231&action=edit
testcase cut from 525.x264_r
for simple testcase
cat test.c:
typedef unsigned char uint8_t;
static inline uint8_t x264_clip_uint8( int x )
{
return x&(~63) ? (-x)>>7 : x;
}
void mc_weight( uint8_t *dst, uint8_t *src, int i_width, int i_height )
{
for( int x = 0; x < i_width; x++ )
dst[x] = x264_clip_uint8(src[x]);
}
Refer to
https://godbolt.org/z/TnACA-
Icc generate much better code by using vptestmd and maskmov
gcc loop:
vmovdqu8(%rsi,%rax), %ymm6
vpmovzxbw %xmm6, %ymm3
vpmovzxwd %xmm3, %ymm0
vextracti128$0x1, %ymm3, %xmm3
vpand %ymm5, %ymm0, %ymm9
vpmovzxwd %xmm3, %ymm3
vextracti128$0x1, %ymm6, %xmm2
vpcmpd $0, %ymm4, %ymm9, %k0
vpmovzxbw %xmm2, %ymm2
vpand %ymm5, %ymm3, %ymm9
vpcmpd $0, %ymm4, %ymm9, %k1
vpmovzxwd %xmm2, %ymm1
vextracti128$0x1, %ymm2, %xmm2
vpand %ymm5, %ymm1, %ymm9
vpmovzxwd %xmm2, %ymm2
vpcmpd $0, %ymm4, %ymm9, %k2
vpand %ymm5, %ymm2, %ymm9
kunpckbw%k0, %k1, %k0
vpcmpd $0, %ymm4, %ymm9, %k1
vpsubd %ymm0, %ymm4, %ymm0
vpsubd %ymm3, %ymm4, %ymm3
vpsubd %ymm1, %ymm4, %ymm1
vpsubd %ymm2, %ymm4, %ymm2
kunpckbw%k2, %k1, %k1
kunpckwd%k0, %k1, %k1
vpermt2w%ymm3, %ymm8, %ymm0
vpermt2w%ymm2, %ymm8, %ymm1
vpsraw $7, %ymm0, %ymm0
vpsraw $7, %ymm1, %ymm1
vpand %ymm0, %ymm7, %ymm0
vpand %ymm1, %ymm7, %ymm1
vpackuswb %ymm1, %ymm0, %ymm0
vpermq $216, %ymm0, %ymm0
vmovdqu8%ymm6, %ymm0{%k1}
vmovdqu8%ymm0, (%rdi,%rax)
addq$32, %rax
cmpq%rcx, %rax
icc loop:
--
vpmovzxbd (%rsi,%r8), %ymm3 #12.31
vptestmd %ymm1, %ymm3, %k1 #5.12
vpsubd%ymm3, %ymm0, %ymm2 #12.31
vpsrad$7, %ymm2, %ymm3{%k1} #12.31
vpmovdb %ymm3, (%r8,%rdi) #12.6
addq $8, %r8 #11.2
cmpq %rcx, %r8 #11.2
jb..B1.7# Prob 82% #11.2
--
origin case cut from SPEC2017 525.x264_r, refer to attachment
[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206 --- Comment #10 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Wed Nov 13 08:42:56 2019 New Revision: 278119 URL: https://gcc.gnu.org/viewcvs?rev=278119&root=gcc&view=rev Log: [C++] Fix interaction between aka changes and DR1558 (PR92206) One of the changes in r277281 was to make the typedef variant handling in strip_typedefs pass the raw DECL_ORIGINAL_TYPE to the recursive call, instead of applying TYPE_MAIN_VARIANT first. This PR shows that that interacts badly with the implementation of DR1558, because we then refuse to strip aliases with dependent template parameters and trip: gcc_assert (!typedef_variant_p (result) || ((flags & STF_USER_VISIBLE) && !user_facing_original_type_p (result))); Keeping the current behaviour but suppressing the ICE leads to a duplicate error (the dg-bogus in the first test), so that didn't seem like a good fix. I assume keeping the alias should never actually be necessary for DECL_ORIGINAL_TYPEs, because it will already have been checked somewhere, even for implicit TYPE_DECLs. This patch therefore passes a flag to say that we can safely strip aliases with dependent template parameters. 2019-11-13 Richard Sandiford gcc/cp/ PR c++/92206 * cp-tree.h (STF_STRIP_DEPENDENT): New constant. * tree.c (strip_typedefs): Add STF_STRIP_DEPENDENT to the flags when calling strip_typedefs recursively on a DECL_ORIGINAL_TYPE. Don't apply the fix for DR1558 in that case; allow aliases with dependent template parameters to be stripped instead. gcc/testsuite/ PR c++/92206 * g++.dg/cpp0x/alias-decl-pr92206-1.C: New test. * g++.dg/cpp0x/alias-decl-pr92206-2.C: Likewise. * g++.dg/cpp0x/alias-decl-pr92206-3.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-pr92206-1.C trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-pr92206-2.C trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-pr92206-3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/92493] New: ICE in get_origin_and_offset at gimple-ssa-sprintf.c:2314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92493
Bug ID: 92493
Summary: ICE in get_origin_and_offset at
gimple-ssa-sprintf.c:2314
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
Happens with x86_64-linux-gnu cross compiler:
$ riscv64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr83312.c -Wrestrict -Og
-finline-functions-called-once
during GIMPLE pass: strlen
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr83312.c: In function
‘ptlrpcd_addref’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr83312.c:27:6: internal
compiler error: Segmentation fault
27 | void ptlrpcd_addref(void) {
| ^~
0xa76e8f crash_signal
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/toplev.c:328
0x7f26fd38814f ???
/usr/src/debug/glibc-2.30-1.2.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xf7752a get_origin_and_offset
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/gimple-ssa-sprintf.c:2314
0xf774ec get_origin_and_offset
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/gimple-ssa-sprintf.c:2362
0xf775ac get_origin_and_offset
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/gimple-ssa-sprintf.c:2390
0xf7744c get_origin_and_offset
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/gimple-ssa-sprintf.c:2353
0xf774ec get_origin_and_offset
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/gimple-ssa-sprintf.c:2362
0xf774ec get_origin_and_offset
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/gimple-ssa-sprintf.c:2362
0xf775ac get_origin_and_offset
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/gimple-ssa-sprintf.c:2390
0xf7d56b handle_printf_call(gimple_stmt_iterator*, vr_values const*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/gimple-ssa-sprintf.c:4666
0xc0511c strlen_check_and_optimize_call
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/tree-ssa-strlen.c:4799
0xc0511c check_and_optimize_stmt
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/tree-ssa-strlen.c:4939
0xc0511c strlen_dom_walker::before_dom_children(basic_block_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/tree-ssa-strlen.c:5166
0xf3b3f5 dom_walker::walk(basic_block_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/domwalk.c:309
0xbfaf31 printf_strlen_execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/tree-ssa-strlen.c:5232
[Bug c/92479] missing warnings for unreachable codes with -Wunreachable-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479 --- Comment #4 from tangyixuan --- (In reply to Eric Gallager from comment #2) > (In reply to Andrew Pinski from comment #1) > > The code for Wunreachable-code was removed a long time ago (around 5-10 > > years ago). > > There are some other bugs open about reviving -Wunreachable-code. There's > bug 46476 for -Wunreachable-code-return, which I thought this was a dup of > at first, but I guess since -Wunreachable-code-break has a different name > that this can stay separate. If we're adding bugs for each of clang's > sub-options for -Wunreachable-code, then I guess it might be worth creating > a bug for -Wunreachable-code-loop-increment, too. (There's also bug 82100 > for code that's unreachable due to conflicting conditions) yeah, -Wunreachable-code-break and -Wunreachable-code-break are two different options in clang, which are also seperated from -Wunreachable-code. I do not know whether gcc could detect the cases. Gcc would be prefect with your efforts.
[Bug tree-optimization/92493] ICE in get_origin_and_offset at gimple-ssa-sprintf.c:2314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92493 Martin Liška changed: What|Removed |Added Target||riscv64-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-13 Host||x86_64-linux-gnu Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 --- Comment #7 from Xiong Hu XS Luo --- Starting broken revision on Power8BE is r265398: commit 171920e88fed13ed26336ca884123eff37176c36 (HEAD, refs/bisect/bad) Author: segher Date: Mon Oct 22 20:23:39 2018 + combine: Do not combine moves from hard registers On most targets every function starts with moves from the parameter passing (hard) registers into pseudos. Similarly, after every call there is a move from the return register into a pseudo. These moves usually combine with later instructions (leaving pretty much the same instruction, just with a hard reg instead of a pseudo).
[Bug target/92492] [AVX512F] Icc generate much better code for loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92492
--- Comment #1 from Hongtao.liu ---
Much more simple case, exclude disturb of point alias and unknown loop count
cat test.c:
typedef unsigned char uint8_t;
static inline uint8_t x264_clip_uint8( int x )
{
return x&(~63) ? (-x)>>7 : x;
}
void mc_weight( uint8_t *__restrict dst, uint8_t *__restrict src)
{
for( int x = 0; x < 16; x++ )
dst[x] = x264_clip_uint8(src[x]);
}
Refer to https://godbolt.org/z/YJXWRD
Gcc failed to vectorize loop, icc succeed.
[Bug c++/92494] New: ICE on function templates with placeholder return type decltype([]{}) and return type doesn't match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92494
Bug ID: 92494
Summary: ICE on function templates with placeholder return type
decltype([]{}) and return type doesn't match
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Target Milestone: ---
Following code produce the ICE on GCC 9 and the GCC 10 latest HEAD:
template < typename T >
decltype([]{}) f( )
{ return 0 ; }
int main ()
{ f() ; }
https://wandbox.org/permlink/Cto4TbyBw0U3ywkB
Expected behaviour:
main.cpp: In function ‘ f()’:
main.cpp:3:10: error: could not convert ‘0’ from ‘int’ to ‘’
Actual behaviour:
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug c++/92481] g++ 9.2.0 SegFault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92481 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-11-13 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, however the code is invalid. Can you please attach the original pre-processed source file (that was valid)?
[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-13 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Known to work||10.0 Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 9.2.0 --- Comment #1 from Martin Liška --- I can confirm that. Question is what guarantees can one expect from a preserve of a padding, Richi? For the record, the issue is fixed on trunk since r273135 and appeared with r240534.
[Bug c++/92481] g++ 9.2.0 SegFault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92481 --- Comment #2 from simon.moll at emea dot nec.com --- The original source file is invalid too (it is huge. Do you still want me to attach it?). I understand that g++ should not segfault in any case.
[Bug c++/92481] g++ 9.2.0 SegFault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92481 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Martin Liška --- (In reply to simon.moll from comment #2) > The original source file is invalid too (it is huge. Do you still want me to > attach it?). Probably not. > I understand that g++ should not segfault in any case. Yes, but it very hard task for languages like C++. Take a look how many ice-on-invalid-code issues we have.
[Bug target/92473] test pr92324-2.c fails on arm and aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92473 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug c++/92490] ’std::stringstream‘ will let the program exit directly and report exit code 127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92490 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Jonathan Wakely --- I can't reproduce this, and you haven't provided nearly enough information for us to tell what the problem is. See https://gcc.gnu.org/bugs/ for how to file a useful report. My guess is you're running "a.out" and the shell is telling you it can't find it, because you need to say "./a.out" instead.
[Bug other/92484] In tree build of ISL 0.22 fails: requires C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484 --- Comment #1 from Jonathan Wakely --- (In reply to Romain Geissler from comment #0) > Is there any official way to build gcc with another C++ standard by default > ? And is in-tree build of libs like gmp/mpfr/mpc/isl still supported or > officially declared deprecated and shall not be used anymore ? It's supported but the recommendation is to use the versions known to work. If ISL 0.22 doesn't work in-tree, don't use that version in-tree.
[Bug other/92484] In tree build of ISL 0.22 fails: requires C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484 --- Comment #2 from Romain Geissler --- Yes this is what I did, I reverted back to ISL 0.21 which for me has been working for the past months (don't know if it's a recommanded version though). Shall we keep this bug open to track the upcoming support of in-tree 0.22 or shall it be closed ?
[Bug rtl-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
Richard Biener changed:
What|Removed |Added
Keywords||ra
Target||x86_64-*-*
CC||vmakarov at gcc dot gnu.org
Component|tree-optimization |rtl-optimization
--- Comment #21 from Richard Biener ---
So the bug is here:
# results.f:473: & vkl(3,1)*vkl(3,3) #
results.f:473: & vkl(3,1)*vkl(3,3)
vfmadd231sd 8(%rsp), %xmm0, %xmm2 # %sfp, preph |
vfmadd231sd %xmm7, %xmm0, %xmm2 # pretmp_8926
where the good case uses 8(%rsp) as operand and the bad case has a stray
use of %xmm7. Suspicous is that %xmm7 was previously moved to a GPR in
the bad case (but that's actually correct AFAICS):
> vmovq
%xmm7, %rsi # _874, _878
vmovsd %xmm7, 488(%rsp)# _878, eyy vmovsd
%xmm7, 488(%rsp)# _878, eyy
More context (you can see 8(%rsp) used in the good case twice, the bad
case has 72(%rsp) for this in the first, loaded to %xmm7 but that reg
is then clobbered in the following insn):
vfmadd132sd %xmm6, %xmm12, %xmm7# tmp2767, pr |
vfmadd132sd %xmm6, %xmm12, %xmm7# tmp2769, pr
> vmovq
%xmm7, %rsi # _874, _878
vmovsd %xmm7, 488(%rsp)# _878, eyy vmovsd
%xmm7, 488(%rsp)# _878, eyy
# results.f:469:ezz=ezz+(vkl(1,3)**2+vkl(2,3) #
results.f:469:ezz=ezz+(vkl(1,3)**2+vkl(2,3)
vmovsd 144(%rsp), %xmm15 # %sfp, pretmp_8932 vmovsd
144(%rsp), %xmm15 # %sfp, pretmp_8932
vmulsd %xmm15, %xmm15, %xmm5 # pretmp_8932, pretmp vmulsd
%xmm15, %xmm15, %xmm5 # pretmp_8932, pretmp
vmovsd 8(%rsp), %xmm9 # %sfp, pretmp_8926 | vmovsd
72(%rsp), %xmm7 # %sfp, pretmp_8926
vfmadd132sd %xmm9, %xmm5, %xmm9 #, _4016, pre |
vfmadd132sd %xmm7, %xmm5, %xmm7 # pretmp_8926
vmovaps %xmm9, %xmm5# pretmp_8926, _879 | vmovaps
%xmm7, %xmm5# pretmp_8926, _879
vfmadd231sd %xmm13, %xmm13, %xmm5 # pretmp_8918
vfmadd231sd %xmm13, %xmm13, %xmm5 # pretmp_8918
vfmadd132sd %xmm6, %xmm13, %xmm5# tmp2767, pr |
vfmadd132sd %xmm6, %xmm13, %xmm5# tmp2769, pr
vmovsd %xmm5, 504(%rsp)# _884, ezz vmovsd
%xmm5, 504(%rsp)# _884, ezz
# results.f:471: & vkl(3,1)*vkl(3,2) #
results.f:471: & vkl(3,1)*vkl(3,2)
vmovsd 80(%rsp), %xmm9 # %sfp, pretmp_8920 <
vfmadd231sd %xmm9, %xmm0, %xmm4 # pretmp_8920
vfmadd231sd %xmm9, %xmm0, %xmm4 # pretmp_8920
vfmadd231sd %xmm14, %xmm12, %xmm4 # pretmp_8922
vfmadd231sd %xmm14, %xmm12, %xmm4 # pretmp_8922
vfmadd231sd %xmm11, %xmm10, %xmm4 # pretmp_8928
vfmadd231sd %xmm11, %xmm10, %xmm4 # pretmp_8928
vmovsd %xmm4, 472(%rsp)# _8924, exyvmovsd
%xmm4, 472(%rsp)# _8924, exy
# results.f:473: & vkl(3,1)*vkl(3,3) #
results.f:473: & vkl(3,1)*vkl(3,3)
vfmadd231sd 8(%rsp), %xmm0, %xmm2 # %sfp, preph |
vfmadd231sd %xmm7, %xmm0, %xmm2 # pretmp_8926
vfmadd231sd %xmm15, %xmm14, %xmm2 # pretmp_8932
vfmadd231sd %xmm15, %xmm14, %xmm2 # pretmp_8932
vfmadd231sd %xmm13, %xmm11, %xmm2 # pretmp_8918
vfmadd231sd %xmm13, %xmm11, %xmm2 # pretmp_8918
vmovsd %xmm2, 480(%rsp)# _8930, exzvmovsd
%xmm2, 480(%rsp)# _8930, exz
before IRA the insns with the stack use and the later bogus reg use are
(insn 1815 1814 1816 176 (set (reg:DF 246 [ _879 ])
(fma:DF (reg:DF 1447 [ pretmp_8926 ])
(reg:DF 1447 [ pretmp_8926 ])
(reg:DF 1018 [ _4016 ]))) "results.f":469:0 1960 {*fma_fmadd_df}
(expr_list:REG_DEAD (reg:DF 1018 [ _4016 ])
(nil)))
(insn 1825 1824 1826 176 (set (reg:DF 252 [ _902 ])
(fma:DF (reg:DF 1440 [ prephitmp_8903 ])
(reg:DF 1447 [ pretmp_8926 ])
(reg:DF 1449 [ _8930 ]))) "results.f":473:0 1960 {*fma_fmadd_df}
(expr_list:REG_DEAD (reg:DF 1449 [ _8930 ])
(nil)))
and after reload it's broken:
(insn 10605 9622 1815 179 (set (reg:DF 27 xmm7 [orig:1447 pretmp_8926 ] [1447])
(mem/c:DF (plus:DI (reg/f:DI 7 sp)
(const_int 72 [0x48])) [22 %sfp+-6808 S8 A64]))
"results.f":469:0 111 {*movdf_internal}
(ni
[Bug fortran/92470] CFI_address wrongly assumes that lower bounds are at zero – invalid for pointers + allocatables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92470 --- Comment #4 from Tobias Burnus --- Author: burnus Date: Wed Nov 13 11:13:57 2019 New Revision: 278128 URL: https://gcc.gnu.org/viewcvs?rev=278128&root=gcc&view=rev Log: PR fortran/92470 Fixes for CFI_address libgfortran/ PR fortran/92470 * runtime/ISO_Fortran_binding.c (CFI_establish): Set lower_bound to 0 also for CFI_attribute_other. gcc/testsuite/ PR fortran/92470 * gfortran.dg/ISO_Fortran_binding_1.c (establish_c): Add assert for lower_bound == 0. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/ISO_Fortran_binding.c
[Bug jit/92483] [10 Regression] many jit test failures due to ABRT, SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92483 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/92495] New: spaceship operator requires public member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92495
Bug ID: 92495
Summary: spaceship operator requires public member
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
The below example only compiles with public member:
#include // omitting trigger ICE
template
struct A {};
struct B {
inline constexpr auto operator<=>(const B& rhs) const = default;
//private:
int value; // why must this member be public?
};
int main() {
A t;
}
[Bug jit/92483] [10 Regression] many jit test failures due to ABRT, SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92483 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-13 Ever confirmed|0 |1
[Bug other/92484] In tree build of ISL 0.22 fails: requires C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-13 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Hmm, we might be able to "smuggle" in other -std flags via the ILS host_modules setting. Or simply _not_ force any -std=XYZ for compiling in-tree mpfr/mpc/isl/gmp. I think we don't use that for stage2+ either, maybe just for stage1 but there using it in GCC "owned" modules should be enough. So yes, keep the bug open.
[Bug c++/92496] New: spaceship operator without include produces ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92496
Bug ID: 92496
Summary: spaceship operator without include produces
ICE
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
Omitting the include in the below example produces ICE
#include // omitting trigger ICE
template
struct A {};
struct B {
inline constexpr auto operator<=>(const B& rhs) const = default;
//private:
int value; // why must this member be public?
};
int main() {
A t;
}
test93.cc: In member function 'constexpr auto B::operator<=>(const B&) const':
test93.cc:7:27: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in is_cat, at cp/method.c:999
7 | inline constexpr auto operator<=>(const B& rhs) const = default;
| ^~~~
0x784e45 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9735
0x63398b tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3396
0x63398b is_cat
../../gcc/cp/method.c:999
0x8dd5ab cat_tag_for
../../gcc/cp/method.c:1011
0x8dd5ab common_comparison_type
../../gcc/cp/method.c:1166
0x8dd5ab build_comparison_op
../../gcc/cp/method.c:1341
0x8ddf19 synthesize_method(tree_node*)
../../gcc/cp/method.c:1501
0x82d6b2 check_bases_and_members
../../gcc/cp/class.c:5909
0x82e5d3 finish_struct_1(tree_node*)
../../gcc/cp/class.c:7113
0x8300f4 finish_struct(tree_node*, tree_node*)
../../gcc/cp/class.c:7399
0x90ea44 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23666
0x910981 cp_parser_class_specifier
../../gcc/cp/parser.c:23965
0x910981 cp_parser_type_specifier
../../gcc/cp/parser.c:17566
0x911956 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14239
0x912371 cp_parser_simple_declaration
../../gcc/cp/parser.c:13502
0x9394ca cp_parser_declaration
../../gcc/cp/parser.c:13322
0x939b42 cp_parser_translation_unit
../../gcc/cp/parser.c:4721
0x939b42 c_parse_file()
../../gcc/cp/parser.c:42925
0xa3ce4b c_common_parse_file()
../../gcc/c-family/c-opts.c:1185
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
CC||law at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
Yes, memcpy of course needs to copy padding.
So the issue is that with
f (struct s * p, struct s * q)
{
struct s w;
long unsigned int _4;
long unsigned int _8;
:
w = *q_2(D);
_4 = MEM[(char * {ref-all})q_2(D)];
MEM[(char * {ref-all})&w] = _4;
*p_6(D) = w;
_8 = MEM[(char * {ref-all})&w];
MEM[(char * {ref-all})p_6(D)] = _8;
w ={v} {CLOBBER};
return;
we view assignments of the form w = *q_2(D); or *p_6(D) = w; as
killing definitions and "loads" like *q_2(D) as loading all bytes.
This leads value-numbering to the conclusion that
MEM[(char * {ref-all})&w] = _4;
is a redundant store. The same reasoning would lead DSE to think
that the store to the padding is "dead" for
__attribute__((noinline,noclone))
void g(struct s *p, struct s * __restrict q)
{
*((char *)p + 1) = 3;
*p = *q;
}
where it elides the store of 3.
Aggregate assignments are bad. The revs. in question don't really address
this cases but merely happen to fix one or another case (here because
of the intent to preserve the dynamic-type changing store).
Of course it's again SRA that "exposes" the individual fields when scalarizing
an aggregate copy, defeating the alias machinerys view of the IL (but IIRC
RTL expansion shares SRAs view, even if that's not appearant in this
testcase?).
Now as an exercise build a complete testcase for the DSE issue above.
[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
--- Comment #3 from Richard Biener ---
Note when changing struct s to say
struct s {
char c;
int i __attribute__((aligned(128)));
};
you can (if you disable SRA!) observe that RTL expansion copies padding
for aggregate assignments:
g:
.LFB0:
.cfi_startproc
movdqa (%rsi), %xmm0
movdqa 16(%rsi), %xmm1
movdqa 32(%rsi), %xmm2
movdqa 48(%rsi), %xmm3
movdqa 64(%rsi), %xmm4
...
movaps %xmm5, 208(%rdi)
movaps %xmm6, 224(%rdi)
movaps %xmm7, 240(%rdi)
ret
so at least there doesn't seem to be middle-end code exploiting the C standards
copy-all-elements interpretation of aggregate assignment.
[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486 Richard Biener changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #4 from Richard Biener --- In my ideal world GIMPLE aggregate copies would be block-copies and all elementwise copy "optimization" would happen by the frontends. A block copy with arbitrary holes is just bad IL design.
[Bug target/92492] [AVX512F] Icc generate much better code for loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92492 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-13 Blocks||53947 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- t.c:12:14: missed: not vectorized: relevant stmt not supported: _4 = (int) _3; # x_25 = PHI # ivtmp_29 = PHI _1 = (sizetype) x_25; _2 = src_9(D) + _1; _3 = *_2; _4 = (int) _3; _5 = dst_10(D) + _1; _11 = _4 & -64; _14 = -_4; _15 = _14 >> 7; iftmp.0_16 = (unsigned char) _15; iftmp.0_17 = _11 == 0 ? _3 : iftmp.0_16; *_5 = iftmp.0_17; x_13 = x_25 + 1; ivtmp_28 = ivtmp_29 - 1; if (ivtmp_28 != 0) goto ; [93.75%] else goto ; [6.25%] was the if-converted loop. This requires unpacking of char to int so this all boils down to failure to narrow all operations to 'short'. Might be doable with a match.pd pattern simplifying ((int) X) & -64 == 0 to X & -64 == 0 which we maybe already have but there's other uses of _4. ICC also uses effectively two vector sizes, v8qi and v8hi AFAICS? But why does it use %ymm then... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug rtl-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283 --- Comment #22 from Richard Biener --- For reference, the following assembler patch fixes the miscompare: --- results.s 2019-11-13 13:07:54.964478824 +0100 +++ results.s.ok2019-11-13 13:06:29.024055977 +0100 @@ -2266,11 +2266,12 @@ vfmadd231sd %xmm11, %xmm10, %xmm4 # pretmp_8928, pretmp_8934, _8924 vmovsd %xmm4, 472(%rsp)# _8924, exy # results.f:473: & vkl(3,1)*vkl(3,3) - vfmadd231sd %xmm7, %xmm0, %xmm2 # pretmp_8926, prephitmp_8903, _902 + vfmadd231sd 72(%rsp), %xmm0, %xmm2 # pretmp_8926, prephitmp_8903, _902 vfmadd231sd %xmm15, %xmm14, %xmm2 # pretmp_8932, pretmp_8922, _906 vfmadd231sd %xmm13, %xmm11, %xmm2 # pretmp_8918, pretmp_8928, _8930 vmovsd %xmm2, 480(%rsp)# _8930, exz # results.f:475: & vkl(3,2)*vkl(3,3) + vmovsd 72(%rsp), %xmm7 vfmadd231sd %xmm9, %xmm7, %xmm1 # pretmp_8920, pretmp_8926, _915 vfmadd231sd %xmm12, %xmm15, %xmm1 # pretmp_8916, pretmp_8932, _919 vfmadd231sd %xmm10, %xmm13, %xmm1 # pretmp_8934, pretmp_8918, _8936
[Bug target/91851] [m68k] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851 --- Comment #4 from Tobias Burnus --- Bernd posted the CC0-to-MODE_CC patches for review, cf: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01028.html [0/4] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01029.html [1/4] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01030.html [2/4] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01031.html [3/4] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01032.html [4/4] Side remark: once MODE_CC is used, at some point the register allocator should also be changed from 'reload' to LRA, cf. https://gcc.gnu.org/wiki/LRAIsDefault ; for now, only CC0 was suggested to be deprecated in GCC 10 and scheduled for removal in GCC 11, cf. https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html – still, getting rid of reload is also a goal.
[Bug c++/92475] [8/9/10 Regression] incorrect code with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92475
--- Comment #8 from Richard Biener ---
So while we clear range info from _5 when
Setting value number of g_16 to _5 (changed)
clearing range info of _5
we're not clearing range info from all defs leading to it and since
# RANGE [0, 7] NONZERO 7
c.6_1 = (sizetype) c_7;
# RANGE [1, 8] NONZERO 15
_5 = c.6_1 + 1
we end up simplifying g_16 != 0 to c.6_1 != -1U which we resolve via
/* X == C (or X & Z == Y | C) is impossible if ~nonzero(X) & C != 0. */
(for cmp (eq ne)
(simplify
(cmp:c (with_possible_nonzero_bits2 @0) (with_certain_nonzero_bits2 @1))
(if (wi::bit_and_not (wi::to_wide (@1), get_nonzero_bits (@0)) != 0)
{ constant_boolean_node (cmp == NE_EXPR, type); })))
The solution for this kind of bugs was indeed the VN rewrite which avoids
simplifying expressions with names that are not available (and thus may
be from a different loop iteration invocation).
The solution we employed for the old VN is inherently fragile and I
don't see any easy workaround besides trying to add some kind of global
flag invalidating all range information (but it's points-to as well for
the cases of PTA disambiguation and that info is quite valuable).
So I fear that WONTFIX is the solution we'll end up with here.
[Bug c++/92439] [concepts] trunk crashes on constraint satisfaction failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92439
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
--- Comment #1 from Andrew Sutton ---
Confirmed. The patch here fixes the crash, but there are other issues that
prevent this from compiling.
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html
In particular, the nested value of:
template struct has_form_of_list { enum : bool { value = false
}; };
cannot be used as an atomic constraint as it doesn't have type bool. That needs
to be a static constexpr bool variable.
Fixing that, you get this:
x.cpp:37:28: error: use of function ‘constexpr bool
detail::dont_overlap(unsigned int, const T&, const Ts& ...) [with T =
list, bf<0, 3> >; Ts = {}]’ with unsatisfied constraints
37 | return dont_overlap(all_prev_masks | this_mask, ts...);
|^~~
... because ...
x.cpp:23:30: error: ‘mask_of_ones’ is not a member of ‘list, bf<0, 3>
>’
23 | requires(T::mask_of_ones >=0)
| ~^~~~
[Bug c++/92496] spaceship operator without include produces ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92496 Jonathan Wakely changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-13 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed. This is ice-on-invalid-code, because the header is required before any use of defaulted comparison operators, see [expr.spaceship] p10. It should print a proper diagnostic though, not ICE.
[Bug c++/92495] spaceship operator requires public member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92495
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-11-13
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Please provide a testcase that actually exhibits the bug, rather than
commenting out the thing that causes the problem. You're also missing the other
info requested by https://gcc.gnu.org/bugs such as output of 'gcc -v' and the
command-line options used.
Confirmed on trunk, for this test, with -std=gnu++2a:
#include
template
struct A {};
struct B {
inline constexpr auto operator<=>(const B& rhs) const = default;
private:
int value; // why must this member be public?
};
int main() {
A t;
}
92495.cc: In function 'int main()':
92495.cc:13:10: error: 'B' is not a valid type for a template non-type
parameter because it is not structural
13 | A t;
| ^
92495.cc:9:9: note: 'B::value' is not public
9 | int value; // why must this member be public?
| ^
92495.cc:13:12: warning: unused variable 't' [-Wunused-variable]
13 | A t;
|^
[Bug c++/92496] spaceship operator without include produces ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92496
--- Comment #2 from Jonathan Wakely ---
Slightly reduced:
template
struct A {};
struct B {
constexpr auto operator<=>(const B&) const = default;
int value;
};
A t;
[Bug target/91851] [m68k] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851 --- Comment #5 from John Paul Adrian Glaubitz --- (In reply to Tobias Burnus from comment #4) > Bernd posted the CC0-to-MODE_CC patches for review, cf: > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01028.html [0/4] > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01029.html [1/4] > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01030.html [2/4] > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01031.html [3/4] > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01032.html [4/4] Woohoo, awesome. I'm really impressed how fast that was. > Side remark: once MODE_CC is used, at some point the register allocator > should also be changed from 'reload' to LRA, cf. > https://gcc.gnu.org/wiki/LRAIsDefault ; for now, only CC0 was suggested to > be deprecated in GCC 10 and scheduled for removal in GCC 11, cf. > https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html – still, getting > rid of reload is also a goal. If Bernd could make that switch as well, that would be awesome but since it was not in the original Bounty I'm not sure it would be fair to ask for that to be done as well.
[Bug lto/91935] Unneeded .debug_info entries in .symtab when using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91935 --- Comment #3 from Dimitar Yordanov --- ld.bfd --gc-sections drops the dead symbols, at least in the example code. ld.gold --gc-sections works differently. I guess it does not even look at sections without SHF_ALLOC
[Bug target/92389] Compiling with -march=icelake-client does not enable __AVX512VPOPCNTDQ__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92389 --- Comment #2 from Martin Liška --- Thank you Tom for the bug report (and the suggested fix). It's obviously correct. One can verify the feature availability here: https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512
[Bug target/92389] Compiling with -march=icelake-client does not enable __AVX512VPOPCNTDQ__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92389 Martin Liška changed: What|Removed |Added Target Milestone|--- |10.0 Known to fail||10.0, 8.3.0, 9.2.0
[Bug ipa/92454] [10 Regression] ICE: Segmentation fault (in identify_dead_nodes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92454 --- Comment #6 from Martin Jambor --- Author: jamborm Date: Wed Nov 13 14:12:58 2019 New Revision: 278142 URL: https://gcc.gnu.org/viewcvs?rev=278142&root=gcc&view=rev Log: Add a few missing checks that IPA_NODE_REF is not NULL (PR 92454) 2019-11-13 Jan Hubicka Martin Jambor PR ipa/92454 * ipa-cp.c (spread_undeadness): Check that IPA_NODE_REF exists. (identify_dead_nodes): Likewise. testsuite/ * g++.dg/ipa/pr92454.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr92454.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/92454] [10 Regression] ICE: Segmentation fault (in identify_dead_nodes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92454 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Jambor --- Fixed. Sorry that it took so long, I've face some testing hickupps.
[Bug ipa/92497] New: Aggregate IPA-CP and inlining do not play well together, transformation is lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92497
Bug ID: 92497
Summary: Aggregate IPA-CP and inlining do not play well
together, transformation is lost
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
The following breaks when compiled with -O2 -fno-early-inlining:
/* { dg-do run } */
/* { dg-options "-O2 -fno-early-inlining" } */
struct a {int a;};
static int //__attribute__ ((noinline))
foo (struct a a)
{
if (!__builtin_constant_p (a.a))
__builtin_abort ();
return a.a;
}
static int __attribute__ ((noinline))
bar (struct a a)
{
return foo(a);
}
int main()
{
struct a a={1};
return bar (a);
}
This happens because we do not apply IPA-CP transformation on foo
before we inline it to bar.
See also the thread beginning with:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00891.html
[Bug c++/92403] [concepts] requires expression in if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92403 Andrew Sutton changed: What|Removed |Added CC||andrew.n.sutton at gmail dot com --- Comment #1 from Andrew Sutton --- A resolution is available here: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01051.html
[Bug fortran/92470] CFI_address wrongly assumes that lower bounds are at zero – invalid for pointers + allocatables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92470
--- Comment #5 from Tobias Burnus ---
Author: burnus
Date: Wed Nov 13 15:06:47 2019
New Revision: 278143
URL: https://gcc.gnu.org/viewcvs?rev=278143&root=gcc&view=rev
Log:
PR fortran/92470 Fixes for CFI_address
Backport from mainline
libgfortran/
2019-11-13 Tobias Burnus
PR fortran/92470
* runtime/ISO_Fortran_binding.c (CFI_establish): Set lower_bound to 0
also for CFI_attribute_other.
2019-11-12 Tobias Burnus
PR fortran/92470
* runtime/ISO_Fortran_binding.c (CFI_address): Handle non-zero
lower_bound; update error message.
(CFI_allocate): Fix comment typo.
(CFI_establish): Fix identation, fix typos, don't check values of 'dv'
argument.
gcc/testsuite/
2019-11-13 Tobias Burnus
PR fortran/92470
* gfortran.dg/ISO_Fortran_binding_1.c (establish_c): Add assert for
lower_bound == 0.
2019-11-12 Tobias Burnus
PR fortran/92470
* gfortran.dg/ISO_Fortran_binding_17.c: New.
* gfortran.dg/ISO_Fortran_binding_17.f90: New.
* gfortran.dg/ISO_Fortran_binding_1.c (elemental_mult_c, allocate_c,
section_c, select_part_c): Update for CFI_{address} changes;
add asserts.
Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.c
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.f90
Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c
branches/gcc-9-branch/libgfortran/ChangeLog
branches/gcc-9-branch/libgfortran/runtime/ISO_Fortran_binding.c
[Bug fortran/92470] CFI_address wrongly assumes that lower bounds are at zero – invalid for pointers + allocatables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92470 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tobias Burnus --- FIXED for trunk/GCC 10 and GCC 9.
[Bug testsuite/92466] new test case gfortran.dg/ISO_Fortran_binding_15.f90 in r278025 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92466 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- See PR 92123 comment 5, 7 and 8.
[Bug c++/92214] Unhelpful diagnostic for static_assert( some_concept(some_type) )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92214 Andrew Sutton changed: What|Removed |Added CC||andrew.n.sutton at gmail dot com --- Comment #1 from Andrew Sutton --- That's part of a functional type conversion: the T in T(args...), not a declaration. If we don't allow placeholders in that context, we can probably generate a better diagnostic.
[Bug c++/92403] [concepts] requires expression in if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92403 --- Comment #2 from Andrew Sutton --- This seems like a duplicate of 92186.
[Bug c++/92103] constraints not checked on nested class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92103 Andrew Sutton changed: What|Removed |Added CC||andrew.n.sutton at gmail dot com --- Comment #3 from Andrew Sutton --- This is one of our x-fail tests. When you instantiate a constrained alias with dependent arguments, you have to propagate its constraints (somehow) into the resulting type. And of course, those can accumulate through multiple instantiations of aliases. Unfortunately, I'm not that familiar with how aliases work.
[Bug c++/92186] [concepts] requires expression outside of concept definition cannot return false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92186 Andrew Sutton changed: What|Removed |Added CC||andrew.n.sutton at gmail dot com --- Comment #1 from Andrew Sutton --- Resolved by the patch here. https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01051.html
[Bug c++/92040] Type requirements don't appear to work when a type doesn't exist.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92040 Andrew Sutton changed: What|Removed |Added CC||andrew.n.sutton at gmail dot com --- Comment #1 from Andrew Sutton --- Duplicate of 92186. A resolution is available here: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01051.html
[Bug other/91396] Link error when I use -fvtable-verify=std and -static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396 --- Comment #7 from ctice at gcc dot gnu.org --- To the best of my knowledge this is fixed; do you have evidence otherwise?
[Bug c++/89070] Attribute [[nodiscard]] should be ignored in unevaluated contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89070 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Wed Nov 13 15:59:53 2019 New Revision: 278147 URL: https://gcc.gnu.org/viewcvs?rev=278147&root=gcc&view=rev Log: PR c++/89070 - bogus [[nodiscard]] warning in SFINAE. This is a complaint that we issue a [[nodiscard]] warning even in SFINAE contexts. Here 'complain' is tf_decltype, but not tf_warning so I guess we can fix it as below. * cvt.c (convert_to_void): Guard maybe_warn_nodiscard calls with tf_warning. * g++.dg/cpp1z/nodiscard7.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/nodiscard7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89070] Attribute [[nodiscard]] should be ignored in unevaluated contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89070 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug ipa/92498] New: [10 regression] gcc.dg/tree-prof/crossmodule-indircall-1.c fails starting with r278100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92498 Bug ID: 92498 Summary: [10 regression] gcc.dg/tree-prof/crossmodule-indircall-1.c fails starting with r278100 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Executing on host: /home/seurer/gcc/build/gcc-test3/gcc/xgcc -B/home/seurer/gcc/build/gcc-test3/gcc/ /home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never /home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -O3 -flto -DDOJOB=1 -fprofile-generate -D_PROFILE_GENERATE -lm -o /home/seurer/gcc/build/gcc-test3/gcc/testsuite/gcc/crossmodule-indircall-1.x01 (timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test3/gcc/xgcc -B/home/seurer/gcc/build/gcc-test3/gcc/ /home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never /home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -O3 -flto -DDOJOB=1 -fprofile-generate -D_PROFILE_GENERATE -lm -o /home/seurer/gcc/build/gcc-test3/gcc/testsuite/gcc/crossmodule-indircall-1.x01 PASS: gcc.dg/tree-prof/crossmodule-indircall-1.c compilation, -fprofile-generate -D_PROFILE_GENERATE Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test3/gcc::/home/seurer/gcc/build/gcc-test3/gcc:/home/seurer/gcc/build/gcc-test3/./gmp/.libs:/home/seurer/gcc/build/gcc-test3/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test3/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test3/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test3/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test3/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test3/./isl/.libs:/home/seurer/gcc/build/gcc-test3/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64 Execution timeout is: 300 spawn [open ...] PASS: gcc.dg/tree-prof/crossmodule-indircall-1.c execution, -fprofile-generate -D_PROFILE_GENERATE Executing on host: /home/seurer/gcc/build/gcc-test3/gcc/xgcc -B/home/seurer/gcc/build/gcc-test3/gcc/ /home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never /home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -O3 -flto -DDOJOB=1 -fprofile-use -D_PROFILE_USE -lm -o /home/seurer/gcc/build/gcc-test3/gcc/testsuite/gcc/crossmodule-indircall-1.x02 (timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test3/gcc/xgcc -B/home/seurer/gcc/build/gcc-test3/gcc/ /home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never /home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -O3 -flto -DDOJOB=1 -fprofile-use -D_PROFILE_USE -lm -o /home/seurer/gcc/build/gcc-test3/gcc/testsuite/gcc/crossmodule-indircall-1.x02 PASS: gcc.dg/tree-prof/crossmodule-indircall-1.c compilation, -fprofile-use -D_PROFILE_USE Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test3/gcc::/home/seurer/gcc/build/gcc-test3/gcc:/home/seurer/gcc/build/gcc-test3/./gmp/.libs:/home/seurer/gcc/build/gcc-test3/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test3/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test3/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test3/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test3/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test3/./isl/.libs:/home/seurer/gcc/build/gcc-test3/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64 Execution timeout is: 300 spawn [open ...] FAIL: gcc.dg/tree-prof/crossmodule-indircall-1.c execution,-fprofile-use -D_PROFILE_USE UNSUPPORTED: gcc.dg/tree-prof/crossmodule-indircall-1.c -fauto-profile testcase /home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp completed in 3 seconds === gcc Summary === # of expected passes3 # of unexpected failures1 # of unsupported tests 1 r278100 | hubicka | 2019-11-12 13:31:04 -0600 (Tue, 12 Nov 2019) | 5 lines PR ipa/92471 * ipa-profile.c (check_argument_count): Break out from ...; watch for missing summaries. (ipa_profile): Here.
[Bug target/92499] New: nios2 backend needs to allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499
Bug ID: 92499
Summary: nios2 backend needs to allocated object size, not C
object size for gprel optimization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: nios2-elf
Consider this test case:
enum { size = 100 };
struct flexible
{
int length;
int data[];
};
struct inflexible
{
int length;
int data[size];
};
static struct flexible flexible =
{
.data = { [size - 1] = 0, }
};
static struct flexible flexible_nonzero =
{
.length = size
.data = { [size - 1] = 0, }
};
static struct inflexible inflexible =
{
.data = { [size - 1] = 0, }
};
struct flexible *
get_flexible (void)
{
return &flexible;
}
struct flexible *
get_flexible_nonzero (void)
{
return &flexible_nonzero;
}
struct inflexible *
get_inflexible (void)
{
return &inflexible;
}
GCC 10 generates this (with -O2):
.section.text
.align 2
.global get_flexible
.type get_flexible, @function
get_flexible:
addir2, gp, %gprel(flexible)
ret
.size get_flexible, .-get_flexible
.align 2
.global get_flexible_nonzero
.type get_flexible_nonzero, @function
get_flexible_nonzero:
addir2, gp, %gprel(flexible_nonzero)
ret
.size get_flexible_nonzero, .-get_flexible_nonzero
.align 2
.global get_inflexible
.type get_inflexible, @function
get_inflexible:
movhi r2, %hiadj(inflexible)
addir2, r2, %lo(inflexible)
ret
.size get_inflexible, .-get_inflexible
.section.bss
.type inflexible, @object
.size inflexible, 404
.align 2
inflexible:
.zero 404
.section.sdata,"aws"
.align 2
.type flexible_nonzero, @object
.size flexible_nonzero, 404
flexible_nonzero:
.long 100
.zero 396
.long 0
.section.bss
.type flexible, @object
.size flexible, 404
.align 2
flexible:
.zero 404
.ident "GCC: (GNU) 10.0.0 20191103 (experimental) [trunk revision
277751]"
All objects have the same size (404 bytes). My understanding is that they do
not qualify for the gprel optimization: %gprel relocations should not be used
to reference to them (i.e., get_flexible and getflexible_nonzero should look
like get_inflexible), and initialized objects (flexible_nonzero in the object)
should be put into .sdata, not .data.
The likely cause for this bug is that the backend looks at the equivalent of
sizeof (flexible) to make the optimization decision, but this is 4 according to
the C language rules.
Joseph Myers reported this as a glibc build failure:
/scratch/jmyers/glibc/many9/install/compilers/nios2-linux-gnu/lib/gcc/nios2-glibc-linux-gnu/9.2.1/../../../../nios2-glibc-linux-gnu/bin/ld:
/scratch/jmyers/glibc/many9/build/glibcs/nios2-linux-gnu/glibc/libc.a(libc-tls.o):
in function `init_slotinfo':
/scratch/jmyers/glibc/many9/src/glibc/csu/../csu/libc-tls.c:72: warning: unable
to reach .bss (at 0xc5ea0) from the global pointer (at 0x8d890) because the
offset (230928) is out of the allowed range, -32678 to 32767
/scratch/jmyers/glibc/many9/install/compilers/nios2-linux-gnu/lib/gcc/nios2-glibc-linux-gnu/9.2.1/../../../../nios2-glibc-linux-gnu/bin/ld:
final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
../Rules:253: recipe for target
'/scratch/jmyers/glibc/many9/build/glibcs/nios2-linux-gnu/glibc/malloc/tst-interpose-static-nothread'
failed
make[3]: ***
[/scratch/jmyers/glibc/many9/build/glibcs/nios2-linux-gnu/glibc/malloc/tst-interpose-static-nothread]
Error 1
[Bug c++/92431] ICE with spaceship in constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92431 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Wed Nov 13 16:26:18 2019 New Revision: 278149 URL: https://gcc.gnu.org/viewcvs?rev=278149&root=gcc&view=rev Log: libsupc++: Implement comparison algorithms for C++20 This is incomplete because std::strong_order doesn't support floating-point types. The partial_order and weak_order tests use VERIFY instead of static_assert because of PR 92431. * libsupc++/compare (strong_order, weak_order, partial_order) (compare_strong_order_fallback, compare_weak_order_fallback) (compare_partial_order_fallback): Define customization point objects for C++20. * testsuite/18_support/comparisons/algorithms/partial_order.cc: New test. * testsuite/18_support/comparisons/algorithms/strong_order.cc: New test. * testsuite/18_support/comparisons/algorithms/weak_order.cc: New test. Added: trunk/libstdc++-v3/testsuite/18_support/comparisons/algorithms/ trunk/libstdc++-v3/testsuite/18_support/comparisons/algorithms/partial_order.cc trunk/libstdc++-v3/testsuite/18_support/comparisons/algorithms/strong_order.cc trunk/libstdc++-v3/testsuite/18_support/comparisons/algorithms/weak_order.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/compare
[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
||pault at gcc dot gnu.org
Summary|Possibly wrong error|BIND(C) with
|diagnostic |array-descriptor mishandled
||for type character
--- Comment #1 from Tobias Burnus ---
Pre-remark: I haven't looked at your code at all, just as your remark regarding
the standard.
I think at least older versions of the standard had such a restriction to avoid
the issue with passing the "len=" argument along. (Fortran by default passes
the length as hidden argument). The solution was to use:
subroutine test(foo) bind(C)
character(kind=c_char,len=1), dimension(*) :: foo
And due to argument association, call test("Hello World"//c_null_char) still
worked/works.
Let's check F2008: "15.3.2 Interoperability of intrinsic types"
"[…] If the type is character, the length type parameter is interoperable21if
and only if its value is one."
And F2018 has the same wording in 18.3.1!
However, TS29113 and Fortran 2018 added support for array descriptors – and in
the array descriptor, one can encode the character length in elem_len (it's the
length as c_char is one-byte wide.)
Thus, a context where a descriptor is used with C binding, a len >1 or len=: is
permitted.
That's not that clearly written in the standard but implicitly at multiple
locations in Chapter 18. For instance in the following, which also lists when
an array descriptor is used:
"The source file ISO_Fortran_binding.h provides definitions and prototypes to
enable a C function to interoperate with a Fortran procedure that has a dummy
data object that is allocatable, assumed-shape, assumed-rank, pointer, or is of
type character with an assumed length." (18.1p3)
An usage example is in 18.2.3, example case (iv) which uses both an explicit
length > 1 and an assumed length.
And the elem_len is mentioned in Note 2 of 18.5.3. – And there several other
places, from which one has to collect this data.
Hence, you have encountered a left-over warning (I assume: error w/ -std=f…)
from Fortran 2003/2008 which has not been updated for Fortran 2018 – plus bugs
in the implementation of the F2018 feature.
[Bug other/91396] Link error when I use -fvtable-verify=std and -static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Gallager --- (In reply to ctice from comment #7) > To the best of my knowledge this is fixed; do you have evidence otherwise? Nope, just wanted to make sure I could close this.
[Bug testsuite/92500] New: New testcase gfortran.dg/ISO_Fortran_binding_17.f90 fails (added in r278143)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92500 Bug ID: 92500 Summary: New testcase gfortran.dg/ISO_Fortran_binding_17.f90 fails (added in r278143) Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -O0 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -O1 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -O2 (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -Os (test for excess errors) r278143 | burnus | 2019-11-13 09:06:47 -0600 (Wed, 13 Nov 2019) | 37 lines PR fortran/92470 Fixes for CFI_address Backport from mainline
[Bug tree-optimization/92501] New: strncmp with constant unterminated arrays not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92501
Bug ID: 92501
Summary: strncmp with constant unterminated arrays not folded
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC 9 and later fold strncmp calls with constant strings as arguments but it
doesn't optimize equivalent calls when one or both arguments is an unterminated
array. The example below shows the difference.
Clang folds both.
$ cat z.c && gcc -O2 -c -Wall -Wextra -fdump-tree-optimized=/dev/stdout z.c
const char a[] = { '1', '2', '3', '\0' };
const char b[] = { '1', '2', '3' };
void f (void)
{
if (__builtin_strncmp (a, "123", 3))
__builtin_abort ();
}
void g (void)
{
if (__builtin_strncmp (b, "123", 3))
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=2)
f ()
{
[local count: 1073741824]:
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1935, cgraph_uid=2, symbol_order=3)
g ()
{
int _1;
[local count: 1073741824]:
_1 = __builtin_strncmp (&b, "123", 3);
if (_1 != 0)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
[Bug c++/92496] spaceship operator without include produces ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92496
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Even
struct B {
constexpr auto operator<=>(const B&) const = default;
int value;
};
is enough.
The reason nothing is reported is that synthetize_method creates it with
tf_none:
else if (sfk == sfk_comparison)
{
/* Pass tf_none so the function is just deleted if there's a problem. */
build_comparison_op (fndecl, tf_none);
need_body = false;
}
I've tried to fix the ICE below:
--- gcc/cp/method.c.jj 2019-11-12 09:09:33.622815406 +0100
+++ gcc/cp/method.c 2019-11-13 18:41:21.645025060 +0100
@@ -1162,6 +1162,8 @@ common_comparison_type (vec &comps
for (unsigned i = 0; i < comps.length(); ++i)
{
tree comp = comps[i];
+ if (error_operand_p (comp))
+ return error_mark_node;
tree ctype = TREE_TYPE (comp);
comp_cat_tag tag = cat_tag_for (ctype);
if (tag < cc_last)
@@ -1339,7 +1341,10 @@ build_comparison_op (tree fndecl, tsubst
if (code == SPACESHIP_EXPR && is_auto (rettype))
{
rettype = common_comparison_type (comps);
- apply_deduced_return_type (fndecl, rettype);
+ if (rettype == error_mark_node)
+ DECL_DELETED_FN (fndecl) = true;
+ else
+ apply_deduced_return_type (fndecl, rettype);
}
for (unsigned i = 0; i < comps.length(); ++i)
{
but unfortunately that means no error is reported on the above testcase,
maybe_explain_implicit_delete is then called only if something attempts to use
the deleted function, so say:
struct B {
constexpr auto operator<=>(const B&) const = default;
int value;
};
B a, b;
auto c = a <=> b;
with:
pr92496-3.C:6:16: error: use of deleted function ‘constexpr auto
B::operator<=>(const B&) const’
6 | auto c = a <=> b;
|^
pr92496-3.C:2:18: note: ‘constexpr auto B::operator<=>(const B&) const’ is
implicitly deleted because the default definition would be ill-formed:
2 | constexpr auto operator<=>(const B&) const = default;
| ^~~~
pr92496-3.C:2:18: error: ‘strong_ordering’ is not a member of ‘std’
pr92496-3.C:1:1: note: ‘std::strong_ordering’ is defined in header ‘’;
did you forget to ‘#include ’?
+++ |+#include
1 | struct B {
pr92496-3.C:2:18: note: forming type of ‘operator<=>’
2 | constexpr auto operator<=>(const B&) const = default;
| ^~~~
[Bug c++/92496] spaceship operator without include produces ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92496 --- Comment #4 from Jakub Jelinek --- Or should spaceship_type just unconditionally use tf_warning_or_error or tf_error?
[Bug target/92502] New: AVX missing _mm256_storeu2_* functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92502 Bug ID: 92502 Summary: AVX missing _mm256_storeu2_* functions Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: e...@coeus-group.com Target Milestone: --- GCC doesn't implement _mm256_storeu2_m128, _mm256_storeu2_m128d, or _mm256_storeu2_m128i. It's not hard to work around their absence, but it would be nice to have them just to match other compilers which support them (clang, ICC, MSVC, PGI…). FWIW, I'm just doing _mm_storeu_ps(lo_addr, _mm256_castps256_ps128(a)); _mm_storeu_ps(hi_addr, _mm256_extractf128_ps(a, 1)); for the ps version. For pd and si just replace ps with the appropriate characters.
[Bug target/92502] AVX missing _mm256_storeu2_* functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92502 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 91341 ***
[Bug target/91341] Missing AVX Intrinsics: load/store u2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91341 Jakub Jelinek changed: What|Removed |Added CC||e...@coeus-group.com --- Comment #4 from Jakub Jelinek --- *** Bug 92502 has been marked as a duplicate of this bug. ***
[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482 --- Comment #2 from José Rui Faustino de Sousa --- IMHO the point here is if interoperable procedures (bind(c)) are required to have arguments of interoperable type. My reading of 18.3.6 is that it is not required, most relevant for character type would be 18.3.6.2 (5) and (7). Which, like you write, imply the use of a C descriptor. If I understood it correctly the descriptor should be scalar (rank=0) and have "elem_len" equal to character length. The error in 10.0.0 is raised without using any flags and the warning in 9.1.0 requires -Wall -Wmaybe-uninitialized. Please notice that the problem shown by the "strg_print_2" procedure is without using "bind(c)". Thank you very much. Best regards, José Rui
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot gnu.org --- Comment #1 from sandra at gcc dot gnu.org --- I'll take care of this. Glibc will have a workaround to disable -mgpopt when using buggy compiler versions, but the fix ought to be backported to all active GCC versions anyway.
[Bug tree-optimization/92493] ICE in get_origin_and_offset at gimple-ssa-sprintf.c:2314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92493
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
This is caused by the:
278098 msebor if ((RECORD_OR_UNION_TYPE_P (xtype)
278098 msebor && field_at_offset (xtype, *off, &index))
278098 msebor || (TREE_CODE (xtype) == ARRAY_TYPE
278098 msebor && TREE_CODE (TREE_TYPE (xtype)) ==
ARRAY_TYPE
278098 msebor && array_elt_at_offset (xtype, *off,
&index)))
278098 msebor {
278098 msebor *fldoff += index;
278098 msebor *off -= index;
278098 msebor fldoff = NULL;
278098 msebor }
278098 msebor }
278098 msebor
278098 msebor return get_origin_and_offset (x, fldoff, NULL);
get_origin_and_offset assumes that fldoff is never NULL.
If the intent that writes to *fldoff from the recursive call should be ignored,
then perhaps it can do say:
index = 0;
fldoff = &index;
instead of fldoff = NULL; or perhaps
else if (idx < HOST_WIDE_INT_MAX)
*fldoff += idx * int_size_in_bytes (eltype);
else
*fldoff = idx;
should be
else if (fldoff)
{
if (idx < HOST_WIDE_INT_MAX)
*fldoff += idx * int_size_in_bytes (eltype);
else
*fldoff = idx;
}
But, it isn't obvious what this function is meant for at all, so while either
one would fix the ICE, it is unclear what the right thing is.
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
Stas Sergeev changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
--- Comment #17 from Stas Sergeev ---
The following code now breaks:
---
#include
#include
template
struct offset_of {
constexpr operator size_t() const {
return (std::uintptr_t)&(static_cast(nullptr)->*M);
}
};
template
struct B {
char aa[10];
static const int off = offset_of();
};
struct A {
char a;
char _mark[0];
B b;
};
int main()
{
A a;
std::cout << "size " << sizeof(A) << " off " << a.b.off << std::endl;
return 0;
}
---
There is no other way of making offsetof(), rather
than by a reinterpret cast in constexpr (unless you
try very hard - I was still able to work around these
new gcc checks, but its tricky).
Would you consider adding this into -fpremissive?
Suddenly removing an extensions that people got used to,
is not the best treatment of users, AFAICT. Isn't -fpermissive
a right place for the extensions that people got used to?
[Bug ipa/92498] [10 regression] gcc.dg/tree-prof/crossmodule-indircall-1.c fails starting with r278100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92498 --- Comment #1 from Jan Hubicka --- Author: hubicka Date: Wed Nov 13 19:44:35 2019 New Revision: 278157 URL: https://gcc.gnu.org/viewcvs?rev=278157&root=gcc&view=rev Log: PR ipa/92498 * ipa-profile.c (check_argument_count): Do not ICE when descriptors is NULL. (ipa_profile): Fix reversed test. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-profile.c
[Bug tree-optimization/92493] ICE in get_origin_and_offset at gimple-ssa-sprintf.c:2314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92493
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #2 from David Binderman ---
Probably related:
This C code:
struct a {
int b;
char c[]
} * i;
struct d {
short e;
struct a f
} g;
h;
j() {
struct d *f = &g.f;
i = f + h;
snprintf(j, 8, ".asr_%s_%x_donotuse", i->c);
}
when compiled by recent gcc trunk and compiler flag -O3 -Wall,
does this:
uring GIMPLE pass: strlen
bug565.c:10:1: internal compiler error: Segmentation fault
10 | j() {
| ^
0xe6692f crash_signal
../../trunk/gcc/toplev.c:328
0x17ae5e3 get_origin_and_offset
../../trunk/gcc/gimple-ssa-sprintf.c:2358
0x17aeea3 alias_offset
../../trunk/gcc/gimple-ssa-sprintf.c:2422
0x17aeea3 format_string
../../trunk/gcc/gimple-ssa-sprintf.c:2447
Problem first seems to occur sometime between revision 278050
and 278100.
[Bug libgomp/92503] New: [OpenACC] Behavior of 'acc_free' if the memory space is still used in a mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92503
Bug ID: 92503
Summary: [OpenACC] Behavior of 'acc_free' if the memory space
is still used in a mapping
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: openacc
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
Target Milestone: ---
Currently, we state ('libgomp/oacc-mem.c:acc_free') that: "OpenACC 2.0a
(3.2.16) doesn't specify what to do in the event the device address is mapped.
We choose to check if it mapped, and if it is, to unmap it."
(That is, 'acc_free' looks up 'acc_hostptr', and if found, then does an
implicit 'acc_unmap_data' on that, and only then frees the memory space.)
This, seems counter-intuitive for me. I'm not aware of "free" functions
generally first cleaning up any usage of the respective memory space, which
isn't even possible in the general case.
[Bug c++/92441] [10 regression] ICE: in strip_typedefs, at cp/tree.c:1681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92441 Jakub Jelinek changed: What|Removed |Added Status|WAITING |NEW CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Reduced testcase: template void foo (); template struct A; template )> using B = U; template using C = B; template A,int> a; -fconcepts isn't needed. Started with r277281. Can't reproduce with current trunk though, only r278068, so most likely dup of PR92206.
[Bug tree-optimization/92128] fold more non-constant strlen relational expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92128 Sihua changed: What|Removed |Added CC||sihua at droid dot ac.cn --- Comment #3 from Sihua --- Hi Martin, Just FYI, riscv* needs to be skipped on strlenopt-81.c as well.
[Bug libgomp/92503] [OpenACC] Behavior of 'acc_free' if the memory space is still used in a mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92503 --- Comment #1 from jules at gcc dot gnu.org --- FWIW, I don't think we should do this implicit unmapping, particularly since it implies an expensive device-to-host-address lookup.
[Bug ipa/92421] [10 Regression] ICE in inline_small_functions, at ipa-inline.c:2001 since r277759
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92421 --- Comment #6 from Jan Hubicka --- Author: hubicka Date: Wed Nov 13 21:02:11 2019 New Revision: 278159 URL: https://gcc.gnu.org/viewcvs?rev=278159&root=gcc&view=rev Log: PR c++/92421 * ipa-prop.c (update_indirect_edges_after_inlining): Mark parameter as used. * ipa-inline.c (recursive_inlining): Reset node cache after inlining. (inline_small_functions): Remove checking ifdef. * ipa-inline-analysis.c (do_estimate_edge_time): Verify cache consistency. * g++.dg/torture/pr92421.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr92421.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-analysis.c trunk/gcc/ipa-inline.c trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog
[Bug testsuite/92500] New testcase gfortran.dg/ISO_Fortran_binding_17.f90 fails (added in r278143)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92500 --- Comment #1 from seurer at gcc dot gnu.org --- This also fails on trunk.
[Bug testsuite/92500] New testcase gfortran.dg/ISO_Fortran_binding_17.f90 fails (added in r278143)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92500 --- Comment #2 from seurer at gcc dot gnu.org --- It looks like a header file is missing: Executing on host: /home/seurer/gcc/build/gcc-trunk-bootstrap/gcc/testsuite/gfortran7/../../gfortran -B/home/seurer/gcc/build/gcc-trunk-bootstrap/gcc/testsuite/gfortran7/../../ -B/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never-O0 -fcheck=all /home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.c -B/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libatomic/.libs -B/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libquadmath/.libs -lm -o ./ISO_Fortran_binding_17.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk-bootstrap/gcc/testsuite/gfortran7/../../gfortran -B/home/seurer/gcc/build/gcc-trunk-bootstrap/gcc/testsuite/gfortran7/../../ -B/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O0 -fcheck=all /home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.c -B/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libatomic/.libs -B/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libquadmath/.libs -lm -o ./ISO_Fortran_binding_17.exe cc1: warning: command-line option '-fcheck=all' is valid for Fortran but not for C /home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.c:5:10: fatal error: ISO_Fortran_binding.h: No such file or directory compilation terminated. compiler exited with status 1 PASS: gfortran.dg/ISO_Fortran_binding_17.f90 -O0 (test for warnings, line ) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 -O0 (test for excess errors) Excess errors: /home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.c:5:10: fatal error: ISO_Fortran_binding.h: No such file or directory compilation terminated. UNRESOLVED: gfortran.dg/ISO_Fortran_binding_17.f90 -O0 compilation failed to produce executable Executing on host: /home/seurer/gcc/build/gcc-trunk-bootstrap/gcc/testsuite/gfortran7/../../gfortran -B/home/seurer/gcc/build/gcc-trunk-bootstrap/gcc/testsuite/gfortran7/../../ -B/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never-O1 -fcheck=all /home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.c -B/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libatomic/.libs -B/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libquadmath/.libs -lm -o ./ISO_Fortran_binding_17.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk-bootstrap/gcc/testsuite/gfortran7/../../gfortran -B/home/seurer/gcc/build/gcc-trunk-bootstrap/gcc/testsuite/gfortran7/../../ -B/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libgfortran/ /home/
[Bug c++/91353] Implement P1331R2: Permitting trivial default initialization in constexpr contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91353 --- Comment #2 from Marek Polacek --- The quux case: CONSTRUCTOR_NO_CLEARING is cleared here 2154 /* The result of a constexpr function must be completely initialized. */ 2155 if (TREE_CODE (result) == CONSTRUCTOR) 2156 clear_no_implicit_zero (result); but we can no longer assume that a constexpr constructor has initialized all the members.
[Bug testsuite/92500] New testcase gfortran.dg/ISO_Fortran_binding_17.f90 fails (added in r278143)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92500 --- Comment #3 from anlauf at gcc dot gnu.org --- Looking at related testcases, does replacing #include "ISO_Fortran_binding.h" by #include "../../../libgfortran/ISO_Fortran_binding.h" help?
[Bug c++/92504] New: ICE on gcc-9 -fopenmp: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92504
Bug ID: 92504
Summary: ICE on gcc-9 -fopenmp: internal compiler error: tree
check: expected tree that contains 'decl common'
structure, have 'baselink' in get_inner_reference, at
expr.c:7238
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Original bug is reported at https://bugs.gentoo.org/699938 by Marc Vinyals
where invalid C++ code crashes gcc with internal error instead of error
message.
creduce turned it into the following:
// $ cat bug.ii
class c {
void d();
};
main() {
c a;
#pragma omp for
for (auto b = a; b != a.d; b)
;
Note: there is no closing bracket and for contents is quite invalid. gcc-master
files like that:
$ gcc/xg++ -Bgcc -O1 -fopenmp -c bug.ii -o bug.o
bug.ii:4:1: warning: ISO C++ forbids declaration of 'main' with no type
[-Wreturn-type]
4 | main() {
| ^~~~
bug.ii: In function 'int main()':
bug.ii:8:5: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
8 | ;
| ^
0x7f1fd53edf1a __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 <https://gcc.gnu.org/bugs/> for instructions.
gcc is built as:
Reading specs from /home/slyfox/dev/git/gcc-native-quick/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-native-quick/gcc/xg++
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++,lto
--disable-bootstrap --with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed
--disable-nls --without-isl CFLAGS='-O1 ' CXXFLAGS='-O1 '
--with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191113 (experimental) (GCC)
[Bug c++/92504] ICE on gcc-9 -fopenmp: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92504 --- Comment #1 from Sergei Trofimovich --- Created attachment 47232 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47232&action=edit bug.ii
[Bug c++/92504] ICE on gcc-9 -fopenmp: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92504 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-13 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed.
[Bug c++/92504] ICE on gcc-9 -fopenmp: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92504 Marek Polacek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Started with r265930.
[Bug c++/92504] ICE on gcc-9 -fopenmp: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92504
--- Comment #4 from Sergei Trofimovich ---
If I read backtrace function names correctly crash happened when openmp for was
expanded and one of arguments was not recognised early enough as invalid (value
vs. function pointer?).
Thread 2.1 "cc1plus" hit Breakpoint 1, internal_error
(gmsgid=gmsgid@entry=0x1c53558 "tree check: expected tree that contains %qs
structure, have %qs in %s, at %s:%d")
at ../../gcc/gcc/diagnostic.c:1577
1577{
(gdb) bt
#0 internal_error (gmsgid=gmsgid@entry=0x1c53558 "tree check: expected tree
that contains %qs structure, have %qs in %s, at %s:%d") at
../../gcc/gcc/diagnostic.c:1577
#1 0x011f74ff in tree_contains_struct_check_failed
(node=node@entry=0x7785ecf0, en=en@entry=TS_DECL_COMMON,
file=file@entry=0x1bc5954 "../../gcc/gcc/expr.c",
line=line@entry=7238, function=function@entry=0x1bc5b35
"get_inner_reference") at ../../gcc/gcc/tree.c:9858
#2 0x00ac66a5 in contains_struct_check (__g=0x1bc5b35
"get_inner_reference", __l=7238, __f=0x1bc5954 "../../gcc/gcc/expr.c",
__s=TS_DECL_COMMON, __t=0x7785ecf0)
at ../../gcc/gcc/tree.h:3387
#3 get_inner_reference (exp=exp@entry=0x7785ed20,
pbitsize=pbitsize@entry=0x7fffc1c0, pbitpos=pbitpos@entry=0x7fffc1a0,
poffset=poffset@entry=0x7fffc198,
pmode=pmode@entry=0x7fffc148,
punsignedp=punsignedp@entry=0x7fffc158, preversep=0x7fffc168,
pvolatilep=0x7fffc178) at ../../gcc/gcc/expr.c:7238
#4 0x00b1d0bd in optimize_bit_field_compare (rhs=0x77ffbc60,
lhs=0x7785ed20, compare_type=0x7787eb28, code=NE_EXPR, loc=2147483649)
at ../../gcc/gcc/fold-const.c:4443
#5 fold_binary_loc (loc=loc@entry=2147483649, code=code@entry=NE_EXPR,
type=type@entry=0x7787eb28, op0=op0@entry=0x7785ed20,
op1=op1@entry=0x77ffbc60)
at ../../gcc/gcc/fold-const.c:11091
#6 0x00b209f4 in fold_build2_loc (loc=loc@entry=2147483649,
code=code@entry=NE_EXPR, type=type@entry=0x7787eb28,
op0=op0@entry=0x7785ed20,
op1=op1@entry=0x77ffbc60) at ../../gcc/gcc/fold-const.c:12720
#7 0x00b17862 in fold_binary_loc (loc=2147483649, code=NE_EXPR,
type=0x7787eb28, op0=0x77ffbc60, op1=0x7785ed20) at
../../gcc/gcc/fold-const.c:9729
#8 0x00b3fce2 in fold (expr=expr@entry=0x779c8ca8) at
../../gcc/gcc/fold-const.c:12342
#9 0x00652a56 in cp_fold (x=) at
../../gcc/gcc/cp/cp-gimplify.c:2534
#10 0x00654ca2 in cp_fold_maybe_rvalue (x=,
rval=rval@entry=true) at ../../gcc/gcc/cp/cp-gimplify.c:2210
#11 0x00654d41 in cp_fold_rvalue (x=) at
../../gcc/gcc/cp/cp-gimplify.c:2233
#12 0x00654d8e in cp_fully_fold (x=,
x@entry=0x779c8ca8) at ../../gcc/gcc/cp/cp-gimplify.c:2257
#13 0x008214b7 in handle_omp_for_class_iterator (i=i@entry=0,
locus=locus@entry=24706, code=code@entry=OMP_FOR,
declv=declv@entry=0x779b8ae0,
orig_declv=orig_declv@entry=0x779b8d20,
initv=initv@entry=0x779b8b00, condv=0x779b8b20, incrv=0x779b8b40,
body=0x7fffc818, pre_body=0x7fffc810,
clauses=@0x7fffc808: 0x0, collapse=1, ordered=0) at
../../gcc/gcc/cp/semantics.c:8437
#14 0x00834bb6 in finish_omp_for (locus=locus@entry=24706,
code=code@entry=OMP_FOR, declv=declv@entry=0x779b8ae0,
orig_declv=0x779b8d20, orig_declv@entry=0x0,
initv=initv@entry=0x779b8b00, condv=condv@entry=0x779b8b20,
incrv=0x779b8b40, body=, pre_body=,
orig_inits=0x7fffc9a0,
clauses=) at ../../gcc/gcc/cp/semantics.c:8948
#15 0x0077db3f in cp_parser_omp_for_loop
(parser=parser@entry=0x7788e7b8, code=code@entry=OMP_FOR,
clauses=, clauses@entry=0x0,
cclauses=cclauses@entry=0x0, if_p=if_p@entry=0x0) at
../../gcc/gcc/cp/parser.c:38279
#16 0x0077e4e1 in cp_parser_omp_for
(parser=parser@entry=0x7788e7b8,
pragma_tok=pragma_tok@entry=0x777de118, p_name=,
p_name@entry=0x7fffcb90 "#pragma omp for", mask=...,
cclauses=cclauses@entry=0x0, if_p=0x0) at ../../gcc/gcc/cp/parser.c:38526
#17 0x00780f2d in cp_parser_omp_construct
(parser=parser@entry=0x7788e7b8,
pragma_tok=pragma_tok@entry=0x777de118, if_p=if_p@entry=0x0)
at ../../gcc/gcc/cp/parser.c:42102
#18 0x00759509 in cp_parser_pragma (parser=parser@entry=0x7788e7b8,
context=context@entry=pragma_compound, if_p=if_p@entry=0x0) at
../../gcc/gcc/cp/parser.c:42763
#19 0x0075b59f in cp_parser_statement
(parser=parser@entry=0x7788e7b8,
in_statement_expr=in_statement_expr@entry=0x0,
in_compound=in_compound@entry=true,
if_p=if_p@entry=0x0, chain=chain@entry=0x0,
loc_after_labels=loc_after_labels@entry=0x0) at ../../gcc/gcc/cp/parser.c:11354
#20 0x0075b80c in cp_parser_statement_seq_opt
(parser=parser@entry=0x7788e7b8,
in_statement_expr=in_statement_expr@entry=0x0) at
../../gcc/gcc/cp/parser.c:11742
#21 0x0075b8e1 in cp_parser_compound_statement
(parser=parser@entry=0x7788e7b8,
in_statement_exp
[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780 S. Davis Herring changed: What|Removed |Added CC||herring at lanl dot gov --- Comment #1 from S. Davis Herring --- P1825R0 now allows noMove to use the Dest(Dest&&) constructor.
[Bug c++/90493] const variable template specialization is always local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90493 S. Davis Herring changed: What|Removed |Added CC||herring at lanl dot gov --- Comment #1 from S. Davis Herring --- It's already wrong for template const int foo = 42; to produce internal linkage; [basic.link]/5.2 excludes variable templates from the rule that const implies static. See also CWG1713.
[Bug ipa/92421] [10 Regression] ICE in inline_small_functions, at ipa-inline.c:2001 since r277759
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92421 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Thu Nov 14 01:02:16 2019 New Revision: 278192 URL: https://gcc.gnu.org/viewcvs?rev=278192&root=gcc&view=rev Log: PR ipa/92421 * g++.dg/torture/pr92421.C: Add -Wno-return-type to dg-additional-options. Avoid -Wwrite-string warnings, most of -Wreturn-type warnings, define bf ctor. Use struct instead of class with public: at the start. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/pr92421.C
[Bug tree-optimization/92493] ICE in get_origin_and_offset at gimple-ssa-sprintf.c:2314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92493 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug target/92465] [10 regression] r278034 breaks gcc.dg/pr47763.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92465 Jiu Fu Guo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jiu Fu Guo --- Missing to update this 'unresolved' case in r278034. Add -fweb for this case.
[Bug target/92256] [10 regression] error in gcc.dg/unroll-and-jam.c after r277501
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92256 Jiu Fu Guo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jiu Fu Guo --- New patch committed to trunk r278034.
[Bug ipa/91682] IPA-cp can not propagate value for by-ref argument in form of *arg = param op constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91682 --- Comment #1 from fxue at gcc dot gnu.org --- Author: fxue Date: Thu Nov 14 03:19:15 2019 New Revision: 278193 URL: https://gcc.gnu.org/viewcvs?rev=278193&root=gcc&view=rev Log: Support extended aggregate jump function in ipa-cp 2019-11-14 Feng Xue PR ipa/91682 * ipa-prop.h (jump_func_type): New value IPA_JF_LOAD_AGG. (ipa_load_agg_data, ipa_agg_value, ipa_agg_value_set): New structs. (ipa_agg_jf_item): Add new field jftype and type, redefine field value. (ipa_agg_jump_function): Remove member function equal_to. (ipa_agg_jump_function_p): Remove typedef. (ipa_copy_agg_values, ipa_release_agg_values): New functions. * ipa-prop.c (ipa_print_node_jump_functions_for_edge): Dump information for aggregate jump function. (get_ssa_def_if_simple_copy): Add new parameter rhs_stmt to record last definition statement. (load_from_unmodified_param_or_agg): New function. (ipa_known_agg_contents_list): Add new field type and value, remove field constant. (build_agg_jump_func_from_list): Rename parameter const_count to value_count, build aggregate jump function from ipa_load_agg_data. (analyze_agg_content_value): New function. (extract_mem_content): Analyze memory store assignment to prepare information for aggregate jump function generation. (determine_known_aggregate_parts): Add new parameter fbi, remove parameter aa_walk_budeget_p. (update_jump_functions_after_inlining): Update aggregate jump function. (ipa_find_agg_cst_for_param): Change type of parameter agg. (try_make_edge_direct_simple_call): Add new parameter new_root. (try_make_edge_direct_virtual_call): Add new parameter new_root and new_root_info. (update_indirect_edges_after_inlining): Pass new argument to try_make_edge_direct_simple_call and try_make_edge_direct_virtual_call. (ipa_write_jump_function): Write aggregate jump function to file. (ipa_read_jump_function): Read aggregate jump function from file. (ipa_agg_value::equal_to): Migrate from ipa_agg_jf_item::equal_to. * ipa-cp.c (ipa_get_jf_arith_result): New function. (ipa_agg_value_from_node): Likewise. (ipa_agg_value_set_from_jfunc): Likewise. (propagate_vals_across_arith_jfunc): Likewise. (propagate_aggregate_lattice): Likewise. (ipa_get_jf_pass_through_result): Call ipa_get_jf_arith_result. (propagate_vals_across_pass_through): Call propagate_vals_across_arith_jfunc. (get_clone_agg_value): Move forward. (propagate_aggs_across_jump_function): Handle value propagation for aggregate jump function. (agg_jmp_p_vec_for_t_vec): Remove. (context_independent_aggregate_values): Replace vec with vec. (copy_plats_to_inter, intersect_with_plats): Likewise. (agg_replacements_to_vector, intersect_with_agg_replacements): Likewise. (intersect_aggregate_with_edge): Likewise. (find_aggregate_values_for_callers_subset): Likewise. (cgraph_edge_brings_all_agg_vals_for_node): Likewise. (estimate_local_effects): Replace vec and vec with vec. (gather_context_independent_values): Likewise. (perform_estimation_of_a_value, decide_whether_version_node): Likewise. * ipa-fnsummary.c (evaluate_conditions_for_known_args): Replace vec with vec. (evaluate_properties_for_edge): Likewise. (estimate_edge_devirt_benefit): Likewise. (estimate_edge_size_and_time): Likewise. (estimate_calls_size_and_time): Likewise. (ipa_call_context::ipa_call_context): Likewise. (estimate_ipcp_clone_size_and_time): Likewise. * ipa-fnsummary.h (ipa_call_context): Replace vec with vec. * ipa-inline-analysis.c (do_estimate_edge_time): Replace vec with vec. (do_estimate_edge_size): Likewise. (do_estimate_edge_hints): Likewise. 2019-11-14 Feng Xue PR ipa/91682 * gcc.dg/ipa/ipcp-agg-10.c: Change dg-scan string. * gcc.dg/ipa/ipcp-agg-11.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/ipcp-agg-11.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/ipa-fnsummary.c trunk/gcc/ipa-fnsummary.h trunk/gcc/ipa-inline-analysis.c trunk/gcc/ipa-prop.c trunk/gcc/ipa-prop.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ipa/ipcp-agg-10.c
[Bug c++/92505] New: Using mutable in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92505
Bug ID: 92505
Summary: Using mutable in constexpr
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
GCC trunk does not accept this well-formed program in -std=c++2a mode:
constexpr int f() {
struct {
mutable int i = 41;
} s;
auto const& cs = s;
return ++cs.i;
}
int main() {
constexpr int i = f();
return 42 - i;
}
Diagnosing (https://godbolt.org/z/n259tb):
: In function 'int main()':
:10:24: in 'constexpr' expansion of 'f()'
:10:25: error: mutable 'f()i' is not usable in
a constant expression
10 | constexpr int i = f();
| ^
Compiler returned: 1
AFAICS this is well-formed back to C++14 since it applies lvalue-to-rvalue
conversion to "a non-volatile glvalue of literal type that refers to a
non-volatile object whose lifetime began within the evaluation of e;".
[Bug target/92492] [AVX512F] Icc generate much better code for loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92492 --- Comment #3 from Hongtao.liu --- (In reply to Richard Biener from comment #2) > ICC also uses effectively two vector sizes, v8qi and v8hi AFAICS? But > why does it use %ymm then... I think it's v8qi and v8si, icc use vpmovzxbd not vpmovzxbw.
[Bug ipa/91089] IPA-cp does not setup proper cost model for switch default case in function versioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91089 Feng Xue changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Feng Xue --- Fixed and close it.
