[Bug target/99314] [Patch] [RISC-V] g++.dg/opt/memcpy1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314 Kito Cheng changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #6 from Kito Cheng --- I would prefer keep this open until merged into master, gcc-10 and gcc-9 branch.
[Bug debug/99457] gcc/gdb -gstabs+ is buggy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99457 --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2017-July/479552.html
[Bug debug/99457] gcc/gdb -gstabs+ is buggy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99457 --- Comment #1 from Andrew Pinski --- stabs support really should be removed.
[Bug debug/99457] New: gcc/gdb -gstabs+ is buggy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99457
Bug ID: 99457
Summary: gcc/gdb -gstabs+ is buggy.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.krell at cornell dot edu
Target Milestone: ---
gcc/gdb -gstabs+ is buggy.
Could be either, I didn't investigate.
The codegen is correct.
That's ok, I didn't really need it, I'll use regular -g.
$ cat 1.c
#include
int main()
{
char a[100] = {0};
printf("%d\n", a[0]);
}
$ gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
$ gcc -gstabs+ 1.c
# correct output
$ ./a.out
0
$ gdb --version
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
$ gdb ./a.out
(gdb) break main
(gdb) r
Breakpoint 1, main () at 1.c:3
3 {
(gdb) n
4 char a[100] = {0};
(gdb)
5 printf("%d\n", a[0]);
(gdb) p a
$1 =
"@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003",
'\000' , "\001", '\000'
(gdb) p a[0]
$2 = 64 '@'
(gdb) disas
Dump of assembler code for function main:
0x5169 <+0>: endbr64
0x516d <+4>: push %rbp
0x516e <+5>: mov%rsp,%rbp
0x5171 <+8>: sub$0x70,%rsp
0x5175 <+12>:mov%fs:0x28,%rax
0x517e <+21>:mov%rax,-0x8(%rbp)
0x5182 <+25>:xor%eax,%eax
0x5184 <+27>:movq $0x0,-0x70(%rbp)
0x518c <+35>:movq $0x0,-0x68(%rbp)
0x5194 <+43>:movq $0x0,-0x60(%rbp)
0x519c <+51>:movq $0x0,-0x58(%rbp)
0x51a4 <+59>:movq $0x0,-0x50(%rbp)
0x51ac <+67>:movq $0x0,-0x48(%rbp)
0x51b4 <+75>:movq $0x0,-0x40(%rbp)
0x51bc <+83>:movq $0x0,-0x38(%rbp)
0x51c4 <+91>:movq $0x0,-0x30(%rbp)
0x51cc <+99>:movq $0x0,-0x28(%rbp)
0x51d4 <+107>: movq $0x0,-0x20(%rbp)
0x51dc <+115>: movq $0x0,-0x18(%rbp)
0x51e4 <+123>: movl $0x0,-0x10(%rbp)
=> 0x51eb <+130>: movzbl -0x70(%rbp),%eax
0x51ef <+134>: movsbl %al,%eax
0x51f2 <+137>: mov%eax,%esi
0x51f4 <+139>: lea0xe09(%rip),%rdi# 0x6004
0x51fb <+146>: mov$0x0,%eax
0x5200 <+151>: callq 0x5070
0x5205 <+156>: mov$0x0,%eax
0x520a <+161>: mov-0x8(%rbp),%rdx
(gdb) q
$ gcc -g 1.c
$ gdb ./a.out
(gdb) r
Breakpoint 1, main () at 1.c:3
3 {
(gdb) n
4 char a[100] = {0};
(gdb)
5 printf("%d\n", a[0]);
(gdb) p a
$1 = '\000'
[Bug tree-optimization/99398] Miss to optimize vector permutation fed by CTOR and CTOR/CST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99398 --- Comment #2 from Kewen Lin --- Created attachment 50329 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50329&action=edit tested patch
[Bug c++/99456] [11 regression] ABI breakage with some static initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99456 Andrew Pinski changed: What|Removed |Added Keywords||ABI Target Milestone|--- |11.0
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 --- Comment #9 from Andrew Pinski --- *** Bug 99455 has been marked as a duplicate of this bug. ***
[Bug c/99455] internal compiler error: In function 'prb_reserve_in_last' in linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99455 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 99422. *** This bug has been marked as a duplicate of bug 99422 ***
[Bug gcov-profile/99443] [GCOV] No coverage with "Aborted(core dumped)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99443 --- Comment #4 from Andrew Pinski --- It is not well documented though. https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Gcov-and-Optimization.html#Gcov-and-Optimization Long-running applications can use the __gcov_reset and __gcov_dump facilities to restrict profile collection to the program region of interest. Calling __gcov_reset(void) will clear all profile counters to zero, and calling __gcov_dump(void) will cause the profile information collected at that point to be dumped to .gcda output files. ** Instrumented applications use a static destructor with priority 99 to invoke the __gcov_dump function.** Thus __gcov_dump is executed after all user defined static destructors, as well as handlers registered with atexit. If an executable loads a dynamic shared object via dlopen functionality, -Wl,--dynamic-list-data is needed to dump all profile data. - CUT
[Bug c++/99456] [11 regression] ABI breakage with some static initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99456 --- Comment #2 from Nathan Sidwell --- Created attachment 50328 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50328&action=edit trunk output (unoptimized)
[Bug c++/99456] [11 regression] ABI breakage with some static initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99456 --- Comment #1 from Nathan Sidwell --- Created attachment 50327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50327&action=edit gcc-10 output (unoptimized)
[Bug c++/99456] New: [11 regression] ABI breakage with some static initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99456 Bug ID: 99456 Summary: [11 regression] ABI breakage with some static initialization Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- Created attachment 50326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50326&action=edit testcase I've noticed some poorer behaviour in trunk than gcc10 with emitting inline vars. The example when compiled with gcc-10 -std=c++17 emits only those vars that are reachable from the externally visible vars. I.e. Var1...Var4 are NOT present. Further all vars are statically initialized with no global initializer function. (This is regardless of optimization level). With trunk, all the inline vars are emitted, even when not referenced. Further, there is a gloabl initializer function emitted, that only tests and sets their respective guard variables, with two exceptions. Var3 and Var13 are dynamically initialized. This is an abi breakage. I attach the two assembly files generated (the source presumes LP32 or LP64 ABI)
[Bug c/99455] New: internal compiler error: In function 'prb_reserve_in_last' in linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99455
Bug ID: 99455
Summary: internal compiler error: In function
'prb_reserve_in_last' in linux kernel
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
compiling attached source with -Os causes the ICE, it works ok with -O1 or -O2
=
$ x86_64-yoe-linux-musl-gcc -Os b.c -c
b.c:21245:1: error: unrecognizable insn:
21245 | }
| ^
(insn 58 57 446 6 (parallel [
(asm_operands/v ("push %0 ; popf") ("") 0 [
(mem:DI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [27 %sfp+-72 S8 A64])
(const_int 8 [0x8])) [16 e_56(D)->irqflags+0 S8
A64])
]
[
(asm_input:DI ("g") b.c:9370)
]
[] b.c:9370)
(clobber (mem:BLK (scratch) [0 A8]))
(clobber (reg:CC 17 flags))
]) "b.c":9370:2 -1
(nil))
during RTL pass: postreload
b.c:21245:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x1564e08 internal_error(char const*, ...)
???:0
0x60277f fancy_abort(char const*, int, char const*)
???:0
0x5dddbe _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x5a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
==
gcc version 11.0.1 20210307 (experimental) (GCC)
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 Andrew Pinski changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 99454 has been marked as a duplicate of this bug. ***
[Bug c/99454] internal compiler error: kernel module tg3 tg3_start_xmit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 99422. *** This bug has been marked as a duplicate of bug 99422 ***
[Bug libfortran/99218] [8/9/10/11 Regression] matmul on temporary array accesses invalid memory (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug debug/95432] inconsistent behaviors at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95432 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #4 from Andrew Pinski --- Closing as moved as it was reported and fixed in gdb already.
[Bug libfortran/99218] [8/9/10/11 Regression] matmul on temporary array accesses invalid memory (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218 --- Comment #8 from CVS Commits --- The releases/gcc-8 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:547563ba5abd685077d37a67c7d6fc9b54653934 commit r8-10787-g547563ba5abd685077d37a67c7d6fc9b54653934 Author: Harald Anlauf Date: Fri Mar 5 20:57:54 2021 +0100 PR libfortran/99218 - matmul on temporary array accesses invalid memory Do not invoke tuned rank-2 times rank-2 matmul if rank(b) == 1. libgfortran/ChangeLog: PR libfortran/99218 * m4/matmul_internal.m4: Invoke tuned matmul only for rank(b)>1. * generated/matmul_c10.c: Regenerated. * generated/matmul_c16.c: Likewise. * generated/matmul_c4.c: Likewise. * generated/matmul_c8.c: Likewise. * generated/matmul_i1.c: Likewise. * generated/matmul_i16.c: Likewise. * generated/matmul_i2.c: Likewise. * generated/matmul_i4.c: Likewise. * generated/matmul_i8.c: Likewise. * generated/matmul_r10.c: Likewise. * generated/matmul_r16.c: Likewise. * generated/matmul_r4.c: Likewise. * generated/matmul_r8.c: Likewise. * generated/matmulavx128_c10.c: Likewise. * generated/matmulavx128_c16.c: Likewise. * generated/matmulavx128_c4.c: Likewise. * generated/matmulavx128_c8.c: Likewise. * generated/matmulavx128_i1.c: Likewise. * generated/matmulavx128_i16.c: Likewise. * generated/matmulavx128_i2.c: Likewise. * generated/matmulavx128_i4.c: Likewise. * generated/matmulavx128_i8.c: Likewise. * generated/matmulavx128_r10.c: Likewise. * generated/matmulavx128_r16.c: Likewise. * generated/matmulavx128_r4.c: Likewise. * generated/matmulavx128_r8.c: Likewise. gcc/testsuite/ChangeLog: PR libfortran/99218 * gfortran.dg/matmul_21.f90: New test. (cherry picked from commit b1bee29167df6b0fbc9a4c8d06e2acbf3367af47)
[Bug c/99454] internal compiler error: kernel module tg3 tg3_start_xmit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454 --- Comment #1 from Khem Raj --- btw. another data point when compiling with -Os it works but fails with -O1 or -O2 it was working ok with gcc snapshot from 10 days ago.
[Bug c/99454] New: internal compiler error: kernel module tg3 tg3_start_xmit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454
Bug ID: 99454
Summary: internal compiler error: kernel module tg3
tg3_start_xmit
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
Created attachment 50325
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50325&action=edit
testcase
Compiling kernel 5.10 for x86_64 is resulting in below ICE
===
$ x86_64-yoe-linux-musl/x86_64-yoe-linux-musl-gcc -c a.c -O
a.c: In function 'tg3_start_xmit':
a.c:97234:1: error: unrecognizable insn:
97234 | }
| ^
(insn 258 1293 1351 23 (parallel [
(set (reg:SI 0 ax [orig:542 sum ] [542])
(asm_operands:SI (" addl %1, %0
adcl %2, %0
adcl %3, %0
adcl $0, %0
") ("=r") 0 [
(mem:SI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 64 [0x40])) [555 %sfp+-32 S8
A64])
(const_int 16 [0x10])) [4 MEM[(struct iphdr
*)_287].daddr+0 S4 A32])
(mem:SI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 64 [0x40])) [555 %sfp+-32 S8
A64])
(const_int 12 [0xc])) [4 MEM[(struct iphdr
*)_287].saddr+0 S4 A32])
(const_int 1536 [0x600])
(reg:SI 0 ax [orig:542 sum ] [542])
]
[
(asm_input:SI ("g") a.c:48913)
(asm_input:SI ("g") a.c:48913)
(asm_input:SI ("g") a.c:48913)
(asm_input:SI ("0") a.c:48913)
]
[] a.c:48913))
(clobber (reg:CC 17 flags))
]) "a.c":48913:2 -1
(nil))
during RTL pass: postreload
a.c:97234:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x1564e08 internal_error(char const*, ...)
???:0
0x60277f fancy_abort(char const*, int, char const*)
???:0
0x5dddbe _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x5a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
===
attached is the preprocessed source
compiler version
gcc version 11.0.1 20210307 (experimental) (GCC)
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 --- Comment #7 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #2) > I see the function is called before selecting a particular alternative, so > perhaps it means to care only about constraints like "X" and "" and not say > that mixed with other constraints etc. > But, shouldn't the code at least skip the =, +, &, % and whitespace from the > start? What about other modifiers (the various disparage slightly etc. > chars)? > And only consider as empty constraint if after those skips constraint is ""? > Not really sure if ",,," constraint is valid... > And, regarding of Eric's change to handle "X" that way, does that really > apply just to MEM and not SUBREG of MEM too? Yes. It seems my bad job on reviewing Richard Sandiford's patch 777e635f1a6c. Before this patch constraint string was checked only for 'p' which can not have modifiers (although spaces are still possible). I am afraid that fixing this mess can result in new failures. But we should do this anyway.
[Bug libfortran/99218] [8/9/10/11 Regression] matmul on temporary array accesses invalid memory (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1dfa6e6c50be570b8240793f58cdac95be9dd3ef commit r9-9273-g1dfa6e6c50be570b8240793f58cdac95be9dd3ef Author: Harald Anlauf Date: Fri Mar 5 20:57:54 2021 +0100 PR libfortran/99218 - matmul on temporary array accesses invalid memory Do not invoke tuned rank-2 times rank-2 matmul if rank(b) == 1. libgfortran/ChangeLog: PR libfortran/99218 * m4/matmul_internal.m4: Invoke tuned matmul only for rank(b)>1. * generated/matmul_c10.c: Regenerated. * generated/matmul_c16.c: Likewise. * generated/matmul_c4.c: Likewise. * generated/matmul_c8.c: Likewise. * generated/matmul_i1.c: Likewise. * generated/matmul_i16.c: Likewise. * generated/matmul_i2.c: Likewise. * generated/matmul_i4.c: Likewise. * generated/matmul_i8.c: Likewise. * generated/matmul_r10.c: Likewise. * generated/matmul_r16.c: Likewise. * generated/matmul_r4.c: Likewise. * generated/matmul_r8.c: Likewise. * generated/matmulavx128_c10.c: Likewise. * generated/matmulavx128_c16.c: Likewise. * generated/matmulavx128_c4.c: Likewise. * generated/matmulavx128_c8.c: Likewise. * generated/matmulavx128_i1.c: Likewise. * generated/matmulavx128_i16.c: Likewise. * generated/matmulavx128_i2.c: Likewise. * generated/matmulavx128_i4.c: Likewise. * generated/matmulavx128_i8.c: Likewise. * generated/matmulavx128_r10.c: Likewise. * generated/matmulavx128_r16.c: Likewise. * generated/matmulavx128_r4.c: Likewise. * generated/matmulavx128_r8.c: Likewise. gcc/testsuite/ChangeLog: PR libfortran/99218 * gfortran.dg/matmul_21.f90: New test. (cherry picked from commit b1bee29167df6b0fbc9a4c8d06e2acbf3367af47)
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #6 from Vladimir Makarov ---
(In reply to Joseph S. Myers from comment #0)
> Created attachment 50314 [details]
> preprocessed source
>
> Commit 9105757a59b890194ebf5b4fcbacd58db34ef332 ("[PR99378] LRA: Skip
> decomposing address for asm insn operand with unknown constraint.")
> introduced the following ICE building glibc for i686-linux-gnu. Tested with
> an x86_64 compiler; compile the attached .i file with the following options:
> -m32 -march=i686 -O2 -pg -S
>
Sorry for causing the troubles. I'll fix this tomorrow.
[Bug target/85074] FAIL: g++.dg/torture/pr81812.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85074 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by John David Anglin : https://gcc.gnu.org/g:8d2f7f40629cc5d0b4f27ee8aadc98c212876959 commit r8-10786-g8d2f7f40629cc5d0b4f27ee8aadc98c212876959 Author: John David Anglin Date: Sun Mar 7 17:55:32 2021 + Add mi_thunk support for vcalls on hppa. gcc/ChangeLog: PR target/85074 * config/pa/pa.c (TARGET_ASM_CAN_OUTPUT_MI_THUNK): Define as hook_bool_const_tree_hwi_hwi_const_tree_true. (pa_asm_output_mi_thunk): Add support for nonzero vcall_offset.
[Bug c++/99365] [11 Regression] ICE on partial specialization with constrained placeholder NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99365 --- Comment #6 from Johel Ernesto Guerrero Peña --- Thank you. Can confirm it's working for my use case.
[Bug target/85074] FAIL: g++.dg/torture/pr81812.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85074 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by John David Anglin : https://gcc.gnu.org/g:4f01123ca27e648611016d00c3ed95945f27ab30 commit r9-9272-g4f01123ca27e648611016d00c3ed95945f27ab30 Author: John David Anglin Date: Sun Mar 7 17:44:49 2021 + Add mi_thunk support for vcalls on hppa. gcc/ChangeLog: PR target/85074 * config/pa/pa.c (TARGET_ASM_CAN_OUTPUT_MI_THUNK): Define as hook_bool_const_tree_hwi_hwi_const_tree_true. (pa_asm_output_mi_thunk): Add support for nonzero vcall_offset.
[Bug bootstrap/98590] [11 regression] Bootstrap failure with Ada on Cygwin since switch to C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98590 Mikael Pettersson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Mikael Pettersson --- This issue is now fixed. Bootstrap still needs the PR94918 fix though.
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 --- Comment #2 from Jonathan Wakely --- Yup
[Bug libstdc++/99430] std::filesystem::path: UNC device paths with \\?\… not supported properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99430 --- Comment #1 from Jonathan Wakely --- They're simply not supported at all.
[Bug libstdc++/45896] [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45896 Jonathan Wakely changed: What|Removed |Added CC||lewis at sophists dot com --- Comment #11 from Jonathan Wakely --- *** Bug 99439 has been marked as a duplicate of this bug. ***
[Bug libstdc++/99439] use_facet> (l); get() API with kMonthDayYearFormat = L"%m/%d/%Y" should allow missing leading zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99439 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- Nothing to do with wchar_t, and it's already known. As it says in PR 45896 this changed between C++03 and C++11. *** This bug has been marked as a duplicate of bug 45896 ***
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- and we can't skip .a because that's the right suffix for AIX, correct?
[Bug c++/99429] [10/11 Regression] ICE for bool return from <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99429 --- Comment #4 from Jonathan Wakely --- Dup of PR 94162 ?
[Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 Bug ID: 99453 Summary: libstdc++*-gdb.py installation depends on library naming Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- libstdc++-v3/python/Makefile.am does: install-data-local: gdb.py @$(mkdir_p) $(DESTDIR)$(toolexeclibdir) ## We want to install gdb.py as SOMETHING-gdb.py. SOMETHING is the ## full name of the final library. We want to ignore symlinks, the ## .la file, and any previous -gdb.py file. This is inherently ## fragile, but there does not seem to be a better option, because ## libtool hides the real names from us. @here=`pwd`; cd $(DESTDIR)$(toolexeclibdir); \ for file in libstdc++.*; do \ case $$file in \ *-gdb.py) ;; \ *.la) ;; \ *) if test -h $$file; then \ continue; \ fi; \ libname=$$file;; \ esac; \ done; \ cd $$here; \ echo " $(INSTALL_DATA) gdb.py $(DESTDIR)$(toolexeclibdir)/$$libname-gdb.py"; \ $(INSTALL_DATA) gdb.py $(DESTDIR)$(toolexeclibdir)/$$libname-gdb.py This will use the last matching file for the libstdc++* glob. That works fine for ELF targets where the matching names are: libstdc++.a libstdc++.so libstdc++.so.6 libstdc++.so.6.0.29 But not for MacOS with: libstdc++.6.dylib libstdc++.a Or mingw with: libstdc++-6.dll libstdc++.dll.a We need a better way to find the dynamic library, whether that's the so.6.0.29 or the .dylib or the .dll, that doesn't depend on the shell's alphabetic sort for the pattern. As the comment says, libtool doesn't give us that info, but we can still do better.
[Bug c++/99452] Inconsistent constinit handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99452
--- Comment #1 from Nathan Sidwell ---
Here's another:
using value_t = unsigned long;
unsigned obj;
constinit value_t failed
= reinterpret_cast (&obj) + (11 << 0);
constinit value_t accepted
= reinterpret_cast (&obj) + (11);
bester:309>gcc-current/bin/g++ -c -std=gnu++20 r.ii
r.ii:5:19: error: ‘constinit’ variable ‘failed’ does not have a constant
initializer
5 | constinit value_t failed
| ^~
r.ii:6:5: error: conversion from pointer type ‘unsigned int*’ to arithmetic
type ‘value_t’ {aka ‘long unsigned int’} in a constant expression
6 | = reinterpret_cast (&obj) + (11 << 0);
[Bug c++/99452] New: Inconsistent constinit handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99452 Bug ID: 99452 Summary: Inconsistent constinit handling Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- constinit forces static initialization (or error). Sadly the std doesn't permit c++98-era address-constant expressions (symbol + addend). but we do accept that (probably a bug std=c++20 vs std=gnu++20 makes no difference) But we do so inconsistently. Both x & y are initializable in this manner -- and we do emit such an initialization if the constinit is removed, regardless of optimization level. But with constinit, the presence of the OR operator causes y's initialization to be rejected. Even though it's totally foldable. constinit long x = reinterpret_cast (&x) + 0; constinit long y = reinterpret_cast (&y) + (0|0); gcc-current/bin/g++ -c c.cc -std=c++20 c.cc:4:16: error: ‘constinit’ variable ‘y’ does not have a constant initializer 4 | constinit long y = reinterpret_cast (&y) + (0|0); |^ c.cc:4:20: error: conversion from pointer type ‘long int*’ to arithmetic type ‘long int’ in a constant expression 4 | constinit long y = reinterpret_cast (&y) + (0|0); Please note I plan an EWG paper to allow symbol+addend, as that seems a useful behaviour.
[Bug c++/99451] New: [plugin] cannot enable dumps for plugin passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99451 Bug ID: 99451 Summary: [plugin] cannot enable dumps for plugin passes Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- Created attachment 50324 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50324&action=edit patch the -fdump-FOO-BAR options are parsed before plugins have been initialized, this means that one cannot name a pass created with a plugin. Here's a patch to defer the dump option processing until later (we cannot just swap the order, as the plugin options themselves need parsing before we initialize the plugins). -fdump-FOO-all will enable the dump, so we have a workaround I don't think this is a regression, so stage 1 I guess?
[Bug debug/95432] inconsistent behaviors at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95432 --- Comment #3 from Tom de Vries --- (In reply to Andrew Pinski from comment #2) > Assembly: > .loc 1 12 3 is_stmt 1 view .LVU12 > .loc 1 10 8 is_stmt 0 view .LVU13 > movaps %xmm0, (%rsp) > .loc 1 11 8 view .LVU14 > movaps %xmm0, 32(%rsp) > .loc 1 12 13 view .LVU15 > callfoo > .LVL1: > .loc 1 13 13 view .LVU16 > leaq32(%rsp), %rdi > .loc 1 12 13 view .LVU17 > movl%eax, %edx > .LVL2: > .loc 1 13 3 is_stmt 1 view .LVU18 > .loc 1 13 13 is_stmt 0 view .LVU19 > callfoo > .LVL3: > .loc 1 14 3 is_stmt 1 view .LVU20 > .loc 1 14 6 is_stmt 0 view .LVU21 > > Looks correct to me, both call foo have the correct line on them. I think > this is another GDB issue, most likely how dwarf3 and is_stmt is handled > just like 95431 even. Ack, this is gdb PR breakpoints/26063 ( https://sourceware.org/bugzilla/show_bug.cgi?id=26063 ). Fixed by https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebde6f2ddc987e7e2d5a218ee8cf0126ec189424 .
[Bug target/99378] [8/9/10/11 Regression] ICE in decompose_normal_address, at rtlanal.c:6710
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99378 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #4 from Arseny Solokha --- I believe [11 Regression] marker can be removed now.
[Bug target/99437] [11 Regression] Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,15'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99437
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot
gnu.org
CC||ktkachov at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #4 from ktkachov at gcc dot gnu.org ---
Confirmed:
#include
uint8x16_t
foo (uint16x8_t a, uint8x8_t b)
{
return vcombine_u8 (vmovn_u16 (vshrq_n_u16 (a, 9)), b);
}
Testing a patch.
[Bug lto/99450] New: ICE: unrecognizable insn with lto build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99450 Bug ID: 99450 Summary: ICE: unrecognizable insn with lto build Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org CC: marxin at gcc dot gnu.org Target Milestone: --- seen with the gcc-10 branch 20210306 on x86_64-linux-gnu, building the emoslib 4.5.9 package. the package fails with other issues building with trunk. $ gfortran -Wl,-z,defs -Wl,--as-needed -flto=auto -Wl,-z,relro -Wl,--disable-new-dtags -g -O2 -ffile-prefix-map=/packages/tmp/emoslib-4.5.9=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fallow-argument-mismatch -ffixed-line-length-none -fcray-pointer -fno-second-underscore -Wuninitialized -Wunused-variable -Wno-maybe-uninitialized -DSHAREDMEMORY -fdefault-real-8 -fdefault-double-8 -fdefault-real-8 -fdefault-double-8 -O3 -DNDEBUG -funroll-all-loops -finline-functions -O2 CMakeFiles/bufr_0t2.dir/bufr_0t2.F.o -o ../../usr/bin/bufr_0t2 -Wl,-rpath,$ORIGIN/../lib libmy_exit.a ../../usr/lib/x86_64-linux-gnu/libemosR64.a /usr/lib/x86_64-linux-gnu/libeccodes.so.0 -lpng -laec -lm /usr/lib/x86_64-linux-gnu/libopenjp2.so -lpthread /usr/lib/x86_64-linux-gnu/libfftw3.so ../../libemos-dp/./bufrdc_wmo/buens4.F:268:57: warning: type of ‘bugbytesr4’ does not match original declaration [-Wlto-type-mismatch] ../../libemos-dp/./bufrdc_wmo/bugbytesR4.F:11:28: note: ‘bugbytesr4’ was previously declared here ../../libemos-dp/./bufrdc_wmo/bugbytesR4.F:11:28: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used ../../libemos-dp/./bufrdc_wmo/buens4.F:275:56: warning: type of ‘bugbytesr8’ does not match original declaration [-Wlto-type-mismatch] ../../libemos-dp/./bufrdc_wmo/bugbytesR8.F:11:28: note: ‘bugbytesr8’ was previously declared here ../../libemos-dp/./bufrdc_wmo/bugbytesR8.F:11:28: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used ../../libemos-dp/./pbio/pbbufr.F:90:57: warning: type of ‘bufrread’ does not match original declaration [-Wlto-type-mismatch] ../../libemos-dp/./pbio/pbio.c:1288:6: note: ‘bufrread_’ was previously declared here ../../libemos-dp/./pbio/pbio.c:1288:6: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used ../../libemos-dp/./bufrdc_wmo/bcmctc.F:13:21: warning: type of ‘bcmctc’ does not match original declaration [-Wlto-type-mismatch] ../../libemos-dp/./bufrdc_wmo/bcmctc.F:13:21: note: ‘bcmctc’ was previously declared here ../../libemos-dp/./bufrdc_wmo/bcmctc.F:13:21: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used ../../libemos-dp/./bufrdc_wmo/bcmwtc.F:12:21: warning: type of ‘bcmwtc’ does not match original declaration [-Wlto-type-mismatch] ../../libemos-dp/./bufrdc_wmo/bcmwtc.F:12:21: note: ‘bcmwtc’ was previously declared here ../../libemos-dp/./bufrdc_wmo/bcmwtc.F:12:21: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used ../../libemos-dp/./bufrdc_wmo/bcmroot.F:11:22: warning: type of ‘bcmroot’ does not match original declaration [-Wlto-type-mismatch] ../../libemos-dp/./bufrdc_wmo/bcmroot.F:11:22: note: ‘bcmroot’ was previously declared here ../../libemos-dp/./bufrdc_wmo/bcmroot.F:11:22: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used ../../libemos-dp/./bufrdc_wmo/bcomctc.F:13:22: warning: type of ‘bcomctc’ does not match original declaration [-Wlto-type-mismatch] ../../libemos-dp/./bufrdc_wmo/bcomctc.F:13:22: note: ‘bcomctc’ was previously declared here ../../libemos-dp/./bufrdc_wmo/bcomctc.F:13:22: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used ../../libemos-dp/./bufrdc_wmo/bcomroot.F:12:23: warning: type of ‘bcomroot’ does not match original declaration [-Wlto-type-mismatch] ../../libemos-dp/./bufrdc_wmo/bcomroot.F:12:23: note: ‘bcomroot’ was previously declared here ../../libemos-dp/./bufrdc_wmo/bcomroot.F:12:23: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used ../../libemos-dp/./bufrdc_wmo/bcomtabloadc.F:12:28: warning: type of ‘bcomtabloadc’ does not match original declaration [-Wlto-type-mismatch] ../../libemos-dp/./bufrdc_wmo/bcomtabloadc.F:12:28: note: ‘bcomtabloadc’ was previously declared here ../../libemos-dp/./bufrdc_wmo/bcomtabloadc.F:12:28: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used ../../libemos-dp/./bufrdc_wmo/bcomdefc.F:12:23: warning: type of ‘bcomdefc’ does not match original declaration [-Wlto-type-mismatch] ../../libemos-dp/./bufrdc_wmo/bcomdefc.F:12:23: note: ‘bcomdefc’ was previously declared here ../../libemos-dp/./bufrdc_wmo/bcomdefc.F:12:23: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used ./tools/bufrtools_wmo/bufr_0t2.F:138:47: warning: type of ‘pbopen’ does not match original declaration [-Wlto-type-mismatch] ../../libemos-dp/./pbio/pbio.c:84:6: note: type mismat
[Bug fortran/57871] gfortran -freal-4-real-16 gives wrong result for selected_real_kind(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871
--- Comment #12 from Dominique d'Humieres ---
> As this issue is about documentation, if I read the later comments correctly:
> Can you check whether the documentation is now sufficient or whether more is
> needed? > If so, what is needed? — If not, can this bug now be closed?
I don't like the sentence
Note that for @code{REAL(KIND=KIND(1.0))} the literal may get promoted and
then the result may get promoted again.
There is only one promotion for -freal-4-real-X, and it does not matter if
1.0 is promoted first KIND(1.0) is then X, or after KIND(1.0) is 4 then
REAL(KIND=4) is promoted to REAL(KIND=X).
The situation for SELECTED_REAL_KIND(1) is quite different: if the promotion of
-freal-4-real-X is done first, then the smallest kind available is 8,
if it is done after then SELECTED_REAL_KIND(1) will be 4, then promoted to X.
What about a sentence such as:
Note that while @code{REAL(KIND=KIND(1.0))} is always promoted to X by
-freal-4-real-X, @code{SELECTED_REAL_KIND(1)} returns always 4 which is then
promoted to X.
?
It may be also useful to add a sentence saying that the promotion options are
provided as such and that the observed behavior is not a bug but a feature.
As said in comment 8, I did not find any other circonstance, by
SELECTED_REAL_KIND
for which such ambiguity exists.
[Bug gcov-profile/99441] [GCOV] Wrong coverage with complex "if" condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99441
--- Comment #2 from Yang Wang ---
(In reply to Andrew Pinski from comment #1)
> So line 27 has a short cutting conditional included, so technically it is
> executed 30 times, one for each side of the &&.
$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
libgcov profiling error:/home/wangyang/coverage/found
bug/gcc/test.gcda:overwriting an existing profile data with a different
timestamp
File 'test.c'
Lines executed:95.83% of 24
Creating 'test.c.gcov'
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:typedef __SIZE_TYPE__ size_t;
-:2:typedef __UINTPTR_TYPE__ uintptr_t;
-:3:
-:4:struct S {
-:5: int a;
-:6: unsigned short b;
-:7: int c, d, e;
-:8: long f, g, h;
-:9: int i, j;
-: 10:};
-: 11:static struct S *k;
-: 12:static size_t l = 1;
-: 13:int m;
-: 14:
15: 15:static int bar(void) {
-: 16: unsigned i;
-: 17: int j;
15: 18: if (k[0].c == 0) {
15: 19:++m;
15: 20:size_t n = l * 2;
-: 21:struct S *o;
15: 22:k = (struct S *)__builtin_realloc(k, sizeof(struct S) * n);
30: 23:for (i = l; i < n; i++) {
15: 24: void *p = (void *)&k[i];
15: 25: int q = 0;
15: 26: size_t r = sizeof(struct S);
15: 27: if uintptr_t)p) % __alignof__(long)) == 0
15: 28:&&
30: 29:r % sizeof(long) == 0) {
15: 30:long __attribute__((may_alias)) *s = (long *)p;
15: 31:long *t = (long *)((char *)s + r);
120: 32:while (s < t)
105: 33: *s++ = 0;
-: 34: } else
#: 35:__builtin_memset(p, q, r);
-: 36:}
-: 37: }
15: 38: return 1;
-: 39:}
-: 40:
1: 41:int main() {
1: 42: k = (struct S *)__builtin_malloc(sizeof(struct S));
1: 43: __builtin_memset(k, '\0', sizeof(struct S));
1: 44: k->a = -1;
16: 45: for (int i = 0; i < 15; ++i)
15: 46:bar();
-: 47:}
Thanks for your reply!
I tried to separate line 27 and put it in a different lines. The coverage of
right side(line 29) is 30, and the left side(line 27) is 15, which is a bit
different from the execution logic about "&&", where the left side of "&&"
should not be less than the right side. Is it a bug?
[Bug gcov-profile/99443] [GCOV] No coverage with "Aborted(core dumped)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99443 --- Comment #3 from Yang Wang --- (In reply to Andrew Pinski from comment #2) > This behavior might even be documented but I have not looked yet. Thanks for your reply! So, this is expected (as well as bug 99442) rather than a bug?
[Bug lto/99449] New: lto1: fatal error: multiple prevailing defs for ‘_ZTIN4sdsl14rank_support_vILh1ELh1EEE’ with -msse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99449
Bug ID: 99449
Summary: lto1: fatal error: multiple prevailing defs for
‘_ZTIN4sdsl14rank_support_vILh1ELh1EEE’ with -msse3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
trunk 20210306 on x86_64-linux-gnu
not sure how to report this ... seen building the vg package in Debian with
-msse3 (according to the packaging, builds with -mavx2, -mavx, -msse4.1,
-mssse3 succeed).
g++ -flto=auto -Wl,-z,relro -Wl,-z,now -I/usr/include/fastahack
-I/usr/include/smithwaterman -I/usr/include/vcflib -I/usr/include/smithwaterman
-I/usr/include/fastahack -I/packages/tmp/vg-1.30.0+ds/include -isystem
/packages/tmp/vg-1.30.0+ds/include -I. -I/packages/tmp/vg-1.30.0+ds/src
-I/packages/tmp/vg-1.30.0+ds/src/unittest
-I/packages/tmp/vg-1.30.0+ds/src/subcommand
-I/packages/tmp/vg-1.30.0+ds/include/dynamic -pthread -isystem
/usr/include/cairo -isystem /usr/include/glib-2.0 -isystem
/usr/lib/x86_64-linux-gnu/glib-2.0/include -isystem /usr/include/pixman-1
-isystem /usr/include/uuid -isystem /usr/include/freetype2 -isystem
/usr/include/libpng16 -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -Werror=return-type
-std=c++14 -ggdb -g -g -O2 -ffile-prefix-map=/packages/tmp/vg-1.30.0+ds=.
-flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat
-Werror=format-security -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -msse3 -fopenmp
-o test/build_graph test/build_graph.cpp -lvg -L/packages/tmp/vg-1.30.0+ds/lib
/packages/tmp/vg-1.30.0+ds/lib/libvgio.a -lz -lvcflib -lgssw -lssw
-lsublinearLS -lpthread -lncurses -lgcsa2 -lgbwtgraph -lgbwt -ldivsufsort
-ldivsufsort64 -lraptor2 -lpinchesandcacti -l3edgeconnected -lsonlib -lfml
-lstructures -lvw -lallreduce -lbdsg -lxg -lsdsl -lhandlegraph -lfastahack
-lsmithwaterman -ldisorder -lvcflib -lsmithwaterman -ldisorder -lfastahack
-lhts -ltabixpp -lcairo -lz -lgobject-2.0 -lffi -lglib-2.0 -pthread -lpcre
-pthread -lpixman-1 -lfontconfig -luuid -lexpat -lfreetype -lbrotlidec
-lbrotlicommon -lpng16 -lm -lz -lm -lz -lxcb-shm -lxcb-render -lXrender -lXext
-lX11 -lpthread -lxcb -lXau -lXdmcp -ljansson -latomic -rdynamic -ldw -lelf
"-lboost_program_options""" -ldl -llzma -lbz2 -ljemalloc -Wl,-Bstatic -lhts
-ldeflate -lz -llzma -lprotobuf -lz -Wl,-Bdynamic
lto1: fatal error: multiple prevailing defs for
‘_ZTIN4sdsl14rank_support_vILh1ELh1EEE’
compilation terminated.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
the gcc-10 branch fails differently:
src/subcommand/../algorithms/walk.hpp:22: warning: type ‘struct walk_t’
violates the C++ One Definition Rule [-Wodr]
22 | struct walk_t {
|
src/algorithms/prune.cpp:12: note: a different type is defined in another
translation unit
12 | struct walk_t {
|
src/subcommand/../algorithms/walk.hpp:29: note: the first difference of
corresponding definitions is field ‘path’
29 | std::vector path;
|
src/algorithms/prune.cpp:20: note: a field with different name is defined in
another translation unit
20 | pos_t begin;
|
lto1: internal compiler error: in lto_read_decls, at lto/lto-common.c:1956
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #2 from Andrew Pinski --- Looks like a stack overflow while doing gc. To me die_struct GTY could use a recursive note added to it. That is just by looking at the backtrace.
[Bug c++/99170] [modules] ICE in get_merge_kind with std::string NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99170 --- Comment #8 from Rémi Galan Alfonso --- I tested it and it works perfectly, thanks!
[Bug libstdc++/70508] libstdc++.*-gdb.py': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70508 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-03-07 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug libstdc++/70508] libstdc++.*-gdb.py': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70508 Jonathan Wakely changed: What|Removed |Added Component|other |libstdc++ Keywords||build --- Comment #1 from Jonathan Wakely --- (In reply to Fiodar from comment #0) > Making install in python > make[3]: Entering directory > `/d/mbuild/src/build-gcc/arm-none-symbianelf/libstdc++-v3/python' > make[4]: Entering directory > `/d/mbuild/src/build-gcc/arm-none-symbianelf/libstdc++-v3/python' > make[4]: Nothing to be done for `install-exec-am'. > /bin/install -c -m 644 gdb.py > /usr/local/gcc-5.3.0/arm-none-symbianelf/lib/libstdc++.*-gdb.py > /bin/install: cannot create regular file > `/usr/local/gcc-5.3.0/arm-none-symbianelf/lib/libstdc++.*-gdb.py': No such > file or directory This means libstdc++.* didn't match any files, which means the shared lib hasn't been built yet. That shouldn't happen. Do you still see this with current releases?
[Bug lto/99448] New: ICE in read_cgraph_and_symbols, at lto/lto-common.c:2739
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99448 Bug ID: 99448 Summary: ICE in read_cgraph_and_symbols, at lto/lto-common.c:2739 Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org CC: marxin at gcc dot gnu.org Target Milestone: --- seen building the log4cxx 0.11.0 package with LTO, both gcc-10 branch 20210306 and trunk 20210306 on x86_64-linux-gnu g++ -g -O2 -ffile-prefix-map=/packages/tmp/log4cxx-0.11.0=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -flto=auto -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/testsuite customlogger/xlogger.o customlogger/xloggertestcase.o defaultinit/testcase1.o defaultinit/testcase2.o defaultinit/testcase3.o defaultinit/testcase4.o filter/andfiltertest.o filter/denyallfiltertest.o filter/levelmatchfiltertest.o filter/levelrangefiltertest.o filter/loggermatchfiltertest.o filter/mapfiltertest.o filter/stringmatchfiltertest.o helpers/absolutetimedateformattestcase.o helpers/cacheddateformattestcase.o helpers/charsetdecodertestcase.o helpers/charsetencodertestcase.o helpers/cyclicbuffertestcase.o helpers/datetimedateformattestcase.o helpers/inetaddresstestcase.o helpers/iso8601dateformattestcase.o helpers/localechanger.o helpers/messagebuffertest.o helpers/optionconvertertestcase.o helpers/propertiestestcase.o helpers/relativetimedateformattestcase.o helpers/stringtokenizertestcase.o helpers/stringhelpertestcase.o helpers/syslogwritertest.o helpers/threadtestcase.o helpers/timezonetestcase.o helpers/transcodertestcase.o net/smtpappendertestcase.o net/socketappendertestcase.o net/sockethubappendertestcase.o net/syslogappendertestcase.o net/telnetappendertestcase.o net/xmlsocketappendertestcase.o pattern/num343patternconverter.o pattern/patternparsertestcase.o rolling/filenamepatterntestcase.o rolling/filterbasedrollingtest.o rolling/manualrollingtest.o rolling/obsoletedailyrollingfileappendertest.o rolling/obsoleterollingfileappendertest.o rolling/sizebasedrollingtest.o rolling/timebasedrollingtest.o util/absolutetimefilter.o util/absolutedateandtimefilter.o util/binarycompare.o util/compare.o util/controlfilter.o util/filenamefilter.o util/utilfilter.o util/iso8601filter.o util/linenumberfilter.o util/relativetimefilter.o util/serializationtesthelper.o util/threadfilter.o util/transformer.o util/xmlfilenamefilter.o util/xmllineattributefilter.o util/xmltimestampfilter.o util/xmlthreadfilter.o varia/errorhandlertestcase.o varia/levelmatchfiltertestcase.o varia/levelrangefiltertestcase.o db/odbcappendertestcase.o xml/customleveltestcase.o xml/domtestcase.o xml/xlevel.o xml/xmllayouttestcase.o xml/xmllayouttest.o nt/nteventlogappendertestcase.o abts.o asyncappendertestcase.o encodingtest.o filetestcase.o hierarchytest.o hierarchythresholdtestcase.o jsonlayouttest.o l7dtestcase.o leveltestcase.o logunit.o loggertestcase.o minimumtestcase.o patternlayouttest.o vectorappender.o appenderskeletontestcase.o consoleappendertestcase.o fileappendertestcase.o rollingfileappendertestcase.o streamtestcase.o writerappendertestcase.o ndctestcase.o propertyconfiguratortest.o mdctestcase.o -L/usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libapr-1.so /usr/lib/x86_64-linux-gnu/libaprutil-1.so ../../../src/main/cpp/.libs/liblog4cxx.so -pthread lto1: internal compiler error: in read_cgraph_and_symbols, at lto/lto-common.c:2739 0x5c94c0 read_cgraph_and_symbols(unsigned int, char const**) ../../src/gcc/lto/lto-common.c:2739 0x1598166 lto_main() ../../src/gcc/lto/lto.c:625 Please submit a full bug report, with preprocessed source if appropriate.
[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #1 from Matthias Klose --- object files at https://people.debian.org/~doko/tmp/guymager-tst.tar.xz
[Bug lto/99447] New: [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 Bug ID: 99447 Summary: [11 Regression] ICE (segfault) in lookup_page_table_entry Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org CC: marxin at gcc dot gnu.org Target Milestone: --- seen with trunk 20210306 on x86_64-linux-gnu building the guymager package with LTO. $ g++ -Wl,-z,relro -ggdb -rdynamic -Wl,-flto -Wl,-z,relro -Wl,-O3 -o guymager compileinfo.o aaff.o aewf.o config.o device.o dlgabort.o dlgacquire.o dlgdirsel.o dlgautoexit.o dlgmessage.o dlgwait.o error.o fifo.o file.o hash.o info.o infofield.o itemdelegate.o main.o mainwindow.o md5.o media.o qtutil.o runstats.o sha1.o sha256.o table.o thread.o threadcompress.o threadhash.o threadread.o threadscan.o threadwrite.o util.o moc_devicelistmodel.o moc_dlgabort.o moc_dlgacquire.o moc_dlgautoexit.o moc_dlgacquire_private.o moc_dlgdirsel.o moc_dlgdirsel_private.o moc_dlgmessage.o moc_dlgwait.o moc_info.o moc_infofield.o moc_itemdelegate.o moc_main_private.o moc_mainwindow.o moc_table.o moc_thread.o moc_threadcompress.o moc_threadhash.o moc_threadread.o moc_threadscan.o moc_threadwrite.o -lz -ldl -lguytools -lewf -lbfio /usr/lib/x86_64-linux-gnu/libQt5Widgets.so /usr/lib/x86_64-linux-gnu/libQt5Gui.so /usr/lib/x86_64-linux-gnu/libQt5DBus.so /usr/lib/x86_64-linux-gnu/libQt5Core.so -lGL -lpthread device.cpp: In member function ‘GetErrorText’: device.cpp:155:1: internal compiler error: Segmentation fault 155 | } | ^ 0xc52c79 crash_signal ../../src/gcc/toplev.c:327 0x7f3b6994fd5f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x11ac4fb lookup_page_table_entry ../../src/gcc/ggc-page.c:630 0x11ac4fb ggc_set_mark(void const*) ../../src/gcc/ggc-page.c:1544 0x13bdefd gt_ggc_mx_basic_block_def(void*) /build/gcc-11-7yDrbQ/gcc-11-11-20210306/build/gcc/gtype-desc.c:1527 0x13bc981 gt_ggc_mx_gimple(void*) /build/gcc-11-7yDrbQ/gcc-11-11-20210306/build/gcc/gtype-desc.c:1238 0x11b188e gt_ggc_mx_cgraph_edge(void*) /build/gcc-11-7yDrbQ/gcc-11-11-20210306/build/gcc/gtype-desc.c:1403 0x11b15e1 gt_ggc_mx_symtab_node(void*) /build/gcc-11-7yDrbQ/gcc-11-11-20210306/build/gcc/gtype-desc.c:1349 0x11a903a gt_ggc_mx_lang_tree_node(void*) ./gtype-lto.h:284 0x11a904e gt_ggc_mx_lang_tree_node(void*) ./gtype-lto.h:280 0x11a9cde gt_ggc_mx_rtx_def(void*) /build/gcc-11-7yDrbQ/gcc-11-11-20210306/build/gcc/gtype-desc.c:722 0x11b435e void gt_ggc_mx(vec*) ../../src/gcc/vec.h:1353 0x11b435e gt_ggc_mx_vec_dw_attr_node_va_gc_(void*) ./gt-dwarf2out.h:275 0x11b435e gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:45 0x11b4433 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:27 0x11b4433 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:47 0x11b4433 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:27 0x11b4433 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:47 0x11b4433 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:27 0x11b4433 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:47 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
[Bug preprocessor/99446] New: [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99446 Bug ID: 99446 Summary: [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- Created attachment 50323 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50323&action=edit preprocessed source seen building the firefox-esr 78.8.0 package, using trunk 20210306. I have a compiler-generated ICE report, however even trying to re-run the command doesn't always generates the ICE report. make[3]: Entering directory '/packages/tmp/firefox-esr-78.8.0esr/build-browser/config/external/rlbox_lucet_sandbox' config/external/rlbox_lucet_sandbox/rlbox_lucet_thread_locals.o /usr/bin/g++ -o rlbox_lucet_thread_locals.o -c -I/packages/tmp/firefox-esr-78.8.0esr/build-browser/dist/stl_wrappers -I/packages/tmp/firefox-esr-78.8.0esr/build-browser/dist/system_wrappers -include /packages/tmp/firefox-esr-78.8.0esr/config/gcc_hidden.h -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -DNDEBUG=1 -DTRIMMED=1 -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DSTATIC_EXPORTABLE_JS_API -I/packages/tmp/firefox-esr-78.8.0esr/config/external/rlbox_lucet_sandbox -I/packages/tmp/firefox-esr-78.8.0esr/build-browser/config/external/rlbox_lucet_sandbox -I/packages/tmp/firefox-esr-78.8.0esr/build-browser/dist/include -I/usr/include/nspr -I/usr/include/nss -I/usr/include/nspr -I/packages/tmp/firefox-esr-78.8.0esr/build-browser/dist/include/nss -fPIC -DMOZILLA_CLIENT -include /packages/tmp/firefox-esr-78.8.0esr/build-browser/mozilla-config.h -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++2a-compat -Wduplicated-cond -Wimplicit-fallthrough -Wunused-function -Wunused-variable -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wno-multistatement-macros -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat -Wformat-overflow=2 -fno-sized-deallocation -fno-aligned-new -O2 -ffile-prefix-map=/packages/tmp/firefox-esr-78.8.0esr=. -fstack-protector-strong -Wformat -Werror=format-security -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -O2 -fomit-frame-pointer -funwind-tables -MD -MP -MF .deps/rlbox_lucet_thread_locals.o.pp /packages/tmp/firefox-esr-78.8.0esr/config/external/rlbox_lucet_sandbox/rlbox_lucet_thread_locals.cpp /packages/tmp/firefox-esr-78.8.0esr/config/external/rlbox_lucet_sandbox/rlbox_lucet_thread_locals.cpp:1: internal compiler error: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005 1 | /* -*- Mode: C++; tab-width: 20; indent-tabs-mode: nil; c-basic-offset: 2 -*- */ | 0x656a93 linemap_position_for_loc_and_offset(line_maps*, unsigned int, unsigned int) ../libcpp/../../src/libcpp/line-map.c:1005 0x18ebee1 cp_lexer_new_main ../../src/gcc/cp/parser.c:676 0x18ebee1 c_parse_file() ../../src/gcc/cp/parser.c:45227 0x18d4aba c_common_parse_file() ../../src/gcc/c-family/c-opts.c:1218 Please submit a full bug report, with preprocessed source if appropriate.
[Bug other/98533] [8/9/10/11 Regression] ICE: 'verify_type' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98533 --- Comment #3 from Matthias Klose --- reconfirmed with 20210306, building the actiona package.
[Bug target/99321] [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670: insn does not satisfy its constraints: {*uminv16qi3} since r11-7121-g37876976b0511ec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a18ebd6c439227b048a91fbfa66f5983f884c157 commit r11-7548-ga18ebd6c439227b048a91fbfa66f5983f884c157 Author: Jakub Jelinek Date: Sun Mar 7 10:27:28 2021 +0100 i386: Fix some -mavx512vl -mno-avx512bw bugs [PR99321] As I wrote in the mail with the previous PR99321 fix, we have various bugs where we emit instructions that need avx512bw and avx512vl ISAs when compiling with -mavx512vl -mno-avx512bw. Without the following patch, the attached testcase fails with: /tmp/ccW4PsfG.s: Assembler messages: /tmp/ccW4PsfG.s:9: Error: unsupported instruction `vpaddb' /tmp/ccW4PsfG.s:20: Error: unsupported instruction `vpaddb' /tmp/ccW4PsfG.s:31: Error: unsupported instruction `vpaddw' /tmp/ccW4PsfG.s:42: Error: unsupported instruction `vpaddw' /tmp/ccW4PsfG.s:53: Error: unsupported instruction `vpsubb' /tmp/ccW4PsfG.s:64: Error: unsupported instruction `vpsubb' /tmp/ccW4PsfG.s:75: Error: unsupported instruction `vpsubw' /tmp/ccW4PsfG.s:86: Error: unsupported instruction `vpsubw' /tmp/ccW4PsfG.s:97: Error: unsupported instruction `vpmullw' /tmp/ccW4PsfG.s:108: Error: unsupported instruction `vpmullw' /tmp/ccW4PsfG.s:133: Error: unsupported instruction `vpminub' /tmp/ccW4PsfG.s:144: Error: unsupported instruction `vpminuw' /tmp/ccW4PsfG.s:155: Error: unsupported instruction `vpminuw' /tmp/ccW4PsfG.s:166: Error: unsupported instruction `vpminsb' /tmp/ccW4PsfG.s:177: Error: unsupported instruction `vpminsb' /tmp/ccW4PsfG.s:202: Error: unsupported instruction `vpminsw' /tmp/ccW4PsfG.s:227: Error: unsupported instruction `vpmaxub' /tmp/ccW4PsfG.s:238: Error: unsupported instruction `vpmaxuw' /tmp/ccW4PsfG.s:249: Error: unsupported instruction `vpmaxuw' /tmp/ccW4PsfG.s:260: Error: unsupported instruction `vpmaxsb' /tmp/ccW4PsfG.s:271: Error: unsupported instruction `vpmaxsb' /tmp/ccW4PsfG.s:296: Error: unsupported instruction `vpmaxsw' We already have Yw constraint which is equivalent to v for -mavx512bw -mavx512vl and to nothing otherwise, per discussions this patch changes it to stand for x otherwise. As it is an undocumented internal constraint, hopefully it won't affect any inline asm in the wild. For the instructions that need both we need to use Yw and v for modes that don't need that. 2021-03-07 Jakub Jelinek PR target/99321 * config/i386/constraints.md (Yw): Use SSE_REGS if TARGET_SSE but TARGET_AVX512BW or TARGET_AVX512VL is not set. Adjust description and comment. * config/i386/sse.md (v_Yw): New define_mode_attr. (*3, *mul3, *avx2_3, *sse4_1_3): Use instead of v in constraints. * config/i386/mmx.md (mmx_pshufw_1, *vec_dupv4hi): Use Yw instead of xYw in constraints. * lib/target-supports.exp (check_effective_target_assembler_march_noavx512bw): New effective target. * gcc.target/i386/avx512vl-pr99321-1.c: New test.
[Bug other/99445] New: [11 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99445
Bug ID: 99445
Summary: [11 Regression] ICE in
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
Created attachment 50322
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50322&action=edit
preprocessed source, unreduced
seen with trunk 20210227, building the broker package.
$cat foo.ii
template class decay;
template struct implicit_conversions;
template
using implicit_conversions_t = typename implicit_conversions::type;
template struct response_type;
template
using response_type_t = typename response_type::type;
template
response_type::type>...>
response_type_t < typename Handle::signatures,
typename implicit_conversions::type>::type...
$ g++ -c -fchecking=2 --param=hash-table-verification-limit=1000 foo.ii
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
foo.ii: In substitution of ‘template using
response_type_t = typename response_type::type [with Ts = typename
Handle::signatures; Xs = {typename implicit_conversions::type>::type ...}]’:
foo.ii:12:66: required from here
foo.ii:7:7: internal compiler error: in hashtab_chk_error, at hash-table.c:137
7 | using response_type_t = typename response_type::type;
| ^~~
0x120e1f7 hashtab_chk_error()
../../src/gcc/hash-table.c:137
0x7863d0 hash_table::verify(spec_entry*
const&, unsigned int)
../../src/gcc/hash-table.h:1033
0x7863d0 hash_table::find_with_hash(spec_entry* const&, unsigned int)
../../src/gcc/hash-table.h:918
0x14cdeff lookup_template_class_1
../../src/gcc/cp/pt.c:9871
0x14fe6fe lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../src/gcc/cp/pt.c:10243
0x14fe6fe tsubst_aggr_type
../../src/gcc/cp/pt.c:13576
0x14e2f18 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:16037
0x15b98f7 tsubst_decl
../../src/gcc/cp/pt.c:14802
0x160ea6d instantiate_template_1
../../src/gcc/cp/pt.c:21118
0x160e884 instantiate_template(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.c:21177
0x14e3a38 instantiate_alias_template
../../src/gcc/cp/pt.c:21215
0x14e3a38 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:15444
0x14cf10d lookup_template_class_1
../../src/gcc/cp/pt.c:9944
0x14cc186 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../src/gcc/cp/pt.c:10243
0x14cc186 finish_template_type(tree_node*, tree_node*, int)
../../src/gcc/cp/semantics.c:3498
0x13e7bd3 cp_parser_template_id
../../src/gcc/cp/parser.c:17437
0x13ef262 cp_parser_class_name
../../src/gcc/cp/parser.c:24664
0x13e240f cp_parser_qualifying_entity
../../src/gcc/cp/parser.c:6994
0x13e240f cp_parser_nested_name_specifier_opt
../../src/gcc/cp/parser.c:6676
0x13ded32 cp_parser_nested_name_specifier
../../src/gcc/cp/parser.c:6920
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug gcov-profile/99441] [GCOV] Wrong coverage with complex "if" condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99441 --- Comment #1 from Andrew Pinski --- So line 27 has a short cutting conditional included, so technically it is executed 30 times, one for each side of the &&.
[Bug gcov-profile/99442] [GCOV] No coverage with "Segmentation fault (core dumped)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99442 --- Comment #1 from Andrew Pinski --- There is no way really to recover from a segfault in a manner that is suitable for all programs. The developer could set a sigv handler if they want to do any recovery from it. The library should not do it.
[Bug gcov-profile/99443] [GCOV] No coverage with "Aborted(core dumped)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99443 --- Comment #2 from Andrew Pinski --- This behavior might even be documented but I have not looked yet.
[Bug gcov-profile/99443] [GCOV] No coverage with "Aborted(core dumped)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99443 --- Comment #1 from Andrew Pinski --- I think this is expected behavior. Aborting should not dump the coverage file at all as it should be used for an really bad unexitable situation only.
[Bug gcov-profile/99444] New: [GCOV] Wrong coverage with "case" label in "switch" statement block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99444
Bug ID: 99444
Summary: [GCOV] Wrong coverage with "case" label in "switch"
statement block
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
$ cat test.c
int doit(int sel, int n, void *p) {
int *const p0 = p;
switch (sel) {
case 0:
do {
*p0 += *p0;
} while (--n);
return *p0 == 0;
default:
__builtin_abort();
}
}
int main() {
int v0;
v0 = 1;
doit(0, 3, &v0);
__builtin_exit(0);
}
$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
File 'test.c'
Lines executed:84.62% of 13
Creating 'test.c.gcov'
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
1:1:int doit(int sel, int n, void *p) {
1:2: int *const p0 = p;
-:3:
1:4: switch (sel) {
3:5: case 0:
-:6:do {
3:7: *p0 += *p0;
3:8:} while (--n);
1:9:return *p0 == 0;
#: 10: default:
#: 11:__builtin_abort();
-: 12: }
-: 13:}
-: 14:
1: 15:int main() {
-: 16: int v0;
1: 17: v0 = 1;
1: 18: doit(0, 3, &v0);
1: 19: __builtin_exit(0);
-: 20:}
-: 21:
Line #5 should only be executed once.
[Bug gcov-profile/99443] New: [GCOV] No coverage with "Aborted(core dumped)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99443
Bug ID: 99443
Summary: [GCOV] No coverage with "Aborted(core dumped)"
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
$ cat test.c
#include
#include
extern void abort(void);
#ifdef __x86_64__
#define EFLAGS_TYPE unsigned long long int
#else
#define EFLAGS_TYPE unsigned int
#endif
int main() {
printf("1\n");
EFLAGS_TYPE flags = 0xD7; /* 111010111b */
__writeeflags(flags);
flags = __readeflags();
printf("2\n");
if ((flags & 0xFF) != 0xD7)
abort();
printf("3\n");
#ifdef DEBUG
printf("PASSED\n");
#endif
}
$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
1
2
Aborted (core dumped)
test.gcda:cannot open data file, assuming not executed
File 'test.c'
Lines executed:0.00% of 8
Creating 'test.c.gcov'
File '/usr/local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/ia32intrin.h'
Lines executed:0.00% of 3
Creating 'ia32intrin.h.gcov'
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:-
-:0:Runs:0
-:1:#include
-:2:#include
-:3:
-:4:extern void abort(void);
-:5:
-:6:#ifdef __x86_64__
-:7:#define EFLAGS_TYPE unsigned long long int
-:8:#else
-:9:#define EFLAGS_TYPE unsigned int
-: 10:#endif
-: 11:
#: 12:int main() {
#: 13: printf("1\n");
#: 14: EFLAGS_TYPE flags = 0xD7; /* 111010111b */
-: 15: __writeeflags(flags);
#: 16: flags = __readeflags();
#: 17: printf("2\n");
#: 18: if ((flags & 0xFF) != 0xD7)
#: 19:abort();
#: 20: printf("3\n");
-: 21:#ifdef DEBUG
-: 22: printf("PASSED\n");
-: 23:#endif
-: 24:}
We can see that line #13,#14 were executed,which means that main function
executed too. However, no coverage generated.
[Bug gcov-profile/99442] New: [GCOV] No coverage with "Segmentation fault (core dumped)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99442
Bug ID: 99442
Summary: [GCOV] No coverage with "Segmentation fault (core
dumped)"
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
$ cat test.c
#include
char fixed_regs[0x0008];
int main() {
printf("PASSED\n");
return fixed_regs[0x000ff000];
}
$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
PASSED
Segmentation fault (core dumped)
test.gcda:cannot open data file, assuming not executed
File 'test.c'
Lines executed:0.00% of 3
Creating 'test.c.gcov'
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:-
-:0:Runs:0
-:1:#include
-:2:char fixed_regs[0x0008];
-:3:
#:4:int main() {
#:5:printf("PASSED\n");
#:6:return fixed_regs[0x000ff000];
-:7:}
Obviously, main function has been executed. However, no coverage information
generated.
[Bug gcov-profile/99441] New: [GCOV] Wrong coverage with complex "if" condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99441
Bug ID: 99441
Summary: [GCOV] Wrong coverage with complex "if" condition
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
$ cat test.c
typedef __SIZE_TYPE__ size_t;
typedef __UINTPTR_TYPE__ uintptr_t;
struct S {
int a;
unsigned short b;
int c, d, e;
long f, g, h;
int i, j;
};
static struct S *k;
static size_t l = 1;
int m;
static int bar(void) {
unsigned i;
int j;
if (k[0].c == 0) {
++m;
size_t n = l * 2;
struct S *o;
k = (struct S *)__builtin_realloc(k, sizeof(struct S) * n);
for (i = l; i < n; i++) {
void *p = (void *)&k[i];
int q = 0;
size_t r = sizeof(struct S);
if uintptr_t)p) % __alignof__(long)) == 0 && r % sizeof(long) == 0) {
long __attribute__((may_alias)) *s = (long *)p;
long *t = (long *)((char *)s + r);
while (s < t)
*s++ = 0;
} else
__builtin_memset(p, q, r);
}
}
return 1;
}
int main() {
k = (struct S *)__builtin_malloc(sizeof(struct S));
__builtin_memset(k, '\0', sizeof(struct S));
k->a = -1;
for (int i = 0; i < 15; ++i)
bar();
}
$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
libgcov profiling error:/home/wangyang/coverage/found
bug/gcc/test.gcda:overwriting an existing profile data with a different
timestamp
File 'test.c'
Lines executed:95.45% of 22
Creating 'test.c.gcov'
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:typedef __SIZE_TYPE__ size_t;
-:2:typedef __UINTPTR_TYPE__ uintptr_t;
-:3:
-:4:struct S {
-:5: int a;
-:6: unsigned short b;
-:7: int c, d, e;
-:8: long f, g, h;
-:9: int i, j;
-: 10:};
-: 11:static struct S *k;
-: 12:static size_t l = 1;
-: 13:int m;
-: 14:
15: 15:static int bar(void) {
-: 16: unsigned i;
-: 17: int j;
15: 18: if (k[0].c == 0) {
15: 19:++m;
15: 20:size_t n = l * 2;
-: 21:struct S *o;
15: 22:k = (struct S *)__builtin_realloc(k, sizeof(struct S) * n);
30: 23:for (i = l; i < n; i++) {
15: 24: void *p = (void *)&k[i];
15: 25: int q = 0;
15: 26: size_t r = sizeof(struct S);
30: 27: if uintptr_t)p) % __alignof__(long)) == 0 && r %
sizeof(long) == 0) {
15: 28:long __attribute__((may_alias)) *s = (long *)p;
15: 29:long *t = (long *)((char *)s + r);
120: 30:while (s < t)
105: 31: *s++ = 0;
-: 32: } else
#: 33:__builtin_memset(p, q, r);
-: 34:}
-: 35: }
15: 36: return 1;
-: 37:}
-: 38:
1: 39:int main() {
1: 40: k = (struct S *)__builtin_malloc(sizeof(struct S));
1: 41: __builtin_memset(k, '\0', sizeof(struct S));
1: 42: k->a = -1;
16: 43: for (int i = 0; i < 15; ++i)
15: 44:bar();
-: 45:}
Line #27 should only be executed 15 times
