[Bug target/100866] New: PPC: Inefficient code for vec_revb(vector unsigned short) < P9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
Bug ID: 100866
Summary: PPC: Inefficient code for vec_revb(vector unsigned
short) < P9
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
Input:
vector unsigned short revb(vector unsigned short a)
{
return vec_revb(a);
}
creates:
_Z4revbDv8_t:
.LFB1:
.cfi_startproc
.LCF1:
0: addis 2,12,.TOC.-.LCF1@ha
addi 2,2,.TOC.-.LCF1@l
.localentry _Z4revbDv8_t,.-_Z4revbDv8_t
addis 9,2,.LC1@toc@ha
addi 9,9,.LC1@toc@l
lvx 0,0,9
xxlnor 32,32,32
vperm 2,2,2,0
blr
Optimal code sequence:
vector unsigned short revb_pwr7(vector unsigned short a)
{
return vec_rl(a, vec_splats((unsigned short)8));
}
_Z9revb_pwr7Dv8_t:
.LFB2:
.cfi_startproc
.localentry _Z9revb_pwr7Dv8_t,1
vspltish 0,8
vrlh 2,2,0
blr
[Bug target/100867] New: z13: Inefficient code for vec_revb(vector unsigned short)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100867
Bug ID: 100867
Summary: z13: Inefficient code for vec_revb(vector unsigned
short)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
Input:
vector unsigned short revb(vector unsigned short a)
{
return vec_revb(a);
}
Creates:
_Z4revbDv4_j:
.LFB1:
.cfi_startproc
larl%r5,.L4
vl %v0,.L5-.L4(%r5),3
vperm %v24,%v24,%v24,%v0
br %r14
Optimal code sequence:
vector unsigned short revb_z13(vector unsigned short a)
{
return vec_rli(a, 8);
}
Creates:
_Z8revb_z13Dv8_t:
.LFB5:
.cfi_startproc
verllh %v24,%v24,8
br %r14
.cfi_endproc
[Bug target/100868] New: PPC: Inefficient code for vec_reve(vector double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100868
Bug ID: 100868
Summary: PPC: Inefficient code for vec_reve(vector double)
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
Input:
vector double reve(vector double a)
{
return vec_reve(a);
}
creates:
_Z4reveDv2_d:
.LFB3:
.cfi_startproc
.LCF3:
0: addis 2,12,.TOC.-.LCF3@ha
addi 2,2,.TOC.-.LCF3@l
.localentry _Z4reveDv2_d,.-_Z4reveDv2_d
addis 9,2,.LC2@toc@ha
addi 9,9,.LC2@toc@l
lvx 0,0,9
xxlnor 32,32,32
vperm 2,2,2,0
blr
Optimal sequence would be:
vector double reve_pwr7(vector double a)
{
return vec_xxpermdi(a,a,2);
}
which creates:
_Z9reve_pwr7Dv2_d:
.LFB4:
.cfi_startproc
xxpermdi 34,34,34,2
blr
[Bug target/100869] New: z13: Inefficient code for vec_reve(vector double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100869
Bug ID: 100869
Summary: z13: Inefficient code for vec_reve(vector double)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
Input:
vector double reve(vector double a)
{
return vec_reve(a);
}
creates:
_Z4reveDv2_d:
.LFB3:
.cfi_startproc
larl%r5,.L12
vl %v0,.L13-.L12(%r5),3
vperm %v24,%v24,%v24,%v0
br %r14
Optimal code sequence:
vector double reve_z13(vector double a)
{
return vec_permi(a,a,2);
}
creates:
_Z6reve_2Dv2_d:
.LFB6:
.cfi_startproc
vpdi%v24,%v24,%v24,4
br %r14
.cfi_endproc
[Bug c++/100859] [12 Regression][OpenMP] ICE in tsubst_omp_clauses, at cp/pt.c:17520 since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859 Tobias Burnus changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[12 Regression] ICE in |[12 Regression][OpenMP] ICE |tsubst_omp_clauses, at |in tsubst_omp_clauses, at |cp/pt.c:17520 since |cp/pt.c:17520 since |r12-1108-g9a5de4d5af1c10a8 |r12-1108-g9a5de4d5af1c10a8 --- Comment #2 from Tobias Burnus --- (In reply to Martin Liška from comment #1) > Started with r12-1108-g9a5de4d5af1c10a8. ... unsurprisingly – as the 'affinity' clause wasn't supported before. Using 'depend' instead of 'affinity' fails with: dep.cc:12:58: error: ‘S7::c’ is not a variable in ‘depend’ clause 12 | #pragma omp task depend (iterator (i = 0 : 10 : 1), out: c[i])
[Bug debug/100852] [11/12 Regression] -fcompare-debug failure (length) with -Og -fif-conversion -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100852 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.2 --- Comment #1 from Richard Biener --- So actual code seems to be the same
[Bug fortran/100870] New: Constant expression for bind(C) name in interface body not importable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100870 Bug ID: 100870 Summary: Constant expression for bind(C) name in interface body not importable Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ehlert at thch dot uni-bonn.de Target Milestone: --- Created attachment 50906 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50906&action=edit Minimal reproducer Following example fails to compile with GFortran 10.2.0. The example was checked with Intel's and NAG's Fortran compiler, which both accept the usage of constant expressions imported into an interface body as valid Fortran code. >From the Fortran standard this usage is valid Fortran 2003. Code example to trigger the bug (also in os.f90 attachment): module m_os use, intrinsic :: iso_c_binding implicit none character(len=*), parameter :: chdir_symbol = "chdir" interface function chdir(path) result(stat) bind(C, name=chdir_symbol) import :: c_char, c_int, chdir_symbol character(kind=c_char, len=1), intent(in) :: path(*) integer(c_int) :: stat end function chdir end interface end module m_os Output showing GFortran rejecting this code with an error ❯ gfortran -v -save-temps -Wall -Wextra -fno-strict-aliasing -fwrapv -c os.f90 Using built-in specs. COLLECT_GCC=gfortran Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-c' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/f951 os.f90 -quiet -dumpbase os.f90 -mtune=generic -march=x86-64 -auxbase os -Wall -Wextra -version -fno-strict-aliasing -fwrapv -fintrinsic-modules-path /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/finclude -fpre-include=/usr/include/finclude/math-vector-fortran.h -o os.s GNU Fortran (GCC) version 10.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 10.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 os.f90:7:51: 7 | function chdir(path) result(stat) bind(C, name=chdir_symbol) | 1 Error: Parameter ‘chdir_symbol’ at (1) has not been declared or is a variable, which does not reduce to a constant expression os.f90:8:13: 8 | import :: c_char, c_int, chdir_symbol | 1 Error: IMPORT statement at (1) only permitted in an INTERFACE body os.f90:9:21: 9 | character(kind=c_char, len=1), intent(in) :: path(*) | 1 Error: Parameter ‘c_char’ at (1) has not been declared or is a variable, which does not reduce to a constant expression os.f90:10:14: 10 | integer(c_int) :: stat | 1 Error: Parameter ‘c_int’ at (1) has not been declared or is a variable, which does not reduce to a constant expression os.f90:11:7: 11 | end function chdir | 1 Error: Expecting END INTERFACE statement at (1)
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855 --- Comment #3 from Richard Biener --- Might be interesting to see whether ifort does any expression simplification here. Can you share the produced assembly?
[Bug target/100871] New: z14: vec_doublee maps to wrong builtin in vecintrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100871
Bug ID: 100871
Summary: z14: vec_doublee maps to wrong builtin in vecintrin.h
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
#include
Input:
vector double doublee(vector float a)
{
return vec_doublee(a);
}
cause compile error:
vec.C: In function ‘__vector(2) double doublee(__vector(4) float)’:
vec.C:43:10: error: ‘__builtin_s390_vfll’ was not declared in this scope; did
you mean ‘__builtin_s390_vflls’?
43 |return vec_doublee(a);
| ^~~~
| __builtin_s390_vflls
vec_doublee in vec_intrin.h should call __builtin_s390_vflls
vector double doublee_fix(vector float a)
{
return __builtin_s390_vflls(a);
}
[Bug tree-optimization/100857] Simple common code sinking is not performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100857 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-06-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- There's a duplicate of this PR. sink_common_stores_to_bb could be quite easily enhanced to perform the desired transform on such simple testcases.
[Bug tree-optimization/100858] Simple common code hoisting is not performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100858
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-06-02
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
That's really a duplicate of 100858 - this case can be handled by sinking as
well
since we "sink" the return. Make it
void bar();
int foo(bool f)
{
if (f) {
bar();
__builtin_abort ();
}
else {
bar();
return 2;
}
}
to force hoisting. Hoisting is done by PRE but that requires a LHS and
doesn't handle calls with side-effects.
[Bug c++/100859] [12 Regression][OpenMP] ICE in tsubst_omp_clauses, at cp/pt.c:17520 since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/100864] (a&!b) | b is not opimized to a | b for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864 --- Comment #3 from Richard Biener --- You can possibly merge it with the (for bitop (bit_and bit_ior) rbitop (bit_ior bit_and) /* (x | y) & x -> x */ /* (x & y) | x -> x */ (simplify (bitop:c (rbitop:c @0 @1) @0) @0) /* (~x | y) & x -> x & y */ /* (~x & y) | x -> x | y */ (simplify (bitop:c (rbitop:c (bit_not @0) @1) @0) (bitop @0 @1))) by using sth like logical_inverted_value (you want bit_inverted_value), Also you don't need (for cmp (tcc_comparison) (for icmp (tcc_comparison) but just (for cmp (tcc_comparison) icmp (inverted_tcc_comparison) ncmp (inverted_tcc_comparison_with_nans)) ... (if (ic == icmp || ic == ncmp) ... right?
[Bug middle-end/100872] New: [OpenMP] internal compiler error: tree check: expected integer_cst, have mult_expr in simd_clone_clauses_extract, at omp-simd-clone.c:253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100872
Bug ID: 100872
Summary: [OpenMP] internal compiler error: tree check: expected
integer_cst, have mult_expr in
simd_clone_clauses_extract, at omp-simd-clone.c:253
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Found when compiling clang's OpenMP testsuite for for
* declare_simd_ast_print.cpp:
https://github.com/llvm/llvm-project/blob/main/clang/test/OpenMP/declare_simd_ast_print.cpp
* declare_simd_codegen.cpp:
https://github.com/llvm/llvm-project/blob/main/clang/test/OpenMP/declare_simd_codegen.cpp
template
class TVV {
public:
#pragma omp declare simd aligned(a : X * 2) aligned(b) linear(ref(b): X)
float taddpf(float *a, T *&b) { return *a + *b; }
};
TVV<16, float> t16;
void f() {
float a = 1.0f, b = 2.0f;
float *p = &b;
float r = t16.taddpf(&a, p);
}
foo.C:14:1: internal compiler error: tree check: expected integer_cst, have
mult_expr in simd_clone_clauses_extract, at omp-simd-clone.c:253
14 | }
| ^
0x8828a4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../repos/gcc/gcc/tree.c:8684
0x97210e tree_int_cst_elt_check(tree_node*, int, char const*, int, char const*)
../../repos/gcc/gcc/tree.h:3571
0x97210e simd_clone_clauses_extract
../../repos/gcc/gcc/omp-simd-clone.c:253
0x97210e expand_simd_clones(cgraph_node*)
../../repos/gcc/gcc/omp-simd-clone.c:1695
0x1cf40a7 ipa_omp_simd_clone
../../repos/gcc/gcc/omp-simd-clone.c:1798
[Bug target/100085] Bad code for union transfer from __float128 to vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 --- Comment #9 from luoxhu at gcc dot gnu.org --- Patch sent, it could fix the __float128 to vector __int128 issue, https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571689.html But for __float128 to __int128 mentioned in #c4, need hack rs6000_modes_tieable_p to remove the stack operation in dse1. But I am not sure this is *LEGAL* since TImode is allocated to GPR, It seems not true to access TImode from ALTIVEC or VSX without copying? diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index ad11b67b125..ee69463ac46 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -1974,6 +1974,9 @@ rs6000_modes_tieable_p (machine_mode mode1, machine_mode mode2) || mode2 == PTImode || mode2 == OOmode || mode2 == XOmode) return mode1 == mode2; + if (mode1 == TImode && ALTIVEC_OR_VSX_VECTOR_MODE (mode2)) +return true; + xxpermdi %vs0,%vs34,%vs34,3 mfvsrd %r4,%vs34 mfvsrd %r3,%vs0
[Bug c++/100859] [12 Regression][OpenMP] ICE in tsubst_omp_clauses, at cp/pt.c:17520 since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug tree-optimization/100873] New: [12 Regression] gcc.target/aarch64/subs_compare_2.c fails since r12-1152-g9f55df63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100873 Bug ID: 100873 Summary: [12 Regression] gcc.target/aarch64/subs_compare_2.c fails since r12-1152-g9f55df63 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: acoplan at gcc dot gnu.org Target Milestone: --- For the test gcc.target/aarch64/subs_compare_2.c, we used to generate: foo: subsw0, w0, 4 cselw0, w0, wzr, lt ret but since r12-1152-g9f55df63154a39d67ef5b24def7044bf87300831 we generate: foo: mov w1, 4 cmp w0, w1 cselw0, w0, w1, le sub w0, w0, #4 ret
[Bug target/100874] New: [12 Regression] slight missed optimization with min-CST on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100874
Bug ID: 100874
Summary: [12 Regression] slight missed optimization with
min-CST on aarch64
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-*-*
Take:
int f(int a) { return a < 4 ? a - 4 : 0; }
int f1(int a) { int x = a - 4; if (a < 4) return x; return 0; }
int f2(int a) { int t = a < 4 ? a : 4; return t - 4; }
In GCC 11, we produce:
f(int):
mov w1, 4
cmp w0, w1
cselw0, w0, w1, le
sub w0, w0, #4
ret
f1(int):
subsw0, w0, 4
cselw0, w0, wzr, lt
ret
f2(int):
mov w1, 4
cmp w0, w1
cselw0, w0, w1, le
sub w0, w0, #4
ret
On the trunk all three give the same code gen (due to PHI-OPT being improved)
but of what f and f2 used to give.
All three should produce what f1 had produed instead.
This is gcc.target/aarch64/subs_compare_2.c
[Bug c++/100862] using enum member access fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100862 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-06-02 Status|UNCONFIRMED |NEW
[Bug target/100874] [12 Regression] slight missed optimization with min-CST on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100874 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 --- Comment #1 from Andrew Pinski --- Note clang even does produce the same code gen for all three: https://godbolt.org/z/hq357jdMd Also I put how we could fix this in https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571699.html
[Bug tree-optimization/100873] [12 Regression] gcc.target/aarch64/subs_compare_2.c fails since r12-1152-g9f55df63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100873 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 100874 which has much more anlysis of the problem. *** This bug has been marked as a duplicate of bug 100874 ***
[Bug target/100874] [12 Regression] slight missed optimization with min-CST on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100874 Andrew Pinski changed: What|Removed |Added CC||acoplan at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- *** Bug 100873 has been marked as a duplicate of this bug. ***
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-06-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Hmm, this looks very familiar, I thought that was fixed already.
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855 --- Comment #4 from Nadav Halahmi --- (In reply to Richard Biener from comment #3) > Might be interesting to see whether ifort does any expression simplification > here. Can you share the produced assembly? gfortran pow.f90 -O3 -fno-tree-vectorize -S -o gnu.s: .file "pow.f90" .text .section.rodata.str1.1,"aMS",@progbits,1 .LC5: .string "pow.f90" .LC6: .string "(\"Time = \",f6.3,\" seconds.\")" .text .p2align 4 .type MAIN__, @function MAIN__: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 xorl%eax, %eax movl$1, %ebp pushq %rbx .cfi_def_cfa_offset 24 .cfi_offset 3, -24 subq$568, %rsp .cfi_def_cfa_offset 592 leaq20(%rsp), %rdi call_gfortran_cpu_time_4 pxor%xmm4, %xmm4 movss .LC1(%rip), %xmm2 movss %xmm4, 8(%rsp) .L4: movss .LC2(%rip), %xmm0 movl$1, %ebx jmp .L3 .p2align 4,,10 .p2align 3 .L8: movss .LC3(%rip), %xmm1 pxor%xmm0, %xmm0 movss %xmm2, 12(%rsp) cvtsi2ssl %ebx, %xmm0 mulss %xmm2, %xmm1 addss .LC4(%rip), %xmm1 callpowf movss 12(%rsp), %xmm2 .L3: addss 8(%rsp), %xmm0 addl$1, %ebx mulss .LC3(%rip), %xmm2 movss %xmm0, 8(%rsp) cmpl$10001, %ebx jne .L8 subl$1, %ebp jne .L4 leaq16(%rsp), %rdi xorl%eax, %eax movss %xmm0, 24(%rsp) call_gfortran_cpu_time_4 leaq32(%rsp), %rdi movabsq $25769803904, %rax movq$.LC5, 40(%rsp) movq%rax, 32(%rsp) movl$21, 48(%rsp) call_gfortran_st_write leaq24(%rsp), %rsi movl$4, %edx leaq32(%rsp), %rdi call_gfortran_transfer_real_write leaq32(%rsp), %rdi call_gfortran_st_write_done leaq32(%rsp), %rdi movabsq $25769807872, %rax movq$.LC5, 40(%rsp) movq%rax, 32(%rsp) movl$22, 48(%rsp) movq$.LC6, 112(%rsp) movq$28, 120(%rsp) call_gfortran_st_write movss 16(%rsp), %xmm0 subss 20(%rsp), %xmm0 leaq28(%rsp), %rsi leaq32(%rsp), %rdi movl$4, %edx movss %xmm0, 28(%rsp) call_gfortran_transfer_real_write leaq32(%rsp), %rdi call_gfortran_st_write_done addq$568, %rsp .cfi_def_cfa_offset 24 popq%rbx .cfi_def_cfa_offset 16 popq%rbp .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE0: .size MAIN__, .-MAIN__ .section.text.startup,"ax",@progbits .p2align 4 .globl main .type main, @function main: .LFB1: .cfi_startproc subq$8, %rsp .cfi_def_cfa_offset 16 call_gfortran_set_args movl$options.2.0, %esi movl$7, %edi call_gfortran_set_options callMAIN__ xorl%eax, %eax addq$8, %rsp .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE1: .size main, .-main .section.rodata .align 16 .type options.2.0, @object .size options.2.0, 28 options.2.0: .long 2116 .long 4095 .long 0 .long 1 .long 1 .long 0 .long 31 .section.rodata.cst4,"aM",@progbits,4 .align 4 .LC1: .long 1073741824 .align 4 .LC2: .long 1065353216 .align 4 .LC3: .long 1056964608 .align 4 .LC4: .long 1028443341 .ident "GCC: (GNU) 11.1.0" .section.note.GNU-stack,"",@progbits
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855 --- Comment #5 from Nadav Halahmi --- (In reply to Richard Biener from comment #3) > Might be interesting to see whether ifort does any expression simplification > here. Can you share the produced assembly? ifort pow.f90 -O3 -no-vec -S -o intel.s: # mark_description "Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.3.304 Build 2020"; # mark_description "0925_00"; # mark_description "-O3 -no-vec -S -o intel.s"; .file "pow.f90" .text ..TXTST0: .L_2__routine_start_MAIN___0: # -- Begin MAIN__ .text # mark_begin; .align16,0x90 .globl MAIN__ # --- POWER MAIN__: ..B1.1: # Preds ..B1.0 # Execution count [1.00e+00] .cfi_startproc ..___tag_value_MAIN__.1: ..L2: #1.9 pushq %rbp #1.9 .cfi_def_cfa_offset 16 movq %rsp, %rbp#1.9 .cfi_def_cfa 6, 16 .cfi_offset 6, -16 andq $-128, %rsp #1.9 subq $128, %rsp#1.9 movl $3, %edi #1.9 xorl %esi, %esi#1.9 call __intel_new_feature_proc_init #1.9 # LOE rbx r12 r13 r14 r15 ..B1.13:# Preds ..B1.1 # Execution count [1.00e+00] stmxcsr (%rsp)#1.9 movl $__NLITPACK_0.0.1, %edi #1.9 orl $32832, (%rsp)#1.9 ldmxcsr (%rsp)#1.9 call for_set_reentrancy#1.9 # LOE rbx r12 r13 r14 r15 ..B1.2: # Preds ..B1.13 # Execution count [1.00e+00] movss .L_2il0floatpacket.0(%rip), %xmm1 #11.5 lea 80(%rsp), %rdi#13.10 movss %xmm1, -64(%rdi) #11.5[spill] pxor %xmm0, %xmm0 #9.5 movss %xmm0, -8(%rdi) #9.5[spill] call for_cpusec#13.10 # LOE rbx r12 r13 r14 r15 ..B1.3: # Preds ..B1.2 # Execution count [8.67e-01] movl $1, %eax #14.5 movq %r15, (%rsp) #12.5[spill] movq %rbx, 8(%rsp) #12.5[spill] .cfi_escape 0x10, 0x03, 0x0e, 0x38, 0x1c, 0x0d, 0x80, 0xff, 0xff, 0xff, 0x1a, 0x0d, 0x88, 0xff, 0xff, 0xff, 0x22 .cfi_escape 0x10, 0x0f, 0x0e, 0x38, 0x1c, 0x0d, 0x80, 0xff, 0xff, 0xff, 0x1a, 0x0d, 0x80, 0xff, 0xff, 0xff, 0x22 movl %eax, %ebx#12.5 # LOE r12 r13 r14 ebx ..B1.4: # Preds ..B1.6 ..B1.3 # Execution count [5.33e+00] movl $1, %r15d #15.9 # LOE r12 r13 r14 ebx r15d ..B1.5: # Preds ..B1.14 ..B1.4 # Execution count [2.96e+01] movss 16(%rsp), %xmm2 #16.13[spill] pxor %xmm0, %xmm0 #17.28 mulss .L_2il0floatpacket.1(%rip), %xmm2 #16.13 cvtsi2ss %r15d, %xmm0 #17.28 movss .L_2il0floatpacket.2(%rip), %xmm1 #17.28 movss %xmm2, 16(%rsp) #16.13[spill] addss %xmm2, %xmm1 #17.28 call powf #17.28 # LOE r12 r13 r14 ebx r15d xmm0 ..B1.14:# Preds ..B1.5 # Execution count [2.96e+01] movss 72(%rsp), %xmm1 #17.13[spill] incl %r15d #18.9 addss %xmm0, %xmm1 #17.13 movss %xmm1, 72(%rsp) #17.13[spill] cmpl $1, %r15d #18.9 jle ..B1.5# Prob 82% #18.9 # LOE r12 r13 r14 ebx r15d ..B1.6:
[Bug target/100874] [12 Regression] slight missed optimization with min-CST on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100874
--- Comment #3 from Andrew Pinski ---
Note here is a 4th variant of the function:
int f1a(int a) { int x = a - 4; return (a < 4) ? x : 0; }
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #17 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:9ca24bd34b6ac44c17f949d89ff60d0fd4665133 commit r12-1158-g9ca24bd34b6ac44c17f949d89ff60d0fd4665133 Author: Tobias Burnus Date: Wed Jun 2 11:48:21 2021 +0200 Fortran/OpenMP: Add gfortran.dg/gomp/taskloop-2.f90 [PR99928] PR middle-end/99928 gcc/testsuite/ChangeLog * gfortran.dg/gomp/taskloop-2.f90: New.
[Bug c++/100859] [12 Regression][OpenMP] ICE in tsubst_omp_clauses, at cp/pt.c:17520 since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859
--- Comment #3 from Jakub Jelinek ---
WIP testcase:
struct S {
S () {}
};
struct W {
S c[10];
W () {
#pragma omp task affinity (iterator (i = 0 : 10 : 1): c[i])
;
#pragma omp task depend (iterator (i = 0 : 10 : 1), inout: c[i])
;
#pragma omp task affinity (this[0])
;
#pragma omp task depend (inout: this[0])
;
#pragma omp taskwait
}
};
template
struct U {
T c[10];
U () {
#pragma omp task affinity (iterator (i = 0 : 10 : 1): c[i])
;
#pragma omp task depend (iterator (i = 0 : 10 : 1), inout: c[i])
;
#pragma omp task affinity (this[0])
;
#pragma omp task depend (inout: this[0])
;
#pragma omp taskwait
}
};
struct V : public U {
V () : U () {}
};
W w;
V v;
and WIP patch:
--- gcc/cp/semantics.c.jj 2021-06-02 10:07:47.633826543 +0200
+++ gcc/cp/semantics.c 2021-06-02 11:35:39.490212873 +0200
@@ -4968,7 +4968,11 @@ handle_omp_array_sections_1 (tree c, tre
if (REFERENCE_REF_P (t))
t = TREE_OPERAND (t, 0);
}
- if (!VAR_P (t) && TREE_CODE (t) != PARM_DECL)
+ if (TREE_CODE (t) == FIELD_DECL
+ && (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_AFFINITY
+ || OMP_CLAUSE_CODE (c) == OMP_CLAUSE_DEPEND))
+ ret = finish_non_static_data_member (t, NULL_TREE, NULL_TREE);
+ else if (!VAR_P (t) && TREE_CODE (t) != PARM_DECL)
{
if (processing_template_decl && TREE_CODE (t) != OVERLOAD)
return NULL_TREE;
@@ -4985,7 +4989,9 @@ handle_omp_array_sections_1 (tree c, tre
else if (ort == C_ORT_OMP
&& TREE_CODE (t) == PARM_DECL
&& DECL_ARTIFICIAL (t)
- && DECL_NAME (t) == this_identifier)
+ && DECL_NAME (t) == this_identifier
+ && OMP_CLAUSE_CODE (c) != OMP_CLAUSE_AFFINITY
+ && OMP_CLAUSE_CODE (c) != OMP_CLAUSE_DEPEND)
{
error_at (OMP_CLAUSE_LOCATION (c),
"% allowed in OpenMP only in %"
@@ -7468,7 +7474,6 @@ finish_omp_clauses (tree clauses, enum c
}
goto handle_field_decl;
- case OMP_CLAUSE_AFFINITY:
case OMP_CLAUSE_DEPEND:
t = OMP_CLAUSE_DECL (c);
if (t == NULL_TREE)
@@ -7477,13 +7482,15 @@ finish_omp_clauses (tree clauses, enum c
== OMP_CLAUSE_DEPEND_SOURCE);
break;
}
- if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_DEPEND
- && OMP_CLAUSE_DEPEND_KIND (c) == OMP_CLAUSE_DEPEND_SINK)
+ if (OMP_CLAUSE_DEPEND_KIND (c) == OMP_CLAUSE_DEPEND_SINK)
{
if (cp_finish_omp_clause_depend_sink (c))
remove = true;
break;
}
+ /* FALLTHRU */
+ case OMP_CLAUSE_AFFINITY:
+ t = OMP_CLAUSE_DECL (c);
if (TREE_CODE (t) == TREE_LIST
&& TREE_PURPOSE (t)
&& TREE_CODE (TREE_PURPOSE (t)) == TREE_VEC)
@@ -7543,11 +7550,9 @@ finish_omp_clauses (tree clauses, enum c
&& TREE_CODE (TREE_OPERAND (t, 1)) == FIELD_DECL
&& DECL_BIT_FIELD (TREE_OPERAND (t, 1)))
{
- gcc_assert (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_DEPEND
- || OMP_CLAUSE_CODE (c) == OMP_CLAUSE_AFFINITY);
error_at (OMP_CLAUSE_LOCATION (c),
"bit-field %qE in %qs clause", t,
- omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
+ omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
remove = true;
}
else if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_DEPEND
--- gcc/cp/pt.c.jj 2021-05-31 10:11:15.149978907 +0200
+++ gcc/cp/pt.c 2021-06-02 10:41:31.319178655 +0200
@@ -17399,6 +17399,7 @@ tsubst_omp_clauses (tree clauses, enum c
case OMP_CLAUSE_COPYPRIVATE:
case OMP_CLAUSE_UNIFORM:
case OMP_CLAUSE_DEPEND:
+ case OMP_CLAUSE_AFFINITY:
case OMP_CLAUSE_FROM:
case OMP_CLAUSE_TO:
case OMP_CLAUSE_MAP:
There are still ICEs on it though (on the non-template case).
[Bug c++/100850] [coroutine] Wrong addresses of variables captured by reference into lambda co-routines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100850 --- Comment #4 from Iain Sandoe --- (In reply to Vlad from comment #3) > My bad. It's actually a UB. The lambda lifetime is just over by the moment > of resumption of the co-routine. (oddly enough) we were discussing thia in a BSI meeting yesterday, perhaps the compiler can do more to warn you if you are making a "dangerous" use of reference. The standard itself has a warning about it - but most people don't read the standard, of course. Can this be closed then?
[Bug c++/100859] [12 Regression][OpenMP] ICE in tsubst_omp_clauses, at cp/pt.c:17520 since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859 --- Comment #4 from Jakub Jelinek --- That last ICE seems to be specific to cdtors only, so iterator handling during cdtor cloning...
[Bug fortran/100875] New: Spurious behavior for non-advancing user defined derived type IO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100875 Bug ID: 100875 Summary: Spurious behavior for non-advancing user defined derived type IO Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ehlert at thch dot uni-bonn.de Target Milestone: --- Created attachment 50907 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50907&action=edit Minimal reproducer First reported in https://github.com/fortran-lang/stdlib/issues/354 This is an instance of user defined derived type IO using non-advancing read to retrieve a whole line into a deferred length character component of a derived type. The implementation boils more or less down to the following subroutine (complete reproducer attached): !> Read a character sequence from a connected formatted unit into the string. subroutine read_formatted(string, unit, iotype, v_list, iostat, iomsg) type(string_type), intent(inout) :: string integer, intent(in) :: unit character(len=*), intent(in) :: iotype integer, intent(in) :: v_list(:) integer, intent(out) :: iostat character(len=*), intent(inout) :: iomsg character(len=:), allocatable :: line call read_line(unit, line, iostat, iomsg) string%raw = line contains !> Internal routine to read a whole record from a formatted unit subroutine read_line(unit, line, iostat, iomsg) integer, intent(in) :: unit character(len=:), allocatable, intent(out) :: line integer, intent(out) :: iostat character(len=*), intent(inout) :: iomsg integer, parameter :: buffer_size = 512 character(len=buffer_size) :: buffer integer :: chunk line = '' do read(unit, '(a)', iostat=iostat, iomsg=iomsg, size=chunk, advance='no') & buffer if (iostat > 0) exit line = line // buffer(:chunk) if (iostat < 0) exit end do if (is_iostat_eor(iostat)) then iostat = 0 end if end subroutine read_line end subroutine read_formatted Reading from a file with three lines (1) Some value (2) Important saved value (3) Another line will skip the second line when using the above routine through the write(formatted) interface. Compiling and running the minimal reproducer yields: ❯ gfortran -v -save-temps -Wall -Wextra -fno-strict-aliasing -fwrapv mwe.f90 Driving: gfortran -v -save-temps -Wall -Wextra -fno-strict-aliasing -fwrapv mwe.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/f951 mwe.f90 -quiet -dumpbase mwe.f90 -mtune=generic -march=x86-64 -auxbase mwe -Wall -Wextra -version -fno-strict-aliasing -fwrapv -fintrinsic-modules-path /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/finclude -fpre-include=/usr/include/finclude/math-vector-fortran.h -o mwe.s GNU Fortran (GCC) version 10.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 10.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 mwe.f90:217:29: 217 | character(len=512) :: flc | 1 Warning: Unused variable ‘flc’ declared at (1) [-Wunused-variable] COLLECT_GCC_OPTIONS='-v' '
[Bug c++/100850] [coroutine] Wrong addresses of variables captured by reference into lambda co-routines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100850 --- Comment #5 from Vlad --- > Can this be closed then? Sure. Thanks you very much! For the history, before it's closed I'd like to leave this reference: https://stackoverflow.com/questions/60592174/lambda-lifetime-explanation-for-c20-coroutines
[Bug c++/100850] [coroutine] Wrong addresses of variables captured by reference into lambda co-routines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100850 Iain Sandoe changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #6 from Iain Sandoe --- this is a known "gotcha" with coroutines and use of references (it's accepted that perhaps there could be better diagnostics about it).
[Bug c++/84476] [[nodiscard]] ignored on virtual functions accessed through pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84476 --- Comment #3 from Jonathan Wakely --- (In reply to Martin Ankerl from comment #1) > I just "discovered" this bug as well. The warning works correctly in g++ > 6.4, but starting from 7.1 upwards it does not work any more. No, I don't think that's true, this never worked. The warning for gcc 6 is telling you that it doesn't understand the [[nodiscard]] attribute. You would get the same warning for [[lolwut]]. GCC 7 does understand the attribute, so that -Wattributes warning is gone, but the expected warning about the unused result is missing.
[Bug c++/97712] Attribute nodiscard in virtual methods is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97712 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Jonathan Wakely --- . *** This bug has been marked as a duplicate of bug 84476 ***
[Bug c++/84476] [[nodiscard]] ignored on virtual functions accessed through pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84476 Jonathan Wakely changed: What|Removed |Added CC||pacoarjonilla at yahoo dot es --- Comment #4 from Jonathan Wakely --- *** Bug 97712 has been marked as a duplicate of this bug. ***
[Bug c++/84476] [[nodiscard]] ignored on virtual functions accessed through pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84476 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2021-04-21 00:00:00 |2021-6-2 --- Comment #5 from Jonathan Wakely --- In PR 97712 Jakub said: [[nodiscard]] is a function attribute rather than function type attribute, so it really doesn't apply to virtual calls (unless it can be devirtualized early).
[Bug other/44032] internals documentation is not legally safe to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032 --- Comment #11 from Jonathan Wakely --- I don't think the policy change affects this at all. There is no change to the licenses of any GCC code or docs.
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 --- Comment #3 from Jonathan Wakely --- Do we ever want the _Hashtable_ebo_helper to *not* value-init its T subobject? I think we should do the value-init in _Hashtable_ebo_helper instead.
[Bug translation/90120] inconsistent punctuation in translation messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120 Claudiu Zissulescu changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Claudiu Zissulescu --- Fixed by this commit: fe3ddee943061bd1f93c42f5c37fbc2c2155a15e
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 90120, which changed state. Bug 90120 Summary: inconsistent punctuation in translation messages https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/100872] [OpenMP] internal compiler error: tree check: expected integer_cst, have mult_expr in simd_clone_clauses_extract, at omp-simd-clone.c:253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100872
--- Comment #1 from Tobias Burnus ---
The problem is that
aligned(a : X * 2)
In pt.c's apply_late_template_attributes, we have:
>
value > value >
chain >
value
op-1:
The comment in apply_late_template_attributes states:
/* save_template_attributes puts the dependent attributes at the beginning of
the list; find the non-dependent ones. */
for (t = attributes; t; t = TREE_CHAIN (t))
if (!ATTR_IS_DEPENDENT (t))
break;
But as the first item is !ATTR_IS_DEPEND, attributes == nondep and the
following loop is skipped - also for 'tree_0', which contains our 'omp declare
simd':
for (t = attributes; t != nondep; t = TREE_CHAIN (t))
{
*q = tsubst_attribute (t, decl_p, args, complain, in_decl);
The latter, i.e. 'tree_0' has a proper
43480 ATTR_IS_DEPENDENT (c) = 1;
set in cp_parser_late_parsing_omp_declare_simd.
However, the problem seems to be that save_template_attributes is never run for
the fndel.
* It is run for 'class TVV' itself.
* And then there is the call:
tsubst_decl -> tsubst_function_decl
-> apply_late_template_attributes
which has the tree as shown above.
[Bug ipa/99122] [10 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #31 from Eric Botcazou --- > We talked about backporting the patches to GCC 10 with Richi on IRC today > and decided to wait for potential fallout even if we miss the 10.3 release. The fallout is major in Ada for the return part because the logic completely overlooks the CALL_EXPR_RETURN_SLOT_OPT flag; when it is set, you don't need to create a variable in the caller when inlining the function, so this works: procedure Inline22 (L, U : Integer) is type Arr is array (Integer range L .. U) of Boolean; function Get_Zero return Arr; pragma Inline_Always (Get_Zero); function Get_Zero return Arr is begin return (others => False); end; A : Arr; begin A := Get_Zero; end; eric@fomalhaut:~/install/gcc-10/bin/gcc -c inline22.adb eric@fomalhaut:~/install/gcc-11/bin/gcc -c inline22.adb inline22.adb: In function 'Inline22.Get_Zero': inline22.adb:10:3: error: function 'Inline22.Get_Zero' can never be inlined because it has a VLA return argument
[Bug ipa/99122] [10 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #32 from Richard Biener --- + /* We cannot inline a function with a VLA typed argument or result since + we have no implementation materializing a variable of such type in + the caller. */ + if (COMPLETE_TYPE_P (TREE_TYPE (TREE_TYPE (fndecl))) + && !poly_int_tree_p (TYPE_SIZE (TREE_TYPE (TREE_TYPE (fndecl) +return true; so that would mean adding && !DECL_BY_REFERENCE (DECL_RESULT (fndecl)) I suppose or looking at DECL_RESULT in the first place (which is a pointer in that case).
[Bug c++/100859] [12 Regression][OpenMP] ICE in tsubst_omp_clauses, at cp/pt.c:17520 since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859 --- Comment #5 from Jakub Jelinek --- Created attachment 50908 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50908&action=edit gcc12-pr100859.patch Full untested patch.
[Bug ipa/99122] [10 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #33 from Eric Botcazou --- > so that would mean adding > >&& !DECL_BY_REFERENCE (DECL_RESULT (fndecl)) > > I suppose or looking at DECL_RESULT in the first place (which is a pointer > in that case). Not in the array case though: (gdb) p debug_tree(fndecl->decl_non_common.result) decl_non_common.result->decl_common.decl_by_reference_flag $16 = 0
[Bug libstdc++/96088] Range insertion into unordered_map is less effective than a loop with insertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:81eab204a56dcd8acb1ca5d7df277437ca07b51a commit r12-1162-g81eab204a56dcd8acb1ca5d7df277437ca07b51a Author: Jonathan Wakely Date: Wed Jun 2 12:33:38 2021 +0100 libstdc++: Fix tests for COW std::string [PR 96088] The expected number of allocations is different when copying COW strings. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/96088 * testsuite/23_containers/unordered_map/96088.cc: Adjust expected number of allocations. * testsuite/23_containers/unordered_set/96088.cc: Likewise.
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f8f0193b5b83f6e85d65015e79c803295baf5166 commit r12-1163-gf8f0193b5b83f6e85d65015e79c803295baf5166 Author: Jonathan Wakely Date: Wed Jun 2 12:34:48 2021 +0100 libstdc++: Value-initialize objects held by EBO helpers [PR 100863] The allocator, hash function and equality function should all be value-initialized by the default constructor of an unordered container. Do it in the EBO helper, so we don't have to get it right in multiple places. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/100863 PR libstdc++/65816 * include/bits/hashtable_policy.h (_Hashtable_ebo_helper): Value-initialize subobject. * testsuite/23_containers/unordered_map/allocator/default_init.cc: Remove XFAIL. * testsuite/23_containers/unordered_set/allocator/default_init.cc: Remove XFAIL.
[Bug c++/65816] Constructor delegation does not perform zero-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f8f0193b5b83f6e85d65015e79c803295baf5166 commit r12-1163-gf8f0193b5b83f6e85d65015e79c803295baf5166 Author: Jonathan Wakely Date: Wed Jun 2 12:34:48 2021 +0100 libstdc++: Value-initialize objects held by EBO helpers [PR 100863] The allocator, hash function and equality function should all be value-initialized by the default constructor of an unordered container. Do it in the EBO helper, so we don't have to get it right in multiple places. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/100863 PR libstdc++/65816 * include/bits/hashtable_policy.h (_Hashtable_ebo_helper): Value-initialize subobject. * testsuite/23_containers/unordered_map/allocator/default_init.cc: Remove XFAIL. * testsuite/23_containers/unordered_set/allocator/default_init.cc: Remove XFAIL.
[Bug ipa/99122] [10 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #34 from Richard Biener --- interestingly I see a.9_70 = .builtin_alloca_with_align (iftmp.8_1, 8); (*a.9_70) = inline22.get_zero (); [static-chain: &FRAME.20] [return slot optimization] so there's no WITH_SIZE_EXPR, but the return value ends up done by reference: leaq-80(%rbp), %rdx movq%rdx, %r10 movq%rax, %rdi callinline22__get_zero.0 movq%rbx, %rsp movq-8(%rbp), %rbx leave so I wonder if omitting DECL_BY_REFERENCE is simply a bug? I mean the ABI of the callee must be aware and it seems CALL_EXPR_RETURN_SLOT_OPT is set by gimplification. IIRC CALL_EXPR_RETURN_SLOT_OPT also only means we _may_ return by reference not that we must. /* In a CALL_EXPR, means that it's safe to use the target of the call expansion as the return slot for a call that returns in memory. */ #define CALL_EXPR_RETURN_SLOT_OPT(NODE) \ (CALL_EXPR_CHECK (NODE)->base.private_flag) But of course if we do not exercise the return slot opt then there definitely is a WITH_SIZE_EXPR missing. Unless I'm missing somehting ... The gimplifier code checks else if (TREE_CODE (*to_p) != SSA_NAME && (!is_gimple_variable (*to_p) || needs_to_live_in_memory (*to_p))) /* Don't use the original target if it's already addressable; if its address escapes, and the called function uses the NRV optimization, a conforming program could see *to_p change before the called function returns; see c++/19317. When optimizing, the return_slot pass marks more functions as safe after we have escape info. */ use_target = false; so I wonder if you can modify the Ada testcase so that CALL_EXPR_RETURN_SLOT_OPT is not set?
[Bug c++/100862] using enum member access fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100862 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Done
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Version|11.0|12.0
[Bug ipa/99122] [10 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #35 from Eric Botcazou --- > interestingly I see > > a.9_70 = .builtin_alloca_with_align (iftmp.8_1, 8); > (*a.9_70) = inline22.get_zero (); [static-chain: &FRAME.20] [return slot > optimization] > > so there's no WITH_SIZE_EXPR, but the return value ends up done by reference: > > leaq-80(%rbp), %rdx > movq%rdx, %r10 > movq%rax, %rdi > callinline22__get_zero.0 > movq%rbx, %rsp > movq-8(%rbp), %rbx > leave > > so I wonder if omitting DECL_BY_REFERENCE is simply a bug? I mean the > ABI of the callee must be aware and it seems CALL_EXPR_RETURN_SLOT_OPT > is set by gimplification. IIRC CALL_EXPR_RETURN_SLOT_OPT also only means > we _may_ return by reference not that we must. I don't think it's a bug, in the sense that you can be aggregate_value_p without being DECL_BY_REFERENCE, as it's the case here; the latter is explicit in the GIMPLE representation whereas the former is not. > But of course if we do not exercise the return slot opt then there definitely > is a WITH_SIZE_EXPR missing. Unless I'm missing somehting ... WITH_SIZE_EXPR is for something else (self-referential types). > so I wonder if you can modify the Ada testcase so that > CALL_EXPR_RETURN_SLOT_OPT is not set? No, CALL_EXPR_RETURN_SLOT_OPT is always set, that's the point.
[Bug fortran/100860] class(*) type is (character(*)) produces a segmentation fault when run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860 --- Comment #3 from Tom Robinson --- I tried with the main (12.0.0) and this code ran. I will try it in with our main codebase to confirm it works there too.
[Bug fortran/100860] class(*) type is (character(*)) produces a segmentation fault when run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860 Tom Robinson changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tom Robinson --- Actually, it looks like someone else saw this bug report and tested the code. They reported it worked. Thanks.
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 --- Comment #17 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ad4c21f0f59b52357019148ec94d767aa2acd8f2 commit r11-8500-gad4c21f0f59b52357019148ec94d767aa2acd8f2 Author: Jonathan Wakely Date: Tue Jun 1 11:00:16 2021 +0100 libstdc++: Fix installation of python hooks [PR 99453] When no shared library is installed, the new code to determine the name of the -gdb.py file yields an empty string. Use the name of the static library in that case. libstdc++-v3/ChangeLog: PR libstdc++/99453 * python/Makefile.am: Use archive name for printer hook if no dynamic library name is available. * python/Makefile.in: Regenerate. (cherry picked from commit 9f7bc160b4a0f27dce248d1226e3ae7104b0e67b)
[Bug libstdc++/100768] Range iterator operations should be function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100768 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f2b76257e9a487fd2c7265094f7b4d1bd46f5f03 commit r11-8501-gf2b76257e9a487fd2c7265094f7b4d1bd46f5f03 Author: Jonathan Wakely Date: Wed May 26 17:32:53 2021 +0100 libstdc++: Change [range.iter.op] functions to function objects [PR 100768] The standard specifies std::ranges::distance etc as function templates, but it also requires them to not be found by ADL, and to suppress ADL when normal unqualified lookup does find them. That means they need to be function objects. libstdc++-v3/ChangeLog: PR libstdc++/100768 * include/bits/ranges_base.h (advance, distance, next, prev): Replace function templates with function objects. * testsuite/24_iterators/headers/iterator/synopsis_c++20.cc: Adjust for changes to function objects. * testsuite/std/ranges/adaptors/elements.cc: Add using declarations for names from namespace ranges. * testsuite/std/ranges/adaptors/transform.cc: Likewise. * testsuite/24_iterators/range_operations/100768.cc: New test. (cherry picked from commit a49a045b92f982f5617c3bbde97a33157237e25b)
[Bug libstdc++/100833] ranges::advance should return n when i == bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100833 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:88ed4abb351117f3b7ef9174b3f538c73e6012c7 commit r11-8502-g88ed4abb351117f3b7ef9174b3f538c73e6012c7 Author: Jonathan Wakely Date: Tue Jun 1 16:02:45 2021 +0100 libstdc++: Fix return value of std::ranges::advance [PR 100833] The three-argument form of ranges::advance is supposed to return the difference between the second argument and the distance the iterator was advanced. When a non-random-access iterator is not advanced (because it already equals the sentinel) we were returning 0 rather than n - 0. libstdc++-v3/ChangeLog: PR libstdc++/100833 * include/bits/ranges_base.h (ranges::advance(iter, n, sentinel)): Fix return value for no-op case. * testsuite/24_iterators/range_operations/advance.cc: Test return values of three-argument overload. (cherry picked from commit d8326291695c0f13124c232ddf4fd34e3310e649)
[Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:10c58754a862470484eca81623b71e6851470bb6 commit r11-8503-g10c58754a862470484eca81623b71e6851470bb6 Author: Jonathan Wakely Date: Thu May 20 16:39:06 2021 +0100 libstdc++: Use __builtin_unreachable for constexpr assertions [PR 100676] The current implementation of compile-time precondition checks causes compilation to fail by calling a non-constexpr function declared at block scope. This breaks the CUDA compiler, which wraps some libstdc++ headers in a pragma that declares everything as a __host__ __device__ function, but others are not wrapped and so everything is a __host__ function. The local declaration thus gets redeclared as two different types of function, which doesn't work. Just use __builtin_unreachable to make constant evaluation fail, instead of the local function declaration. Also simplify the assertion macros, which has the side effect of giving simpler compilation errors when using Clang. libstdc++-v3/ChangeLog: PR libstdc++/100676 * include/bits/c++config (__glibcxx_assert_1): Rename to ... (__glibcxx_constexpr_assert): ... this. (__glibcxx_assert_impl): Use __glibcxx_constexpr_assert. (__glibcxx_assert): Define as either __glibcxx_constexpr_assert or __glibcxx_assert_impl. (__glibcxx_assert_2): Remove * include/debug/macros.h (_GLIBCXX_DEBUG_VERIFY_AT_F): Use __glibcxx_constexpr_assert instead of __glibcxx_assert_1. * testsuite/21_strings/basic_string_view/element_access/char/back_constexpr_neg.cc: Adjust expected error. * testsuite/21_strings/basic_string_view/element_access/char/constexpr_neg.cc: Likewise. * testsuite/21_strings/basic_string_view/element_access/char/front_constexpr_neg.cc: Likewise. Likewise. * testsuite/21_strings/basic_string_view/element_access/wchar_t/back_constexpr_neg.cc: Likewise. * testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc: Likewise. * testsuite/21_strings/basic_string_view/element_access/wchar_t/front_constexpr_neg.cc: Likewise. * testsuite/23_containers/span/back_neg.cc: Likewise. * testsuite/23_containers/span/front_neg.cc: Likewise. * testsuite/23_containers/span/index_op_neg.cc: Likewise. (cherry picked from commit 6b42b5a8a207de5e021a2916281f46bcd60b20d2)
[Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jonathan Wakely --- Fixed for 11.2
[Bug c++/100876] New: -Wmismatched-new-delete should either look through or ignore placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 Bug ID: 100876 Summary: -Wmismatched-new-delete should either look through or ignore placement new Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redbeard0531 at gmail dot com Target Milestone: --- https://godbolt.org/z/KTTMrEGns Example code: free(new (malloc(4)) int()); // Warns but shouldn't delete new (malloc(4)) int(); // Doesn't warn but should output: :5:9: warning: 'void free(void*)' called on pointer returned from a mismatched allocation function [-Wmismatched-new-delete] 5 | free(new (malloc(4)) int()); // Warns but shouldn't | ^~~ :5:30: note: returned from 'void* operator new(std::size_t, void*)' 5 | free(new (malloc(4)) int()); // Warns but shouldn't | ^ While it would be nice to have a warning on the second line, not warning on the first seems more important. And hopefully is a backportable fix. Here is some Real World Code exhibiting this pattern that g++ currently warns about when compiling: https://github.com/facebook/hermes/blob/dfef1abd6d20b196e24c591e225a7003e6337a94/unittests/VMRuntime/StringPrimitiveTest.cpp#L221-L235. There is also an example using calloc() lower in that file.
[Bug middle-end/100872] [12 Regression] [OpenMP] internal compiler error: tree check: expected integer_cst, have mult_expr in simd_clone_clauses_extract, at omp-simd-clone.c:253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100872 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-06-02 Ever confirmed|0 |1 Target Milestone|--- |12.0 Summary|[OpenMP] internal compiler |[12 Regression] [OpenMP] |error: tree check: expected |internal compiler error: |integer_cst, have mult_expr |tree check: expected |in |integer_cst, have mult_expr |simd_clone_clauses_extract, |in |at omp-simd-clone.c:253 |simd_clone_clauses_extract, ||at omp-simd-clone.c:253 --- Comment #2 from Jakub Jelinek --- Started with the PR51577 fix r12-702-g6ab1176667734bd6de20833f8d263c03a418c452
[Bug middle-end/100872] [12 Regression] [OpenMP] internal compiler error: tree check: expected integer_cst, have mult_expr in simd_clone_clauses_extract, at omp-simd-clone.c:253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100872 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 50909 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50909&action=edit gcc12-pr100872.patch Untested fix.
[Bug testsuite/100750] new test case gcc.target/powerpc/rop-5.c fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Bill Schmidt --- The LE problems were shown to be an out-of-date assembler, so this is now fixed.
[Bug target/100866] PPC: Inefficient code for vec_revb(vector unsigned short) < P9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866 Segher Boessenkool changed: What|Removed |Added Target|powerpc-*-*-* |powerpc* Severity|normal |enhancement Last reconfirmed||2021-06-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Segher Boessenkool --- Confirmed. There are other ways to write this in two insns, but this is probably the cheapest and simplest, and the immediate can be reused potentially.
[Bug c++/100877] New: g++ freezes system by consuming infinite amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100877 Bug ID: 100877 Summary: g++ freezes system by consuming infinite amount of memory Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wang_feng at live dot com Target Milestone: --- Created attachment 50910 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50910&action=edit The preprocessed source code to reproduce the problem. g++ tends to allocate infinite amount of memory while compiling this program. 1. g++ version: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.0 (GCC) 2. compile command (dcgan.cc is attached with this report): g++ -c -std=c++20 -Wall -Wextra -fmax-errors=1 -ftemplate-backtrace-limit=0 -fdata-sections -ffunction-sections -funsafe-math-optimizations -fconcepts-diagnostics-depth=4 -ftemplate-depth=100860 -Ofast -flto -pipe -march=native ./dcgan.cc 3. host system: Arch Linux 5.10.39-1-lts #1 SMP Sat, 22 May 2021 10:57:31 + x86_64 GNU/Linux
[Bug c++/100876] -Wmismatched-new-delete should either look through or ignore placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-06-02 Ever confirmed|0 |1 Keywords||diagnostic Status|UNCONFIRMED |NEW
[Bug target/100868] PPC: Inefficient code for vec_reve(vector double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100868 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-06-02 Severity|normal |enhancement Status|UNCONFIRMED |NEW --- Comment #1 from Segher Boessenkool --- Confirmed.
[Bug target/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 --- Comment #2 from Segher Boessenkool --- (In reply to Jens Seifert from comment #0) > - Avoid additional "int" unsigned long long int => unsigned long long Why? Those are exactly the same types! > - add missing line breaks between builtins > - remove semicolons Patches welcome. Comment 1 is a separate issue, please use a different bug to track that.
[Bug target/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 --- Comment #3 from Jens Seifert --- - Avoid additional "int" unsigned long long int => unsigned long long Why? Those are exactly the same types! Yes, but the rest of the documentation uses unsigned long long. This is just for consistency with existing documentation.
[Bug c++/100592] Bogus "qualifiers cannot be applied" error with reference type produced by dependent alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100592 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug sanitizer/100878] New: enabling UBSAN leads to false positive `'this' pointer is null` when casting lambda to function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100878
Bug ID: 100878
Summary: enabling UBSAN leads to false positive `'this' pointer
is null` when casting lambda to function pointer
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at milianw dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
```
const auto lambda = [](int i) -> int { return i + 1; };
using Callback = int (*)(int);
int run(Callback callback, int i)
{
return callback(i);
}
int main()
{
return run(lambda, 52);
}
```
compile with `-g -Og -fsanitize=undefined -Wall -Werror -Wpedantic -Wextra`
leads to:
```
: In static member function 'static constexpr
int::_FUN(int)':
:1:54: error: 'this' pointer is null [-Werror=nonnull]
1 | const auto lambda = [](int i) -> int { return i + 1; };
| ^
:1:21: note: in a call to non-static member function ''
1 | const auto lambda = [](int i) -> int { return i + 1; };
| ^
cc1plus: all warnings being treated as errors
Compiler returned: 1
```
see also: https://godbolt.org/z/jTYYWbMsz
[Bug c++/100825] function signature constraints are not a part of mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #7 from TC --- I think the code is valid; it's just that the ABI doesn't have a mangling for constraints yet: https://github.com/itanium-cxx-abi/cxx-abi/issues/24
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855 --- Comment #6 from Dominique d'Humieres --- On a MacOS, Corei9, 2.4Ghz, the program runs in ~1s, almost indpendtly of the option level. This PR remind me an old problem in which the transcendental functions were almost slower for REAL(4) then for REAL(8) on some Unix distros (Fedora(?), based of "correct rounding"). What are your timings if you replace real :: sum, n, q with real(8) :: sum, n, q and sum = sum + (i ** (0.05 + n)) with sum = sum + (i ** (0.05_8 + n)) ?
[Bug c++/100879] New: gcc is complaining of a signed compare when comparing enums of different types (same underlying type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100879
Bug ID: 100879
Summary: gcc is complaining of a signed compare when comparing
enums of different types (same underlying type)
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andre at kostur dot net
Target Milestone: ---
With the following test code:
enum e1 { e1val };
enum e2 { e3val };
int main( int, char * [] ) {
if ( e1val == e3val ) return 1;
}
The compiler emits two warnings:
: In function 'int main(int, char**)':
:6:15: warning: comparison between 'enum e1' and 'enum e2'
[-Wenum-compare]
6 |if ( e1val == e3val ) return 1;
| ~~^~~~
:6:15: warning: comparison between types 'e1' and 'e2' [-Wsign-compare]
The first is correct, but the second warning seems wrong. There is no sign
mismatch as both enums would have the same underlying type.
gcc 9.3 does not seem to suffer this problem. gcc 10.1 does, and appears every
version up to at least 11.1 does. (Checked on compiler-explorer)
[Bug middle-end/100876] -Wmismatched-new-delete should understand placement new when it's not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 Martin Sebor changed: What|Removed |Added Blocks||100406 Known to fail||11.1.0 Summary|-Wmismatched-new-delete |-Wmismatched-new-delete |should either look through |should understand placement |or ignore placement new |new when it's not inlined CC||msebor at gcc dot gnu.org Component|c++ |middle-end --- Comment #1 from Martin Sebor --- [Please include all the information we ask for in the bug report, including the command line options and the full test cases: https://gcc.gnu.org/bugs/#need] The test case behaves as expected when the placement new is inlined, either with optimization or when the operator is declared with attribute always_inline: inline __attribute__ ((__always_inline__)) void* operator new (__SIZE_TYPE__, void*); The problem is a general one, not specific to -Wmismatched-new-delete: GCC understands the semantics of built-in functions, including whether they return one of their arguments, but not user-defined ones. Even though it's special, GCC treats placement new as an ordinary user-defined function. Because nothing indicates the operator returns its pointer argument, no logic in GCC can determine that unless the operator is inlined. The fix is to either hardcode into GCC the knowledge of placement new, or provide an attribute for users (and the standard library) to indicate that a function returns one of its argument. The former might be suitable for GCC 11 as a bug fix for this warning, the latter is something I'd like to do in GCC 12 regardless. Let me work on the former and plan on looking into the latter in the future. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406 [Bug 100406] bogus/missing -Wmismatched-new-delete
[Bug middle-end/100876] -Wmismatched-new-delete should understand placement new when it's not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug c++/100838] [11/12 Regression] -fno-elide-constructors for C++14 missing required destructor call since r11-5872-g4eb28483004f8291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100838 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:63d182b29306e582bfb151cf762820211ea1cc7e commit r12-1165-g63d182b29306e582bfb151cf762820211ea1cc7e Author: Jason Merrill Date: Mon May 31 12:36:25 2021 -0400 c++: missing dtor with -fno-elide-constructors [PR100838] tf_no_cleanup only applies to the outermost TARGET_EXPR, and we already clear it for nested calls in build_over_call, but in this case both constructor calls came from convert_like, so we need to clear it in the recursive call as well. This revealed that we were adding an extra ck_rvalue in direct-initialization cases where it was wrong. PR c++/100838 gcc/cp/ChangeLog: * call.c (convert_like_internal): Clear tf_no_cleanup when recursing. (build_user_type_conversion_1): Only add ck_rvalue if LOOKUP_ONLYCONVERTING. gcc/testsuite/ChangeLog: * g++.dg/init/no-elide2.C: New test.
[Bug middle-end/100880] New: The build should error out for define_insn without insn template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100880 Bug ID: 100880 Summary: The build should error out for define_insn without insn template Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- Currently, the build allows define_insn RTX without insn template. It would be nice to detect this invalid RTX and error out during build. This would help to avoid thinkos like: -(define_insn "abs2" +(define_expand "abs2" [(set (match_operand:MMXMODEI 0 "register_operand") (abs:MMXMODEI (match_operand:MMXMODEI 1 "register_operand")))] "TARGET_MMX_WITH_SSE && TARGET_SSSE3") which worked only by luck due to the shadowing of the insn above this one. The documentation does not say that insn template can be optional in the define_insn RTX.
[Bug c++/100881] New: [c++ modules][possible bug?] default arguments break when the default argument's type isn't explicitly included/exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100881
Bug ID: 100881
Summary: [c++ modules][possible bug?] default arguments break
when the default argument's type isn't explicitly
included/exported
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: evanc.github at gmail dot com
Target Milestone: ---
Created attachment 50911
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50911&action=edit
Preprocessed output of foo.cc
GCC Version / steps to reproduce:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-11.1.1-20210428/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.1 20210428 (Red Hat 11.1.1-1) (GCC)
$ cat foo.cc
module;
#include
export module foo;
export void log(const std::source_location& loc =
std::source_location::current()) {
//
}
$ cat main.cc
import foo;
int main() {
log();
}
$ g++ -fmodules-ts -std=c++20 -c foo.cc -o foo.o
$ g++ -fmodules-ts -std=c++20 main.cc foo.o
main.cc: In function ‘int main()’:
main.cc:4:8: error: ‘source_location’ is not a member of ‘std’
4 | log();
| ~~~^~
main.cc:1:1: note: ‘std::source_location’ is defined in header
‘’; did you forget to ‘#include ’?
+++ |+#include
1 | import foo;
main.cc:4:8: note: evaluating ‘__builtin_source_location’
4 | log();
| ~~~^~
In file included from foo.cc:2,
of module foo, imported at main.cc:1:
main.cc:4:8: in ‘constexpr’ expansion of
‘std::source_location@foo::current(0)’
/usr/include/c++/11/source_location:54:23: error: cast from ‘const void*’ is
not allowed
54 | __ret._M_impl = static_cast (__p);
|
=
Apologies if this isn't actually a bug, but it seemed to be.
This error disappears when is included in main.cc or `export
import ).
[Bug d/100882] New: ICE in gimplify_var_or_parm_decl, at gimplify.c:2755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100882
Bug ID: 100882
Summary: ICE in gimplify_var_or_parm_decl, at gimplify.c:2755
Product: gcc
Version: 9.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Reduced test, adapted to make clear what the correct behaviour should be after
the ICE is fixed.
---
__gshared int counter = 0;
struct S
{
this(int) { counter++; }
~this() { counter++; }
}
static S s;
static this()
{
s = cast(shared) S(0);
assert(counter == 2);
}
---
Reproducible from gdc-9 onwards.
[Bug tree-optimization/96674] Failure to optimize combination of comparisons to dec+compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at gcc dot gnu.org Resolution|--- |FIXED --- Comment #11 from Jeffrey A. Law --- Resolved by Eugene's patch on the trunk.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96674, which changed state. Bug 96674 Summary: Failure to optimize combination of comparisons to dec+compare https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/100883] New: ifcombine should use (gimple) match and simplify instead of fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100883 Bug ID: 100883 Summary: ifcombine should use (gimple) match and simplify instead of fold Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Like PHI-OPT, ifcombine was written before match and simplify was around so it calls fold_build* to do the folding of the if statements. It would be better if it calls gimple_simplify instead of doing the gimplification manually.
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407
--- Comment #2 from seurer at gcc dot gnu.org ---
I got it to fail on the gcc110 gcc farm machine.
g:659cc7d6320aae7ab390b5886f0efed22f78e244, r12-1164
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
compile.exp=gcc.c-torture/compile/attr-retain-1.c"
FAIL: gcc.c-torture/compile/attr-retain-1.c -O0 scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c -O1 scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c -O3 -g scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c -Os scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none scan-assembler .rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects scan-assembler .rodata.*,"aR"
# of expected passes35
# of unexpected failures7
I did have to use my own binutils (2.36.1) or the test came up as unsupported.
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407
--- Comment #3 from H.J. Lu ---
(In reply to seurer from comment #2)
> I got it to fail on the gcc110 gcc farm machine.
>
> g:659cc7d6320aae7ab390b5886f0efed22f78e244, r12-1164
> make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
> compile.exp=gcc.c-torture/compile/attr-retain-1.c"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -O0 scan-assembler
> .rodata.*,"aR"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -O1 scan-assembler
> .rodata.*,"aR"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 scan-assembler
> .rodata.*,"aR"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -O3 -g scan-assembler
> .rodata.*,"aR"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -Os scan-assembler
> .rodata.*,"aR"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto
> -fno-use-linker-plugin -flto-partition=none scan-assembler .rodata.*,"aR"
> FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects scan-assembler .rodata.*,"aR"
> # of expected passes 35
> # of unexpected failures 7
>
> I did have to use my own binutils (2.36.1) or the test came up as
> unsupported.
Does it fail on LE?
[Bug sanitizer/71458] ICE with -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71458
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #9 from Harald van Dijk ---
I know the GCC 5 branch is long closed and this will not be fixed, but for
completeness, the backport to GCC 5 was wrong: error (UNKNOWN_LOCATION, "...")
should have been error ("..."). error (UNKNOWN_LOCATION, "...") compiles but
does the wrong thing: UNKNOWN_LOCATION is interpreted as a null pointer format
string and causes a segfault.
[Bug target/100841] xtensa-linux: dwarf2cfi.c:291:12: error: comparison of integer expressions of different signedness: 'const unsigned int' and 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100841 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:50b1de860a58bf85b40a72219bc2fdfaf0dff355 commit r12-1167-g50b1de860a58bf85b40a72219bc2fdfaf0dff355 Author: Jakub Jelinek Date: Wed Jun 2 22:09:53 2021 +0200 xtensa: Fix 2 warnings during xtensa build [PR100841] When building gcc targetting xtensa-linux, there are 2 warnings the PR complains about: ../../gcc/dwarf2cfi.c: In function âvoid init_one_dwarf_reg_size(int, machine_mode, rtx, machine_mode, init_one_dwarf_reg_state*)â: ../../gcc/dwarf2cfi.c:291:12: warning: comparison of integer expressions of different signedness: âconst unsigned intâ and âintâ [-Wsign-compare] 291 | if (rnum >= DWARF_FRAME_REGISTERS) ../../gcc/function.c: In function âvoid gen_call_used_regs_seq(rtx_insn*, unsigned int)â: ../../gcc/function.c:5897:63: warning: comparison of unsigned expression in â< 0â is always false [-Wtype-limits] 5897 | if (crtl->uses_only_leaf_regs && LEAF_REG_REMAP (regno) < 0) which might during bootstrap or when configured with --enable-werror-always be turned into errors. The first one is the -Wsign-compare warning, in c-family we do: 2281 /* Do not warn if the signed quantity is an unsuffixed integer 2282 literal (or some static constant expression involving such 2283 literals or a conditional expression involving such literals) 2284 and it is non-negative. */ 2285 if (tree_expr_nonnegative_warnv_p (sop, &ovf)) 2286/* OK */; and so don't warn if that function determines the expression is non-negative. But xtensa defines DWARF_FRAME_REGISTERS as (16 + (something ? 0 : 1)) and that isn't handled by tree_expr_nonnegative_warnv_p, VRP can handle it of course, but that is much later. The second chunk rewrites it into a form that tree_expr_nonnegative_warnv_p can handle, in particular (something ? 16 : 16 + 1), where for COND_EXPRs that function checks both the 2nd and 3rd operand of the ternary operator and if both are nonnegative, returns true. The other warning has been introduced fairly recently; LEAF_REG_REMAP is currently used by 2 targets only, and is documented to yield -1 if a hard reg number can't be remapped and the remapped register number otherwise. That means that the type of the expression should be signed (otherwise -1 could never appear), and on SPARC indeed it is defined as extern char leaf_reg_remap[]; #define LEAF_REG_REMAP(REGNO) (leaf_reg_remap[REGNO]) so unless the host is -funsigned-char by default it works fine. I guess sparc.[ch] should be fixed to use signed char of leaf_reg_remap, Eric? The argument to LEAF_REG_REMAP is often unsigned int though, hard register numbers are usually not negative, and thus the warning. I think xtensa doesn't have 2G hard registers and so it is ok to just cast it to int. 2021-06-02 Jakub Jelinek PR target/100841 * config/xtensa/xtensa.h (LEAF_REG_REMAP): Cast REGNO to int to avoid -Wtype-limits warnings. (DWARF_FRAME_REGISTER): Rewrite into ternary operator with addition in operands to avoid -Wsign-compare warnings.
[Bug c++/100884] New: Comparing unsigned 32 bit integer values generates 64 bit compare instructions when optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100884
Bug ID: 100884
Summary: Comparing unsigned 32 bit integer values generates 64
bit compare instructions when optimized
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mfarazma.ext at gmail dot com
Target Milestone: ---
**0.c**
```
#include
uint32_t codegen();
int main(){
uint32_t expected = (codegen()) != 0 ? -1 : -2;
bool check_eq = expected == codegen();
if (!(check_eq)){
std::cout << "Check failed" << std::endl;
}
return 0;
}
```
**1.cc**
```
#include
uint32_t codegen(){
volatile int64_t a = -1;
return a;
}
```
Compile it with optimization enabled:
g++ -O3 0.cc 1.cc
Checking the generate code shows this instruction is generated for ` if
(!(check_eq)){...}`:
```
cmpdr31,r3
```
Compiling the same code with gcc version 8.4.0 emits this instead which is
correct:
```
cmpwcr7,r3,r31
```
This issue is causing failures as the returned value from `codegen()` may not
have its upper 32 bits cleared and using `cmpd` on it will create the wrong
output.
[Bug target/100885] New: [12 Regression] ICE: in extract_constrain_insn, at recog.c:2671: insn does not satisfy its constraints: {sse4_1_zero_extendv8qiv8hi2}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100885
Bug ID: 100885
Summary: [12 Regression] ICE: in extract_constrain_insn, at
recog.c:2671: insn does not satisfy its constraints:
{sse4_1_zero_extendv8qiv8hi2}
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 50912
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50912&action=edit
auto-reduced testcase (from OpenTTD sources)
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -mavx512vl testcase.C
testcase.C: In instantiation of 'void Blitter_32bppSSE4_Anim::Draw(const
Blitter::BlitterParams*, ZoomLevel) [with BlitterMode =
BM_COLOUR_REMAP; Blitter_32bppSSE_Base::ReadMode =
Blitter_32bppSSE_Base::RM_WITH_MARGIN; Blitter_32bppSSE_Base::BlockType
= Blitter_32bppSSE_Base::BT_NONE; bool = true; bool
= false]':
testcase.C:154:62: required from here
testcase.C:120:27: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
120 | Colour *src_rgba_line = (Colour *)sd->data;
| ^~
testcase.C:130:19: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
130 | int mvX2 = *(unsigned *)sd->infos[zoom], m = byte(mvX2);
| ^~~
testcase.C: In member function 'void Blitter_32bppSSE4_Anim::Draw(const
Blitter::BlitterParams*, ZoomLevel) [with BlitterMode =
BM_COLOUR_REMAP; Blitter_32bppSSE_Base::ReadMode =
Blitter_32bppSSE_Base::RM_WITH_MARGIN; Blitter_32bppSSE_Base::BlockType
= Blitter_32bppSSE_Base::BT_NONE; bool = true; bool
= false]':
testcase.C:150:1: error: insn does not satisfy its constraints:
150 | }
| ^
(insn 295 221 134 12 (set (reg:V8HI 22 xmm2 [230])
(zero_extend:V8HI (vec_select:V8QI (reg:V16QI 52 xmm16 [orig:134
__trans_tmp_5 ] [134])
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
] "testcase.C":49:46 4653 {sse4_1_zero_extendv8qiv8hi2}
(expr_list:REG_DEAD (reg:V16QI 52 xmm16 [orig:134 __trans_tmp_5 ] [134])
(nil)))
during RTL pass: cprop_hardreg
testcase.C:150:1: internal compiler error: in extract_constrain_insn, at
recog.c:2671
0x7ece3a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0x7ecec7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:118
0x7dbaaf extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2671
0x1292534 copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.c:825
0x129383e execute
/repo/gcc-trunk/gcc/regcprop.c:1390
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.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-1164-20210602094549-g659cc7d6320-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-1164-20210602094549-g659cc7d6320-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210602 (experimental) (GCC)
[Bug fortran/100886] New: Variable character pointer within a Fortran derived type can't determine the shape(mold) of the target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100886
Bug ID: 100886
Summary: Variable character pointer within a Fortran derived
type can't determine the shape(mold) of the target
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.robinson at noaa dot gov
Target Milestone: ---
A character pointer within a Fortran DDT can't determine the shape(mold) of a
variable length allocatable target character array
Desired behavior: DDT pointer behaves like a non-DDT pointer and properly
determines shape(mold) of the target and points to it
Here is some sample code:
program char_ptr_test
implicit none
character(len=:), dimension(:), allocatable, target:: input_nml_file
character(len=:), dimension(:), pointer:: copy_input_nml_file => null()
type init_type
character(len=:), dimension(:), pointer:: input_nml_file => null()
end type init_type
type(init_type):: Init
integer:: i
character(len=6):: arg
logical:: gnu=.false.
!--- parse command line
call get_command_argument(1, arg)
if (len_trim(arg) > 0) print *, trim(arg)
!--- set up input_nml_file and output the result
call init_input()
do i = 1,size(input_nml_file)
print *, 'Main input_nml_file is: "',input_nml_file(i),'"'
enddo
!--- plain pointer - works as expected
print *, NEW_LINE('a'),'plain pointer'
copy_input_nml_file => input_nml_file
do i = 1,size(copy_input_nml_file)
print *, 'copy_input_nml_file is: "',copy_input_nml_file(i),'"'
enddo
nullify(copy_input_nml_file)
!--- pointer within a DDT - fails
!--- point to input_nml_file elements (:)
print *, NEW_LINE('a'),'pointer within fortran ddt @ elements (:)'
Init%input_nml_file => input_nml_file(:)
do i = 1,size(Init%input_nml_file)
print *, 'Init%input_nml_file is: "',Init%input_nml_file(i),'"'
enddo
!--- pointer within a DDT - fails
!--- point to input_nml_file as whole
print *, NEW_LINE('a'),'pointer within fortran ddt @ whole entity'
Init%input_nml_file => input_nml_file
do i = 1,size(Init%input_nml_file)
print *, 'Init%input_nml_file is: "',Init%input_nml_file(i),'"'
enddo
nullify(Init%input_nml_file)
!--- pointer within a DDT - works
!--- point to input_nml_file elements (:)
!--- allocate/deallocate to get shape
print *, NEW_LINE('a'),'pointer within fortran ddt with shape settings @
elements(:)'
allocate(Init%input_nml_file, mold=input_nml_file)
deallocate(Init%input_nml_file)
Init%input_nml_file => input_nml_file(:)
do i = 1,size(Init%input_nml_file)
print *, 'Init%input_nml_file is: "',Init%input_nml_file(i),'"'
enddo
nullify(Init%input_nml_file)
!--- pointer within a DDT - fails with segfault
!--- point to input_nml_file as whole
!--- allocate/deallocate to get shape
print *, NEW_LINE('a'),'pointer within fortran ddt w/ shape settings @ whole
entity'
allocate(Init%input_nml_file, mold=input_nml_file)
deallocate(Init%input_nml_file)
Init%input_nml_file => input_nml_file
do i = 1,size(Init%input_nml_file)
print *, 'Init%input_nml_file is: "',Init%input_nml_file(i),'"'
enddo
nullify(Init%input_nml_file)
contains
subroutine init_input()
allocate(character(len=10)::input_nml_file(7))
input_nml_file(1) = 'New York '
input_nml_file(2) = 'London'
input_nml_file(3) = 'Paris '
input_nml_file(4) = 'Munich'
input_nml_file(5) = 'Everybody '
input_nml_file(6) = 'talk about'
input_nml_file(7) = 'Pop Muzik '
end subroutine init_input
end program char_ptr_test
The behavior is different between 9.3 and 10.2, but the same for 10.2 to 12.0
(at least for the versions that I have available). Please let me know if
there's any other information you need
[Bug target/100887] New: [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100887 Bug ID: 100887 Summary: [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector() Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 50913 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50913&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -mavx512f testcase.c during RTL pass: expand testcase.c: In function 'foo': testcase.c:6:3: internal compiler error: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 6 | __builtin_shufflevector (u, v, 0); | ^~~ 0x7ddb42 ix86_expand_vector_init_concat /repo/gcc-trunk/gcc/config/i386/i386-expand.c:14178 0x149cf87 ix86_expand_vector_init(bool, rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/config/i386/i386-expand.c:14622 0x18c32ee ??? /repo/gcc-trunk/gcc/config/i386/sse.md:22289 0xce0ba6 rtx_insn* insn_gen_fn::operator()(rtx_def*, rtx_def*) const /repo/gcc-trunk/gcc/recog.h:407 0xce0ba6 store_constructor /repo/gcc-trunk/gcc/expr.c:7217 0xce2645 expand_constructor /repo/gcc-trunk/gcc/expr.c:8555 0xccea3a expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /repo/gcc-trunk/gcc/expr.c:10738 0xcdbe6c store_expr(tree_node*, rtx_def*, int, bool, bool) /repo/gcc-trunk/gcc/expr.c:5986 0xcdd62d expand_assignment(tree_node*, tree_node*, bool) /repo/gcc-trunk/gcc/expr.c:5721 0xb97ef1 expand_gimple_stmt_1 /repo/gcc-trunk/gcc/cfgexpand.c:3916 0xb97ef1 expand_gimple_stmt /repo/gcc-trunk/gcc/cfgexpand.c:4014 0xb9e79b expand_gimple_basic_block /repo/gcc-trunk/gcc/cfgexpand.c:6056 0xba06c7 execute /repo/gcc-trunk/gcc/cfgexpand.c:6782 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. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-1164-20210602094549-g659cc7d6320-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-1164-20210602094549-g659cc7d6320-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20210602 (experimental) (GCC)
[Bug rtl-optimization/100264] REE does not work on PARALLEL expressions with a single register SET child
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100264 --- Comment #2 from CVS Commits --- The master branch has been updated by Jim Wilson : https://gcc.gnu.org/g:d5ba2eaf7032f234fdcf11d9cfc513ce7be0a255 commit r12-1168-gd5ba2eaf7032f234fdcf11d9cfc513ce7be0a255 Author: Christoph Muellner Date: Mon May 10 14:39:03 2021 +0200 REE: PR rtl-optimization/100264: Handle more PARALLEL SET expressions Move the check for register targets (i.e. REG_P ()) into the function get_sub_rtx () and change the restriction of REE to "only one child of a PARALLEL expression is a SET register expression" (was "only one child of a PARALLEL expression is a SET expression"). This allows to handle more PARALLEL SET expressions. gcc/ChangeLog: PR rtl-optimization/100264 * ree.c (get_sub_rtx): Ignore SET expressions without register destinations and remove assertion, as it is not valid anymore with this new behaviour. (merge_def_and_ext): Eliminate destination check for register as such SET expressions can't occur anymore. (combine_reaching_defs): Likewise.
[Bug rtl-optimization/100264] REE does not work on PARALLEL expressions with a single register SET child
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100264 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||wilson at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Jim Wilson --- Fixed on mainline.
[Bug target/100706] Invalid instructions in plt calls on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100706 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Bill Schmidt --- Sorry, just now saw this...closing.
[Bug testsuite/100749] [12 regression] gcc.dg/pch/valid-1.c fails after r12-949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #4 from Bill Schmidt --- @seurer, is this working now? Can it be closed?
[Bug fortran/100194] [9/10/11/12 Regression] ICE in gfc_trans_create_temp_array, at fortran/trans-array.c:1351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100194 --- Comment #4 from anlauf at gcc dot gnu.org --- We are hitting the assert 1351 gcc_assert (ss->dimen > 0); in gfc_trans_create_temp_array which does not handle assumed rank yet. (here ss->dimen = -1).
[Bug c/100888] New: ICE: symtab_node::verify failed, symtab_node::verify()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100888
Bug ID: 100888
Summary: ICE: symtab_node::verify failed, symtab_node::verify()
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210602 (experimental) [master revision
:5b6bc0f6e:b75978d14fc35981ffd8bf060ee52300db4dae50] (GCC)
$ cat mutant.c
register __sys_res asm("r10");
r10() {}
$ gcc-trunk mutant.c
mutant.c:1:10: warning: type defaults to ‘int’ in declaration of ‘__sys_res’
[-Wimplicit-int]
1 | register __sys_res asm("r10");
| ^
mutant.c:1:10: warning: call-clobbered register used for global register
variable
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | r10() {}
| ^~~
mutant.c:2:1: error: assembler name hash list corrupted
*r10/0 (__sys_res) @0x7f5bf87f5000
Type: variable definition analyzed
Visibility: force_output no_reorder public
References:
Referring:
Availability: not-ready
Varpool flags:
mutant.c:2:1: internal compiler error: symtab_node::verify failed
0xa717c9 symtab_node::verify()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/symtab.c:1361
0xa717c9 symtab_node::verify()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/symtab.c:1349
0xa72a27 symtab_node::verify_symtab_nodes()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/symtab.c:1384
0xa88b04 symtab_node::checking_verify_symtab_nodes()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/cgraph.h:678
0xa88b04 symbol_table::compile()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/cgraphunit.c:2272
0xa8b7db symbol_table::compile()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/cgraphunit.c:2269
0xa8b7db symbol_table::finalize_compilation_unit()
/tmp/tmp.2G3KkJkZyC-gcc-builder/gcc/gcc/cgraphunit.c:2537
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug middle-end/100876] -Wmismatched-new-delete should understand placement new when it's not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 Martin Sebor changed: What|Removed |Added Keywords||patch Target Milestone|--- |11.2 --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571777.html
