[Bug target/87555] There is no need for UNSPEC_FMADDSUB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87555 --- Comment #8 from Hongtao.liu --- (In reply to Hongtao.liu from comment #7) > (In reply to Hongtao.liu from comment #6) > > > So it there any canonical rtx for vec_merge? > > > (vec_merge (A B const_int 10) should abviously equal to (vec_merge B A > > > const_int 5) > > > > A and B here are 4-element vector. > > Similar for 8-element vector C, D. > (vec_merge (C D const_int 170 [0xaa])) equal to (vec_merge (D C const_int 85 > [0x55])) > > 16-element vector [0x] and [0x] And also (vec_merge (C D const_int 170 [0xaa])) equal to (vec_merge (D C const_int 85 [0x55])) is equal to (vec_select (vec_concat D C) (0,9,2,11,4,13,6,15))
[Bug c/101117] New: Does not diagnose invalid constant initializers with -std=c11 -pedantic -pedantic-errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101117 Bug ID: 101117 Summary: Does not diagnose invalid constant initializers with -std=c11 -pedantic -pedantic-errors Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- const int i = 0; static int j = i; is not diagnosed with any option I tried - I am aware that the C standard allows compilers to accept other forms of constant expressions but this makes writing portable code hard. The above is for example rejected with GCC 7 but accepted with GCC 8 and on and there's no way to get such code diagnosed that might not be accepted by other compilers.
[Bug c/71983] "error: initializer element is not constant" only with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71983 Richard Biener changed: What|Removed |Added Known to fail||7.5.0 Status|NEW |RESOLVED Known to work||8.1.0 Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed in GCC 8+
[Bug target/87555] There is no need for UNSPEC_FMADDSUB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87555 --- Comment #7 from Hongtao.liu --- (In reply to Hongtao.liu from comment #6) > > So it there any canonical rtx for vec_merge? > > (vec_merge (A B const_int 10) should abviously equal to (vec_merge B A > > const_int 5) > > A and B here are 4-element vector. Similar for 8-element vector C, D. (vec_merge (C D const_int 170 [0xaa])) equal to (vec_merge (D C const_int 85 [0x55])) 16-element vector [0x] and [0x]
[Bug target/87555] There is no need for UNSPEC_FMADDSUB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87555 --- Comment #6 from Hongtao.liu --- > So it there any canonical rtx for vec_merge? > (vec_merge (A B const_int 10) should abviously equal to (vec_merge B A > const_int 5) A and B here are 4-element vector.
[Bug target/87555] There is no need for UNSPEC_FMADDSUB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87555
--- Comment #5 from Hongtao.liu ---
With open-code
successfully optimize
__m128d f1(__m128d x, __m128d y, __m128d z){
__m128d tem = _mm_mul_pd (x,y);
__m128d tem2 = tem + z;
__m128d tem3 = tem - z;
return __builtin_shuffle (tem2, tem3, (__m128i) {0, 3});
}
to
f1:
.LFB5481:
.cfi_startproc
vfmsubadd132pd %xmm1, %xmm2, %xmm0
ret
.cfi_endproc
But failed to optimize
__m256d f2(__m256d x, __m256d y, __m256d z){
__m256d tem = _mm256_mul_pd (x,y);
__m256d tem2 = tem + z;
__m256d tem3 = tem - z;
return __builtin_shuffle (tem2, tem3, (__m256i) {0, 5, 2, 7});
}
since simplify_rtx didn't realize
Failed to match this instruction:
(set (reg:V4SF 88)
(vec_merge:V4SF (fma:V4SF (reg/v:V4SF 85 [ x ])
(reg/v:V4SF 86 [ y ])
(neg:V4SF (reg/v:V4SF 87 [ z ])))
(fma:V4SF (reg/v:V4SF 85 [ x ])
(reg/v:V4SF 86 [ y ])
(reg/v:V4SF 87 [ z ]))
(const_int 10 [0xa])))
is equal to
(set (reg:V4SF 88)
(vec_merge:V4SF
(fma:V4SF (reg/v:V4SF 85 [ x ])
(reg/v:V4SF 86 [ y ])
(reg/v:V4SF 87 [ z ]))
(fma:V4SF (reg/v:V4SF 85 [ x ])
(reg/v:V4SF 86 [ y ])
(neg:V4SF (reg/v:V4SF 87 [ z ])))
(const_int 5 [0x5])))
later is how our pattern is defined.
So it there any canonical rtx for vec_merge?
(vec_merge (A B const_int 10) should abviously equal to (vec_merge B A
const_int 5)
[Bug target/101116] missed peephole optimization not of bitwise and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101116
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andrew Pinski ---
Take:
unsigned char foo(unsigned *i) {
return !(*i & 1);
}
GCC and clang/LLVM produce similar code. In fact similar to what GCC produces
before.
Note also ICC produces the same code as GCC for original case. So does
Microsoft compiler. So I think we can say this is not a missed optimization
for GCC.
[Bug target/87555] There is no need for UNSPEC_FMADDSUB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87555 --- Comment #4 from Hongtao.liu --- > (define_mode_attr addsub_cst [(V4DF "5") (V2DF "1") > (V4SF "5") (V8SF "85")]) > (define_insn "*fma_fmaddsub_" > [(set (match_operand:VF_128_256 0 "register_operand" "=v,v,v,x,x") > (vec_merge:VF_128_256 > (fma:VF_128_256 > (match_operand:VF_128_256 1 "nonimmediate_operand" "%0,0,v,x,x") > (match_operand:VF_128_256 2 "nonimmediate_operand" "vm,v,vm,x,m") > (match_operand:VF_128_256 3 "nonimmediate_operand" "v,vm,0,xm,x")) > (fma:VF_128_256 > (match_dup 1) > (match_dup 2) > (neg:VF_128_256 (match_dup 3)) > (const_int )))] Should be bellow, addsub means add in the highpart (define_insn "*fma_fmaddsub_" [(set (match_operand:VF_128_256 0 "register_operand" "=v,v,v,x,x") (vec_merge:VF_128_256 (fma:VF_128_256 (match_operand:VF_128_256 1 "nonimmediate_operand" "%0,0,v,x,x") (match_operand:VF_128_256 2 "nonimmediate_operand" "vm,v,vm,x,m") (neg:VF_128_256 (match_operand:VF_128_256 3 "nonimmediate_operand" "v,vm,0,xm,x")) (fma:VF_128_256 (match_dup 1) (match_dup 2) (match_dup 3)) (const_int )))] "TARGET_FMA || TARGET_FMA4"
[Bug target/101116] missed peephole optimization not of bitwise and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101116 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |target --- Comment #1 from Andrew Pinski --- It is an open question which is better.
[Bug tree-optimization/101116] New: missed peephole optimization not of bitwise and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101116
Bug ID: 101116
Summary: missed peephole optimization not of bitwise and
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
$ cat test.c
bool foo(unsigned i) {
return !(i & 1);
}
gcc -O2 test.c -S -o-
foo(unsigned int):
mov eax, edi
not eax
and eax, 1
ret
clang -O2 test.c -S -o-
foo(unsigned int): # @foo(unsigned int)
testb $1, %dil
sete %al
retq
Ref: https://godbolt.org/z/Tndb1dM8Y
[Bug target/101115] ld.bfd: warning: .init_array section has zero size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101115 --- Comment #2 from Chris Packham --- (In reply to Andrew Pinski from comment #1) > Try adding --enable-initfini-array to gcc config > > Most likely GCC config is not detecting .init_array/.fini_array support > which is now always turned on the trunk for *linux-* targets. Yes that does the trick. I'll work on plumbing that into ct-ng when building GCC 10 or GCC 11. Any idea how that will interact with the non-GNU libcs (specifically musl and uClibc)?
[Bug target/101115] ld.bfd: warning: .init_array section has zero size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101115 --- Comment #1 from Andrew Pinski --- Try adding --enable-initfini-array to gcc config Most likely GCC config is not detecting .init_array/.fini_array support which is now always turned on the trunk for *linux-* targets.
[Bug target/100777] MMA builtin usage ICEs when used in a #pragma omp parallel and using -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100777 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:9e10782370391ed48d2a690a4205594f6b7d2fbe commit r10-9931-g9e10782370391ed48d2a690a4205594f6b7d2fbe Author: Peter Bergner Date: Mon Jun 14 16:55:18 2021 -0500 rs6000: MMA builtin usage ICEs when used in a #pragma omp parallel and using -fopenmp [PR100777] Using an MMA builtin within an openmp parallel code block, leads to an SSA verification ICE on the temporaries we create while expanding the MMA builtins at gimple time. The solution is to use create_tmp_reg_or_ssa_name(), which knows when to create either an SSA or register temporary. 2021-06-14 Peter Bergner gcc/ PR target/100777 * config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Use create_tmp_reg_or_ssa_name(). gcc/testsuite/ PR target/100777 * gcc.target/powerpc/pr100777.c: New test. (cherry picked from commit 20073534c0ccca0a4e079c053ee0874af10b2ea0)
[Bug target/99842] MMA test case ICEs using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99842 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:206d49a23735168769065716c4b211328dbf1b76 commit r10-9929-g206d49a23735168769065716c4b211328dbf1b76 Author: Peter Bergner Date: Sun May 30 22:45:55 2021 -0500 rs6000: MMA test case ICEs using -O3 [PR99842] The mma_assemble_input_operand predicate does not accept reg+reg indexed addresses which can lead to ICEs. The lxv and lxvp instructions have indexed forms (lxvx and lxvpx), so the simple solution is to just allow indexed addresses in the predicate. 2021-05-30 Peter Bergner gcc/ PR target/99842 * config/rs6000/predicates.md(mma_assemble_input_operand): Allow indexed form addresses. gcc/testsuite/ PR target/99842 * g++.target/powerpc/pr99842.C: New. (cherry picked from commit df4e0359dad239854af0ea9eacb8e7e3719557d0)
[Bug other/101115] New: ld.bfd: warning: .init_array section has zero size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101115 Bug ID: 101115 Summary: ld.bfd: warning: .init_array section has zero size Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: judge.packham at gmail dot com Target Milestone: --- When cross-compiling for arm using GCC 11.1.0 the linker complains that .init_array and .fini_array have a zero size. x-tool@063c4281c760:~$ rm -f test test.o; make CC=arm-unknown-linux-gnueabi-gcc test arm-unknown-linux-gnueabi-gcc test.c -o test /home/x-tool/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/11.1.0/../../../../arm-unknown-linux-gnueabi/bin/ld.bfd: warning: .init_array section has zero size /home/x-tool/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/11.1.0/../../../../arm-unknown-linux-gnueabi/bin/ld.bfd: warning: .fini_array section has zero size The program being compiled is a simple "hello world". I've also seen the same problem with GCC 10.3.0. I do not see the problem with GCC 9.3.0. Based on some debugging with the help of the bintutils mailing list[1] it seems that crtbegin.o has a zero sized init_array/.fini_array find . -name 'crtbegin.o' | xargs readelf -SW File: ./x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/11.1.0/crtbegin.o There are 13 section headers, starting at offset 0x2bc: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 34 00 00 AX 0 0 1 [ 2] .data PROGBITS 34 04 00 WA 0 0 4 [ 3] .bss NOBITS 38 00 00 WA 0 0 1 [ 4] .rodata PROGBITS 38 90 00 A 0 0 4 [ 5] .init_array INIT_ARRAY c8 00 04 WA 0 0 1 [ 6] .fini_array FINI_ARRAY c8 00 04 WA 0 0 1 [ 7] .comment PROGBITS c8 2f 01 MS 0 0 1 [ 8] .note.GNU-stack PROGBITS f7 00 00 0 0 1 [ 9] .ARM.attributes ARM_ATTRIBUTES f7 31 00 0 0 1 [10] .symtab SYMTAB 000128 f0 10 11 14 4 [11] .strtab STRTAB 000218 2e 00 0 0 1 [12] .shstrtab STRTAB 000246 75 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), y (purecode), p (processor specific) With GCC 9.3.0 it does not File: ./x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/9.3.0/crtbegin.o There are 16 section headers, starting at offset 0x518: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 34 90 00 AX 0 0 4 [ 2] .rel.text REL 000444 38 08 I 13 1 4 [ 3] .data PROGBITS c4 04 00 WA 0 0 4 [ 4] .bss NOBITS c8 01 00 WA 0 0 1 [ 5] .init_array INIT_ARRAY c8 04 04 WA 0
[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100940 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Patrick Palka --- Fixed.
[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100940 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:f0d8d001d94166242be4387ca72fe0fc483860f1 commit r11-8613-gf0d8d001d94166242be4387ca72fe0fc483860f1 Author: Patrick Palka Date: Thu Jun 17 09:46:07 2021 -0400 libstdc++: Non-triv-copyable extra args aren't simple [PR100940] This force-enables perfect forwarding call wrapper semantics whenever the extra arguments of a partially applied range adaptor aren't all trivially copyable, so as to avoid incurring unnecessary copies of potentially expensive-to-copy objects (such as std::function objects) when invoking the adaptor. PR libstdc++/100940 libstdc++-v3/ChangeLog: * include/std/ranges (__adaptor::_Partial): For the "simple" forwarding partial specializations, also require that the extra arguments are trivially copyable. * testsuite/std/ranges/adaptors/100577.cc (test04): New test. (cherry picked from commit 2b87f3318cf6334a3a42dcf27f2fdec0fce04665)
[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100940 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:bc7a522548c37daf612c2ba4c44e9ea93548ed45 commit r11-8612-gbc7a522548c37daf612c2ba4c44e9ea93548ed45 Author: Patrick Palka Date: Thu Jun 17 09:46:04 2021 -0400 libstdc++: Refine range adaptors' "simple extra args" mechanism [PR100940] The _S_has_simple_extra_args mechanism is used to simplify forwarding of range adaptor's extra arguments when perfect forwarding call wrapper semantics isn't required for correctness, on a per-adaptor basis. Both views::take and views::drop are flagged as such, but it turns out perfect forwarding semantics are needed for these adaptors in some contrived cases, e.g. when their extra argument is a move-only class that's implicitly convertible to an integral type. To fix this, we could just clear the flag for views::take/drop as with views::split, but that'd come at the cost of acceptable diagnostics for ill-formed uses of these adaptors (see PR100577). This patch instead allows adaptors to parameterize their _S_has_simple_extra_args flag according the types of the captured extra arguments, so that we could conditionally disable perfect forwarding semantics only when the types of the extra arguments permit it. We then use this finer-grained mechanism to safely disable perfect forwarding semantics for views::take/drop when the extra argument is integer-like, rather than incorrectly always disabling it. Similarly, for views::split, rather than always enabling perfect forwarding semantics we now safely disable it when the extra argument is a scalar or a view, and recover good diagnostics for these common cases. PR libstdc++/100940 libstdc++-v3/ChangeLog: * include/std/ranges (__adaptor::_RangeAdaptor): Document the template form of _S_has_simple_extra_args. (__adaptor::__adaptor_has_simple_extra_args): Add _Args template parameter pack. Try to treat _S_has_simple_extra_args as a variable template parameterized by _Args. (__adaptor::_Partial): Pass _Arg/_Args to the constraint __adaptor_has_simple_extra_args. (views::_Take::_S_has_simple_extra_args): Templatize according to the type of the extra argument. (views::_Drop::_S_has_simple_extra_args): Likewise. (views::_Split::_S_has_simple_extra_args): Define. * testsuite/std/ranges/adaptors/100577.cc (test01, test02): Adjust after changes to _S_has_simple_extra_args mechanism. (test03): Define. (cherry picked from commit 0f4a2fb44dad6c9c140226fc19ed16109b85e6f4)
[Bug target/87555] There is no need for UNSPEC_FMADDSUB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87555
--- Comment #3 from Hongtao.liu ---
(In reply to Richard Biener from comment #1)
> The complication is that the define_insn looks like
>
> (define_insn "*fma_fmaddsub_"
> [(set (match_operand:VF_128_256 0 "register_operand" "=v,v,v,x,x")
> (unspec:VF_128_256
> [(match_operand:VF_128_256 1 "nonimmediate_operand" "%0,0,v,x,x")
>(match_operand:VF_128_256 2 "nonimmediate_operand" "vm,v,vm,x,m")
>(match_operand:VF_128_256 3 "nonimmediate_operand" "v,vm,0,xm,x")]
> UNSPEC_FMADDSUB))]
> "TARGET_FMA || TARGET_FMA4"
> "@
>vfmaddsub132\t{%2, %3, %0|%0, %3, %2}
>vfmaddsub213\t{%3, %2, %0|%0, %2, %3}
>vfmaddsub231\t{%2, %1, %0|%0, %1, %2}
>vfmaddsub\t{%3, %2, %1, %0|%0, %1, %2, %3}
>vfmaddsub\t{%3, %2, %1, %0|%0, %1, %2, %3}"
>
> so it can handle the {132,213,231} variants without much duplication from a
> single pattern. But it seems this cannot prevail when we open-code the
> operation. Likewise handling multiple modes with the VF_128_256 iterator
> becomes difficult since the addsub requires either a vec_merge (as in the
> addsub patterns) with a constant selector specific to the mode (unless we
> can provide a large one that is implicitely truncated) or a vector constant
> when using the (vec_select (vec_concat ...)) form. So the above would
> split into 12 somewhat repetitive patterns.
we already has *fma_fmadd_ with one pattern
(define_insn "*fma_fmadd_"
[(set (match_operand:FMAMODE 0 "register_operand" "=v,v,v,x,x")
(fma:FMAMODE
(match_operand:FMAMODE 1 "nonimmediate_operand" "%0,0,v,x,x")
(match_operand:FMAMODE 2 "nonimmediate_operand" "vm,v,vm,x,m")
(match_operand:FMAMODE 3 "nonimmediate_operand" "v,vm,0,xm,x")))]
"TARGET_FMA || TARGET_FMA4"
"@
vfmadd132\t{%2, %3, %0|%0, %3, %2}
vfmadd213\t{%3, %2, %0|%0, %2, %3}
vfmadd231\t{%2, %1, %0|%0, %1, %2}
vfmadd\t{%3, %2, %1, %0|%0, %1, %2, %3}
vfmadd\t{%3, %2, %1, %0|%0, %1, %2, %3}"
[(set_attr "isa" "fma,fma,fma,fma4,fma4")
(set_attr "type" "ssemuladd")
(set_attr "mode" "")])
So can't it be changed to
(define_mode_attr addsub_cst [(V4DF "5") (V2DF "1")
(V4SF "5") (V8SF "85")])
(define_insn "*fma_fmaddsub_"
[(set (match_operand:VF_128_256 0 "register_operand" "=v,v,v,x,x")
(vec_merge:VF_128_256
(fma:VF_128_256
(match_operand:VF_128_256 1 "nonimmediate_operand" "%0,0,v,x,x")
(match_operand:VF_128_256 2 "nonimmediate_operand" "vm,v,vm,x,m")
(match_operand:VF_128_256 3 "nonimmediate_operand" "v,vm,0,xm,x"))
(fma:VF_128_256
(match_dup 1)
(match_dup 2)
(neg:VF_128_256 (match_dup 3))
(const_int )))]
"TARGET_FMA || TARGET_FMA4"
"@
vfmaddsub132\t{%2, %3, %0|%0, %3, %2}
vfmaddsub213\t{%3, %2, %0|%0, %2, %3}
vfmaddsub231\t{%2, %1, %0|%0, %1, %2}
vfmaddsub\t{%3, %2, %1, %0|%0, %1, %2, %3}
vfmaddsub\t{%3, %2, %1, %0|%0, %1, %2, %3}"
[(set_attr "isa" "fma,fma,fma,fma4,fma4")
(set_attr "type" "ssemuladd")
(set_attr "mode" "")])
[Bug target/100866] PPC: Inefficient code for vec_revb(vector unsigned short) < P9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #6 from luoxhu at gcc dot gnu.org ---
For V4SI, it is also better to use vector splat and vector rotate operations.
revb:
.LFB0:
.cfi_startproc
vspltish %v1,8
vspltisw %v0,-16
vrlh %v2,%v2,%v1
vrlw %v2,%v2,%v0
blr
Performance improved from 7.322s to 2.445s with a small benchmark due to load
instruction replaced.
But for V2DI, we don't have "vspltisd" to splat {32,32} to vector register
before Power9, so lvx is still required?
vector unsigned long long revb_pwr7_l(vector unsigned long long a)
{
return vec_rl(a, vec_splats((unsigned long long)32));
}
generates:
revb_pwr7_l:
.LFB1:
.cfi_startproc
.LCF1:
0: addis 2,12,.TOC.-.LCF1@ha
addi 2,2,.TOC.-.LCF1@l
.localentry revb_pwr7_l,.-revb_pwr7_l
addis %r9,%r2,.LC0@toc@ha
addi %r9,%r9,.LC0@toc@l
lvx %v0,0,%r9
vrld %v2,%v2,%v0
blr
.LC0:
.quad 32
.quad 32
.align 4
[Bug target/87555] There is no need for UNSPEC_FMADDSUB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87555 --- Comment #2 from Hongtao.liu --- I'll take a look.
[Bug testsuite/101114] New: new test case libgomp.c/../libgomp.c-c++-common/struct-elem-5.c fails after its introduction in r12-1565
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101114 Bug ID: 101114 Summary: new test case libgomp.c/../libgomp.c-c++-common/struct-elem-5.c fails after its introduction in r12-1565 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:275c736e732d29934e4d22e8f030d5aae8c12a52, r12-1565 make -k check-target-libgomp RUNTESTFLAGS="c.exp=libgomp.c/../libgomp.c-c++-common/struct-elem-5.c" FAIL: libgomp.c/../libgomp.c-c++-common/struct-elem-5.c execution test # of expected passes1 # of unexpected failures1 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include /home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.c/../libgomp.c-c++-common/struct-elem-5.c -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/../../include -I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -O2 -L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs -lm -o ./struct-elem-5.exe PASS: libgomp.c/../libgomp.c-c++-common/struct-elem-5.c (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/./gcc:.:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/./gcc:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs Execution timeout is: 300 spawn [open ...] FAIL: libgomp.c/../libgomp.c-c++-common/struct-elem-5.c execution test testcase /home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.c/c.exp completed in 0 seconds commit 275c736e732d29934e4d22e8f030d5aae8c12a52 (HEAD) Author: Chung-Lin Tang Date: Thu Jun 17 21:33:32 2021 +0800 libgomp: Structure element mapping for OpenMP 5.0
[Bug tree-optimization/101112] [12 regression] ICE compiling gcc.dg/pr86179.c after r12-1551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101112 --- Comment #1 from Andrew Pinski --- What target is this on?
[Bug tree-optimization/101112] [12 regression] ICE compiling gcc.dg/pr86179.c after r12-1551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101112 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||ice-on-valid-code
[Bug sanitizer/101111] Undefined reference to ___lsan_default_suppressions when compiling GCC 11.1 for x86_64 macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #1 from Mosè Giordano ---
To add more information, the real problem seems to be that xgcc can't generate
weak symbols:
sandbox:${WORKSPACE}/srcdir/gcc_build # x86_64-apple-darwin14-nm
x86_64-apple-darwin14/libsanitizer/lsan/.libs/lsan_common.o | grep '___lsan'
18c0 T ___lsan_default_options
U ___lsan_default_suppressions
18a0 T ___lsan_disable
3440 T ___lsan_do_leak_check
3460 T ___lsan_do_recoverable_leak_check
18b0 T ___lsan_enable
14c0 T ___lsan_ignore_object
U ___lsan_default_suppressions
1580 T ___lsan_register_root_region
17c0 T ___lsan_unregister_root_region
___lsan_default_suppressions and ___lsan_default_suppressions should be weak,
instead they're undefined. I can reproduce the same issue with this simpler
example:
sandbox:${WORKSPACE}/srcdir/gcc_build # /workspace/srcdir/gcc_build/./gcc/xgcc
-B/workspace/srcdir/gcc_build/./gcc -x c - << EOF
#include
int __attribute__((weak)) func(int);
#if 0
int func(int a) { return 2 * a; }
#endif
int main() {
if (&func) {
printf("Func implemented: %d\n", func(10));
} else {
printf("Func not implemented\n");
}
return 0;
}
EOF
Undefined symbols for architecture x86_64:
"_func", referenced from:
_main in ccMDdanO.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
[Bug target/100777] MMA builtin usage ICEs when used in a #pragma omp parallel and using -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100777 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:04a6793eec7f3482f3fb1273a725b3001865a685 commit r11-8610-g04a6793eec7f3482f3fb1273a725b3001865a685 Author: Peter Bergner Date: Mon Jun 14 16:55:18 2021 -0500 rs6000: MMA builtin usage ICEs when used in a #pragma omp parallel and using -fopenmp [PR100777] Using an MMA builtin within an openmp parallel code block, leads to an SSA verification ICE on the temporaries we create while expanding the MMA builtins at gimple time. The solution is to use create_tmp_reg_or_ssa_name(), which knows when to create either an SSA or register temporary. 2021-06-14 Peter Bergner gcc/ PR target/100777 * config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Use create_tmp_reg_or_ssa_name(). gcc/testsuite/ PR target/100777 * gcc.target/powerpc/pr100777.c: New test. (cherry picked from commit 20073534c0ccca0a4e079c053ee0874af10b2ea0)
[Bug target/99842] MMA test case ICEs using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99842 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:aaa8419bcf2ec491c0fd41a526f5817da0cf3ed4 commit r11-8608-gaaa8419bcf2ec491c0fd41a526f5817da0cf3ed4 Author: Peter Bergner Date: Sun May 30 22:45:55 2021 -0500 rs6000: MMA test case ICEs using -O3 [PR99842] The mma_assemble_input_operand predicate does not accept reg+reg indexed addresses which can lead to ICEs. The lxv and lxvp instructions have indexed forms (lxvx and lxvpx), so the simple solution is to just allow indexed addresses in the predicate. 2021-05-30 Peter Bergner gcc/ PR target/99842 * config/rs6000/predicates.md(mma_assemble_input_operand): Allow indexed form addresses. gcc/testsuite/ PR target/99842 * g++.target/powerpc/pr99842.C: New. (cherry picked from commit df4e0359dad239854af0ea9eacb8e7e3719557d0)
[Bug c++/101113] g++ thinks constructor suppressed by a requires clause is actually a bad copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101113 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-06-17 Keywords||rejects-valid Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- Confirmed. Fails with older versions too and doesn't seem to be a regression.
[Bug libstdc++/91488] [9/10/11/12 Regression] char_traits::length causes "inlining failed in call to always_inline" error with -fgnu-tm -O2 -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91488 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b376b1ef38971b84975ad1540bf5d2ae0b924e76 commit r12-1603-gb376b1ef38971b84975ad1540bf5d2ae0b924e76 Author: Jonathan Wakely Date: Thu Jun 17 14:11:22 2021 +0100 libstdc++: Simplify constexpr checks in std::char_traits [PR 91488] This removes the helper functions added by r8-1294 to detect whether the char_traits member functions can be evaluated at compile time. Instead, we can just use __builtin_constant_evaluated directly, which is well supported by non-GCC compilers by now. As a result, there is a chance that those members will no longer be usable in constant expressions when using old versions of non-GCC compilers. Make the relevant feature test macros depend on the availability of __builtin_constant_evaluated, so they are defined only when the feature is actualyl available. The new testcase from the PR is added to the libitm testsuite, because that's where we can be sure it's OK to use the -fgnu-tm option. Signed-off-by: Jonathan Wakely PR libstdc++/91488 libstdc++-v3/ChangeLog: * include/bits/basic_string.h (__cpp_lib_constexpr_string): Only define when is_constant_evaluated is available. * include/bits/char_traits.h (__cpp_lib_constexpr_char_traits): Likewise. (__constant_string_p, __constant_array_p): Remove. (char_traits): Use is_constant_evaluated directly. * include/std/version (__cpp_lib_constexpr_char_traits) (__cpp_lib_constexpr_string): Only define when is_constant_evaluated is available. libitm/ChangeLog: * testsuite/libitm.c++/libstdc++-pr91488.C: New test.
[Bug c++/101106] [11/12 regression] =delete on second declaration of the same function produces a note with no error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101106 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:331e20a69be0d9e7d448580945945d4c7a1e3c0a commit r12-1602-g331e20a69be0d9e7d448580945945d4c7a1e3c0a Author: Jason Merrill Date: Thu Jun 17 15:31:15 2021 -0400 c++: deleted after first declaration [PR101106] An explicitly deleted function must be deleted on its first declaration. We were diagnosing this error only with -Wpedantic, but always giving the "previous declaration" note. This patch removes the -Wpedantic dependency and also makes the note depend on the previous diagnostic. PR c++/101106 gcc/cp/ChangeLog: * decl.c (duplicate_decls): Make 'deleted after first declaration' pedwarn on by default. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/deleted15.C: New test.
[Bug c/98571] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3542
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98571 Martin Sebor changed: What|Removed |Added Target Milestone|--- |11.2 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Martin Sebor --- Fixed in r12-774 (AKA PR c/100550).
[Bug c/100719] missing -Wvla-parameter on a mismatch in second parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100719 Martin Sebor changed: What|Removed |Added Target Milestone|11.2|12.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed in GCC 12.0.
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 José Rui Faustino de Sousa changed: What|Removed |Added Attachment #51010|0 |1 is obsolete|| --- Comment #11 from José Rui Faustino de Sousa --- Created attachment 51032 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51032&action=edit Updated patch.
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 --- Comment #10 from José Rui Faustino de Sousa --- Second and hopefully last update... https://gcc.gnu.org/pipermail/fortran/2021-June/056170.html
[Bug middle-end/100406] bogus/missing -Wmismatched-new-delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406 Bug 100406 depends on bug 100876, which changed state. Bug 100876 Summary: [11 Regression] -Wmismatched-new-delete should understand placement new when it's not inlined https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/100876] [11 Regression] -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 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Martin Sebor --- Backported to GCC 11.2.
[Bug c/100783] [10/11 Regression] ICE on attribute nonnull and erroneous type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100783 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Martin Sebor --- Backported to GCC 11.2.
[Bug tree-optimization/100732] [11 Regression] ICE on sprintf %s with integer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100732 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Martin Sebor --- Backported to GCC 11.2.
[Bug middle-end/95507] [meta-bug] bogus/missing -Wnonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 Bug 95507 depends on bug 100684, which changed state. Bug 100684 Summary: [11 Regression] spurious -Wnonnull with -O1 on a C++ lambda https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100684 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/100684] [11 Regression] spurious -Wnonnull with -O1 on a C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100684 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Sebor --- Backported to GCC 11.2.
[Bug c/100619] [11 Regression] ICE on a VLA parameter with too many dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100619 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Sebor --- Backported to GCC 11.2.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 100574, which changed state. Bug 100574 Summary: [11 Regression] ICE: in size_remaining, at builtins.c:413 with -O3 -ftracer -fno-tree-dominator-opts -fno-tree-fre https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100574 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/100574] [11 Regression] ICE: in size_remaining, at builtins.c:413 with -O3 -ftracer -fno-tree-dominator-opts -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100574 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Sebor --- Backported to GCC 11.2.
[Bug c++/100399] bogus/missing -Wplacement-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100399 Bug 100399 depends on bug 100307, which changed state. Bug 100307 Summary: [11 Regression] spurious -Wplacement-new with negative pointer offset https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100307 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/100307] [11 Regression] spurious -Wplacement-new with negative pointer offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100307 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Martin Sebor --- Backported to GCC 11.2.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 100250, which changed state. Bug 100250 Summary: [11 Regression] ICE related to -Wmaybe-uninitialized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100250 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/100250] [11 Regression] ICE related to -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100250 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Martin Sebor --- Backported to GCC 11.2.
[Bug middle-end/100876] [11 Regression] -Wmismatched-new-delete should understand placement new when it's not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:00bf3e4d12944e659b3a3706ca720f1d6346e610 commit r11-8607-g00bf3e4d12944e659b3a3706ca720f1d6346e610 Author: Martin Sebor Date: Thu Jun 17 12:22:28 2021 -0600 Backported from trunk: Consider size_t mangling as unsigned int and long [PR100876]. gcc/ChangeLog: PR middle-end/100876 * builtins.c: (gimple_call_return_array): Account for size_t mangling as either unsigned int or unsigned long
[Bug middle-end/100876] [11 Regression] -Wmismatched-new-delete should understand placement new when it's not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:fbafba7114939b279e860198d009d7641f3ce49c commit r11-8606-gfbafba7114939b279e860198d009d7641f3ce49c Author: Martin Sebor Date: Thu Jun 17 12:18:53 2021 -0600 Backported from trunk: Teach compute_objsize about placement new [PR100876]. Resolves: PR c++/100876 - -Wmismatched-new-delete should understand placement new when it's not inlined gcc/ChangeLog: PR c++/100876 * builtins.c (gimple_call_return_array): Check for attribute fn spec. Handle calls to placement new. (ndecl_dealloc_argno): Avoid placement delete. gcc/testsuite/ChangeLog: PR c++/100876 * g++.dg/warn/Wmismatched-new-delete-4.C: New test. * g++.dg/warn/Wmismatched-new-delete-5.C: New test. * g++.dg/warn/Wstringop-overflow-7.C: New test. * g++.dg/warn/Wfree-nonheap-object-6.C: New test. * g++.dg/analyzer/placement-new.C: Prune out expected warning.
[Bug c/100783] [10/11 Regression] ICE on attribute nonnull and erroneous type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100783 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:3863203bf306a730482861e974ff779e0d1db02f commit r11-8605-g3863203bf306a730482861e974ff779e0d1db02f Author: Martin Sebor Date: Thu Jun 17 12:17:02 2021 -0600 PR c/100783 - ICE on -Wnonnull and erroneous type gcc/c-family/ChangeLog: PR c/100783 * c-attribs.c (positional_argument): Bail on erroneous types. gcc/c/ChangeLog: PR c/100783 * c-objc-common.c (print_type): Handle erroneous types. gcc/testsuite/ChangeLog: PR c/100783 * gcc.dg/nonnull-6.c: New test.
[Bug tree-optimization/100732] [11 Regression] ICE on sprintf %s with integer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100732 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:b9edb8fb8202dc6907f69094a8b2a621840174e1 commit r11-8604-gb9edb8fb8202dc6907f69094a8b2a621840174e1 Author: Martin Sebor Date: Thu Jun 17 12:08:15 2021 -0600 Backported from trunk: PR middle-end/100732 - ICE on sprintf %s with integer argument gcc/ChangeLog: PR middle-end/100732 * gimple-fold.c (gimple_fold_builtin_sprintf): Avoid folding calls with either source or destination argument of invalid type. * tree-ssa-uninit.c (maybe_warn_pass_by_reference): Avoid checking calls with arguments of invalid type. gcc/testsuite/ChangeLog: PR middle-end/100732 * gcc.dg/tree-ssa/builtin-snprintf-11.c: New test. * gcc.dg/tree-ssa/builtin-snprintf-12.c: New test. * gcc.dg/tree-ssa/builtin-sprintf-28.c: New test. * gcc.dg/tree-ssa/builtin-sprintf-29.c: New test. * gcc.dg/uninit-pr100732.c: New test.
[Bug middle-end/100684] [11 Regression] spurious -Wnonnull with -O1 on a C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100684 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:ca0bc927103f5408f4812a3ad65d2d02a37840b2 commit r11-8603-gca0bc927103f5408f4812a3ad65d2d02a37840b2 Author: Martin Sebor Date: Thu Jun 17 12:01:38 2021 -0600 PR middle-end/100684 - spurious -Wnonnull with -O1 on a C++ lambda gcc/ChangeLog: PR middle-end/100684 * tree-ssa-ccp.c (pass_post_ipa_warn::execute): Handle C++ lambda. gcc/testsuite/ChangeLog: PR middle-end/100684 * g++.dg/warn/Wnonnull13.C: New test. * g++.dg/warn/Wnonnull14.C: New test. * g++.dg/warn/Wnonnull15.C: New test.
[Bug c/100619] [11 Regression] ICE on a VLA parameter with too many dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100619 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:933885db3872cc58dc36498aa1b8e8f15484e008 commit r11-8602-g933885db3872cc58dc36498aa1b8e8f15484e008 Author: Martin Sebor Date: Thu Jun 17 11:42:10 2021 -0600 Backported from trunk: PR c/100619 - ICE on a VLA parameter with too many dimensions gcc/c-family/ChangeLog: PR c/100619 * c-attribs.c (build_attr_access_from_parms): Handle arbitrarily many bounds. gcc/testsuite/ChangeLog: PR c/100619 * gcc.dg/pr100619.c: New test.
[Bug tree-optimization/100574] [11 Regression] ICE: in size_remaining, at builtins.c:413 with -O3 -ftracer -fno-tree-dominator-opts -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100574 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:11133f8f113e4591a2a5c9e61d810b9e5931043e commit r11-8601-g11133f8f113e4591a2a5c9e61d810b9e5931043e Author: Martin Sebor Date: Thu Jun 17 10:32:00 2021 -0600 Bacported from trunk: PR middle-end/100574 - ICE in size_remaining, at builtins.c gcc/ChangeLog: PR middle-end/100574 * builtins.c (access_ref::get_ref): Improve detection of PHIs with all null arguments. gcc/testsuite/ChangeLog: PR middle-end/100574 * g++.dg/pr100574.C: New test.
[Bug middle-end/100307] [11 Regression] spurious -Wplacement-new with negative pointer offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100307 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:c2791cd4e62731ccde165c0e62b83f8e7ee38118 commit r11-8600-gc2791cd4e62731ccde165c0e62b83f8e7ee38118 Author: Martin Sebor Date: Thu Jun 17 10:24:34 2021 -0600 Backported from trunk: PR middle-end/100307 - spurious -Wplacement-new with negative pointer offset gcc/ChangeLog: PR middle-end/100307 * builtins.c (compute_objsize_r): Clear base0 for pointers. gcc/testsuite/ChangeLog: PR middle-end/100307 * g++.dg/warn/Wplacement-new-size-9.C: New test. * gcc.dg/tree-ssa/builtin-sprintf-warn-26.c: New test.
[Bug tree-optimization/100250] [11 Regression] ICE related to -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100250 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:a52b2f4cae38abecda2a7ad72a47c4e38236870a commit r11-8599-ga52b2f4cae38abecda2a7ad72a47c4e38236870a Author: Martin Sebor Date: Thu Jun 17 10:20:09 2021 -0600 Backported from trunk: PR middle-end/100250 - ICE related to -Wmaybe-uninitialized gcc/ChangeLog: PR middle-end/100250 * attribs.c (attr_access::array_as_string): Avoid dereferencing a pointer when it's null. gcc/testsuite/ChangeLog: PR middle-end/100250 * gcc.dg/uninit-pr100250.c: New test.
[Bug c++/101113] New: g++ thinks constructor suppressed by a requires clause is actually a bad copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101113
Bug ID: 101113
Summary: g++ thinks constructor suppressed by a requires clause
is actually a bad copy constructor
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at nospam dot scs.stanford.edu
Target Milestone: ---
g++ 11.1.0 is rejecting the following correct code when compiling with
`-std=c++20` (test case public domain):
template struct S {
S() {}
S(S) requires B {}
};
S sf;
Here is the error message:
$ g++ -std=c++20 -c test.cc
y.cc: In instantiation of 'struct S':
y.cc:3:26: required from here
y.cc:3:3: error: invalid constructor; you probably meant 'S (const
S&)'
3 | S(S) requires B {}
| ^
[Bug tree-optimization/101112] New: [12 regression] ICE compiling gcc.dg/pr86179.c after r12-1551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101112 Bug ID: 101112 Summary: [12 regression] ICE compiling gcc.dg/pr86179.c after r12-1551 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:3dfa4fe9f1a089b2b3906c83e22a1b39c49d937c, r12-1551 make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr86179.c" FAIL: gcc.dg/pr86179.c (internal compiler error) FAIL: gcc.dg/pr86179.c (test for excess errors) # of unexpected failures2 Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled731.cc -fdiagnostics-plain-output -S -o exceptions_enabled731.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled731.cc -fdiagnostics-plain-output -S -o exceptions_enabled731.s FAIL: gcc.dg/pr86179.c (test for excess errors) Excess errors: during GIMPLE pass: vect /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr86179.c:7:6: internal compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.c:4541 0x10f66307 vect_slp_analyze_node_operations /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4539 0x10f65993 vect_slp_analyze_node_operations /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4482 0x10f65993 vect_slp_analyze_node_operations /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4482 0x10f65993 vect_slp_analyze_node_operations /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4482 0x10f65993 vect_slp_analyze_node_operations /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4482 0x10f68667 vect_slp_analyze_operations(vec_info*) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4737 0x10f381fb vect_analyze_loop_2 /home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.c:2396 0x10f3a5c7 vect_analyze_loop(loop*, vec_info_shared*) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.c:2986 0x10f7c25f try_vectorize_loop_1 /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1004 0x10f7d14f vectorize_loops() /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1238 0x10dbde47 execute /home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop.c:414 commit 3dfa4fe9f1a089b2b3906c83e22a1b39c49d937c Author: Richard Biener Date: Tue Jun 8 15:10:45 2021 +0200
[Bug sanitizer/101111] New: Undefined reference to ___lsan_default_suppressions when compiling GCC 11.1 for x86_64 macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 Bug ID: 10 Summary: Undefined reference to ___lsan_default_suppressions when compiling GCC 11.1 for x86_64 macOS Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: mose at gnu dot org 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: --- I'm trying to cross-compile GCC 11.1 for x86_64-apple-darwin on an x86_64-linux-musl host. You can find the full build script at https://github.com/giordano/Yggdrasil/blob/2597ce2a3fdc4689ce089730263386d979fa1f65/0_RootFS/gcc_common.jl#L274-L778. The macOS SDK used is version 10.12. When doing the final compilation, line 771 of the fine linked above, compilation of libasan fails with the following error: [10:03:02] libtool: link: (cd .libs/libasan.lax/libsanitizer_lsan.a && /workspace/destdir/bin/llvm-ar x "/workspace/srcdir/gcc_build/x86_64-apple-darwin14/libsanitizer/asan/../lsan/.libs/libsanitizer_l[49/1977] [10:03:02] libtool: link: /workspace/srcdir/gcc_build/./gcc/xgcc -shared-libgcc -B/workspace/srcdir/gcc_build/./gcc -nostdinc++ -L/workspace/srcdir/gcc_build/x86_64-apple-darwin14/libstdc++-v3/src -L/workspace /srcdir/gcc_build/x86_64-apple-darwin14/libstdc++-v3/src/.libs -L/workspace/srcdir/gcc_build/x86_64-apple-darwin14/libstdc++-v3/libsupc++/.libs -B/workspace/destdir/x86_64-apple-darwin14/bin/ -B/workspace/destd ir/x86_64-apple-darwin14/lib/ -isystem /workspace/destdir/x86_64-apple-darwin14/include -isystem /workspace/destdir/x86_64-apple-darwin14/sys-include-dynamiclib -o .libs/libasan.6.dylib .libs/asan_activat ion.o .libs/asan_allocator.o .libs/asan_debugging.o .libs/asan_descriptions.o .libs/asan_errors.o .libs/asan_fake_stack.o .libs/asan_flags.o .libs/asan_globals.o .libs/asan_interceptors.o .libs/asan_interceptor s_memintrinsics.o .libs/asan_linux.o .libs/asan_mac.o .libs/asan_malloc_linux.o .libs/asan_malloc_mac.o .libs/asan_malloc_win.o .libs/asan_memory_profile.o .libs/asan_new_delete.o .libs/asan_poisoning.o .libs/a san_posix.o .libs/asan_premap_shadow.o .libs/asan_report.o .libs/asan_rtems.o .libs/asan_rtl.o .libs/asan_shadow_setup.o .libs/asan_stack.o .libs/asan_stats.o .libs/asan_suppressions.o .libs/asan_thread.o .libs /asan_win.o .libs/asan_win_dll_thunk.o .libs/asan_win_dynamic_runtime_thunk.o .libs/asan_interceptors_vfork.o .libs/libasan.lax/libsanitizer_common.a/sancov_flags.o .libs/libasan.lax/libsanitizer_common.a/san itizer_allocator.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_allocator_checks.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_allocator_report.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_com mon.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_common_libcdep.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_coverage_libcdep_new.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_deadlock_detec tor1.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_deadlock_detector2.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_errno.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_file.o .libs/libasan.lax /libsanitizer_common.a/sanitizer_flag_parser.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_flags.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_libc.o .libs/libasan.lax/libsanitizer_common.a/sanitize r_libignore.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_linux.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_linux_libcdep.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_linux_s390.o .libs/lib asan.lax/libsanitizer_common.a/sanitizer_mac.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_mac_libcdep.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_netbsd.o .libs/libasan.lax/libsanitizer_common.a/ sanitizer_openbsd.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_persistent_allocator.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_platform_limits_freebsd.o .libs/libasan.lax/libsanitizer_common.a/s anitizer_platform_limits_linux.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_platform_limits_openbsd.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_platform_limits_posix.o .libs/libasan.lax/libsaniti zer_common.a/sanitizer_platform_limits_solaris.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_posix.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_posix_libcdep.o .libs/libasan.lax/libsanitizer_common .a/sanitizer_printf.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_procmaps_bsd.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_procmaps_common.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_procm aps_linux.o .libs/libasan.lax/libsanitizer_common.a/sanitizer_procmaps_mac.o .libs/libasan.lax/libsanitizer_common.a/sanitizer
[Bug target/100884] Comparing unsigned 32 bit integer values generates 64 bit compare instructions when optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100884 m farazma changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from m farazma --- Details are mentioned in the above comment.
[Bug target/100884] Comparing unsigned 32 bit integer values generates 64 bit compare instructions when optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100884 --- Comment #1 from m farazma --- The development team has mentioned this is correct behaviour, according to PPC ABI the returning function needs to sign or zero extend the result when necessary: https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#RETURN-VAL Will be closing this issue.
[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 --- Comment #9 from Nick Desaulniers --- (In reply to Fangrui Song from comment #8) > I am thinking of __attribute__((no_profile)). > > In Clang, > -fprofile-generate(-fcs-profile-generate)/-fprofile-instr-generate/-fprofile- > arcs are all different. It will make sense to have a attribute disabling all > such profiling related features. > > I am not sure an umbrella __attribute__((no_instrument_function)) is > suitable. > The Linux kernel wanting noinstr to exclude -fprofile-* is a very specific > characteristic, not suitable for other applications. Sure, though now we'll need to add use of that to the Linux kernel. v2: https://reviews.llvm.org/D104475.
[Bug other/101110] New: [12 regression] gcc.c-torture/execute/950704-1.c fails after r12-1546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101110 Bug ID: 101110 Summary: [12 regression] gcc.c-torture/execute/950704-1.c fails after r12-1546 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:786188e8b8cab47cb31177c6f4ab1a1578a607c3, r12-1546 make -k check-gcc RUNTESTFLAGS="execute.exp=gcc.c-torture/execute/950704-1.c" FAIL: gcc.c-torture/execute/950704-1.c -O2 execution test FAIL: gcc.c-torture/execute/950704-1.c -O3 -g execution test FAIL: gcc.c-torture/execute/950704-1.c -Os execution test FAIL: gcc.c-torture/execute/950704-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.c-torture/execute/950704-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test # of expected passes9 # of unexpected failures5 The runs don't provide any info on what failed: spawn [open ...] FAIL: gcc.c-torture/execute/950704-1.c -O2 execution test commit 786188e8b8cab47cb31177c6f4ab1a1578a607c3 Author: Andrew MacLeod Date: Wed Jun 16 18:08:03 2021 -0400 Add recomputation to outgoing_edge_range.
[Bug other/67300] -foffload* undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67300 --- Comment #3 from Tobias Burnus --- Patch to document -foffload= https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573081.html Still undocumented: -foffload-abi=[lp64|ilp32]
[Bug target/100704] Vector register isn't used to push BLKmode argument onto stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100704 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from H.J. Lu --- Fixed for GCC 12.
[Bug c++/101106] [11/12 regression] =delete on second declaration of the same function produces a note with no error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101106
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #2)
> This was intentionally changed from an error to a pedwarn by r11-1454
>
>
> c++: Treat in-class default/delete as definitions.
>
> We were complaining about a constrained defaulted non-template friend in
> a
> template class because funcdef_flag wasn't set. grokdeclarator would
> set it
> for default/delete, but grokfield wasn't passing the 'initialized' values
> needed. Fixing that revealed some errors in existing tests that we
> weren't
> diagnosing. Since we accepted them for so long, I'm reducing the error
> to a
> pedwarn to ease compiler upgrade.
>
> gcc/cp/ChangeLog:
>
> * decl2.c (grokfield): Pass SD_DEFAULTED and SD_DELETED.
> * decl.c (duplicate_decls): Reduce error for delete
> after earlier declaration to pedwarn.
>
> The fix would be:
>
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -2170,11 +2170,13 @@ duplicate_decls (tree newdecl, tree olddecl, bool
> hiding, bool was_hidden)
> if (DECL_DELETED_FN (newdecl))
> {
> auto_diagnostic_group d;
> - pedwarn (newdecl_loc, OPT_Wpedantic,
> - "deleted definition of %qD is not first declaration",
> - newdecl);
> - inform (olddecl_loc,
> - "previous declaration of %qD", olddecl);
> + if (pedwarn (newdecl_loc, OPT_Wpedantic,
> + "deleted definition of %qD is not first
> declaration",
> + newdecl);
> + {
> + inform (olddecl_loc,
> + "previous declaration of %qD", olddecl);
> + }
Except for the {}s around inform, those aren't needed.
Otherwise LGTM (even obvious).
[Bug c/101109] New: ICE: Segmentation Fault: tree_check(tree_node*, char const*, int, char const*, tree_code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101109
Bug ID: 101109
Summary: ICE: Segmentation Fault: tree_check(tree_node*, char
const*, int, char const*, tree_code)
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.fE7wx4xftU-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 20210617 (experimental) [master revision
:7d4a310d9:9a61dfdb5ecb58bc4caea1c11e017d93bdd1d9a5] (GCC)
$ cat mutant.c
__attribute__((section(".vtable_map_vars"))) f3() {}
$ gcc-trunk mutant.c
mutant.c:1:46: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | __attribute__((section(".vtable_map_vars"))) f3() {}
| ^~
during RTL pass: final
mutant.c: In function ‘f3’:
mutant.c:1:52: internal compiler error: Segmentation fault
1 | __attribute__((section(".vtable_map_vars"))) f3() {}
|^
0xf0b603 crash_signal
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/toplev.c:327
0x1263b09 tree_check(tree_node*, char const*, int, char const*, tree_code)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/tree.h:3370
0x1263b09 default_elf_asm_named_section(char const*, unsigned int, tree_node*)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/varasm.c:6908
0x1265e25 switch_to_section(section*, tree_node*)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/varasm.c:7832
0x127227d assemble_start_function(tree_node*, char const*)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/varasm.c:1915
0xb90253 rest_of_handle_final
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/final.c:4281
0xb90253 execute
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/final.c:4363
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 c/101108] New: ICE: segmentation fault: gimplify_target_expr, gimplify.c:6760
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101108
Bug ID: 101108
Summary: ICE: segmentation fault: gimplify_target_expr,
gimplify.c:6760
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.fE7wx4xftU-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 20210617 (experimental) [master revision
:7d4a310d9:9a61dfdb5ecb58bc4caea1c11e017d93bdd1d9a5] (GCC)
$ cat mutant.c
#include
test_ptr(void *p) {
atomic_int j;
j += *p;
}
$ gcc-trunk mutant.c
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | test_ptr(void *p) {
| ^~~~
mutant.c: In function ‘test_ptr’:
mutant.c:4:8: warning: dereferencing ‘void *’ pointer
4 | j += *p;
|^~
mutant.c:4:3: error: void value not ignored as it ought to be
4 | j += *p;
| ^
mutant.c:4:5: internal compiler error: Segmentation fault
4 | j += *p;
| ^~
0xf0b603 crash_signal
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/toplev.c:327
0xc43442 gimplify_target_expr
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:6760
0xc34f32 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:14491
0xc383fa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:6865
0xc359fb gimplify_statement_list
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:1887
0xc359fb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:14539
0xc383fa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:6865
0xc38829 gimplify_compound_expr
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:6065
0xc35563 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:14084
0xc383fa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:6865
0xc359fb gimplify_statement_list
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:1887
0xc359fb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:14539
0xc383fa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:6865
0xc38c2e gimplify_bind_expr
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:1426
0xc34e63 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:14295
0xc383fa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:6865
0xc399f3 gimplify_body(tree_node*, bool)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:15339
0xc39e41 gimplify_function_tree(tree_node*)
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/gimplify.c:15493
0xa8b6d7 cgraph_node::analyze()
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/cgraphunit.c:670
0xa8e601 analyze_functions
/tmp/tmp.fE7wx4xftU-gcc-builder/gcc/gcc/cgraphunit.c:1234
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 libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100940 --- Comment #10 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:2b87f3318cf6334a3a42dcf27f2fdec0fce04665 commit r12-1567-g2b87f3318cf6334a3a42dcf27f2fdec0fce04665 Author: Patrick Palka Date: Thu Jun 17 09:46:07 2021 -0400 libstdc++: Non-triv-copyable extra args aren't simple [PR100940] This force-enables perfect forwarding call wrapper semantics whenever the extra arguments of a partially applied range adaptor aren't all trivially copyable, so as to avoid incurring unnecessary copies of potentially expensive-to-copy objects (such as std::function objects) when invoking the adaptor. PR libstdc++/100940 libstdc++-v3/ChangeLog: * include/std/ranges (__adaptor::_Partial): For the "simple" forwarding partial specializations, also require that the extra arguments are trivially copyable. * testsuite/std/ranges/adaptors/100577.cc (test04): New test.
[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100940 --- Comment #9 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0f4a2fb44dad6c9c140226fc19ed16109b85e6f4 commit r12-1566-g0f4a2fb44dad6c9c140226fc19ed16109b85e6f4 Author: Patrick Palka Date: Thu Jun 17 09:46:04 2021 -0400 libstdc++: Refine range adaptors' "simple extra args" mechanism [PR100940] The _S_has_simple_extra_args mechanism is used to simplify forwarding of range adaptor's extra arguments when perfect forwarding call wrapper semantics isn't required for correctness, on a per-adaptor basis. Both views::take and views::drop are flagged as such, but it turns out perfect forwarding semantics are needed for these adaptors in some contrived cases, e.g. when their extra argument is a move-only class that's implicitly convertible to an integral type. To fix this, we could just clear the flag for views::take/drop as with views::split, but that'd come at the cost of acceptable diagnostics for ill-formed uses of these adaptors (see PR100577). This patch instead allows adaptors to parameterize their _S_has_simple_extra_args flag according the types of the captured extra arguments, so that we could conditionally disable perfect forwarding semantics only when the types of the extra arguments permit it. We then use this finer-grained mechanism to safely disable perfect forwarding semantics for views::take/drop when the extra argument is integer-like, rather than incorrectly always disabling it. Similarly, for views::split, rather than always enabling perfect forwarding semantics we now safely disable it when the extra argument is a scalar or a view, and recover good diagnostics for these common cases. PR libstdc++/100940 libstdc++-v3/ChangeLog: * include/std/ranges (__adaptor::_RangeAdaptor): Document the template form of _S_has_simple_extra_args. (__adaptor::__adaptor_has_simple_extra_args): Add _Args template parameter pack. Try to treat _S_has_simple_extra_args as a variable template parameterized by _Args. (__adaptor::_Partial): Pass _Arg/_Args to the constraint __adaptor_has_simple_extra_args. (views::_Take::_S_has_simple_extra_args): Templatize according to the type of the extra argument. (views::_Drop::_S_has_simple_extra_args): Likewise. (views::_Split::_S_has_simple_extra_args): Define. * testsuite/std/ranges/adaptors/100577.cc (test01, test02): Adjust after changes to _S_has_simple_extra_args mechanism. (test03): Define.
[Bug target/100704] Vector register isn't used to push BLKmode argument onto stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100704 --- Comment #4 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:967b46530234b4e6ad3983057705aea6c20a03c4 commit r12-1564-g967b46530234b4e6ad3983057705aea6c20a03c4 Author: H.J. Lu Date: Fri May 21 11:56:55 2021 -0700 Add a target calls hook: TARGET_PUSH_ARGUMENT 1. Replace PUSH_ARGS with a target calls hook, TARGET_PUSH_ARGUMENT, which takes an integer argument. When it returns true, push instructions will be used to pass outgoing arguments. If the argument is nonzero, it is the number of bytes to push and indicates the PUSH instruction usage is optional so that the backend can decide if PUSH instructions should be generated. Otherwise, the argument is zero. 2. Implement x86 target hook which returns false when the number of bytes to push is no less than 16 (8 for 32-bit targets) if vector load and store can be used. 3. Remove target PUSH_ARGS definitions which return 0 as it is the same as the default. 4. Define TARGET_PUSH_ARGUMENT of cr16 and m32c to always return true. gcc/ PR target/100704 * calls.c (expand_call): Replace PUSH_ARGS with targetm.calls.push_argument (0). (emit_library_call_value_1): Likewise. * defaults.h (PUSH_ARGS): Removed. (PUSH_ARGS_REVERSED): Replace PUSH_ARGS with targetm.calls.push_argument (0). * expr.c (block_move_libcall_safe_for_call_parm): Likewise. (emit_push_insn): Pass the number bytes to push to targetm.calls.push_argument and pass 0 if ARGS_ADDR is 0. * hooks.c (hook_bool_uint_true): New. * hooks.h (hook_bool_uint_true): Likewise. * rtlanal.c (nonzero_bits1): Replace PUSH_ARGS with targetm.calls.push_argument (0). * target.def (push_argument): Add a targetm.calls hook. * targhooks.c (default_push_argument): New. * targhooks.h (default_push_argument): Likewise. * config/bpf/bpf.h (PUSH_ARGS): Removed. * config/cr16/cr16.c (TARGET_PUSH_ARGUMENT): New. * config/cr16/cr16.h (PUSH_ARGS): Removed. * config/i386/i386.c (ix86_push_argument): New. (TARGET_PUSH_ARGUMENT): Likewise. * config/i386/i386.h (PUSH_ARGS): Removed. * config/m32c/m32c.c (TARGET_PUSH_ARGUMENT): New. * config/m32c/m32c.h (PUSH_ARGS): Removed. * config/nios2/nios2.h (PUSH_ARGS): Likewise. * config/pru/pru.h (PUSH_ARGS): Likewise. * doc/tm.texi.in: Remove PUSH_ARGS documentation. Add TARGET_PUSH_ARGUMENT hook. * doc/tm.texi: Regenerated. gcc/testsuite/ PR target/100704 * gcc.target/i386/pr100704-1.c: New test. * gcc.target/i386/pr100704-2.c: Likewise. * gcc.target/i386/pr100704-3.c: Likewise.
[Bug target/97194] optimize vector element set/extract at variable position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97194 --- Comment #24 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:20a2c8ace0ab56c147fd995432abd5e7cf89b0e3 commit r12-1563-g20a2c8ace0ab56c147fd995432abd5e7cf89b0e3 Author: Uros Bizjak Date: Thu Jun 17 15:19:12 2021 +0200 i386: Add variable vec_set for 64bit vectors [PR97194] To generate sane code a SSE4.1 variable PBLENDV instruction is needed. 2021-06-17 Uroš Bizjak gcc/ PR target/97194 * config/i386/i386-expand.c (expand_vector_set_var): Handle V2FS mode remapping. Pass TARGET_MMX_WITH_SSE to ix86_expand_vector_init_duplicate. (ix86_expand_vector_init_duplicate): Emit insv_1 for QImode for !TARGET_PARTIAL_REG_STALL. * config/i386/predicates.md (vec_setm_mmx_operand): New predicate. * config/i386/mmx.md (vec_setv2sf): Use vec_setm_mmx_operand as operand 2 predicate. Call ix86_expand_vector_set_var for non-constant index operand. (vec_setv2si): Ditto. (vec_setv4hi): Ditto. (vec_setv8qi): ditto. gcc/testsuite/ PR target/97194 * gcc.target/i386/sse4_1-vec-set-1.c: New test. * gcc.target/i386/sse4_1-vec-set-2.c: ditto.
[Bug c++/101107] New: Misleading error message in aggregate initialization in CRTP base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101107
Bug ID: 101107
Summary: Misleading error message in aggregate initialization
in CRTP base class
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: btzy1996 at gmail dot com
Target Milestone: ---
The following code gives a compile error:
```
template
struct Combiner;
template
struct Base {
template
auto dostuff(Next next) {
return Combiner{Base>{}, *this, next};
}
};
template
struct Combiner : public Base> {
Prev prev;
Next next;
};
struct A : public Base {
int stuff;
};
struct B : public Base {
int stuff;
};
int main(){
A{{}, 1}.dostuff(B{{}, 2});
}
```
Error message:
```
: In instantiation of 'auto Base::dostuff(Next) [with Next = B; T =
A]':
:27:21: required from here
:8:68: error: cannot convert 'B' to 'int' in initialization
8 | return Combiner{Base>{}, *this,
next};
|^~~~
||
|B
Compiler returned: 1
```
However, the error message is misleading - it seems clear that the programmer
forgot to cast `*this` to the derived type (i.e. change `*this` to
`static_cast(*this)`), but the error message is about something
totally different.
[Bug libstdc++/100823] Special member functions of common_iterator should be conditionally trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100823 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-06-17
[Bug c++/101106] [11/12 regression] =delete on second declaration of the same function produces a note with no error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101106
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 from Jonathan Wakely ---
This was intentionally changed from an error to a pedwarn by r11-1454
c++: Treat in-class default/delete as definitions.
We were complaining about a constrained defaulted non-template friend in a
template class because funcdef_flag wasn't set. grokdeclarator would set
it
for default/delete, but grokfield wasn't passing the 'initialized' values
needed. Fixing that revealed some errors in existing tests that we weren't
diagnosing. Since we accepted them for so long, I'm reducing the error to
a
pedwarn to ease compiler upgrade.
gcc/cp/ChangeLog:
* decl2.c (grokfield): Pass SD_DEFAULTED and SD_DELETED.
* decl.c (duplicate_decls): Reduce error for delete
after earlier declaration to pedwarn.
The fix would be:
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -2170,11 +2170,13 @@ duplicate_decls (tree newdecl, tree olddecl, bool
hiding, bool was_hidden)
if (DECL_DELETED_FN (newdecl))
{
auto_diagnostic_group d;
- pedwarn (newdecl_loc, OPT_Wpedantic,
- "deleted definition of %qD is not first declaration",
- newdecl);
- inform (olddecl_loc,
- "previous declaration of %qD", olddecl);
+ if (pedwarn (newdecl_loc, OPT_Wpedantic,
+ "deleted definition of %qD is not first
declaration",
+ newdecl);
+ {
+ inform (olddecl_loc,
+ "previous declaration of %qD", olddecl);
+ }
}
DECL_DELETED_FN (newdecl) |= DECL_DELETED_FN (olddecl);
}
[Bug c++/101106] [11/12 regression] =delete on second declaration of the same function produces a note with no error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101106 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-06-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The note is attached to a pedantic warning, which is not emitted by default. With -Wpedantic you get: del.C:2:9: warning: deleted definition of ‘int f()’ is not first declaration [-Wpedantic] 2 | int f() = delete; | ^ del.C:1:9: note: previous declaration of ‘int f()’ 1 | int f(); | ^ The note should only be printed when the pedwarn was printed.
[Bug target/87555] There is no need for UNSPEC_FMADDSUB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87555
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-06-17
--- Comment #1 from Richard Biener ---
The complication is that the define_insn looks like
(define_insn "*fma_fmaddsub_"
[(set (match_operand:VF_128_256 0 "register_operand" "=v,v,v,x,x")
(unspec:VF_128_256
[(match_operand:VF_128_256 1 "nonimmediate_operand" "%0,0,v,x,x")
(match_operand:VF_128_256 2 "nonimmediate_operand" "vm,v,vm,x,m")
(match_operand:VF_128_256 3 "nonimmediate_operand" "v,vm,0,xm,x")]
UNSPEC_FMADDSUB))]
"TARGET_FMA || TARGET_FMA4"
"@
vfmaddsub132\t{%2, %3, %0|%0, %3, %2}
vfmaddsub213\t{%3, %2, %0|%0, %2, %3}
vfmaddsub231\t{%2, %1, %0|%0, %1, %2}
vfmaddsub\t{%3, %2, %1, %0|%0, %1, %2, %3}
vfmaddsub\t{%3, %2, %1, %0|%0, %1, %2, %3}"
so it can handle the {132,213,231} variants without much duplication from a
single pattern. But it seems this cannot prevail when we open-code the
operation. Likewise handling multiple modes with the VF_128_256 iterator
becomes difficult since the addsub requires either a vec_merge (as in the
addsub patterns) with a constant selector specific to the mode (unless we
can provide a large one that is implicitely truncated) or a vector constant
when using the (vec_select (vec_concat ...)) form. So the above would
split into 12 somewhat repetitive patterns.
Doable.
Repeat for the AVX512 ones. Tedious ;)
[Bug c++/101106] [11/12 regression] =delete on second declaration of the same function produces a note with no error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101106 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.2 Summary|[11 regression] =delete on |[11/12 regression] =delete |second declaration of the |on second declaration of |same function produces a|the same function produces |note with no error |a note with no error Keywords||diagnostic
[Bug c++/101106] New: [11 regression] =delete on second declaration of the same function produces a note with no error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101106 Bug ID: 101106 Summary: [11 regression] =delete on second declaration of the same function produces a note with no error Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jlegg at feralinteractive dot com Target Milestone: --- GCC 10.3 correctly ([dcl.fct.def.delete] paragraph 4) diagnosed a "deleted definition of 'int f()'" error for: int f(); int f() = delete; However, GCC 11.1 doesn't emit the error part of the diagnostic, which pointed at the location of the deleted definition. It still emits a note pointing at the previous declaration, with no associated error or warning. This is possibly related to bug 90703. Unlike the example in that bug, this previously was correctly rejected however.
[Bug tree-optimization/100790] ICE with -O2: in verify_range, at value-range.cc:385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100790 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Aldy Hernandez --- ...and closed.
[Bug tree-optimization/100790] ICE with -O2: in verify_range, at value-range.cc:385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100790 --- Comment #4 from Aldy Hernandez --- fixed in trunk.
[Bug tree-optimization/100790] ICE with -O2: in verify_range, at value-range.cc:385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100790 --- Comment #3 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:f1555d4013ed3cae2589270436387063d1c2f1a3 commit r12-1562-gf1555d4013ed3cae2589270436387063d1c2f1a3 Author: Aldy Hernandez Date: Thu May 13 13:47:41 2021 -0400 Cleanup clz and ctz code in range_of_builtin_call. These are various cleanups to the clz/ctz code. First, ranges from range_of_expr are always numeric so we should adjust. Also, the checks for non-zero were assuming the argument was unsigned, which in the PR's testcase is clearly not. I've cleaned this up, so that it works either way. I've also removed the following annoying idiom: - int newmini = prec - 1 - wi::floor_log2 (r.upper_bound ()); - if (newmini == prec) This is really a check for r.upper_bound() == 0, as floor_log2(0) returns -1. It's confusing. Tested on x86-64 Linux. gcc/ChangeLog: PR tree-optimization/100790 * gimple-range.cc (range_of_builtin_call): Cleanup clz and ctz code. gcc/testsuite/ChangeLog: * gcc.dg/pr100790.c: New test.
[Bug fortran/101100] [9/10/11/12 Regression] ICE in trans_caf_token_assign, at fortran/trans-expr.c:9433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101100 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||vehre at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-06-17 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r7-5771-gde91486c745d5ff6.
[Bug c++/101099] [9/10/11/12 Regression] ICE in type_unification_real, at cp/pt.c:22173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101099 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2021-06-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r10-884-g9b79d5d3baad087f.
[Bug c++/101098] [11/12 Regression] ICE in instantiate_body, at cp/pt.c:25858 since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101098 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2021-06-17 Summary|[11/12 Regression] ICE in |[11/12 Regression] ICE in |instantiate_body, at|instantiate_body, at |cp/pt.c:25858 |cp/pt.c:25858 since ||r10-3735-gcb57504a55015891 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r10-3735-gcb57504a55015891.
[Bug target/100871] z14: vec_doublee maps to wrong builtin in vecintrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100871 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Marius Hillenbrand : https://gcc.gnu.org/g:de0fcacd568bbd86726df7a5416edd08a525c93a commit r9-9587-gde0fcacd568bbd86726df7a5416edd08a525c93a Author: Marius Hillenbrand Date: Wed Jun 16 18:26:48 2021 +0200 IBM Z: Fix vector intrinsics vec_double and vec_floate Fix the mapping of vec_double and vec_floate to builtins. gcc/ChangeLog: PR target/100871 * config/s390/vecintrin.h (vec_doublee): Fix to use __builtin_s390_vflls. (vec_floate): Fix to use __builtin_s390_vflrd. (cherry picked from commit a4fc63e0c3c6c7b895225c883137d152743be7fc)
[Bug target/100871] z14: vec_doublee maps to wrong builtin in vecintrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100871 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Marius Hillenbrand : https://gcc.gnu.org/g:66d838e249814dbe731ee8d983d63dedfa4ecffa commit r10-9927-g66d838e249814dbe731ee8d983d63dedfa4ecffa Author: Marius Hillenbrand Date: Wed Jun 16 18:26:48 2021 +0200 IBM Z: Fix vector intrinsics vec_double and vec_floate Fix the mapping of vec_double and vec_floate to builtins. gcc/ChangeLog: PR target/100871 * config/s390/vecintrin.h (vec_doublee): Fix to use __builtin_s390_vflls. (vec_floate): Fix to use __builtin_s390_vflrd. (cherry picked from commit a4fc63e0c3c6c7b895225c883137d152743be7fc)
[Bug target/100871] z14: vec_doublee maps to wrong builtin in vecintrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100871 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Marius Hillenbrand : https://gcc.gnu.org/g:e86ad5ad011573121291bccb88d3a6fdb933469c commit r11-8597-ge86ad5ad011573121291bccb88d3a6fdb933469c Author: Marius Hillenbrand Date: Wed Jun 16 18:26:48 2021 +0200 IBM Z: Fix vector intrinsics vec_double and vec_floate Fix the mapping of vec_double and vec_floate to builtins. gcc/ChangeLog: PR target/100871 * config/s390/vecintrin.h (vec_doublee): Fix to use __builtin_s390_vflls. (vec_floate): Fix to use __builtin_s390_vflrd. gcc/testsuite/ChangeLog: * gcc.target/s390/zvector/vec-doublee.c: New test. * gcc.target/s390/zvector/vec-floate.c: New test. (cherry picked from commit a4fc63e0c3c6c7b895225c883137d152743be7fc)
[Bug target/100871] z14: vec_doublee maps to wrong builtin in vecintrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100871 --- Comment #1 from CVS Commits --- The master branch has been updated by Marius Hillenbrand : https://gcc.gnu.org/g:a4fc63e0c3c6c7b895225c883137d152743be7fc commit r12-1559-ga4fc63e0c3c6c7b895225c883137d152743be7fc Author: Marius Hillenbrand Date: Wed Jun 16 18:26:48 2021 +0200 IBM Z: Fix vector intrinsics vec_double and vec_floate Fix the mapping of vec_double and vec_floate to builtins. gcc/ChangeLog: PR target/100871 * config/s390/vecintrin.h (vec_doublee): Fix to use __builtin_s390_vflls. (vec_floate): Fix to use __builtin_s390_vflrd. gcc/testsuite/ChangeLog: * gcc.target/s390/zvector/vec-doublee.c: New test. * gcc.target/s390/zvector/vec-floate.c: New test.
[Bug middle-end/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062 --- Comment #15 from Eric Botcazou --- > Eric, any idea what's going on? Shall I readd if (TREE_CODE (t) == > QUAL_UNION_TYPE) return; at the start function and thus ignore > QUAL_UNION_TYPE and handle only UNION_TYPEs, or should the bitfield > representatives in QUAL_UNION_TYPE get some DECL_QUALIFIER (either one that > always evaluates to false, or the same as corresponding bitfield), something > else? Let's try the former, i.e. disable the new code for QUAL_UNION_TYPE.
[Bug middle-end/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062 --- Comment #14 from Jakub Jelinek --- Sorry for bad paste, on QUAL_UNION_TYPE atree__atree_private_part__node_record___is_extension___XVN
[Bug middle-end/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062 --- Comment #13 from Jakub Jelinek --- I have tried to backport this patch to the 11 branch, but unlike the trunk, it doesn't build there, with atree.ads:3844:34: size for "Node_Record" too small make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:139: ada/errout.o] Error 1 (and many further occurrences of the same error). Seems the stor-layout.c changes trigger during ada/errout.o compilation just once, on QUAL_UNION_TYPE atree.ads:3844:34: size for "Node_Record" too small make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:139: ada/errout.o] Error 1 which has byte size 28 and bitfield FIELD_DECL S0 with the same byte size (224 bits) and another bitfield FIELD_DECL O with the same size. The code then adds two bit field representatives with the same size. Eric, any idea what's going on? Shall I readd if (TREE_CODE (t) == QUAL_UNION_TYPE) return; at the start function and thus ignore QUAL_UNION_TYPE and handle only UNION_TYPEs, or should the bitfield representatives in QUAL_UNION_TYPE get some DECL_QUALIFIER (either one that always evaluates to false, or the same as corresponding bitfield), something else? Wonder what is different that it works on the trunk...
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 54400, which changed state. Bug 54400 Summary: recognize vector reductions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54400 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/54400] recognize vector reductions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54400 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Declaring fixed.
[Bug middle-end/100898] [9/10 Regression] ICE with -O2: in gimple_call_arg_ptr, at gimple.h:3264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100898 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE|[9/10 Regression] ICE with |with -O2: in|-O2: in |gimple_call_arg_ptr, at |gimple_call_arg_ptr, at |gimple.h:3264 |gimple.h:3264 --- Comment #6 from Jakub Jelinek --- Fixed for 11.2 too.
[Bug debug/100852] [11 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 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug middle-end/54400] recognize vector reductions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54400
--- Comment #9 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:3dfa4fe9f1a089b2b3906c83e22a1b39c49d937c
commit r12-1551-g3dfa4fe9f1a089b2b3906c83e22a1b39c49d937c
Author: Richard Biener
Date: Tue Jun 8 15:10:45 2021 +0200
Vectorization of BB reductions
This adds a simple reduction vectorization capability to the
non-loop vectorizer. Simple meaning it lacks any of the fancy
ways to generate the reduction epilogue but only supports
those we can handle via a direct internal function reducing
a vector to a scalar. One of the main reasons is to avoid
massive refactoring at this point but also that more complex
epilogue operations are hardly profitable.
Mixed sign reductions are for now fend off and I'm not finally
settled with whether we want an explicit SLP node for the
reduction epilogue operation. Handling mixed signs could be
done by multiplying with a { 1, -1, .. } vector. Fend off
are also reductions with non-internal operands (constants
or register parameters for example).
Costing is done by accounting the original scalar participating
stmts for the scalar cost and log2 permutes and operations for
the vectorized epilogue.
--
SPEC CPU 2017 FP with rate workload measurements show (picked
fastest runs of three) regressions for 507.cactuBSSN_r (1.5%),
508.namd_r (2.5%), 511.povray_r (2.5%), 526.blender_r (0.5) and
527.cam4_r (2.5%) and improvements for 510.parest_r (5%) and
538.imagick_r (1.5%). This is with -Ofast -march=znver2 on a Zen2.
Statistics on CPU 2017 shows that the overwhelming number of seeds
we find are reductions of two lanes (well - that's basically every
associative operation). That means we put a quite high pressure
on the SLP discovery process this way.
In total we find 583218 seeds we put to SLP discovery out of which
66205 pass that and only 6185 of those make it through
code generation checks. 796 of those are discarded because the reduction
is part of a larger SLP instance. 4195 of the remaining
are deemed not profitable to vectorize and 1194 are finally
vectorized. That's a poor 0.2% rate.
Of the 583218 seeds 486826 (83%) have two lanes, 60912 have three (10%),
28181 four (5%), 4808 five, 909 six and there are instances up to 120
lanes.
There's a set of 54086 candidate seeds we reject because
they contain a constant or invariant (not implemented yet) but still
have two or more lanes that could be put to SLP discovery.
2021-06-16 Richard Biener
PR tree-optimization/54400
* tree-vectorizer.h (enum slp_instance_kind): Add
slp_inst_kind_bb_reduc.
(reduction_fn_for_scalar_code): Declare.
* tree-vect-data-refs.c (vect_slp_analyze_instance_dependence):
Check SLP_INSTANCE_KIND instead of looking at the
representative.
(vect_slp_analyze_instance_alignment): Likewise.
* tree-vect-loop.c (reduction_fn_for_scalar_code): Export.
* tree-vect-slp.c (vect_slp_linearize_chain): Split out
chain linearization from vect_build_slp_tree_2 and generalize
for the use of BB reduction vectorization.
(vect_build_slp_tree_2): Adjust accordingly.
(vect_optimize_slp): Elide permutes at the root of BB reduction
instances.
(vectorizable_bb_reduc_epilogue): New function.
(vect_slp_prune_covered_roots): Likewise.
(vect_slp_analyze_operations): Use them.
(vect_slp_check_for_constructors): Recognize associatable
chains for BB reduction vectorization.
(vectorize_slp_instance_root_stmt): Generate code for the
BB reduction epilogue.
* gcc.dg/vect/bb-slp-pr54400.c: New testcase.
[Bug driver/101103] -fsanitise=undef gives better help than -fsanitize=undef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101103 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Martin Liška --- I can take a look.
[Bug tree-optimization/101097] Vectorizer is too eager to use vec_unpack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101097 --- Comment #10 from Richard Biener --- (In reply to Uroš Bizjak from comment #8) > (In reply to Hongtao.liu from comment #6) > > > > I just to want to classify the test is used to test another optimization > > which rely on either loop vectorization or slp. it means it's ok to add > > unroll pragma here. > > The code with new patterns is clearly less optimal, so I've had some second > thoughts... But clearly the code is better than when not vectorized at all which is what happens when the iteration count isn't exactly 4, 8, 12 or 16.
[Bug tree-optimization/101097] Vectorizer is too eager to use vec_unpack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101097 --- Comment #9 from Hongtao.liu --- > As said - a lot of work, sth that might be easier when we got rid of the > SLP vs. non-SLP duality. Understand. I guess we will encounter more redundant packs and unpacks, considering that we have supported 4byte/8byte vectorization.
