[Bug tree-optimization/98774] gcc -O3 does not vectorize some operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98774 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Last reconfirmed||2021-01-21 Status|UNCONFIRMED |NEW Blocks||53947 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- There's t.ii:21:9: note: ==> examining statement: a$x_1 = *dpos_10(D).x; t.ii:21:9: missed: BB vectorization with gaps at the end of a load is not supported t.ii:27:6: missed: not vectorized: relevant stmt not supported: a$x_1 = *dpos_10(D).x; t.ii:21:9: note: Building vector operands of 0x4047278 from scalars instead which we eventually can improve. With AVX2 we split into one AVX and one SSE part and then run into a duplicate PR where we end up with conflicting vector types for a load which we do not yet support. We then end up with only vectorizing the AVX part. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug debug/98776] New: DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98776
Bug ID: 98776
Summary: DW_AT_low_pc is inconsistent with function entry
address, when enabling -fpatchable-function-entry
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: lvlin at mail dot ustc.edu.cn
Target Milestone: ---
Target: x86,arm64
-fpatchable-function-entry will generate N NOPs at the beginning of each
function. Observe the binary compiled by gcc, the function entry address is
inconsistent with the value of DW_AT_low_pc in the corresponding DWARF data.
I used a toy example to describe the issue;
1.Compile the source file toy_exam.c
$ gcc -o toy_exam.gcc toy_exam.c -g -gdwarf-4
-fpatchable-function-entry=2 -save-temps
2.Check the symbolic address of the function fun_a
$ readelf -s toy_exam.gcc |grep -w fun_a
95: 07f080 FUNCGLOBAL DEFAULT 13 fun_a
3.Display assembler contents
objdump -d toy_exam.gcc |grep -A 8 -w \:
07f0 :
7f0: d503201fnop
7f4: d503201fnop
7f8: a9be7bfdstp x29, x30, [sp, #-32]!
7fc: 910003fdmov x29, sp
800: 52800040mov w0, #0x2// #2
804: b90017e0str w0, [sp, #20]
808: 528000a0mov w0, #0x5// #5
80c: b9001be0str w0, [sp, #24]
4.dump dwarf info
$ llvm-dwarfdump toy_exam.gcc |grep -C 10 -w fun_a
0x0315: DW_TAG_subprogram
DW_AT_external (true)
DW_AT_name ("fun_a")
DW_AT_decl_file ("/home/jianlin/code/test/toy_exam.c")
DW_AT_decl_line (14)
DW_AT_decl_column (0x06)
DW_AT_low_pc(0x07f8)
DW_AT_high_pc (0x0840)
DW_AT_frame_base(DW_OP_call_frame_cfa)
DW_AT_GNU_all_tail_call_sites (true)
DW_AT_sibling (0x035d)
5. Assembler code
fun_a:
.section__patchable_function_entries
.8byte .LPFE2
.text
.LPFE2:
nop
nop
.LFB7:
.loc 1 15 1
.cfi_startproc
stp x29, x30, [sp, -32]!
.cfi_def_cfa_offset 32
.cfi_offset 29, -32
.cfi_offset 30, -24
mov x29, sp
.loc 1 16 13
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/gcc-trunk/libexec/gcc/aarch64-unknown-linux-gnu/11.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/gcc-trunk
--enable-languages=c,c++,fortran --disable-libquadmath
--disable-libquadmath-support --disable-werror --disable-bootstrap
--enable-gold
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210119 (experimental) (GCC)
the first instruction in the compile unit indicated by DW_AT_low_pc does not
include NOP.
GCC-9, GCC-10 and the latest master branch were respectively tested, and the
results were the same.
[Bug target/98743] ICE in convert_move, at expr.c:220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98743 --- Comment #2 from Kito Cheng --- ICE after g:6fbec038f7a7ddf29f074943611b53210d17c40c, hmmm...interesting...
[Bug target/98694] [11 Regression] GCC produces incorrect code for loops with -O3 for skylake-avx512 and icelake-server
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98694 --- Comment #9 from Hongtao.liu --- Fix on trunk sofar
[Bug target/98694] [11 Regression] GCC produces incorrect code for loops with -O3 for skylake-avx512 and icelake-server
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98694 --- Comment #8 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:e711b67a9081ae84c66174a50705dc98ba993a43 commit r11-6828-ge711b67a9081ae84c66174a50705dc98ba993a43 Author: liuhongt Date: Mon Jan 18 16:55:32 2021 +0800 Fix incorrect optimization by cprop_hardreg. If SRC had been assigned a mode narrower than the copy, we can't always link DEST into the chain even they have same hard_regno_nregs(i.e. HImode/SImode in i386 backend). i.e kmovw %k0, %edi vmovd %edi, %xmm2 vpshuflw$0, %xmm2, %xmm0 kmovw %k0, %r8d kmovd %k0, %r9d ... -movl %r9d, %r11d +vmovd %xmm2, %r11d gcc/ChangeLog: PR rtl-optimization/98694 * regcprop.c (copy_value): If SRC had been assigned a mode narrower than the copy, we can't link DEST into the chain even they have same hard_regno_nregs(i.e. HImode/SImode in i386 backend). gcc/testsuite/ChangeLog: PR rtl-optimization/98694 * gcc.target/i386/pr98694.c: New test.
[Bug target/98743] ICE in convert_move, at expr.c:220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98743 Kito Cheng changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |kito at gcc dot gnu.org --- Comment #1 from Kito Cheng --- Confirmed.
[Bug tree-optimization/98774] gcc -O3 does not vectorize some operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98774 --- Comment #1 from Hongtao.liu --- It's fixed in current trunk https://godbolt.org/z/63576n
[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172 --- Comment #10 from Hongtao.liu --- (In reply to Hongtao.liu from comment #9) > > .L3: > > vmovupd (%rcx,%rax), %xmm3 > > vmovupd (%rsi,%rax), %xmm4 > > vinsertf128 $0x1, 16(%rcx,%rax), %ymm3, %ymm0 > > vinsertf128 $0x1, 16(%rsi,%rax), %ymm4, %ymm2 > > vmovupd (%rdi,%rax), %xmm5 > > vinsertf128 $0x1, 16(%rdi,%rax), %ymm5, %ymm1 > > vfmadd132pd %ymm2, %ymm1, %ymm0 > > vmovupd %xmm0, (%rdx,%rax) > > vextractf128$0x1, %ymm0, 16(%rdx,%rax) > > addq$32, %rax > > cmpq$2048, %rax > > jne .L3 > > vzeroupper > > ret > > The kernel loop could be better as > > .L3: > vmovupd (%rcx,%rax), %ymm0 > vmovupd (%rdi,%rax), %ymm1 > vfmadd132pd (%rsi,%rax), %ymm1, %ymm0 > vmovupd %ymm0, (%rdx,%rax) > addq$32, %rax > cmpq$2048, %rax > jne .L3 It went into movmisalign, and finally be splitted into parts by ix86_avx256_split_vector_move_misalign, and the differences between -mtune=generic and -mtune=haswell matters here is X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL and X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL --- /* X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL: if false, unaligned loads are split. */ DEF_TUNE (X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL, "256_unaligned_load_optimal", ~(m_NEHALEM | m_SANDYBRIDGE | m_GENERIC)) /* X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL: if false, unaligned stores are split. */ DEF_TUNE (X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL, "256_unaligned_store_optimal", ~(m_NEHALEM | m_SANDYBRIDGE | m_BDVER | m_ZNVER1 | m_GENERIC)) manually adding two tunes to generic gcc -S -O3 y.c -mavx2 -mfma -mtune-ctrl="256_unaligned_load_optimal,256_unaligned_store_optimal" successfully generate optimial codes. .L3: vmovupd (%rcx,%rax), %ymm0 vmovupd (%rdi,%rax), %ymm1 vfmadd132pd (%rsi,%rax), %ymm1, %ymm0 vmovupd %ymm0, (%rdx,%rax) addq$32, %rax cmpq$2048, %rax jne .L3 vzeroupper ret .L5:
[Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653 Michael Meissner changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Michael Meissner --- Bug fixed with the December 3rd, 2020 check-in to the master branch. We do not expect GCC 10 to build with IEEE 128-bit long double default, so we don't need a backport at this time.
[Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653 Bug 97653 depends on bug 97543, which changed state. Bug 97543 Summary: powerpc64le: libgcc has unexpected long double in .gnu_attribute https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug libgcc/97543] powerpc64le: libgcc has unexpected long double in .gnu_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Michael Meissner --- Back port to GCC 10 done on January 20th, 2021. Bug closed.
[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172 --- Comment #9 from Hongtao.liu --- > .L3: > vmovupd (%rcx,%rax), %xmm3 > vmovupd (%rsi,%rax), %xmm4 > vinsertf128 $0x1, 16(%rcx,%rax), %ymm3, %ymm0 > vinsertf128 $0x1, 16(%rsi,%rax), %ymm4, %ymm2 > vmovupd (%rdi,%rax), %xmm5 > vinsertf128 $0x1, 16(%rdi,%rax), %ymm5, %ymm1 > vfmadd132pd %ymm2, %ymm1, %ymm0 > vmovupd %xmm0, (%rdx,%rax) > vextractf128$0x1, %ymm0, 16(%rdx,%rax) > addq$32, %rax > cmpq$2048, %rax > jne .L3 > vzeroupper > ret The kernel loop could be better as .L3: vmovupd (%rcx,%rax), %ymm0 vmovupd (%rdi,%rax), %ymm1 vfmadd132pd (%rsi,%rax), %ymm1, %ymm0 vmovupd %ymm0, (%rdx,%rax) addq$32, %rax cmpq$2048, %rax jne .L3
[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #13 from Martin Sebor --- A simple patch that just makes sure the NO_WARNING bits stays set: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563944.html
[Bug middle-end/98465] [11 Regression] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Martin Sebor changed: What|Removed |Added Summary|Bogus warning |[11 Regression] Bogus |stringop-overread wuth |-Wstringop-overread with |-std=gnu++20 -O2 and|-std=gnu++20 -O2 and |std::string::insert |std::string::insert --- Comment #17 from Martin Sebor --- Emitting the warning even with -Wno-system-headers is technically a regression.
[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172
--- Comment #8 from H.J. Lu ---
-mtune=generic -mavx2 -mfma generates awful code:
[hjl@gnu-skx-1 tmp]$ cat y.c
#define DATA_ENTRIES 256
extern double *a, *x, *y, *z;
void work()
{
int i;
for (i = 0; i < DATA_ENTRIES; ++i)
z[i] = a[i] * x[i] + y[i];
}
[hjl@gnu-skx-1 tmp]$ gcc -S -O3 y.c -mavx2 -mfma
[hjl@gnu-skx-1 tmp]$ cat y.s
.file "y.c"
.text
.p2align 4
.globl work
.type work, @function
work:
.LFB0:
.cfi_startproc
movqz(%rip), %rdx
movqx(%rip), %rsi
movqa(%rip), %rcx
movqy(%rip), %rdi
leaq8(%rsi), %r8
movq%rdx, %rax
subq%r8, %rax
leaq8(%rcx), %r9
cmpq$16, %rax
movq%rdx, %rax
seta%r8b
subq%r9, %rax
cmpq$16, %rax
seta%al
testb %al, %r8b
je .L5
leaq8(%rdi), %r8
movq%rdx, %rax
subq%r8, %rax
cmpq$16, %rax
jbe .L5
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L3:
vmovupd (%rcx,%rax), %xmm3
vmovupd (%rsi,%rax), %xmm4
vinsertf128 $0x1, 16(%rcx,%rax), %ymm3, %ymm0
vinsertf128 $0x1, 16(%rsi,%rax), %ymm4, %ymm2
vmovupd (%rdi,%rax), %xmm5
vinsertf128 $0x1, 16(%rdi,%rax), %ymm5, %ymm1
vfmadd132pd %ymm2, %ymm1, %ymm0
vmovupd %xmm0, (%rdx,%rax)
vextractf128$0x1, %ymm0, 16(%rdx,%rax)
addq$32, %rax
cmpq$2048, %rax
jne .L3
vzeroupper
ret
.L5:
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L2:
vmovsd (%rcx,%rax), %xmm0
vmovsd (%rdi,%rax), %xmm6
vfmadd132sd (%rsi,%rax), %xmm6, %xmm0
vmovsd %xmm0, (%rdx,%rax)
addq$8, %rax
cmpq$2048, %rax
jne .L2
ret
.cfi_endproc
.LFE0:
.size work, .-work
.ident "GCC: (GNU) 10.2.1 20210119 (Red Hat 10.2.1-10)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 tmp]$ gcc -S -O3 y.c -mavx2 -mfma -mtune=haswell
[hjl@gnu-skx-1 tmp]$ cat y.s
.file "y.c"
.text
.p2align 4
.globl work
.type work, @function
work:
.LFB0:
.cfi_startproc
movqz(%rip), %rdx
movqx(%rip), %rsi
movqa(%rip), %rcx
movqy(%rip), %rdi
leaq8(%rsi), %r8
movq%rdx, %rax
subq%r8, %rax
leaq8(%rcx), %r9
cmpq$16, %rax
movq%rdx, %rax
seta%r8b
subq%r9, %rax
cmpq$16, %rax
seta%al
testb %al, %r8b
je .L5
leaq8(%rdi), %r8
movq%rdx, %rax
subq%r8, %rax
cmpq$16, %rax
jbe .L5
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L3:
vmovupd (%rcx,%rax), %ymm0
vmovupd (%rdi,%rax), %ymm1
vfmadd132pd (%rsi,%rax), %ymm1, %ymm0
vmovupd %ymm0, (%rdx,%rax)
addq$32, %rax
cmpq$2048, %rax
jne .L3
vzeroupper
ret
.L5:
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L2:
vmovsd (%rcx,%rax), %xmm0
vmovsd (%rdi,%rax), %xmm2
vfmadd132sd (%rsi,%rax), %xmm2, %xmm0
vmovsd %xmm0, (%rdx,%rax)
addq$8, %rax
cmpq$2048, %rax
jne .L2
ret
.cfi_endproc
.LFE0:
.size work, .-work
.ident "GCC: (GNU) 10.2.1 20210119 (Red Hat 10.2.1-10)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 tmp]$
[Bug tree-optimization/98775] missing optimization opportunity on nbody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98775 --- Comment #1 from Ivan Sorokin --- Created attachment 50016 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50016=edit nbody-unrolled.cpp
[Bug tree-optimization/98775] New: missing optimization opportunity on nbody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98775 Bug ID: 98775 Summary: missing optimization opportunity on nbody Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vanyacpp at gmail dot com Target Milestone: --- Created attachment 50015 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50015=edit nbody.cpp On the attached sample (208 LOC), clang 11.0 generates the code that is almost twice as fast as the one generated by GCC 10.2 (-O3 -ffast-math -flto). $ ./nbody 5000 4.0s for clang vs 7.5s for GCC. A quick look at the generated code shows that clang aggressively unrolled all inner loops. If I unroll all inner loops manually I get: $ ./nbody-unrolled 5000 3.7s for clang vs 6.3s for GCC. 17.6B instructions for clang vs 29.6B instructions for GCC. While the first sample is a subject to unrolling heuristic, the second is about optimizing the completely linear chunk of code with many floating point multiplications and additions. I tried reducing the sample further, but I only came up with PR98774.
[Bug ada/98773] [11 regression] Bootstrap failure: "Trmsgggg" conflicts with declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98773 Rainer Orth changed: What|Removed |Added Target|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11 |sparc-sun-solaris2.11, ||i686-pc-linux-gnu --- Comment #1 from Rainer Orth --- FWIW it seems to be a 32-bit-only issue: while both amd64-pc-solaris2.11 and x86_64-pc-linux-gnu bootstraps worked fine, i686-pc-linux-gnu is similarly broken: targparm.adb:76:04: "Tbbccstr" conflicts with declaration at line 75
[Bug tree-optimization/98774] New: gcc -O3 does not vectorize multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98774
Bug ID: 98774
Summary: gcc -O3 does not vectorize multiplication
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
Created attachment 50014
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50014=edit
nbody-update-velocity.cpp
In the following sample GCC (-O3 -ffast-math) fails to vectorize operations.
The results is that GCC 10.2 does 8 mulsd, while clang 11.0 does 4 mulpd.
struct vec3 { double x, y, z; };
void update_velocities(vec3* __restrict velocity,
double const* __restrict mass,
vec3 const* __restrict dpos,
double const* __restrict mag)
{
velocity[0] -= dpos[0] * (mass[1] * mag[0]);
velocity[1] += dpos[0] * (mass[0] * mag[0]);
}
See an attachment for the complete sample.
[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug testsuite/98643] [11 regression] r11-6615 causes failure in gcc.target/powerpc/fold-vec-extract- char.p7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98643 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from seurer at gcc dot gnu.org --- Works now, thanks for the fix!
[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646
--- Comment #12 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #10)
> So, the problem is IMHO that the warning about passing NULL to this is
> misplaced, it shouldn't be done in the FEs, but later when there was at
> least some chance of dead code removal.
That would be a hack. First, the this argument to a member function is just
like a plain argument to an ordinary nonnull function, so they all should be
treated the same. Second, there already is code in tree-ssa-ccp.c to handle
-Wnonnull, so nothing needs to be moved.
The -Wnonnull code could be removed from the front end, but that would
considerably compromise the warning: passing null pointers to inline member
functions would cease to be diagnosed. See for example the effect on the code
below. In C++ that wouldn't be a good deal.
$ cat u.C && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout u.C
struct S {
int i;
void f () { i = 0; };
void g ();
};
void f (void)
{
S *p = 0;
p->f (); // missing warning
}
void g (void)
{
S *p = 0;
p->g (); // -Wnonnull (good)
}
;; Function f (_Z1fv, funcdef_no=1, decl_uid=2357, cgraph_uid=2,
symbol_order=1) (executed once)
void f ()
{
[local count: 1073741824]:
MEM[(struct S *)0B].i ={v} 0;
__builtin_trap ();
}
u.C: In function ‘void g()’:
u.C:16:8: warning: ‘this’ pointer null [-Wnonnull]
16 | p->g (); // -Wnonnull (good)
| ~^~
u.C:4:8: note: in a call to non-static member function ‘void S::g()’
4 | void g ();
|^
;; Function g (_Z1gv, funcdef_no=2, decl_uid=2360, cgraph_uid=3,
symbol_order=2)
void g ()
{
[local count: 1073741824]:
S::g (0B); [tail call]
return;
}
Also, removing the -Wnonnull handling from the FE wouldn't actually solve the
reported problem. It would just paper over it because the middle end warning
doesn't consider PHIs yet. If/when it's enhanced to consider them the warning
would come back again as is plain to see in the dump for the test case from
comment #11:
$ cat pr98646.C && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout pr98646.C
struct A { virtual ~A (); };
struct B { virtual ~B (); B* f (); };
struct C: A, B { virtual ~C (); void g () const; };
void f (B *p)
{
static_cast(p->f ())->g (); // bogus -Wnonnull
}
;; Function f (_Z1fP1B, funcdef_no=0, decl_uid=2430, cgraph_uid=1,
symbol_order=0)
Removing basic block 5
void f (struct B * p)
{
struct C * iftmp.0_1;
struct B * _5;
struct C * iftmp.0_6;
[local count: 1073741824]:
_5 = B::f (p_3(D));
if (_5 != 0B)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 751619281]:
iftmp.0_6 = _5 + 18446744073709551608;
[local count: 1073741824]:
# iftmp.0_1 = PHI
C::g (iftmp.0_1); [tail call] <<< should get a warning: pointer may be
null
return;
}
We can see that already today by running the analyzer on the test case:
pr98646.C: In function ‘void f(B*)’:
pr98646.C:8:31: warning: use of NULL where non-null expected [CWE-476]
[-Wanalyzer-null-argument]
8 | static_cast(p->f ())->g (); // bogus -Wnonnull
| ^~
‘void f(B*)’: events 1-3
|
|
pr98646.C:4:38: note: argument 'this' of ‘void C::g() const’ must be non-null
4 | struct C: A, B { virtual ~C (); void g () const; };
| ^
Which is why, if we want to avoid these warnings, we need the front end to
annotate the implicit COND_EXPR somehow. It could be done by setting
TREE_NO_WARNING but I'd worry about it getting lost or unintentionally
suppressing important warnings. Adding a special internal function instead and
expanding it after the first -Wnonnull handler would be better.
[Bug fortran/85547] Run-time error: character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #6 from anlauf at gcc dot gnu.org ---
The trim() and string concatenation are not even needed to see the string
length getting lost.
Example:
program p
implicit none
character(10) :: path = 'xyz/'
print *, len ( [ character(16) :: path ] ) ! ok
call print_string ( [ character(16) :: path ] ) ! typespec lost
contains
subroutine print_string (s)
character(*), intent(in) :: s(:)
print *, len(s), len(s)==16
end subroutine
end program
prints:
16
10 F
Inspection of the tree-dump shows that the temporary creation for the
subroutine call looks like we initially have the proper string length
after the array constructor
atmp.6.dtype = {.elem_len=16, .rank=1, .type=6};
atmp.6.dim[0].stride = 1;
atmp.6.dim[0].lbound = 0;
atmp.6.dim[0].ubound = 0;
atmp.6.span = 16;
which gets copied to the temporary
atmp.9.dtype = {.elem_len=10, .rank=1, .type=6};
atmp.9.dim[0].stride = 1;
atmp.9.dim[0].lbound = 0;
atmp.9.dim[0].ubound = 0;
atmp.9.span = 10;
I wonder where we get this from.
Besides, we actually create two temporaries in succession instead of just
one...
[Bug c++/98750] does not detect dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98750 --- Comment #2 from Tiago Macarios --- Correct. I was expecting a warning there.
[Bug c++/98744] [11 Regression] ICE in gimple_call_arg, at gimple.h:3246 since r11-6735-g424deca72b63e644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- It's easy enough to change tree-ssa-uninit.c to avoid assuming that a call has as many arguments as the called function type indicates by calling gimple_call_arg() with an index in excess of gimple_call_num_args(). The last time we had something like this happen the decision was to make the type match: pr95581. If this case is different I can adjust the uninit pass.
[Bug c++/97399] [9/10/11 Regression] g++ 9.3 cannot compile SFINAE code with separated declaration and definition, g++ 7.3 compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97399
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
CC||ppalka at gcc dot gnu.org
--- Comment #4 from Patrick Palka ---
The alias template in the reduced testcase is a red herring, the ICE can be
reproduced without it:
template struct enable_if_t {};
struct tmp {
template static constexpr bool is_integral();
template
static auto func(E, E) -> enable_if_t()>;
};
template constexpr bool tmp::is_integral() { return true; }
int main() { tmp::func(1, 0); }
Looks like the problematic hunk from r9-5972 is
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2096,7 +2096,8 @@ finish_qualified_id_expr (tree qualifying_class,
{
/* See if any of the functions are non-static members. */
/* If so, the expression may be relative to 'this'. */
- if (!shared_member_p (expr)
+ if ((type_dependent_expression_p (expr)
+ || !shared_member_p (expr))
&& current_class_ptr
&& DERIVED_FROM_P (qualifying_class,
current_nonlambda_class_type ()))
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #22 from Segher Boessenkool --- Fixed with commit f8c66617ab91826af1d950b00d853eaff622 Author: Segher Boessenkool Date: Tue Jan 19 23:43:56 2021 + rs6000: Fix rs6000_emit_le_vsx_store (PR98549) One of the advantages of LRA is that you can create new pseudos from it just fine. The code in rs6000_emit_le_vsx_store was not aware of this. This patch changes that, in the process fixing PR98549 (where it is shown that we do call rs6000_emit_le_vsx_store during LRA, which we used to assert can not happen). 2021-01-20 Segher Boessenkool * config/rs6000/rs6000.c (rs6000_emit_le_vsx_store): Change assert. Adjust comment. Simplify code.
[Bug ada/98773] [11 regression] Bootstrap failure: "Trmsgggg" conflicts with declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98773 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug ada/98773] New: [11 regression] Bootstrap failure: "Trmsgggg" conflicts with declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98773 Bug ID: 98773 Summary: [11 regression] Bootstrap failure: "Trms" conflicts with declaration Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 Between 20210119 (8227106f5668c8fb1f0c5d2026e44cc0b84ee991) and 20210120 (261cdd23195bc921737fd7a44e34a93ccc44), bootstrap began to fail in stage 2: * Solaris/x86: a-except.adb:625:04: "Trms" conflicts with declaration at line 624 * Solaris/SPARC: osint.ads:51:04: "T" conflicts with declaration at line 50 a-except.adb:625:04: "Trrr" conflicts with declaration at line 624 butil.adb:401:55: "T" conflicts with declaration at line 397 osint.ads:51:04: "T" conflicts with declaration at line 50 erroutc.adb:383:55: "T" conflicts with declaration at line 381 errout.adb:787:07: "T" conflicts with declaration at line 786 exp_ch6.adb:82:04: "T" conflicts with declaration at exp_ch6.ads:59 sem_util.adb:885:30: "T" conflicts with declaration at line 881 sem_util.adb:885:30: "T" conflicts with declaration at line 881 Seems like a miscompilation; haven't started a reghunt yet.
[Bug middle-end/95848] missing -Wuninitialized passing structs by value (VOPS)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95848
--- Comment #4 from Martin Sebor ---
There's no code code to handle the last case. The first case is handled
because the local s is assigned to a temporary and there is code to detect
uninitialized sources of assignments. The second case is handled in the new
maybe_warn_pass_by_reference() function. The third case enters the function
but is excluded because the argument is passed by value and nothing else checks
passing non-SSA_NAME operands.
In the test case below passing the uninitialized i is diagnosed because i's an
SSA_NAME. Passing s isn't because it's not one.
maybe_warn_pass_by_reference() should handle this case as well (and be renamed
appropriately).
$ gcc -S -Wall -fdump-tree-ssa=/dev/stdout ../t.c
;; Function h (h, funcdef_no=0, decl_uid=1948, cgraph_uid=1, symbol_order=0)
void h ()
{
int i;
struct S s;
:
fs (s, i_2(D));
s ={v} {CLOBBER};
return;
}
../t.c: In function ‘h’:
../t.c:9:3: warning: ‘i’ is used uninitialized [-Wuninitialized]
9 | fs (s, i);
| ^
[Bug debug/98765] [11 Regression] stripping of LTO debug sections doesn't work anymore since switch to -gdwarf-5 by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98765 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug debug/98765] [11 Regression] stripping of LTO debug sections doesn't work anymore since switch to -gdwarf-5 by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98765 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:27c792895bd809115c1f70672835b7fdff74d318 commit r11-6820-g27c792895bd809115c1f70672835b7fdff74d318 Author: Jakub Jelinek Date: Wed Jan 20 18:51:04 2021 +0100 debug: Fix up DWARF 5 -g -flto -ffat-lto-objects [PR98765] As mentioned in the PR, with -gdwarf-5 (or -g now) -flto -ffat-lto-objects, users can't strip the LTO sections with strip -p -R .gnu.lto_* -R .gnu.debuglto_* -N __gnu_lto_v1 anymore when GCC is configured against recent binutils. The problem is that in that case .gnu.debuglto_.debug_line_str section is then used, which is fine for references to strings in .gnu.debuglto_.* sections, but not when those references are in .debug_info section too; those should really reference separate strings in .debug_line_str section. For .gnu.debuglto_.debug_str vs. .debug_str we handle it right, we reset_indirect_string the strings and thus force creation of new labels for the second time. But for DW_FORM_line_strp as the patch shows, there were multiple problems. First one was that reset_indirect_string, even when called through traverse on debug_line_str_hash, didn't do anything at all (fixed by first hunk). The second bug was that the DW_FORM_line_strp strings, which were supposed to be only visible through debug_line_str_hash, leaked into debug_str_hash (second hunk). And the third thing is that when we reset debug_line_str_hash, we should still make those strings DW_FORM_line_strp if they are accessed. One could do it by reinstantiating DW_FORM_line_strp right away in reset_indirect_string and not clear debug_line_str_hash, but that has the disadvantage that we then force emitting .debug_line_str strings that aren't really needed - we need those from the CU DIEs' DW_AT_name and DW_AT_comp_dir attributes, but when emitting .debug_line section through assembler, we don't need to emit the strings we only needed for .gnu.debuglto_.debug_line which is always emitted by the compiler. 2021-01-20 Jakub Jelinek PR debug/98765 * dwarf2out.c (reset_indirect_string): Also reset indirect strings with DW_FORM_line_strp form. (prune_unused_types_update_strings): Don't add into debug_str_hash indirect strings with DW_FORM_line_strp form. (adjust_name_comp_dir): New function. (dwarf2out_finish): Call it on CU DIEs after resetting debug_line_str_hash.
[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753 --- Comment #9 from Akim Demaille --- Hi Martin, Thanks for the detailed explanation. (In reply to Martin Sebor from comment #5) > Changing this message alone to say "free() may be called with non-heap > object" wouldn't be appropriate without also changing all the other messages > that are subject to the same problem (all flow-sensitive warnings are). And I definitely believe this should be done. All the messages that claim "you _have_ this problem" should be reworded to "you _may have_ this problem"–unless of course that the problem can be proven to exist. But I agree this is beyond the scope of this issue. Cheers
[Bug testsuite/98643] [11 regression] r11-6615 causes failure in gcc.target/powerpc/fold-vec-extract- char.p7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98643 --- Comment #3 from Vladimir Makarov --- I believe a patch for PR98722 fixes this PR too. 4334b524274203125193a08a8485250c41c2daa9
[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #21 from Vladimir Makarov --- Additional fix for PR98722 is necessary for this PR. 4334b524274203125193a08a8485250c41c2daa9
[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753 --- Comment #8 from Akim Demaille --- Hi Richard, (In reply to Richard Biener from comment #3) > The issue is that we isolate a path that is impossible to take but on that > path we have p = free (p); and thus a "proved" mistake. But in > reality it is guarded by an effective if (false) condition. So it's not as > simple as you think. Point taken, thanks (though I'm not sure I understand why it would explore branches below an 'if (false)', but I definitely don't know the details). > (we also emit diagnostics on function bodies we do not > know are actually never called) I will not dispute that this is a hard job (I was just pointing that it should not impossible in that precise case). But it just emphasizes again that the *wording* is wrong. > warning: ‘void free(void*)’ called on unallocated object ‘yyssa’ This is plain false. Free is provably *never* called with yyssa. The wording should stop being so affirmative, so that the users don't get the wrong impression. Cheers!
[Bug rtl-optimization/98722] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-6615-gcf2ac1c30af0fa783c8d72e527904dda5d8cc330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722 --- Comment #4 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:4334b524274203125193a08a8485250c41c2daa9 commit r11-6819-g4334b524274203125193a08a8485250c41c2daa9 Author: Vladimir N. Makarov Date: Wed Jan 20 11:40:14 2021 -0500 [PR98722] LRA: Check that target has no 3-op add insn to transform 2 plus expression. Patch cf2ac1c30af0fa783c8d72e527904dda5d8cc330 for solving PR97969 was assumed for targets with absent 3-op add insn. But the original patch did not check this. This patch adds the check. gcc/ChangeLog: PR rtl-optimization/98722 * lra-eliminations.c (eliminate_regs_in_insn): Check that target has no 3-op add insn to transform insns containing two pluses. gcc/testsuite/ChangeLog: PR rtl-optimization/98722 * g++.target/s390/pr98722.C: New.
[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753 Martin Sebor changed: What|Removed |Added Summary|-Wfree-nonheap-object on|-Wfree-nonheap-object on |Bison generated code|unreachable code with -O0 Known to fail||11.0 Status|WAITING |NEW Component|c++ |middle-end --- Comment #7 from Martin Sebor --- I can reproduce the warning with no optimization, thanks. At -O0, there are three calls to free in the IL when the warning runs. The second one that triggers it # .MEM_218 = VDEF <.MEM_216> free (yymsg.17_83); is eliminated by copy propagation at -O1. It's not eliminated at -O0 because the optimization isn't done then. So the ultimate root cause of the problem is the same as in pr54202, except at -O0 (the test case there depends on inlining). It would be possible to disable the warning at -O0 to avoid this false positive at the expense of some false negatives. I'm not sure that would be a good solution based on a single report. If more bugs like this are reported we might reconsider. Let me keep this bug open until then.
[Bug c++/98744] [11 Regression] ICE in gimple_call_arg, at gimple.h:3246 since r11-6735-g424deca72b63e644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744
Martin Jambor changed:
What|Removed |Added
Component|ipa |c++
--- Comment #3 from Martin Jambor ---
This is the gimple dump (omitting only function main), note the mismatch
between formal parameters of B::B and the actual arguments of its call:
void C::C (struct C * const this)
{
*this = {CLOBBER};
{
this->D.2385._vptr.B = 0B;
_1 = >D.2385;
B::B (_1);
_2 = &_ZTV1C + 24;
this->D.2385._vptr.B = _2;
}
}
void B::B (struct B * const this, const void * * __vtt_parm)
{
_1 = *__vtt_parm;
this->_vptr.B = _1;
}
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #14 from Marius Hillenbrand --- Comparing x86-64 to s390x, modref_may_conflict makes a mistake when analyzing whether the called function Get_Next_Interp because of incomplete data on alias sets. That specific analysis involves alias sets 2, 5, and 6, which are missing in vec *alias_sets on s390x, while they are present on x86-64. (I'm using -flto-partition=max and only looking at a single LTO partition of an affected function) looking at loops of this kind: while Present (It.Typ) loop Get_Next_Interp (I, It); end loop; optimization goes off the rails because ipa-modref makes incorrect claims about Get_Next_Interp and how it handles "It" (a padding around a record of type info in the Ada frontend, the variable used like an iterator). ipa-modref: call to sem_type__get_next_interp/2320 does not clobber ref: it.F.typ alias sets: 5->5 ltrans.085i.modref claims to read ok data on both x86-64 and s390x, Read modref for sem_type__get_next_interp/2320 loads: Limits: 32 bases, 16 refs Base 0: alias set 1 Ref 0: alias set 1 Every access Base 1: alias set 2 Ref 0: alias set 2 Every access stores: Limits: 32 bases, 16 refs Base 0: alias set 2 Ref 0: alias set 2 access: Parm 1 param offset:0 offset:0 size:96 max_size:96 parm 0 flags: direct noclobber noescape nodirectescape parm 1 flags: direct noescape nodirectescape yet the alias set 2 does not show up on s390x. The padding record (type of It) has an alias-set in its type-decl (5 on s390x, 6 on x86) yet that does not show up in alias.c:alias_sets. Further, the record-type sem_type__interp (i.e., it.F, inside the padding) has alias set 2 assigned on x86-64, which matches the loaded modref data, but has alias-set -1 on s390x. Another discrepancy: the record-type decl sem_type__interp is flagged unaddressable and has TImode on s390x vs BLKmode on x86-64 (and not flagged unaddressable). Could that flag cause the type to not get associated an alias-set?
[Bug c++/98753] -Wfree-nonheap-object on Bison generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753 --- Comment #6 from Christoph --- Sorry for not providing the command line argument and the new output. > gcc-11 -std=c++17 cmCommandArgumentParser_complete.cxx cmCommandArgumentParser.cxx: In function ‘int cmCommandArgument_yyparse(yyscan_t)’: cmCommandArgumentParser.cxx:1838:10: warning: ‘void free(void*)’ called on unallocated object ‘yyssa’ [-Wfree-nonheap-object] cmCommandArgumentParser.cxx:1203:16: note: declared here /usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/11/../../../../lib64/crt1.o: in function `_start': /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:110: undefined reference to `main' ...
[Bug ipa/98744] [11 Regression] ICE in gimple_call_arg, at gimple.h:3246 since r11-6735-g424deca72b63e644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744 --- Comment #2 from Martin Jambor --- That cannot be the problem. IPA-SRA re-creates the call statements and builds them with gimple_build_call_vec (callee_decl, vargs); where calle_decl is the new function which has had its type adjusted and everything. Indeed, IPA-SRA does not remove an argument here, it just tries to push one dereference to the caller and the printed type is correct. Even in the release_ssa dump, pre-IPA, the constructor has two parameters but is called with just one. At the moment it looks to me that IPA-SRA makes an already invalid IL somehow a bit worse. Indeed, in the revision before 424deca72b6 the constructor in the release_ssa dump only has one parameter. Jason, is it possible a wrong constructor is emitted to the IL? (And note that tree-ssa-uninit.c should not ICE either, because with K C input or malformed LTO we can have weird mismatches too.)
[Bug c++/98753] -Wfree-nonheap-object on Bison generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753 --- Comment #5 from Martin Sebor --- I can't reproduce the warning with the default options. There are just two calls to free() in the dump. In each instance its argument resolves to the yymsg pointer and not to the yyssa array as in the warning message in comment #0. We would also need to see the command line options you use to compile the file (please review https://gcc.gnu.org/bugs/#need for the full details we ask for). In GCC 11, -Wfree-nonheap-object was enhanced to validate every argument to every deallocation function. Prior to GCC 11 it only considered a negligible subset of arguments (basically just straight addresses of variables). The warning was prone to false positives then (as is evident from pr54202), and the enhancement hasn't changed that. Different optimization options produce different intermediate representation. Some result in constants substituted for what would otherwise be variables. When a constant is substituted into an expression that it's not valid for it might trigger a warning because in the IL it's indistinguishable from a bug in the original source code. There's nothing a warning designed to detect such invalid expressions can do about it. Changing this message alone to say "free() may be called with non-heap object" wouldn't be appropriate without also changing all the other messages that are subject to the same problem (all flow-sensitive warnings are). At least two solutions are theoretically possible: a) make the warning "smarter" than the optimization it depends on that does the substitution, and have it figure out that the invalid code was synthesized by it, doesn't occur in the source code, and cannot be reached in the program given the preconditions, or b) make the optimizations "smarter" either by not substituting constants into contexts where they're invalid, or by figuring out that these invalid expressions cannot be reached based on their preconditions. The two sets of preconditions need not be the same. Both approaches are worth exploring but both are hard and neither will ever be perfect. Which is partly why GCC documents that "Warnings are diagnostic messages that report constructions that are not inherently erroneous but that are risky or suggest there may have been an error." If the warning gets it wrong #pragma GCC diagnostic can be used to avoid the false positive.
[Bug target/98759] arm cortex-r5 single precisions flotaing point generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98759 --- Comment #4 from Daniel Allred --- Looks like this was it, came direct from ARM. https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=48f4d8ce966e20e1e759e29ca8cf05a5dd328883
[Bug target/98759] arm cortex-r5 single precisions flotaing point generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98759 --- Comment #3 from Daniel Allred --- Thank you for the quick feedback. I can't find any bug report for binutils/gas in https://sourceware.org/bugzilla related to this, so I may try and see if I can find commits for gas between 2.35.1.20201116 and 2.35.1.20201120 that would explain the fix.
[Bug libgomp/98738] task-detach-6.f90 hangs intermittently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98738 --- Comment #8 from Jakub Jelinek --- I think omp_fullfill_event needs to do much more than it does. Just look e.g. at what gomp_target_task_completion does. The function needs to find out in what state the task is (I'm afraid it needs to take the team->task_lock around that checking (if any)), if the task hasn't finished yet, it shouldn't need anything but sem_post but if it has already finished and it is just waiting for the completion event, it needs to handle taskwait, depend wait, taskgroup waits and barrier waits. Sorry for not catching that during patch review.
[Bug libgomp/98738] task-detach-6.f90 hangs intermittently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98738 --- Comment #7 from Jakub Jelinek --- Seems making task_fulfilled_p return always false makes the task-detach-6.c hangs 100% reproduceable.
[Bug tree-optimization/98772] Widening patterns causing missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98772 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Blocks||53947 Target||arm Version|unknown |11.0 --- Comment #1 from Richard Biener --- Looks like arm assembly so assuming arm target. The pattern recognizer is supposed to a) fixate the vector type, b) verify the target supports the op. You need to trace where there's a disconnect between vectorizable_conversion checking and pattern match checking. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/96674] Failure to optimize combination of comparisons to dec+compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674
--- Comment #10 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:49e8c14ef6f1f968602a04c8499a672182590e87
commit r11-6817-g49e8c14ef6f1f968602a04c8499a672182590e87
Author: Eugene Rozenfeld
Date: Wed Dec 9 16:44:25 2020 -0800
Optimize combination of comparisons to dec+compare
This patch adds patterns for optimizing
x < y || y == XXX_MIN to x <= y-1
x >= y && y != XXX_MIN to x > y-1
if y is an integer with TYPE_OVERFLOW_WRAPS.
This fixes pr96674.
Tested on x86_64-pc-linux-gnu.
For this function
bool f(unsigned a, unsigned b)
{
return (b == 0) | (a < b);
}
the code without the patch is
test esi,esi
sete al
cmpesi,edi
seta dl
or eax,edx
ret
the code with the patch is
subesi,0x1
cmpesi,edi
setae al
ret
PR tree-optimization/96674
gcc/
* match.pd: New patterns: x < y || y == XXX_MIN --> x <= y - 1
x >= y && y != XXX_MIN --> x > y - 1
gcc/testsuite
* gcc.dg/pr96674.c: New tests.
[Bug tree-optimization/98772] New: Widening patterns causing missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98772
Bug ID: 98772
Summary: Widening patterns causing missed vectorization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: joelh at gcc dot gnu.org
Target Milestone: ---
Disabling widening patterns (widening_mult, widening_plus, widening_minus)
allows some testcases to be vectorized better. Currently mixed scalar and
vector code is produced, due to the patterns being recognized and substituted
but vectorization failing 'no optab'. When they are recognized 16bytes -> 16
shorts, using a pair 8byte->8short instructions is presumed, the datatypes
chosen in 'vectorizable_conversion' are 'vectype_in' 8 bytes, 'vectype out' 8
shorts. This causes the scalar code to be emitted where these patterns were
recognized.
For the following testcases with: gcc -O3
#include
extern void wdiff( int16_t d[16], uint8_t *restrict pix1, uint8_t *restrict
pix2)
{
for( int y = 0; y < 4; y++ )
{
for( int x = 0; x < 4; x++ )
d[x + y*4] = pix1[x] * pix2[x];
pix1 += 16;
pix2 += 16;
}
The following output is seen, processing 8 elements per cycle using scalar
instructions and 8 elements per cycle using vector instructions.
wdiff:
.LFB0:
.cfi_startproc
ldrbw3, [x1, 32]
ldrbw6, [x2, 32]
ldrbw8, [x1, 33]
ldrbw5, [x2, 33]
ldrbw4, [x1, 34]
mul w3, w3, w6
ldrbw7, [x1, 35]
fmovs0, w3
ldrbw3, [x2, 34]
mul w8, w8, w5
ldrbw9, [x2, 35]
ldrbw6, [x2, 48]
ldrbw5, [x1, 49]
ins v0.h[1], w8
mul w3, w4, w3
mul w7, w7, w9
ldrbw4, [x1, 48]
ldrbw8, [x2, 49]
ldrbw9, [x2, 50]
ins v0.h[2], w3
ldrbw3, [x1, 51]
mul w6, w6, w4
ldrbw4, [x1, 50]
mul w5, w5, w8
ldrbw8, [x2, 51]
ldr d2, [x1]
ins v0.h[3], w7
ldr d1, [x2]
mul w4, w4, w9
ldr d4, [x1, 16]
ldr d3, [x2, 16]
mul w1, w3, w8
ins v0.h[4], w6
zip1v2.2s, v2.2s, v4.2s
zip1v1.2s, v1.2s, v3.2s
ins v0.h[5], w5
umull v1.8h, v1.8b, v2.8b
ins v0.h[6], w4
ins v0.h[7], w1
stp q1, q0, [x0]
ret
if the widening multiply instruction is disabled e.g.:
- { vect_recog_widen_mult_pattern, "widen_mult" },
+ //{ vect_recog_widen_mult_pattern, "widen_mult" },
in tree-vect-patterns.c
then the same testcase is able to process 16 elements per cycle using vector
instructions.
wdiff:
.LFB0:
.cfi_startproc
ldr b3, [x1, 33]
ldr b2, [x2, 33]
ldr b1, [x1, 32]
ldr b0, [x2, 32]
ldr b5, [x1, 34]
ins v1.b[1], v3.b[0]
ldr b4, [x2, 34]
ins v0.b[1], v2.b[0]
ldr b3, [x1, 35]
ldr b2, [x2, 35]
ldr b19, [x1, 48]
ins v1.b[2], v5.b[0]
ldr b17, [x2, 48]
ins v0.b[2], v4.b[0]
ldr b18, [x1, 49]
ldr b16, [x2, 49]
ldr b7, [x1, 50]
ins v1.b[3], v3.b[0]
ldr b6, [x2, 50]
ins v0.b[3], v2.b[0]
ldr b5, [x1, 51]
ldr b4, [x2, 51]
ldr d3, [x1]
ins v1.b[4], v19.b[0]
ldr d2, [x2]
ins v0.b[4], v17.b[0]
ldr d19, [x1, 16]
ldr d17, [x2, 16]
ins v1.b[5], v18.b[0]
zip1v3.2s, v3.2s, v19.2s
ins v0.b[5], v16.b[0]
zip1v2.2s, v2.2s, v17.2s
ins v1.b[6], v7.b[0]
umull v2.8h, v2.8b, v3.8b
ins v0.b[6], v6.b[0]
ins v1.b[7], v5.b[0]
ins v0.b[7], v4.b[0]
umull v0.8h, v0.8b, v1.8b
stp q2, q0, [x0]
ret
.cfi_endproc
note the use of 2 umull instructions.
The same can be seen for widening plus and widening minus.
It appears to be due to the way than the vectype_in is chosen in vectorizable
conversion,
in vectorizable conversion, tree-vect-stmts.c:4626
vect_is_simple_use fills the _in parameter, which fills the vectype_in
parameter.
during slp vectorization vect_is_simple_use uses the slp tree vectype:
tree-vect-stmts.c:
11369 if (slp_node)
11370 {
11371 slp_tree child = SLP_TREE_CHILDREN (slp_node)[operand]; |
11372 *slp_def = child;
11373 *vectype = SLP_TREE_VECTYPE (child);
11374 if (SLP_TREE_DEF_TYPE (child) == vect_internal_def)
11375 { | |11376 *op = gimple_get_lhs (SLP_TREE_REPRESENTATIVE (child)->stmt);
| |11377 return vect_is_simple_use (*op, vinfo, dt, def_stmt_info_out); |
|11378 }
for 'vect'
[Bug c++/90448] [8/9/10/11 Regression] decltype-based lambda parameter pack is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448 Rainer Orth changed: What|Removed |Added CC||jozefl at gcc dot gnu.org --- Comment #9 from Rainer Orth --- *** Bug 96458 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/96458] [10/11 Regression] internal compiler error: in expand_expr_addr_expr_1, at expr.c:8075 for msp430-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96458 Rainer Orth changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||ro at gcc dot gnu.org --- Comment #1 from Rainer Orth --- Already known/reported. *** This bug has been marked as a duplicate of bug 90448 ***
[Bug middle-end/95848] missing -Wuninitialized passing structs by value (VOPS)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95848 --- Comment #3 from Manuel López-Ibáñez --- Martin, it is not clear from the dumps what is the difference between the two cases. Also, this warning triggers even with -O0, so it must come pretty earlier even before we have VOPS. What is the difference at the level of GIMPLE?
[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98771 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.3
[Bug c++/59002] [meta-bug] Access checking in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 Bug 59002 depends on bug 82613, which changed state. Bug 82613 Summary: Cannot access private definitions in base clause of friend class template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82613 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/82613] Cannot access private definitions in base clause of friend class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82613 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 --- Comment #4 from Patrick Palka --- Fixed for GCC 11.
[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98771 --- Comment #1 from Rainer Orth --- Created attachment 50013 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50013=edit 64-bit sparc-sun-solaris2.11 strcmpopt_8.c.033t.forwprop1
[Bug c++/95434] ICE for CTAD in generic lambda within variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95434
--- Comment #5 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:cafcfcb5840b62d9fc80c12192189351e995a4f2
commit r11-6816-gcafcfcb5840b62d9fc80c12192189351e995a4f2
Author: Patrick Palka
Date: Wed Jan 20 09:44:33 2021 -0500
c++: Fix tsubsting CLASS_PLACEHOLDER_TEMPLATE [PR95434]
Here, during partial instantiation of the generic lambda, we do
tsubst_copy on the CLASS_PLACEHOLDER_TEMPLATE for U{0} which yields a
(level-lowered) TEMPLATE_TEMPLATE_PARM rather than the corresponding
TEMPLATE_DECL. This later confuses do_class_deduction which expects
that a CLASS_PLACEHOLDER_TEMPLATE is always a TEMPLATE_DECL.
gcc/cp/ChangeLog:
PR c++/95434
* pt.c (tsubst) : If tsubsting
CLASS_PLACEHOLDER_TEMPLATE yields a TEMPLATE_TEMPLATE_PARM,
adjust to its TEMPLATE_TEMPLATE_PARM_TEMPLATE_DECL.
gcc/testsuite/ChangeLog:
PR c++/95434
* g++.dg/cpp2a/lambda-generic9.C: New test.
[Bug c++/82613] Cannot access private definitions in base clause of friend class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82613 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:79e1251b642db038df276153c9f2ec6b82e56162 commit r11-6815-g79e1251b642db038df276153c9f2ec6b82e56162 Author: Patrick Palka Date: Wed Jan 20 09:43:48 2021 -0500 c++: Defer access checking when processing bases [PR82613] When parsing the base-clause of a class declaration, we need to defer access checking until the entire base-clause has been seen, so that access can be properly checked relative to the scope of the class with all its bases attached. This allows us to accept the declaration of struct D from Example 2 of [class.access.general] (access12.C below). Similarly when substituting into the base-clause of a class template, which is the subject of PR82613. gcc/cp/ChangeLog: PR c++/82613 * parser.c (cp_parser_class_head): Defer access checking when parsing the base-clause until all bases are seen and attached to the class type. * pt.c (instantiate_class_template): Likewise when substituting into dependent bases. gcc/testsuite/ChangeLog: PR c++/82613 * g++.dg/parse/access12.C: New test. * g++.dg/template/access35.C: New test.
[Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98771 Bug ID: 98771 Summary: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 Created attachment 50012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50012=edit i386-pc-solaris2.11 64-bit strcmpopt_8.c.033t.forwprop1 As originally reported in PR tree-optimization/92683, the gcc.dg/strcmpopt_8.c test still FAILs on both Solaris/x86 and SPARC: * on x86 with -m64 only: FAIL: gcc.dg/strcmpopt_8.c scan-tree-dump-not forwprop1 "strncmp" * on sparc with -m64 only: FAIL: gcc.dg/strcmpopt_8.c (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] FAIL: gcc.dg/strcmpopt_8.c scan-tree-dump-not forwprop1 "strncmp" This only happens with 32-bit-default compilers, the corresponding 64-bit-default compilers don't show the failure. I'm attaching both the amd64 and sparcv9 dumps (which are effectively identical).
[Bug c++/59002] [meta-bug] Access checking in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 Bug 59002 depends on bug 58993, which changed state. Bug 58993 Summary: incorrectly accept access of protected member method from derived class template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58993 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/58993] incorrectly accept access of protected member method from derived class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58993 Patrick Palka changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Patrick Palka --- Fixed for GCC 11.
[Bug tree-optimization/98766] [10/11 Regression] SVE: ICE in tree_to_shwi with -O3 --param=avoid-fma-max-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98766 --- Comment #2 from Richard Biener --- bool check_defer = (state->m_deferring_p && (tree_to_shwi (TYPE_SIZE (type)) <= param_avoid_fma_max_bits)); known_le (tree_to_poly_uint64 (TYPE_SIZE (type)), ...) or so.
[Bug c++/98767] Function signature lost in concept diagnostic message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98767 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-20 Ever confirmed|0 |1
[Bug fortran/98769] ICE for gfortran.dg/associate_26.f90 with -fcoarray=lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98769 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-20 CC||marxin at gcc dot gnu.org, ||vehre at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r6-1698-g76540ac3e39cd58b.
[Bug c++/98770] New: [modules] including certain stdlib headers in the global module fragment of different modules causes conflicting global module declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98770
Bug ID: 98770
Summary: [modules] including certain stdlib headers in the
global module fragment of different modules causes
conflicting global module declarations
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pilarlatiesa at gmail dot com
Target Milestone: ---
$ /home/pililatiesa/GCC-11/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/pililatiesa/GCC-11/bin/g++
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-master/configure --prefix=($HOME)/GCC-11
--enable-languages=c++ --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210115 (experimental) (GCC)
$ cat Tensor.ixx
module;
#include
#include
export module VF.Tensor;
namespace VF
{
export
template
struct TTensor
{
private:
std::istream
inline (std::istream )
{ return is; }
};
export
template
using TVector = TTensor;
} // VF
$ cat Mesh.ixx
module;
#include
#include
export module VF.Mesh;
import VF.Tensor;
namespace VF
{
template
class TPoint final : public TVector {};
}
$ /home/pililatiesa/GCC-11/bin/g++ -fmodules-ts -x c++ -std=c++20 -I../ -I./
Tensor.ixx Mesh.ixx -o foo
In file included from
/home/pililatiesa/GCC-11/include/c++/11.0.0/bits/move.h:57,
from
/home/pililatiesa/GCC-11/include/c++/11.0.0/bits/nested_exception.h:40,
from
/home/pililatiesa/GCC-11/include/c++/11.0.0/exception:148,
from /home/pililatiesa/GCC-11/include/c++/11.0.0/ios:39,
from /home/pililatiesa/GCC-11/include/c++/11.0.0/ostream:38,
from /home/pililatiesa/GCC-11/include/c++/11.0.0/iostream:39,
from Tensor.ixx:5,
of module VF.Tensor, imported at Mesh.ixx:9:
/home/pililatiesa/GCC-11/include/c++/11.0.0/type_traits:634:31: error:
conflicting global module declaration ‘template using __void_t =
void’
634 | template using __void_t = void;
| ^~~~
In file included from Mesh.ixx:5:
/home/pililatiesa/GCC-11/include/c++/11.0.0/type_traits:634:31: note: existing
declaration ‘template using __void_t = void’
634 | template using __void_t = void;
| ^~~~
Mesh.ixx:14:29: note: during load of binding ‘VF::TVector@VF.Tensor’
14 | class TPoint final : public TVector {};
| ^~~
Mesh.ixx:7:8: warning: not writing module ‘VF.Mesh’ due to errors
7 | export module VF.Mesh;
|
[Bug c++/98768] Improve diagnostics for incorrect result type checking "-> Type" in concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98768
--- Comment #2 from Jonathan Wakely ---
Oops! I meant:
{ func() } -> std::same_as;
[Bug c++/98768] Improve diagnostics for incorrect result type checking "-> Type" in concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98768
--- Comment #1 from Jonathan Wakely ---
(In reply to Antony Polukhin from comment #0)
> For such cases a warning like "Unused `T` in concept definition. Did you
> mean `-> std::same_as`" would be really helpful.
That wouldn't fix it though, the correct form would be:
{ func() } -> T;
[Bug fortran/98565] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98565 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-01-20 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Dominique d'Humieres --- Confirmed from GCC7 up to GCC11, no option needed. This correspond to gcc_assert (TREE_CODE (TREE_TYPE (tmp)) == POINTER_TYPE && TREE_CODE (TREE_TYPE (TREE_TYPE (tmp))) == FUNCTION_TYPE);
[Bug fortran/98769] New: ICE for gfortran.dg/associate_26.f90 with -fcoarray=lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98769 Bug ID: 98769 Summary: ICE for gfortran.dg/associate_26.f90 with -fcoarray=lib Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Target Milestone: --- Compiling the test gfortran.dg/associate_26.f90 with -fcoarray=lib gives an ICE 13 | associate (i => a(1:p, 1:p)) |1 internal compiler error: in generate_coarray_sym_init, at fortran/trans-decl.c:5634 corresponding to gcc_assert (GFC_ARRAY_TYPE_P (TREE_TYPE (decl))); I see the ICE from GCC7 up to GC11, but not on the coarray-shared branch.
[Bug c++/98768] New: Improve diagnostics for incorrect result type checking "-> Type" in concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98768
Bug ID: 98768
Summary: Improve diagnostics for incorrect result type checking
"-> Type" in concepts
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example:
template
concept Callable0Arg = requires(Function func) {
func() -> T;
};
The expression "-> T" is valid only if the "func()" returns pointer to a type
that has member "T". At the same time there is an unused "typename T" in the
concept definition.
For such cases a warning like "Unused `T` in concept definition. Did you mean
`-> std::same_as`" would be really helpful.
[Bug c++/98767] New: Function signature lost in concept diagnostic message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98767
Bug ID: 98767
Summary: Function signature lost in concept diagnostic message
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example:
template
concept Callable1Arg = requires(Function func, T value) {
func(value);
};
// Should fail and fails:
static_assert(Callable1Arg);
The diagnotics has the following line:
"in requirements with 'Function func', 'T value' [with T = bool; Function = int
(*)()]"
However the type of the Function is "int (*)(int*)" not "int (*)()"
Godbolt playground: https://godbolt.org/z/afKqq5
[Bug tree-optimization/98535] [11 Regression] ICE in operands_scanner::get_expr_operands(tree_node**, int) building 538.imagick_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98535 --- Comment #11 from rsandifo at gcc dot gnu.org --- Fixed on trunk, but it's latent on release branches and should be fixed there too.
[Bug debug/98765] [11 Regression] stripping of LTO debug sections doesn't work anymore since switch to -gdwarf-5 by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98765
--- Comment #3 from Jakub Jelinek ---
--- gcc/dwarf2out.c.jj 2021-01-20 08:32:09.612958930 +0100
+++ gcc/dwarf2out.c 2021-01-20 14:15:14.735459774 +0100
@@ -4733,12 +4733,20 @@ int
reset_indirect_string (indirect_string_node **h, void *)
{
struct indirect_string_node *node = *h;
- if (node->form == DW_FORM_strp || node->form == dwarf_FORM (DW_FORM_strx))
+ if (node->form == DW_FORM_strp
+ || node->form == DW_FORM_line_strp
+ || node->form == dwarf_FORM (DW_FORM_strx))
{
+ bool line_strp = node->form == DW_FORM_line_strp;
free (node->label);
node->label = NULL;
node->form = (dwarf_form) 0;
node->index = 0;
+ if (line_strp)
+ {
+ set_indirect_string (node);
+ node->form = DW_FORM_line_strp;
+ }
}
return 1;
}
@@ -31395,10 +31403,7 @@ dwarf2out_finish (const char *filename)
/* Remove indirect string decisions. */
debug_str_hash->traverse (NULL);
if (debug_line_str_hash)
- {
- debug_line_str_hash->traverse (NULL);
- debug_line_str_hash = NULL;
- }
+ debug_line_str_hash->traverse (NULL);
}
#if ENABLE_ASSERT_CHECKING
emits them in .debug_line_str, but emits also strings that aren't really
needed.
[Bug tree-optimization/98535] [11 Regression] ICE in operands_scanner::get_expr_operands(tree_node**, int) building 538.imagick_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98535
--- Comment #10 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:ea74a3f548eb321429c371e327e778e63d9128a0
commit r11-6814-gea74a3f548eb321429c371e327e778e63d9128a0
Author: Richard Sandiford
Date: Wed Jan 20 13:16:30 2021 +
vect: Fix VLA SLP invariant optimisation [PR98535]
duplicate_and_interleave is the main fallback way of loading
a repeating sequence of elements into variable-length vectors.
The code handles cases in which the number of elements in the
sequence is potentially several times greater than the number
of elements in a vector.
Let:
- NE be the (compile-time) number of elements in the sequence
- NR be the (compile-time) number of vector results and
- VE be the (run-time) number of elements in each vector
The basic approach is to duplicate each element into a
separate vector, giving NE vectors in total, then use
log2(NE) rows of NE permutes to generate NE results.
In the worst case â when VE has no known compile-time factor
and NR >= NE â all of these permutes are necessary. However,
if VE is known to be a multiple of 2**F, then each of the
first F permute rows produces duplicate results; specifically,
the high permute for a given pair is the same as the low permute.
The code dealt with this by reusing the low result for the
high result. This part was OK.
However, having duplicate results from one row meant that the
next row did duplicate work. The redundancies would be optimised
away by later passes, but the code tried to avoid generating them
in the first place. This is the part that went wrong.
Specifically, NR is typically less than NE when some permutes are
redundant, so the code tried to use NR to reduce the amount of work
performed. The problem was that, although it correctly calculated
a conservative bound on how many results were needed in each row,
it chose the wrong results for anything other than the final row.
This doesn't usually matter for fully-packed SVE vectors. We first
try to coalesce smaller elements into larger ones, so normally
VE ends up being 2**VQ (where VQ is the number of 128-bit blocks
in an SVE vector). In that situation we'd only apply the faulty
optimisation to the final row, i.e. the case it handled correctly.
E.g. for things like:
void
f (long *x)
{
for (int i = 0; i < 100; i += 8)
{
x[i] += 1;
x[i + 1] += 2;
x[i + 2] += 3;
x[i + 3] += 4;
x[i + 4] += 5;
x[i + 5] += 6;
x[i + 6] += 7;
x[i + 7] += 8;
}
}
(already tested by the testsuite), we'd have 3 rows of permutes
producing 4 vector results. The schemne produced:
1st row: 8 results from 4 permutes, highs duplicates of lows
2nd row: 8 results from 8 permutes (half of which are actually redundant)
3rd row: 4 results from 4 permutes
However, coalescing elements is trickier for unpacked vectors,
and at the moment we don't try to do it (see the GET_MODE_SIZE
check in can_duplicate_and_interleave_p). Unpacked vectors
therefore stress the code in ways that packed vectors didn't.
The patch fixes this by removing the redundancies from each row,
rather than trying to work around them later. This also removes
the redundant work in the second row of the example above.
gcc/
PR tree-optimization/98535
* tree-vect-slp.c (duplicate_and_interleave): Use
quick_grow_cleared.
If the high and low permutes are the same, remove the high permutes
from the working set and only continue with the low ones.
[Bug debug/98765] [11 Regression] stripping of LTO debug sections doesn't work anymore since switch to -gdwarf-5 by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98765
--- Comment #2 from Jakub Jelinek ---
--- gcc/dwarf2out.c.jj 2021-01-20 08:32:09.612958930 +0100
+++ gcc/dwarf2out.c 2021-01-20 13:49:42.367772872 +0100
@@ -4733,7 +4733,9 @@ int
reset_indirect_string (indirect_string_node **h, void *)
{
struct indirect_string_node *node = *h;
- if (node->form == DW_FORM_strp || node->form == dwarf_FORM (DW_FORM_strx))
+ if (node->form == DW_FORM_strp
+ || node->form == DW_FORM_line_strp
+ || node->form == dwarf_FORM (DW_FORM_strx))
{
free (node->label);
node->label = NULL;
fixes it but the string is then emitted into .debug_str rather than
.debug_line_str in the non-.gnu.debuglto_* case.
[Bug target/98729] [11 Regression] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 --- Comment #9 from Brecht Sanders --- The attached .exe will run on Windows after removing the section called `/20` from the PE file using: `strip conftest.exe --remove-section="/20"` I don't know what this section does, but I did notice it contains a reference to `cygwin.S`, which I didn't expect to see in a pure MinGW binary.
[Bug debug/98765] [11 Regression] stripping of LTO debug sections doesn't work anymore since switch to -gdwarf-5 by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98765 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/98766] [10/11 Regression] SVE: ICE in tree_to_shwi with -O3 --param=avoid-fma-max-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98766 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to fail||10.2.1 Summary|SVE: ICE in tree_to_shwi|[10/11 Regression] SVE: ICE |with -O3|in tree_to_shwi with -O3 |--param=avoid-fma-max-bits |--param=avoid-fma-max-bits Last reconfirmed||2021-01-20 Priority|P3 |P2 Known to work||9.3.1 Target Milestone|--- |10.3 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/98766] New: SVE: ICE in tree_to_shwi with -O3 --param=avoid-fma-max-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98766
Bug ID: 98766
Summary: SVE: ICE in tree_to_shwi with -O3
--param=avoid-fma-max-bits
Product: gcc
Version: 11.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: ---
The following fails:
$ cat test.c
extern int a[];
void c(short *d) {
for (int e = 0; e < 9; e++)
a[e] = d[e] * 2;
}
$ aarch64-elf-gcc -c test.c -march=armv8.2-a+sve -O3
--param=avoid-fma-max-bits=8
during GIMPLE pass: widening_mul
test.c: In function 'c':
test.c:2:6: internal compiler error: in tree_to_shwi, at tree.c:7448
2 | void c(short *d) {
| ^
0x11684f0 tree_to_shwi(tree_node const*)
/home/alecop01/toolchain/src/gcc/gcc/tree.c:7448
0xfd97c1 convert_mult_to_fma
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-math-opts.c:3255
0xfda040 after_dom_children
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-math-opts.c:4619
0x19d3d80 dom_walker::walk(basic_block_def*)
/home/alecop01/toolchain/src/gcc/gcc/domwalk.c:352
0xfd3731 execute
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-math-opts.c:4718
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug debug/98765] [11 Regression] stripping of LTO debug sections doesn't work anymore since switch to -gdwarf-5 by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98765 --- Comment #1 from Jakub Jelinek --- Seems to be a gcc bug to me: .section.gnu.debuglto_.debug_info,"e",@progbits ... .long .LASF0 # DW_AT_name: "a.c" .long .LASF1 # DW_AT_comp_dir: "/var/tmp" .long .Ldebug_line0 # DW_AT_stmt_list ... .section.gnu.debuglto_.debug_line,"e",@progbits .Ldebug_line0: ... .uleb128 0x3# File names count .long .LASF0 # File Entry: 0: "a.c" .byte 0 .long .LASF0 # File Entry: 0: "a.c" .byte 0 ... .section.gnu.debuglto_.debug_line_str,"eMS",@progbits,1 .LASF0: .string "a.c" ... .section.debug_info,"",@progbits .Ldebug_info1: .long .LASF0 # DW_AT_name: "a.c" .long .LASF1 # DW_AT_comp_dir: "/var/tmp" .quad .Ltext0 # DW_AT_low_pc .quad .Letext0-.Ltext0# DW_AT_high_pc .long .Ldebug_line1 # DW_AT_stmt_list The references in .debug_info to .LASF0/.LASF1 labels from .gnu.debuglto_.debug_line_str is what is incorrect.
[Bug target/98759] arm cortex-r5 single precisions flotaing point generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98759 Richard Earnshaw changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Richard Earnshaw --- Not a bug in GCC (and was fixed in GAS), so closing.
[Bug debug/98765] [11 Regression] stripping of LTO debug sections doesn't work anymore since switch to -gdwarf-5 by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98765 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-20 Target Milestone|--- |11.0 Priority|P3 |P1
[Bug debug/98765] New: [11 Regression] stripping of LTO debug sections doesn't work anymore since switch to -gdwarf-5 by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98765
Bug ID: 98765
Summary: [11 Regression] stripping of LTO debug sections
doesn't work anymore since switch to -gdwarf-5 by
default
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Testcase a.i:
# 0 "a.c"
# 1 "/var/tmp//"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "a.c"
# 1 "a.h" 1
int
foo (void)
{
return 0;
}
# 2 "a.c" 2
int
bar (void)
{
return 0;
}
With gcc configured against latest binutils:
gcc -S -g -flto -ffat-lto-objects a.i
gcc -c a.s -o a.o
strip -p -R .gnu.lto_* -R .gnu.debuglto_* -N __gnu_lto_v1 a.o
strip: st3FEz69: symbol `.gnu.debuglto_.debug_line_str' required but not
present
strip: st3FEz69: no symbols
[Bug target/98759] arm cortex-r5 single precisions flotaing point generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98759 Przemyslaw Wirkus changed: What|Removed |Added CC||wirkus at gcc dot gnu.org --- Comment #1 from Przemyslaw Wirkus --- Hi Daniel, I can confirm that this issue exists for Arm's toolchain releases (available from developer.arm.com): * gcc-arm-none-eabi-10-2020-q4-major and * gcc-arm-none-eabi-9-2020-q2-update. Quick bisect tells me that this issue was fixed in Binutils' GAS somewhere between 2.35.1.20201116 and 2.35.1.20201120. gcc-arm-none-eabi-10-2020-q4-major was released with Binutils 2.35.1.20201028: $ ./gcc-arm-none-eabi-10-2020-q4-major/bin/arm-none-eabi-as --version GNU assembler (GNU Arm Embedded Toolchain 10-2020-q4-major) 2.35.1.20201028
[Bug fortran/98764] ICE for the test gfortran.dg/coarray_alloc_comp_3.f08 with -fcoarray=single since r7-5021-gba85c8c3fcb19c77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98764 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-01-20 Summary|ICE for the test|ICE for the test |gfortran.dg/coarray_alloc_c |gfortran.dg/coarray_alloc_c |omp_3.f08 with |omp_3.f08 with |-fcoarray=single|-fcoarray=single since ||r7-5021-gba85c8c3fcb19c77 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||vehre at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r7-5021-gba85c8c3fcb19c77.
[Bug fortran/98764] New: ICE for the test gfortran.dg/coarray_alloc_comp_3.f08 with -fcoarray=single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98764 Bug ID: 98764 Summary: ICE for the test gfortran.dg/coarray_alloc_comp_3.f08 with -fcoarray=single Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Target Milestone: --- Compiling the test gfortran.dg/coarray_alloc_comp_3.f08 with -fcoarray=single gives an ICE: 43 | deallocate(obj%link) | 1 internal compiler error: in gfc_get_descriptor_field, at fortran/trans-array.c:140 corresponding to gcc_assert (GFC_DESCRIPTOR_TYPE_P (type));
[Bug testsuite/98574] Make gcc-jenkins an OSS Project
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98574 Eric Gallager changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-01-20 Status|UNCONFIRMED |NEW CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Seems like a good idea; I'm going to confirm this.
[Bug testsuite/97299] [11 regression] gcc.dg/vect/slp-reduc-3.c fails after r11-3563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97299 Rainer Orth changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org --- Comment #6 from Rainer Orth --- This patch has caused +XPASS: gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects scan-tree-dump-times vect "VEC_PERM_EXPR" 0 +XPASS: gcc.dg/vect/slp-reduc-3.c scan-tree-dump-times vect "VEC_PERM_EXPR" 0 on sparc-sun-solaris2.11 (32 and 64-bit) and, according to gcc-testresults, on armeb-none-linux-gnueabihf, aarch64-suse-linux-gnu
[Bug fortran/98763] gfortran.dg/gomp/task-detach-1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98763 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED CC||burnus at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Tobias Burnus --- FIXED. Thanks for the report – and pointing at the issue.
[Bug other/84904] Implement an option to attempt to auto-apply fix-it hints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84904 --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > (In reply to David Malcolm from comment #0) > > In my original edit_context patch kit I posted a > > "-fdiagnostics-apply-fixits" option that would auto-apply fix-it hints: > > https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01682.html > > ...but there was no error-checking. > > > > This is something of a brainstorm: > > > > A really smart implementation of this would directly modify the token > > stream, and fix the AST as we go. > > > > Sadly I don't think that doing that would be feasible, for C, at least, so > > any implementation is probably going to have to write a file to disk. > > (maybe it's doable for C++, given that that has all the tokens in-memory > > up-front? but what about the preprocessor?) > > > > Error-handling needs to be perfect: we must *never* lose or corrupt the > > user's source code. > > > > Would probably need to be something like: > > * write the proposed new code to disk > > * verify that it works > > * make a backup copy of the old code > > * copy the new code into place (various failures here need to be dealt with) > > * tell the user where the backup is > > * maybe keep the last, say, 10 copies around, with rolling backup (param to > > control it) > > As far as backups go, the standard way for GNU programs to do backups is > Emacs backups; see autoupdate and autoheader in autoconf, gnulib-tool in > gnulib, gettextize in gettext, and probably a few others I'm forgetting. See > also gnulib modules backupfile and backup-rename: > https://www.gnu.org/software/gnulib/MODULES.html#module=backupfile > https://www.gnu.org/software/gnulib/MODULES.html#module=backup-rename Update: apparently autoconf/automake check the environment variable $SIMPLE_BACKUP_SUFFIX: https://lists.gnu.org/archive/html/autoconf/2021-01/msg5.html > > > > > Further complications: > > * fix-it hints could affect multiple files, not just the primary source file > > * we might not have write access to some of the files (e.g. headers). > > (Reminiscent of fixincludes?) > > > > There could be interaction with the driver: apply the fixes, reinvoke the > > compiler, etc. Maybe keep going until we can't fix. If so, could need some > > diagnostic-suppression to avoid spamming the user with the same diagnostic > > over and over again. Question: if we successfully get the user's code to > > compile, but there were errors along the way, do we still generate a .o > > file? > > > > Maybe "-fixit" is a better name? > > Sounds like "-fast", which got renamed to "-Ofast" (to make what I was saying here a bit more explicit, what I meant was that making intentional puns out of option names seems to be on its way out. Instead of just "-fixit" I'd say at least extend it to "-ffixit" so the negative becomes "-fno-fixit" rather than just "-fno-ixit", but really I think the original longer name of "-fdiagnostics-apply-fixits" is still the best.)
[Bug fortran/98763] gfortran.dg/gomp/task-detach-1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98763 --- Comment #1 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:a95538b6c5a9ea480e341da9ca8fbf201417dba5 commit r11-6813-ga95538b6c5a9ea480e341da9ca8fbf201417dba5 Author: Tobias Burnus Date: Wed Jan 20 11:27:26 2021 +0100 Fix gfortran.dg/gomp/task-detach-1.f90 for non 64bit pointers gcc/testsuite/ChangeLog: PR fortran/98763 * gfortran.dg/gomp/task-detach-1.f90: Use integer(1) to avoid missing diagnostic issues with c_intptr_t == default integer kind.
[Bug fortran/98763] gfortran.dg/gomp/task-detach-1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98763 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug fortran/98763] New: gfortran.dg/gomp/task-detach-1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98763 Bug ID: 98763 Summary: gfortran.dg/gomp/task-detach-1.f90 FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: kcy at codesourcery dot com Target Milestone: --- The new gfortran.dg/gomp/task-detach-1.f90 test FAILs on large number of targets: +FAIL: gfortran.dg/gomp/task-detach-1.f90 -O (test for errors, line 21) +FAIL: gfortran.dg/gomp/task-detach-1.f90 -O (test for errors, line 22) I'm seeing this on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32-bit only), but there are reports on gcc-testresults for x86_64-pc-linux-gnu, s390x-ibm-linux-gnu, powerpc-ibm-aix7.2.3.0, hppa-unknown-linux-gnu, i586-unknown-freebsd11.4, m68k-unknown-linux-gnu, aarch64-suse-linux-gnu, i686-pc-linux-gnu, probably all for the 32-bit multilib.
[Bug debug/98755] [11 regression] r11-6755 causes failure in g++.dg/debug/dwarf2/constexpr-var-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98755 Mark Wielaard changed: What|Removed |Added Build|powerpc64*-linux-gnu| Target|powerpc64*-linux-gnu| Host|powerpc64*-linux-gnu| CC||jakub at redhat dot com, ||jason at redhat dot com, ||law at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- This isn't ppc64 specific and was also reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728 > This is https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552474.html > There is a suggested fix, but no consensus on whether that is a good one: > https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553102.html
[Bug debug/98728] [11 regression] Several debug tests FAIL with DWARF-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Mark Wielaard --- Since the second issue was fixed lets close this and track the other issue in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98755
[Bug tree-optimization/98335] [9/10/11 Regression] Poor code generation for partial struct initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98335
Jakub Jelinek changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
I agree it would be weird to try to undo the
- D.2365 = {};
+ MEM [(struct Data *) + 1B] = {};
transformation by DSE in store_merging instead of adjusting the DSE
optimization to take into account costs and likely ways how the clearing will
be expanded.
On the other side, the user could have written it that way.
Regressed with r9-1663-g99e87c0eef2f6020a3ded2c785389939c07ac04e aka PR86010
fix.
[Bug target/98762] New: Wrong code for avrtiny if source is Z and destination is R30 or R31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98762
Bug ID: 98762
Summary: Wrong code for avrtiny if source is Z and destination
is R30 or R31
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: saaadhu at gcc dot gnu.org
Target Milestone: ---
avr_out_movqi_r_mr_reg_disp_tiny skips restoration of the base pointer reg pair
(using subi/sbci) if reg_overlap_mentioned_p or reg_unused_after returns true
for the pointer reg.
In the below case, (reg:HI 30) is the base reg, and (reg:QI 31) is the
destination. reg_overlap_mentioned_p (correctly) returns true, and therefore
*both* R30 and R31 are not restored to their original values, instead of just
R31. reg_unused_after also returns true for this case, as it also checks if
reg_overlap_mentioned_p for the current insn.
This causes miscompilation if the compiler later uses R30 with the assumption
that it is unmodified (which is what movqi_insn promises). In the below case
(reduced from execute/961122-1.c), the compiler only sets R31 again (with R19),
as it believes R30 is unmodified.
Note that the bug is exposed if the splitter for HImode move to two QImode move
runs - otherwise, movhi_insn ensures both R30 and R31 are loaded again.
$ cat reduced.c
long long acc;
void addhi (short a)
{
acc += (long long) a << 32;
}
$ avr-gcc -mmcu=attiny40 -Os -dP -S reduce.c -o -
; (insn 53 52 264 (set (reg:QI 31 r31)
; (mem/c:QI (plus:HI (reg:HI 30 r30)
; (const_int 3 [0x3])) [1 acc+3 S1 A8])) "reduce.c":5:7 56
{movqi_insn}
; (expr_list:REG_EQUAL (mem/c:QI (const:HI (plus:HI (symbol_ref:HI
("acc") [flags 0x2] )
; (const_int 3 [0x3]))) [1 acc+3 S1 A8])
; (nil)))
subi r30,lo8(-(3)) ; 53 [c=4 l=3] movqi_insn/3
sbci r31,hi8(-(3))
ld r31,Z
; (insn 264 53 296 (set (mem/c:QI (plus:HI (reg/f:HI 28 r28)
; (const_int 16 [0x10])) [3 %sfp+16 S1 A8])
; (reg:QI 31 r31)) "reduce.c":5:7 56 {movqi_insn}
; (expr_list:REG_DEAD (reg:QI 31 r31)
; (nil)))
subi r28,lo8(-(16)) ; 264 [c=4 l=5] movqi_insn/2
sbci r29,hi8(-(16))
st Y,r31
subi r28,lo8((16))
sbci r29,hi8((16))
; (insn 296 264 54 (set (reg:QI 31 r31 [+1 ])
; (reg:QI 19 r19 [+1 ])) "reduce.c":5:7 56 {movqi_insn}
; (nil))
mov r31,r19 ; 296 [c=4 l=1] movqi_insn/0
; (insn 54 296 266 (set (reg:QI 31 r31)
; (mem/c:QI (plus:HI (reg:HI 30 r30)
; (const_int 4 [0x4])) [1 acc+4 S1 A8])) "reduce.c":5:7 56
{movqi_insn}
; (expr_list:REG_EQUAL (mem/c:QI (const:HI (plus:HI (symbol_ref:HI
("acc") [flags 0x2] )
; (const_int 4 [0x4]))) [1 acc+4 S1 A8])
; (nil)))
subi r30,lo8(-(4)) ; 54 [c=4 l=3] movqi_insn/3
sbci r31,hi8(-(4))
ld r31,Z
; (insn 266 54 298 (set (mem/c:QI (plus:HI (reg/f:HI 28 r28)
; (const_int 17 [0x11])) [3 %sfp+17 S1 A8])
; (reg:QI 31 r31)) "reduce.c":5:7 56 {movqi_insn}
; (expr_list:REG_DEAD (reg:QI 31 r31)
; (nil)))
subi r28,lo8(-(17)) ; 266 [c=4 l=5] movqi_insn/2
sbci r29,hi8(-(17))
st Y,r31
[Bug c++/772] Statement expressions issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=772
--- Comment #17 from Jakub Jelinek ---
(In reply to Ed Smith-Rowland from comment #14)
> I wonder what the relationship of these expression statements are to lambdas.
>
> Is ({int _a = (a), _b = (b); _a > _b ? _a : _b; })
> equivalent to
> [](){int _a = (a), _b = (b); _a > _b ? _a : return _b; }}
>
> Can expression statements change enclosing scope variables? It seems like
> they could. The lambda may need to be mutable.
>
> Maybe these could route to the lambda code.
>
> Just an idle thought.
There are substantial differences.
E.g. one can do ({ return 1; }), with lambdas it means something different,
or ({ break; }) or ({ continue; }).
[Bug c++/98752] wrong "error: ‘this’ is not a constant expression" with consteval constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98752 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Due to the consteval we call cxx_constant_value with S1::S1 (&((struct S2 *) this)->x, NON_LVALUE_EXPR <0>) and ((struct S2 *) this)->x arguments. Shall we turn it into construction on a dummy object instead somewhere, or shall cxx_eval_* for arguments equal to ctx->object be more permissive in certain cases?
