[Bug inline-asm/101727] invalid symbol redefinition when -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101727 --- Comment #3 from zhan3299 at purdue dot edu --- (In reply to Jakub Jelinek from comment #2) > Note, the documentation talks about it: > https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Basic-Asm.html#Basic-Asm > Under certain circumstances, GCC may duplicate (or remove duplicates of) > your assembly code when optimizing. This can lead to unexpected duplicate > symbol errors during compilation if your assembly code defines symbols or > labels. > and > https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Extended-Asm.html#Extended-Asm > Under certain circumstances, GCC may duplicate (or remove duplicates of) > your assembly code when optimizing. This can lead to unexpected duplicate > symbol errors during compilation if your asm code defines symbols or labels. > Using ‘%=’ (see AssemblerTemplate) may help resolve this problem. > Normally people use numbered labels instead (leal 1f(...); ... 1: ...) or > one can use %=. Thanks for letting me know. I do apologize that I haven't gone through the whole document and bothering you by this invalid issue. Sorry about it.
[Bug inline-asm/101727] New: invalid symbol redefinition when -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101727
Bug ID: 101727
Summary: invalid symbol redefinition when -O2 enabled
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Following code can be successfully compiled with O0 optimization enabled, but
not O2.
Example code:
---
#include
int func() {
int filter;
asm volatile(
" leaq _filter(%%rip), %%rax\n"
" jmp _out\n"
"_filter:\n"
".ascii \"\\040\"\n"
"_out:"
: "=rax"(filter)
:
:);
return filter;
}
int main() {
printf("%#x", func());
return 0;
}
---
Error messages of O2:
---
ASM generation compiler returned: 0
: Assembler messages:
:7: Error: symbol `_filter' is already defined
:9: Error: symbol `_out' is already defined
Execution build compiler returned: 1
---
It affects 11.0, 12.0.
O2: https://godbolt.org/z/j9xG96fxW
O0: https://godbolt.org/z/b4TqddvYh
[Bug c/99211] New: gcc fails on program which overrides __builtin_clzll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99211
Bug ID: 99211
Summary: gcc fails on program which overrides __builtin_clzll
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
GCC fails to compile the attached code: https://godbolt.org/z/sdqq3M
One interesting thing is that, only when we override __builtin_clzll this issue
will occur. If we replace the __builtin_clzll as any other builtin function
(e.g., __builtin_expect), GCC will accept the program with a conflicting type
warning: https://godbolt.org/z/5c45T6
For other compilers,
Clang rejects such conflicts with built-in functions:
https://godbolt.org/z/9WzTKP
Icc accepts and successfully compiles it (with warnings):
https://godbolt.org/z/W4zK89
$ cat test.c
struct S {
int a;
};
struct S __builtin_clzll(long x) {
if (x == 1) {
struct S y = { .a = 1 };
return y;
} else {
struct S y = { .a = __builtin_clzll(1).a + 1 };
return y;
}
}
int main() {
return __builtin_clzll(10).a;
}
$ gcc test.c
test.c: In function '__builtin_clzll':
test.c:10:16: internal compiler error: in wide_int_to_tree_1, at tree.c:1644
10 | struct S y = { .a = __builtin_clzll(1).a + 1 };
|^
0x1a31d99 internal_error(char const*, ...)
???:0
0x6877ad fancy_abort(char const*, int, char const*)
???:0
0x9bed4a fold_build_call_array_loc(unsigned int, tree_node*, tree_node*, int,
tree_node**)
???:0
0x6e1010 build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*, tree_node*)
???:0
0x7322e9 c_parse_file()
???:0
0x7a02c2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/99207] New: #pragma pack(1) and __int128 lead to bad optimization under O2 and higher optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99207
Bug ID: 99207
Summary: #pragma pack(1) and __int128 lead to bad optimization
under O2 and higher optimization
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Following code behaves differently with different optimizations.
$ cat test.c
#pragma pack(1)
struct {
char a;
__int128 b;
} c;
__int128 *d =
int main() { *d = 0; }
In short, with O2 and higher optimization, gcc tries to use xmm register to
initialize *d. However, as #pragma pack(1) enforces a different alignments, xmm
operation will trigger a segment fault.
O0 (program returns 0): https://godbolt.org/z/nc997z
O1 (program returns 0): https://godbolt.org/z/GqGfnf
O2 (program returns 139): https://godbolt.org/z/4PWKMo
O3 (program returns 139): https://godbolt.org/z/Y81sKK
Os (program returns 139): https://godbolt.org/z/M3KGnh
With asan, we can get: https://godbolt.org/z/34oW7e
AddressSanitizer:DEADLYSIGNAL
=
==1==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x004010ae bp
0x sp 0x7ffd361619b8 T0)
==1==The signal is caused by a READ memory access.
==1==Hint: this fault was caused by a dereference of a high value address (see
register values below). Dissassemble the provided pc to learn which register
was used.
#0 0x4010ae in main example.c:10
#1 0x7f8c4b3b60b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#2 0x40111d in _start (/app/output.s+0x40111d)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV example.c:10 in main
==1==ABORTING
[Bug sanitizer/99168] inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168 --- Comment #4 from zhan3299 at purdue dot edu --- (In reply to Martin Liška from comment #3) > Very interesting issue, the failure is caused by IPA ICF that merges 2 > variables with different alignments. I've got a patch candidate. Hi, just curious because I am also studying the source code of GCC. Is this issue is about sanitizer or optimization?
[Bug c/99198] New: when combinating nested function and __builtin_call_with_static_chain, optimization triggers an internal compiler error (verify_gimple)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99198
Bug ID: 99198
Summary: when combinating nested function and
__builtin_call_with_static_chain, optimization
triggers an internal compiler error (verify_gimple)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Following code is reduced by c-reduce and meaningless, but seems valid as gcc
-O0 accept it.
Under O0, the program can be successfully compiled
(https://godbolt.org/z/zvGxTP); but under O1, it triggers an internal compiler
error (https://godbolt.org/z/xbvrs6). Besides, any version prior version 11.0
has no such problem.
$ cat test.c
int main() {
void f() {}
__builtin_call_with_static_chain(f(), );
return 0;
}
$ gcc --version
gcc (Compiler-Explorer-Build) 11.0.0 20210221 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -O0 test.c # Execution build compiler returned: 0
$ gcc -O1 test.c
: In function 'main':
:1:5: error: static chain with function that doesn't use one
1 | int main() {
| ^~~~
f (); [static-chain: f]
during GIMPLE pass: *warn_unused_result
:1:5: internal compiler error: 'verify_gimple' failed
0x1a31d99 internal_error(char const*, ...)
???:0
0xdc218d verify_gimple_in_seq(gimple*)
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/99156] __builtin_expect affects the interpretation of its first operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99156 --- Comment #2 from zhan3299 at purdue dot edu --- (In reply to Martin Liška from comment #1) > Yes, I can confirm the issue. Thanks for the report. Many thanks for your prompt reply. Additionally, I have to give credit to Richard Smith for finding the root cause.
[Bug c/99168] inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168 --- Comment #1 from zhan3299 at purdue dot edu --- If we resolved the conflicts on "aligned", it would behave normally. I feel like the ASAN is confused by the "aligned" somehow. Should it have thrown some warnings?
[Bug c/99168] New: inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168
Bug ID: 99168
Summary: inconsistent behavior on -O0 and -O2 with ASAN on
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
I am not sure whether the following problem is caused by ASAN or O2.
Following code has different behaviors between "-fsanitize=address -O0" and
"-fsanitize=address -O2"
It affects my local 7.5.0, 10.2.0, and 11.0.0 on godbolt.
O0 (succ): https://godbolt.org/z/zMKP6K
O1 (succ): https://godbolt.org/z/Yf3oP7
O2 (fail): https://godbolt.org/z/erahvc
O3 (fail): https://godbolt.org/z/7zaqaf
Os (fail): https://godbolt.org/z/38e6xc
-
$ cat test.c
#include
struct my_struct {
unsigned long volatile x;
} __attribute__((aligned(128)));
static int k[5][6] = {};
static struct my_struct s1 = {0UL};
static struct my_struct s2 __attribute__((aligned(32))) = {0UL};
int main() {
int i, j;
for (i = 0; i < 5; i++) {
for (j = 0; j < 6; j++) {
printf("%d\n", k[i][j]);
}
}
printf("%lu\n", s1.x);
printf("%lu\n", s2.x);
return 0;
}
$ gcc test.c -Wall -fsanitize=address -O0 -o g0.out
# no any warning or error
$ gcc test.c -Wall -fsanitize=address -O2 -o g2.out
# no any warning or error
$ ./g0.out
... # normal output
$ ./g2.out
=
==26165==ERROR: AddressSanitizer: global-buffer-overflow on address
0x55a5cf268184 at pc 0x55a5cf267201 bp 0x7ffd23b80f60 sp 0x7ffd23b80f50
READ of size 4 at 0x55a5cf268184 thread T0
#0 0x55a5cf267200 in main
(/root/docker_share/csmith/gcc_self_10/g2.out+0x1200)
#1 0x7efea78c10b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#2 0x55a5cf26726d in _start
(/root/docker_share/csmith/gcc_self_10/g2.out+0x126d)
0x55a5cf268184 is located 4 bytes inside of global variable 'k' defined in
'test.c:7:12' (0x55a5cf268180) of size 120
0x55a5cf268184 is located 4 bytes to the right of global variable 's2' defined
in 'test.c:11:25' (0x55a5cf268100) of size 128
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/docker_share/csmith/gcc_self_10/g2.out+0x1200) in main
Shadow bytes around the buggy address:
0x0ab539e44fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e44ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e45000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e45010: 04 f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9
0x0ab539e45020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ab539e45030:[f9]f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 f9
0x0ab539e45040: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e45050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e45060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e45070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e45080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
Shadow gap: cc
[Bug c/99156] New: __builtin_expect affects the interpretation of its first operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99156
Bug ID: 99156
Summary: __builtin_expect affects the interpretation of its
first operand
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
I hope it does not bother. I try to refer to a bug in llvm which may also
affect gcc.
Following are copied-and-pasted from the discussion about a similar bug in
clang (https://bugs.llvm.org/show_bug.cgi?id=49239#c3).
Specifically,
> int maybe_vla(int n) {
>goto label;
>int arr[({0;})];
> label:
>return sizeof(arr);
> }
>
> ... is rejected by both Clang and GCC because the statement-expression is not
> an ICE, but
>
> int maybe_vla(int n) {
> goto label;
> int arr[__builtin_expect(({0;}), 0)];
> label:
> return sizeof(arr);
> }
>
> ... is accepted. This seems like a bug in both compilers to me:
> __builtin_expect isn't supposed to affect the interpretation of its first
> operand, and presumably shouldn't be weakening the strict ICE checks.
case 1: https://godbolt.org/z/zWGEfx
case 2: https://godbolt.org/z/bejfcc
[Bug inline-asm/99015] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99015 --- Comment #1 from zhan3299 at purdue dot edu --- It seems clang at any optimization level can compile this. GCC at -O0 can also compile it.
[Bug inline-asm/99015] New: ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99015
Bug ID: 99015
Summary: ICE: Max. number of generated reload insns per insn is
achieved (90)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Another inline-asm issue causes an ICE.
--- poc.c starts ---
int main() {
asm("" : : "fq"(.100));
}
--- poc.c ends ---
The version of GCC is 10.2.0 x86-64, and running 'gcc -O1 poc.c ' can trigger
the ICE.
--- error trace starts ---
$ gcc -O1 poc.c
during RTL pass: reload
test.c: In function ‘main’:
test.c:3:1: internal compiler error: maximum number of generated reload insns
per insn achieved (90)
3 | }
| ^
0x9fb0c0 lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:4952
0x9e9314 lra(_IO_FILE*)
../../gcc/gcc/lra.c:2440
0x9a7201 do_reload
../../gcc/gcc/ira.c:5523
0x9a7201 execute
../../gcc/gcc/ira.c:5709
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug inline-asm/98991] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98991 --- Comment #4 from zhan3299 at purdue dot edu --- Seems '-fpermissive' is useless. I can reproduce the ICE simply via 'gcc poc.cc'
[Bug inline-asm/98991] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98991
--- Comment #3 from zhan3299 at purdue dot edu ---
(In reply to Martin Liška from comment #1)
> Is it a valid or invalid code, please?
Hi, sorry for the confusion. I used a simple delta debugging to reduce the
test-case, and it seems very confused.
Currently, I use C-Reduce to get a simple test-case:
--- poc.cc starts ---
void a() {
float b;
asm("" : "=rmf"(b) : "0"(0));
}
--- poc.cc ends ---
run 'gcc poc.cc -fpermissive' and we can get the same ICE.
--- error trace starts ---
during RTL pass: reload
poc.cc: In function 'void a()':
poc.cc:5:1: internal compiler error: maximum number of generated reload insns
per insn achieved (90)
5 | }
| ^
0x20cb324 lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:4951
0x20ab2c8 lra(_IO_FILE*)
../../gcc/gcc/lra.c:2440
0x1ff80de do_reload()
../../gcc/gcc/ira.c:5523
0x1ff80de (anonymous namespace)::pass_reload::execute(function*)
../../gcc/gcc/ira.c:5709
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/98993] New: Potential memory problem in GCC compiled with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98993
Bug ID: 98993
Summary: Potential memory problem in GCC compiled with ASAN on
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Created attachment 50141
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50141=edit
poc.cc
Hi all,
Hope I do not bother too much.
I got a crafted program which will trigger an internal compiler error in GCC
10.2.0 compiled with ASAN. Note that it means the GCC is compiled with ASAN,
instead of GCC compiling the crafted program with ASAN.
The crafted program is named as poc.cc, and the ICE can be triggered by "g++
poc.cc".
It is also noting that when the GCC is not compiled with ASAN, the ICE cannot
be reproduced. As such, I guess there is a potential memory problem. Maybe I
did something wrong here, and it is very appreciated if anyone can correct me.
Again, I do hope I do not bother too much, and apologize in advance.
Followings are the detailed information.
--- poc.cc starts ---
constexpr _([]{struct v __builtin_unre0c00ble();goto l union s
__builtin_unre0c00ble();l:
--- poc.cc ends ---
--- md5 of poc.cc starts ---
b3b9e2c84ed1d7ea07b0ead058e3340d
--- md5 of poc.cc ends ---
--- error trace starts ---
$ ./xg++ poc.cc
poc.cc:1:11: error: ISO C++ forbids declaration of ‘_’ with no type
[-fpermissive]
1 | constexpr _([]{struct v __builtin_unre0c00ble();goto l union s
__builtin_unre0c00ble();l:
| ^
poc.cc: In lambda function:
poc.cc:1:55: error: expected ‘;’ before ‘union’
1 | constexpr _([]{struct v __builtin_unre0c00ble();goto l union s
__builtin_unre0c00ble();l:
| ^~
| ;
poc.cc:1:64: error: conflicting declaration of C function ‘::s
__builtin_unre0c00ble()’
1 | constexpr _([]{struct v __builtin_unre0c00ble();goto l union s
__builtin_unre0c00ble();l:
|
^
poc.cc:1:25: note: previous declaration ‘::v __builtin_unre0c00ble()’
1 | constexpr _([]{struct v __builtin_unre0c00ble();goto l union s
__builtin_unre0c00ble();l:
| ^
poc.cc:1:88: internal compiler error: Segmentation fault
1 | constexpr _([]{struct v __builtin_unre0c00ble();goto l union s
__builtin_unre0c00ble();l:
|
^
0x1b279d0 crash_signal(int)
../../gcc/gcc/toplev.c:328
0xd999f8 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3407
0xea9b02 decl_jump_unsafe(tree_node*)
../../gcc/gcc/cp/decl.c:3235
0xf0b630 check_previous_goto_1(tree_node*, cp_binding_level*, tree_node*, bool,
unsigned int const*)
../../gcc/gcc/cp/decl.c:3299
0xf0b4c0 check_previous_goto(tree_node*, named_label_use_entry*)
../../gcc/gcc/cp/decl.c:3382
0xec233f define_label_1(unsigned int, tree_node*)
../../gcc/gcc/cp/decl.c:3569
0xec206b define_label(unsigned int, tree_node*)
../../gcc/gcc/cp/decl.c:3582
0x11349eb finish_label_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:1721
0x101c468 cp_parser_label_for_labeled_statement(cp_parser*, tree_node*)
../../gcc/gcc/cp/parser.c:11634
0x101bc43 cp_parser_statement(cp_parser*, tree_node*, bool, bool*,
vec*, unsigned int*)
../../gcc/gcc/cp/parser.c:11430
0x101b91a cp_parser_statement_seq_opt(cp_parser*, tree_node*)
../../gcc/gcc/cp/parser.c:11843
0x101b647 cp_parser_compound_statement(cp_parser*, tree_node*, int, bool)
../../gcc/gcc/cp/parser.c:11793
0x1025da4 cp_parser_function_body(cp_parser*, bool)
../../gcc/gcc/cp/parser.c:23079
0x102deb9 cp_parser_lambda_body(cp_parser*, tree_node*)
../../gcc/gcc/cp/parser.c:11223
0x101a145 cp_parser_lambda_expression(cp_parser*)
../../gcc/gcc/cp/parser.c:10593
0x1017e01 cp_parser_primary_expression(cp_parser*, bool, bool, bool, bool,
cp_id_kind*)
../../gcc/gcc/cp/parser.c:5416
0x101258c cp_parser_postfix_expression(cp_parser*, bool, bool, bool, bool,
cp_id_kind*)
../../gcc/gcc/cp/parser.c:7257
0x1006c52 cp_parser_unary_expression(cp_parser*, cp_id_kind*, bool, bool, bool)
../../gcc/gcc/cp/parser.c:8560
0x100595e cp_parser_cast_expression(cp_parser*, bool, bool, bool, cp_id_kind*)
../../gcc/gcc/cp/parser.c:9458
0x1002dd5 cp_parser_binary_expression(cp_parser*, bool, bool, bool,
cp_parser_prec, cp_id_kind*)
../../gcc/gcc/cp/parser.c:9561
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any
[Bug c++/98991] New: ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98991
Bug ID: 98991
Summary: ICE: Max. number of generated reload insns per insn is
achieved (90)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Created attachment 50140
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50140=edit
poc.cc
Hi all,
I am not sure whether it is indeed an ICE, so I do apologize in advance for any
possible inconvenience.
I have a file generated by my little toy fuzzer, named poc.cc.
When I compile it with: "g++ poc.cc -fpermissive", I got an "internal compiler
error: Max. number of generated reload insns per insn is achieved (90)".
Followings are the detailed information.
--- poc.cc starts ---
namespace{thread_local;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
--- poc.cc ends ---
--- md5 of poc.cc starts ---
c11f34bb78474a2a8bdcb5c5de6d19a2
--- md5 of poc.cc ends ---
--- error trace starts ---
$ ./xg++ poc.cc -fpermissive
poc.cc:1:11: warning: declaration does not declare anything [-fpermissive]
1 | namespace{thread_local;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
| ^~~~
poc.cc:1:42: warning: ISO C++ forbids declaration of ‘n’ with no type
[-fpermissive]
1 | namespace{thread_local;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
| ^
poc.cc:1:44: warning: ‘e’ attribute directive ignored [-Wattributes]
1 | namespace{thread_local;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
|^
poc.cc: In function ‘int {anonymous}::n()’:
poc.cc:1:46: warning: declaration does not declare anything [-fpermissive]
1 | namespace{thread_local;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
| ^~~
poc.cc:1:50: warning: declaration does not declare anything [-fpermissive]
1 | namespace{thread_local;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
| ^~~~
poc.cc:1:237: warning: using rvalue as lvalue [-fpermissive]
1 | ocal;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
|
^
poc.cc:1:338: warning: no return statement in function returning non-void
[-Wreturn-type]
1 |
[Bug c++/98972] internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98972 --- Comment #3 from Zhuo Zhang --- I reduced the test-case, and the simplest test-case should be: --- crash1.cc starts --- constexpr p([](register const signed struct s; --- crash1.cc ends --- The bug is also reproduced on the commit 8d0737d8f4b10bffe0411507ad2dc21ba7679883. Hope it can help. Thanks.
[Bug c++/98972] internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98972 --- Comment #2 from Zhuo Zhang --- (In reply to Martin Liška from comment #1) > Thank you for the report. Actually, it's an invalid code and we do have a > lot of error recovery ICEs. > Or do you have an original test-case that is a valid C++ code? Hi, thanks for your prompt reply. I think I do not have a valid C++ code, as this test-case is generated by fuzzer.
[Bug c++/98972] New: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98972
Bug ID: 98972
Summary: internal compiler error: Segmentation fault signal
terminated program cc1plus
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Hi,
I have a crafted .cc program named crash1.cc. When I use both gcc-10 and g++-10
compile it, an internal compiler error occurs. I run it on Ubuntu 20.04 x64.
Details are attached.
--- crash1.cc starts
constexpr const short f() { return 1.2345 * 0 / 01e9; try { enum s { } a[] =
{ 0 };; __attribute__ ((noinline(2))); a || -1ULL; } catch (int x) { int a[] =
{ 0 }; struct s { }; struct t: s {} ; try { (x %= 0); (x == 0); l:; } catch
(int x) { auto x = f(); struct s {}; struct l: s {} t; 0 - 0; 0 + 0; } [] (
union s {} ) {};f; (sizeof(x) == __builtin_popcount(x)); if (sizeof ((void)
sizeof(char[1 - 2 * x]))) { register const ; extern void; ; asm("" : "=a"(x),
"=d"(x) : "r" (x), "0" (x), "1" (x)); void; } else { for (unsigned int i =
f(); i < .1; i++) { for (unsigned int i = (x == 0); i < & i++) { ;
__builtin_inf(); __builtin_alloca(1); alignof(x); ; class s { } ; asm
volatile ("" : : : ); ; }; int a[] = {};; x; ; class s { } ; const ; x; ~-1
- 0; }; 0 << 0 >> 0; s; __builtin_constant_p(2); ;; struct s restrict ;
struct t: s {} ; }; } class & { } ;; } void T( int *x) { f(); }
--- crash1.cc ends ---
--- g++-10 version starts ---
root@c0d53067e55a:~/docker_share/gcc# g++-10 --version
g++-10 (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
root@c0d53067e55a:~/docker_share/gcc# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04.2 LTS
Release:20.04
Codename: focal
--- g++-10 version ends ---
--- g++-10 crash log starts ---
root@c0d53067e55a:~/docker_share/gcc# g++-10 crash1.cc
crash1.cc: In function 'constexpr const short int f()':
crash1.cc:1:55: warning: 'try' in 'constexpr' function only available with
'-std=c++2a' or '-std=gnu++2a'
1 | constexpr const short f() { return 1.2345 * 0 / 01e9; try { enum s {
} a[] = { 0 };; __attribute__ ((noinline(2))); a || -1ULL; } catch (int x) {
int a[] = { 0 }; struct s { }; struct t: s {} ; try { (x %= 0); (x == 0); l:;
} catch (int x) { auto x = f(); struct s {}; struct l: s {} t; 0 - 0; 0 + 0; }
[] ( union s {} ) {};f; (sizeof(x) == __builtin_popcount(x)); if (sizeof
((void) sizeof(char[1 - 2 * x]))) { register const ; extern void; ; asm("" :
"=a"(x), "=d"(x) : "r" (x), "0" (x), "1" (x)); void; } else { for (unsigned
int i = f(); i < .1; i++) { for (unsigned int i = (x == 0); i < & i++) { ;
__builtin_inf(); __builtin_alloca(1); alignof(x); ; class s { } ; asm
volatile ("" : : : ); ; }; int a[] = {};; x; ; class s { } ; const ; x; ~-1
- 0; }; 0 << 0 >> 0; s; __builtin_constant_p(2); ;; struct s restrict ;
struct t: s {} ; }; } class & { } ;; } void T( int *x) { f(); }
| ^~~
crash1.cc:1:83: error: invalid conversion from 'int' to 'f()::s' [-fpermissive]
1 | constexpr const short f() { return 1.2345 * 0 / 01e9; try { enum s {
} a[] = { 0 };; __attribute__ ((noinline(2))); a || -1ULL; } catch (int x) {
int a[] = { 0 }; struct s { }; struct t: s {} ; try { (x %= 0); (x == 0); l:;
} catch (int x) { auto x = f(); struct s {}; struct l: s {} t; 0 - 0; 0 + 0; }
[] ( union s {} ) {};f; (sizeof(x) == __builtin_popcount(x)); if (sizeof
((void) sizeof(char[1 - 2 * x]))) { register const ; extern void; ; asm("" :
"=a"(x), "=d"(x) : "r" (x), "0" (x), "1" (x)); void; } else { for (unsigned
int i = f(); i < .1; i++) { for (unsigned int i = (x == 0); i < & i++) { ;
__builtin_inf(); __builtin_alloca(1); alignof(x); ; class s { } ; asm
volatile ("" : : : ); ; }; int a[] = {};; x; ; class s { } ; const ; x; ~-1
- 0; }; 0 << 0 >> 0; s; __builtin_constant_p(2); ;; struct s restrict ;
struct t: s {} ; }; } class & { } ;; } void T( int *x) { f(); }
|
^
|
|
|
int
crash1.cc:1:89: warning: attributes at the beginning of statement are ignored
[-Wattributes]
1 | constexpr const short f() { return 1.2345 * 0 / 01e9; try { enum s {
} a[] = { 0 };; __attribute__ ((noinline(2))); a || -1ULL; } catch (int x) {
int a[] = { 0 }; struct s { }; struct t: s {} ; try { (x %= 0); (x == 0); l:;
} catch (int
