[Bug c/94053] New: Segmentation fault in default Optimization, but works well in O1 ~ Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94053
Bug ID: 94053
Summary: Segmentation fault in default Optimization, but works
well in O1 ~ Os
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, The code test.c
#include
#include
void foo(int* a ) {
a[-1]=1;
}
int main (int argc, char* argv[]) {
int size= 10;
printf("%d\n", size);
int array[size];
memset(array,0,size*sizeof(int));
foo(array);
return 0;
}
is getting "Segmentation fault" when I use `gcc test.c` to compile and
`./a.out`
to execute it (in Ubuntu 16.04, gcc 8.1.0).
I know that the index of an array is -1 and not suitable, but when I add -O1,
-O2, -O3, or -Os to compile it, then the fault is gone.
[Bug c/94055] New: Segmentation fault in memet function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94055
Bug ID: 94055
Summary: Segmentation fault in memet function
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, this code test.c
#include
#include
#include
int main (int argc, char* argv[]) {
int size = 1000;
printf("%d \n", size);
int array[size];
memset(array,0,size*sizeof(int));
return 0;
}
get "Segmentation fault" when I use a larger size, that is to say, smaller size
is ok (in ubuntu 16.04, gcc 8.1.0).
Surprisingly, when I use O1, O2, O3, or Os to compile, it works well.
[Bug c/94055] Segmentation fault in memet function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94055 --- Comment #3 from Haoxin Tu --- I see. Thank you for your responding. Have a good day!
[Bug c/93849] New: 'Segmentation fault' in the special index for an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93849
Bug ID: 93849
Summary: 'Segmentation fault' in the special index for an array
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, I am developing a random c generation tool to find c compiler bugs.
I found an interesting code that compiles successfully but get a "Segmentation
fault" result when executing it.
The c code is
void foo(int* a ) {
a[6]=1;
}
int main (int argc, char* argv[]) {
int array[] = {0};
foo(array);
return 0;
}
My compile command is "gcc test.cc" and it succeeds. Then I execute it using
"./a.out" but I got a "Segmentation fault" error.
I know we should initialize an array before using it. But the most interesting
thing is that only an index of 6 in an array can trigger the error, other index
is fine for execution.
I test the code in GCC 5.4.0 in ubuntu 16.04.
[Bug c/93850] New: 'stack smashing detected' in the special index for an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93850
Bug ID: 93850
Summary: 'stack smashing detected' in the special index for an
array
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, I am developing a random c generation tool to find c compiler bugs.
I found an interesting code that compiles successfully but get a "stack
smashing detected" error when executing it.
The c code is
void foo(int* a ) {
a[2]=1;
}
int main (int argc, char* argv[]) {
int array[] = {0};
foo(array);
return 0;
}
My compile command is "gcc test.cc" and it succeeds. Then I execute it using
"./a.out" but I got a
"*** stack smashing detected ***: ./a.out terminated
Aborted"
error.
I know we should initialize an array before using it. But the most interesting
thing is that only an index of 2 in an array can trigger the error, other index
is fine for execution.
I test the code in GCC 5.4.0 in ubuntu 16.04.
[Bug c/94686] New: internal compiler error: in gimplify_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94686
Bug ID: 94686
Summary: internal compiler error: in gimplify_expr
Product: gcc
Version: 6.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, the test.c (reduced by C-Reduce)
#include
int a = 0,b = 0;
int main(){
int c = (int)(long)(b * 0 >= a & b * 0 >= a);
return 0;
}
$gcc-6 test.c
then got the ICE error
test.c: In function ‘main’:
test.c:6:33: internal compiler error: in gimplify_expr, at gimplify.c:11192
int c = (int)(long)(b * 0 >= a & b * 0 >= a);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
My GCC version is
$gcc-6 --version
gcc-6 (Ubuntu 6.5.0-2ubuntu1~18.04) 6.5.0 20181026
Copyright (C) 2017 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.
[Bug c/94322] New: Detected memory leaks while using clang AddressSanitizer to build GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94322 Bug ID: 94322 Summary: Detected memory leaks while using clang AddressSanitizer to build GCC Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- Hi, I use clang with AddressSanitizer and detected memory leaks while building GCC. The SUMMARY are: = ==7174==ERROR: LeakSanitizer: detected memory leaks Direct leak of 112 byte(s) in 1 object(s) allocated from: #0 0x4debb0 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4debb0) #1 0x521a45 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x521a45) #2 0x51e2a9 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51e2a9) #3 0x51a8e5 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51a8e5) #4 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Direct leak of 23 byte(s) in 1 object(s) allocated from: #0 0x4de998 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4de998) #1 0x5219c1 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x5219c1) #2 0x521b7d (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x521b7d) #3 0x51bb89 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51bb89) #4 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Indirect leak of 13368 byte(s) in 456 object(s) allocated from: #0 0x4de998 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4de998) #1 0x5219c1 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x5219c1) #2 0x521b7d (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x521b7d) #3 0x51a9f0 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51a9f0) #4 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Indirect leak of 8168 byte(s) in 1 object(s) allocated from: #0 0x4debb0 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4debb0) #1 0x521a45 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x521a45) #2 0x520384 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x520384) #3 0x51f5af (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51f5af) #4 0x51ab44 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51ab44) #5 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Indirect leak of 7296 byte(s) in 456 object(s) allocated from: #0 0x4de998 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4de998) #1 0x5219c1 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x5219c1) #2 0x51a9e5 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51a9e5) #3 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) SUMMARY: AddressSanitizer: 28967 byte(s) leaked in 915 allocation(s). Makefile:2504: recipe for target 's-tm-texi' failed make[3]: *** [s-tm-texi] Error 1 make[3]: *** Waiting for unfinished jobs 31 warnings generated. 19 warnings generated. rm fsf-funding.pod gcov.pod gpl.pod cpp.pod gcc.pod make[3]: Leaving directory '/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc' Makefile:4617: recipe for target 'all-stage1-gcc' failed make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory '/home/haoxin/corpus-compilers/clang-build-gcc8/build' Makefile:24352: recipe for target 'stage1-bubble' failed make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory '/home/haoxin/corpus-compilers/clang-build-gcc8/build' Makefile:944: recipe for target 'all' failed Here are my instructions: $export FUZZ_FLAGS="-O2 -fno-omit-frame-pointer -g -fsanitize=address -fsanitize-coverage=edge,trace-pc-guard,indirect-calls,trace-cmp,trace-div,trace-gep" $CC="clang $FUZZ_FLAGS" CXX="clang++ $FUZZ_FLAGS" ../configure $make -j4 Without FUZZ_FLAGS, clang can build GCC well. I used GCC-8.1.0, clang-6.0, and Ubuntu16.04.
[Bug c++/91867] Internal compiler error in simple for(auto) loop when using -std=c++11 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91867
Haoxin Tu changed:
What|Removed |Added
CC||haoxintu at gmail dot com
--- Comment #4 from Haoxin Tu ---
I also find this in a simple code.
test.cc
include
int main(){
for(int i:{});
}
$g++ --version
g++ (GCC) 10.0.1 20200420 (experimental)
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.
$g++ -fconcepts -std=c++11 test.cc
test.cc: In function ‘int main()’:
test.cc:3:13: internal compiler error: in type_unification_real, at
cp/pt.c:21752
3 | for(int i:{});
| ^
0x6bf3ed type_unification_real
../../gcc/cp/pt.c:21752
0xa427ff do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.c:28954
0x9e4025 build_range_temp
../../gcc/cp/parser.c:12516
0x9ee792 cp_convert_range_for(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int, bool, unsigned short)
../../gcc/cp/parser.c:12616
0x9f40b0 cp_parser_range_for
../../gcc/cp/parser.c:12498
0xa1ea0a cp_parser_for
../../gcc/cp/parser.c:12354
0xa1ea0a cp_parser_iteration_statement
../../gcc/cp/parser.c:12902
0xa00ccd cp_parser_statement
../../gcc/cp/parser.c:11353
0xa022d8 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11835
0xa023b8 cp_parser_compound_statement
../../gcc/cp/parser.c:11785
0xa198b5 cp_parser_function_body
../../gcc/cp/parser.c:23060
0xa198b5 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:23111
0xa1cbed cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:28993
0xa1dbd9 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:28909
0xa1dbd9 cp_parser_init_declarator
../../gcc/cp/parser.c:20667
0x9fe992 cp_parser_simple_declaration
../../gcc/cp/parser.c:13731
0xa27ba2 cp_parser_declaration
../../gcc/cp/parser.c:13430
0xa2832a cp_parser_translation_unit
../../gcc/cp/parser.c:4731
0xa2832a c_parse_file()
../../gcc/cp/parser.c:43972
0xb3d5eb c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/96623] New: [10/11 Regression] ICE in inject_parm_decls, at cp/parser.c:23893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96623
Bug ID: 96623
Summary: [10/11 Regression] ICE in inject_parm_decls, at
cp/parser.c:23893
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Input:
//small.cc
struct A{
void a(){
struct B {
void b () noexcept();
};
}
};
Command:
g++ small.cc
Output:
small.cc: In member function ‘void A::a()’:
small.cc:5:25: internal compiler error: in inject_parm_decls, at
cp/parser.c:23893
5 | };
| ^
0x67450f inject_parm_decls
../../gcc/cp/parser.c:23893
0x67450f cp_parser_class_specifier_1
../../gcc/cp/parser.c:24239
0x9d3143 cp_parser_class_specifier
../../gcc/cp/parser.c:24308
0x9d3143 cp_parser_type_specifier
../../gcc/cp/parser.c:17811
0x9d40be cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14436
0x9d4e71 cp_parser_simple_declaration
../../gcc/cp/parser.c:13690
0x9d6fdd cp_parser_declaration_statement
../../gcc/cp/parser.c:13249
0x9d7c67 cp_parser_statement
../../gcc/cp/parser.c:11555
0x9d8ccd cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11921
0x9d8da8 cp_parser_compound_statement
../../gcc/cp/parser.c:11871
0x9f0ee5 cp_parser_function_body
../../gcc/cp/parser.c:23170
0x9f0ee5 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:23221
0x9f4510 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:29117
0x9f590c cp_parser_late_parsing_for_member
../../gcc/cp/parser.c:30019
0x9d225b cp_parser_class_specifier_1
../../gcc/cp/parser.c:24284
0x9d3143 cp_parser_class_specifier
../../gcc/cp/parser.c:24308
0x9d3143 cp_parser_type_specifier
../../gcc/cp/parser.c:17811
0x9d40be cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14436
0x9d4e71 cp_parser_simple_declaration
../../gcc/cp/parser.c:13690
0xa002fe cp_parser_declaration
../../gcc/cp/parser.c:13510
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
GCC-10 compiles this code ok, and I test in GCC-trunk-20200808.
[Bug c++/95354] GCC misuse "nonnull-attribute" option and can not detect it as UB as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95354
--- Comment #5 from Haoxin Tu ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Haoxin Tu from comment #3)
> > I see. Are there any cases that can trigger the UB of nonnull-attribute? I
> > doubt the usage of “-fsanitize=nonnull-attribute” in GCC...
>
> Yes, just use the attribute correctly.
>
> Using:
>
> __attribute__((nonnull)) void has_nonnull_argument(int *p) {
> ;
> }
>
> will cause UBsan to diagnose it:
>
> nn.cc:7:25: runtime error: null pointer passed as argument 1, which is
> declared to never be null
Thanks, Jonathan, Got it ~
[Bug c++/95334] New: GCC detect missing signed-integer-overflow when add "const"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95334
Bug ID: 95334
Summary: GCC detect missing signed-integer-overflow when add
"const"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code test1.cc
#include
#include
wchar_t g_wchar = 0;
int g_int = -1975564288;
int l_int = -1227761344;
int main () {
g_wchar = l_int + g_int;
std::cout << g_wchar << std::endl;
std::cout << "WCHAR_MIN = " << WCHAR_MIN << std::endl;
std::cout << "WCHAR_MAX = " << WCHAR_MAX << std::endl;
return 0;
}
GCC can detect UB correctly
$g++ -w -fsanitize=signed-integer-overflow ; ./a.out
test1.cc:9:21: runtime error: signed integer overflow: -1227761344 +
-1975564288 cannot be represented in type 'int'
1091641664
WCHAR_MIN = -2147483648
WCHAR_MAX = 2147483647
But in this case test2.cc add "const" for int
#include
#include
wchar_t g_wchar = 0;
const int g_int = -1975564288;
const int l_int = -1227761344;
int main () {
g_wchar = l_int + g_int;
std::cout << g_wchar << std::endl;
std::cout << "WCHAR_MIN = " << WCHAR_MIN << std::endl;
std::cout << "WCHAR_MAX = " << WCHAR_MAX << std::endl;
return 0;
}
GCC detect nothing.
$g++ -w -fsanitize=signed-integer-overflow test2.cc; ./a.out
1091641664
WCHAR_MIN = -2147483648
WCHAR_MAX = 2147483647
My g++ version
$g++ --version
g++ (GCC) 11.0.0 20200526 (experimental)
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.
I have tested them in recent GCC versions including GCC-8, GCC-9, GCC-10, they
have the same symptom as well.
I also test them in clang-trunk, above two testcases can be detected as "signed
integer overflow".
[Bug middle-end/95326] GCC can not detect signed-integer-overflow correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95326 --- Comment #3 from Haoxin Tu --- Would GCC shorten the multiple to be other types early as well? I also find some cases in "short" type with the same symptom. I am still testing now and don't know there are any cases in rest of types(such as char, int, long...) have the problem. By the way, should I file a new bug report when I found another type (for example,int) that GCC can not detect the signed-integer-overflow UB issues?
[Bug c++/95326] New: UBsan can not detect signed-integer-overflow correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95326
Bug ID: 95326
Summary: UBsan can not detect signed-integer-overflow correctly
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This case example.cpp
#include
volatile wchar_t g_volatile_wchar = 2082494266;
volatile unsigned short g_volatile_ushort = 31503U;
int main () {
unsigned long l_var_ulong = 526562505494506029UL;
const wchar_t l_const_wchar = 1188246531;
g_volatile_ushort = l_var_ulong + l_const_wchar * g_volatile_wchar;
std::cout << "hello" << std::endl;
return 0;
}
can not detect signed-integer-overflow runtime error in gcc-trunk
$g++ -fsanitize=signed-integer-overflow example.cpp ; ./a.out
hello
But in clang-trunk
$clang++ -fsanitize=signed-integer-overflow test.cc ; ./a.out
example.cpp:9:53: runtime error: signed integer overflow: 1188246531 *
2082494266 cannot be represented in type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior example.cpp:9:53 in
hello
godbolt clang-trunk : https://godbolt.org/z/s4-AqW
godbolt gcc-trunk : https://godbolt.org/z/k7NhG6
[Bug c++/95326] GCC can not detect signed-integer-overflow correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95326
Haoxin Tu changed:
What|Removed |Added
Version|11.0|10.0
--- Comment #1 from Haoxin Tu ---
I also found another case example.cpp
#include
unsigned short g_var_ushort = 52781U;
const unsigned int g_const_uint = 2331271054U;
int main () {
//test_function();
short l_var_short = -14674;
volatile unsigned char l_volatile_uchar = 151U;
long l_var_long = 572469544701421587L;
g_var_ushort = l_volatile_uchar - l_var_short % g_const_uint * l_var_long;
std::cout << "hello" << std::endl;
return 0;
}
$g++ -fsanitize=signed-integer-overflow example.cpp ; ./a.out
hello
$clang++ -fsanitize=signed-integer-overflow example.cpp ; ./a.out
example.cpp:12:66: runtime error: signed integer overflow: 1963681568 *
572469544701421587 cannot be represented in type 'long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior example.cpp:12:66 in
hello
My g++ version is
$g++ --version
g++ (GCC) 10.0.1 20200420 (experimental)
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.
I have tested all GCC versions including GCC-8, GCC-9, GCC-10, and GCC-Trunk in
Godbolt, they can not detect this UB as well.
[Bug c++/95385] New: GCC stop detect UBs after a divide by zero in for statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95385
Bug ID: 95385
Summary: GCC stop detect UBs after a divide by zero in for
statement
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code test1.cc
#include
int main () {
int a = 1;
for (int i = 0; i < 10; ++i) {
a /= i; // Error: division by zero on the first iteration
}
int b = 0;
int bb = 0 / b;
0 / 0;
std::cout << "ok" << std::endl;
return 0;
}
$./g++ -w -fsanitize=integer-divide-by-zero test1.cc ; ./a.out
test.cc:5:11: runtime error: division by zero
Floating point exception (core dumped)
GCC only detects one runtime error in for statement but leaves out detecting
the statements following ones.
In test2.cc
#include
int main () {
/*
int a = 1;
for (int i = 0; i < 10; ++i) {
a /= i; // Error: division by zero on the first iteration
}
*/
int b = 0;
int bb = 0 / b;
0 / 0;
std::cout << "ok" << std::endl;
return 0;
}
$./g++ -w -fsanitize=integer-divide-by-zero test2.cc ; ./a.out
test.cc:11:16: runtime error: division by zero
test.cc:12:7: runtime error: division by zero
ok
Should the main function return from "return 0" rather than exit directly from
the for statement?
[Bug c++/95385] GCC stop detect UBs after a divide by zero in for statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95385
--- Comment #3 from Haoxin Tu ---
(In reply to Richard Biener from comment #2)
> We likely eliminate the dead 0/0 and 0/b instructions but fail for the one in
> the loop at -O0. As soon as the actual instruction is carried out the
> program traps and obviously further runtime messages are no longer emitted.
>
> There's no bug here.
Hi Richard, take look at this case
test3.cc
#include
int main () {
for (int i = 0; i < 1; ++i) {
int a1 = 0;
int aa1 = a1/0;
}
int b = 0;
int bb = 0 / b;
0 / 0;
std::cout << "ok" << std::endl;
return 0;
}
$./g++ -w -fsanitize=integer-divide-by-zero test3.cc ; ./a.out
test3.cc:5:21: runtime error: division by zero
The actual instruction is carried out as you said.
But in test4.cc
#include
int main () {
for (int i = 0; i < 1; ++i) {
int b = 0;
int bb = 0 / b;
0 / 0;
}
int b = 0;
int bb = 0 / b;
0 / 0;
std::cout << "ok" << std::endl;
return 0;
}
$$./g++ -w -fsanitize=integer-divide-by-zero test4.cc ; ./a.out
test4.cc:5:20: runtime error: division by zero
test4.cc:6:11: runtime error: division by zero
test4.cc:9:16: runtime error: division by zero
test4.cc:10:7: runtime error: division by zero
ok
I am wondering why GCC treats test3.cc and test4.cc differently. Is there
something I didn’t understand correctly?
[Bug sanitizer/95430] New: [UBSAN] doesn't detect out of bounds in a simple case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95430
Bug ID: 95430
Summary: [UBSAN] doesn't detect out of bounds in a simple case
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
This case test.cc
#include
int main () {
int a[10];
int *p1 = a - 100; // UB
int *p2 = a + 100; // UB
std::cout << "ok" << std::endl;
return 0;
}
$g++ -fsanitize=undefined test.cc ; ./a.out
ok
While in Clang
$clang++ -fsanitize=undefined test.cc ; ./a.out
test.cc:5:17: runtime error: index -100 out of bounds for type 'int [10]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.cc:5:17 in
test.cc:6:17: runtime error: index 100 out of bounds for type 'int [10]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.cc:6:17 in
ok
My GCC version is
$g++ --version
g++ (GCC) 11.0.0 20200526 (experimental)
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.
GCC doesn't trigger warning or runtime error in out of bounds in an array.
[Bug c++/95461] New: GCC misses -Warray-bounds warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95461
Bug ID: 95461
Summary: GCC misses -Warray-bounds warning message
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This case test.cc
#include
int main () {
int a[10] = {0};
a[11] = 0;
std::cout << "ok" << std::endl;
return 0;
}
produce nothing in gcc-trunk.
While in clang
$clang++ test.cc
test.cc:4:5: warning: array index 11 is past the end of the array (which
contains 10 elements) [-Warray-bounds]
a[11] = 0;
^ ~~
test.cc:3:5: note: array 'a' declared here
int a[10] = {0};
^
1 warning generated.
My gcc version is
g++ (GCC) 11.0.0 20200526 (experimental)
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.
All GCC versions have this missing.
[Bug sanitizer/95385] GCC stop detect UBs after a divide by zero in for statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95385 --- Comment #4 from Haoxin Tu --- (In reply to Haoxin Tu from comment #3) Hi, so sorry to bother you. Is still there any problem here? Please take a look at test3.cc and test4.cc. Thank you so much.
[Bug c++/95473] New: GCC misses -Wnull-dereference warning in a simple code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95473
Bug ID: 95473
Summary: GCC misses -Wnull-dereference warning in a simple code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
$cat null_ref.cc
int main(){
int = *(int *)nullptr; // null reference
return 0;
}
GCC can not catch any warning when I use -Wnull-dereference option.
I also try to add -O1~Os, but GCC still produces nothing.
While in clang
$clang++-trunk -Wnull-dereference null_ref.cc
null_ref.cc:2:15: warning: binding dereferenced null pointer to reference has
undefined behavior [-Wnull-dereference]
int = *(int *)nullptr; // null reference
^~~
1 warning generated.
$g++ --version
g++ (GCC) 11.0.0 20200526 (experimental)
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.
[Bug c++/95475] Imprecise column number of runtime error in unreachable program point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95475
--- Comment #2 from Haoxin Tu ---
(In reply to Andrew Pinski from comment #1)
> The question is where should it be, at the open of the () or the start of
> the identifier __builtin_unreachable ? In C++, it is the open. In C, it is
> the start.
Hi, Andrew,
My question is that GCC treats the identifier "__builtin_unreachable" and
normal identifier differently?
For example
$cat test.cc
int foo_long_identifier(){;}
int main(){
foo_long_identifier();
}
$g++ -w -fsanitize=undefined test.cc ; ./a.out
test.cc:1:5: runtime error: execution reached the end of a value-returning
function without returning a value
I think this time the column number is the start of the identifier
"foo_long_identifier" rather than "()".
[Bug c++/95475] New: Imprecise column number of runtime error in unreachable program point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95475
Bug ID: 95475
Summary: Imprecise column number of runtime error in
unreachable program point
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
$cat test.cc
int main(){
int var = 2;
switch (var) {
case 1:
default:
__builtin_unreachable();
}
}
$cat test.c
int main(){
int var = 2;
switch (var) {
case 1:
default:
__builtin_unreachable();
}
}
$g++ -fsanitize=undefined test.cc ; ./a.out
test.cc:6:34: runtime error: execution reached an unreachable program point
$gcc -fsanitize=undefined test.c ; ./a.out
test.c:6:13: runtime error: execution reached an unreachable program point
In clang-trunk
$clang++ -fsanitize=undefined test.cc ; ./a.out
test.cc:6:13: runtime error: execution reached an unreachable program point
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.cc:6:13 in
$clang -fsanitize=undefined test.c ; ./a.out
test.c:6:13: runtime error: execution reached an unreachable program point
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.c:6:13 in
$g++ --version
g++ (GCC) 11.0.0 20200526 (experimental)
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.
[Bug c++/95334] GCC detect missing signed-integer-overflow when add "const"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95334
--- Comment #2 from Haoxin Tu ---
I also find these cases
test1.cc
#include
bool g_bool = 0;
long g_long = -4075183478711827874L;
const long l_long = 7122990940771016367L;
int main () {
g_bool = g_long * l_long;
std::cout << g_bool << std::endl;
return 0;
}
GCC detects nothing.
$g++ -w -fsanitize=signed-integer-overflow test1.cc
1
But when remove "const"
test2.cc
#include
bool g_bool = 0;
long g_long = -4075183478711827874L;
const long l_long = 7122990940771016367L;
int main () {
g_bool = g_long * l_long;
std::cout << g_bool << std::endl;
return 0;
}
GCC can dectect the signed-integer-overflow.
$g++ -w -fsanitize=signed-integer-overflow test2.cc
test2.cc:7:21: runtime error: signed integer overflow: -4075183478711827874 *
7122990940771016367 cannot be represented in type 'long int'
1
[Bug c++/95354] New: GCC misuse "nonnull-attribute" option and can not detect it as UB as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95354
Bug ID: 95354
Summary: GCC misuse "nonnull-attribute" option and can not
detect it as UB as well
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This case test.cc
#include
#include
void has_nonnull_argument(__attribute__((nonnull)) int *p) {
;
}
int main () {
has_nonnull_argument(NULL);
std::cout << "ok" << std::endl;
return 0;
}
in GCC-trunk
$./g++ -fsanitize=undefined test.cc ; ./a.out
test.cc:3:57: warning: ‘nonnull’ attribute only applies to function types
[-Wattributes]
3 | void has_nonnull_argument(__attribute__((nonnull)) int *p) {
| ^
ok
$./g++ -fsanitize=nonull-attribute test.cc ; ./a.out
test.cc:3:57: warning: ‘nonnull’ attribute only applies to function types
[-Wattributes]
3 | void has_nonnull_argument(__attribute__((nonnull)) int *p) {
| ^
ok
in Clang-trunk
$clang++ -fsanitize=nonnull-attribute test.cc ; ./a.out
est.cc:7:30: warning: null passed to a callee that requires a non-null argument
[-Wnonnull]
has_nonnull_argument(NULL);
^
1 warning generated.
test.cc:7:26: runtime error: null pointer passed as argument 1, which is
declared to never be null
test.cc:3:42: note: nonnull attribute specified here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.cc:7:26 in
ok
According to the description in
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#Instrumentation-Options
for "-fsanitize=nonull-attribute", it says "This option enables instrumentation
of calls, checking whether null values are not passed to arguments marked as
requiring a non-null value by the nonnull function attribute."
I guess the warning message by GCC may also incorrect, the correct one should
look like in Clang produced.
I have tested them in recent GCC versions including GCC-8, GCC-9, and GCC-10,
they have the same symptom as well.
My GCC version is
$g++ --version
g++ (GCC) 11.0.0 20200526 (experimental)
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.
[Bug c++/95354] GCC misuse "nonnull-attribute" option and can not detect it as UB as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95354 --- Comment #3 from Haoxin Tu --- I see. Are there any cases that can trigger the UB of nonnull-attribute? I doubt the usage of “-fsanitize=nonnull-attribute” in GCC...
[Bug c++/96437] New: [10/11 Regression] ICE in tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in synthesize_implicit_template_parm, at cp/parser.c:44246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96437
Bug ID: 96437
Summary: [10/11 Regression] ICE in tree check: expected tree
that contains ‘decl common’ structure, have
‘error_mark’ in synthesize_implicit_template_parm, at
cp/parser.c:44246
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, reduced by C-Vise, makes GCC-trunk ICE, while GCC-10 and downwards
versions behave well in error-recovery.
Input:
//small.cc
template <()> void A(auto){}
Command:
g++ small.cc
Output:
small.cc:1:11: error: expected identifier before ‘(’ token
1 | template <()> void A(auto){}
| ^
small.cc:1:22: internal compiler error: tree check: expected tree that contains
‘decl common’ structure, have ‘error_mark’ in
synthesize_implicit_template_parm, at cp/parser.c:44246
1 | template <()> void A(auto){}
| ^~~~
0x7c899e tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/tree.c:9861
0x6440d9 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3417
0x6440d9 synthesize_implicit_template_parm
../../gcc/cp/parser.c:44246
0x9c72b0 cp_parser_simple_type_specifier
../../gcc/cp/parser.c:18064
0x9aa52d cp_parser_type_specifier
../../gcc/cp/parser.c:17873
0x9ab50e cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14436
0x9c90ee cp_parser_parameter_declaration
../../gcc/cp/parser.c:22858
0x9c9a82 cp_parser_parameter_declaration_list
../../gcc/cp/parser.c:22681
0x9c9e81 cp_parser_parameter_declaration_clause
../../gcc/cp/parser.c:22608
0x9b6951 cp_parser_direct_declarator
../../gcc/cp/parser.c:21285
0x9b6951 cp_parser_declarator
../../gcc/cp/parser.c:21149
0x9cbab6 cp_parser_init_declarator
../../gcc/cp/parser.c:20649
0x9d31f4 cp_parser_single_declaration
../../gcc/cp/parser.c:29590
0x9d3356 cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.c:29163
0x9d3b00 cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:29428
0x9d76e1 cp_parser_declaration
../../gcc/cp/parser.c:13459
0x9d7d2b cp_parser_translation_unit
../../gcc/cp/parser.c:4793
0x9d7d2b c_parse_file()
../../gcc/cp/parser.c:44081
0xaf2e9d c_common_parse_file()
../../gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
My gcc version is
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/
--enable-languages=c,c++ CC=gcc CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200801 (experimental) (GCC)
Thanks,
Haoxin
[Bug c++/96440] New: ICE in tree check: expected tree_list, have error_mark in get_attribute_name, at attribs.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96440 Bug ID: 96440 Summary: ICE in tree check: expected tree_list, have error_mark in get_attribute_name, at attribs.c:841 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: error-recovery, ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- Hi, all. This code, reduced by C-Vise, makes GCC-trunk ICE and makes released GCC versions "confused by early errors". Input: //small.cc auto alignas a [[]] [[const]] (); Command: g++ small.cc Output: small.cc:1:14: error: expected ‘(’ before ‘a’ 1 | auto alignas a [[]] [[const]] (); | ^ | ( small.cc:1:29: internal compiler error: tree check: expected tree_list, have error_mark in get_attribute_name, at attribs.c:841 1 | auto alignas a [[]] [[const]] (); | ^ 0x7c7fd7 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:9687 0x6a0bd3 tree_check(tree_node const*, char const*, int, char const*, tree_code) ../../gcc/tree.h:3559 0x6a0bd3 get_attribute_name(tree_node const*) ../../gcc/attribs.c:841 0xa9e159 private_lookup_attribute(char const*, unsigned long, tree_node*) ../../gcc/attribs.c:1812 0x911518 lookup_attribute ../../gcc/attribs.h:179 0x911518 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*, decl_context, int, tree_node**) ../../gcc/cp/decl.c:11384 0x91d418 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) ../../gcc/cp/decl.c:5233 0x9cbd7d cp_parser_init_declarator ../../gcc/cp/parser.c:20858 0x9ac3cc cp_parser_simple_declaration ../../gcc/cp/parser.c:13811 0x9d763e cp_parser_declaration ../../gcc/cp/parser.c:13510 0x9d7d2b cp_parser_translation_unit ../../gcc/cp/parser.c:4793 0x9d7d2b c_parse_file() ../../gcc/cp/parser.c:44081 0xaf2e9d c_common_parse_file() ../../gcc/c-family/c-opts.c:1188 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. My gcc version is Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../configure --prefix=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/ --enable-languages=c,c++ CC=gcc CXX=g++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.0 20200801 (experimental) (GCC) Thanks, Haoxin
[Bug c++/96438] New: [10/11 Regression] ICE in do_pushtag, at cp/name-lookup.c:6861
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96438
Bug ID: 96438
Summary: [10/11 Regression] ICE in do_pushtag, at
cp/name-lookup.c:6861
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, reduced by C-Vise, makes GCC-trunk ICE, while GCC-10 and downwards
versions behave well in error-recovery.
Input:
//small.cc
class A {
template
void foo (int (operator struct { union :});
}
Command:
g++ small.cc
Output:
small.cc:3:40: error: types may not be defined in a conversion-type-id
3 | void foo (int (operator struct { union :});
|^
small.cc:3:42: internal compiler error: in do_pushtag, at cp/name-lookup.c:6861
3 | void foo (int (operator struct { union :});
| ^
0x641ae8 do_pushtag
../../gcc/cp/name-lookup.c:6861
0x641ae8 pushtag(tree_node*, tree_node*, tag_scope)
../../gcc/cp/name-lookup.c:6988
0x9030d0 xref_tag(tag_types, tree_node*, tag_scope, bool)
../../gcc/cp/decl.c:15085
0x9aa0af cp_parser_class_head
../../gcc/cp/parser.c:24698
0x9aa0af cp_parser_class_specifier_1
../../gcc/cp/parser.c:23920
0x9aa593 cp_parser_class_specifier
../../gcc/cp/parser.c:24294
0x9aa593 cp_parser_type_specifier
../../gcc/cp/parser.c:17797
0x9ab50e cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14436
0x9d5570 cp_parser_member_declaration
../../gcc/cp/parser.c:25035
0x9a82f8 cp_parser_member_specification_opt
../../gcc/cp/parser.c:24890
0x9a82f8 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23987
0x9aa593 cp_parser_class_specifier
../../gcc/cp/parser.c:24294
0x9aa593 cp_parser_type_specifier
../../gcc/cp/parser.c:17797
0x9c0273 cp_parser_type_specifier_seq
../../gcc/cp/parser.c:22479
0x9bf53a cp_parser_conversion_type_id
../../gcc/cp/parser.c:15154
0x9bf53a cp_parser_conversion_function_id
../../gcc/cp/parser.c:15115
0x9bf53a cp_parser_unqualified_id
../../gcc/cp/parser.c:6335
0x9b6d07 cp_parser_declarator_id
../../gcc/cp/parser.c:22267
0x9b6d07 cp_parser_direct_declarator
../../gcc/cp/parser.c:21515
0x9b6d07 cp_parser_declarator
../../gcc/cp/parser.c:21149
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
My gcc version is
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/
--enable-languages=c,c++ CC=gcc CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200801 (experimental) (GCC)
Thanks,
Haoxin
[Bug c++/96441] New: ICE in tree check: expected integer_cst, have cond_expr in get_len, at tree.h:5954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96441
Bug ID: 96441
Summary: ICE in tree check: expected integer_cst, have
cond_expr in get_len, at tree.h:5954
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, reduced by C-Vise, makes GCC-trunk ICE and makes released GCC
versions "confused by early errors".
Input:
//small.cc
enum struct a : int;
template class A {};
template <> enum struct a {c};
Command:
g++ small.cc
Output:
small.cc:2:47: error: expression ‘’ is not a constant
expression
2 | template class A {};
| ^
small.cc:3:28: internal compiler error: tree check: expected integer_cst, have
cond_expr in get_len, at tree.h:5954
3 | template <> enum struct a {c};
|^
0x7c7fd7 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9687
0x616fed tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3559
0x616fed wi::extended_tree<192>::get_len() const
../../gcc/tree.h:5954
0x616fed wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../gcc/wide-int.h:985
0x616fed wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:1034
0x616fed generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:790
0x616fed wi::binary_traits >, int,
wi::int_traits > >::precision_type,
wi::int_traits::precision_type>::result_type
wi::add >,
int>(generic_wide_int > const&, int const&, signop,
wi::overflow_type*)
../../gcc/wide-int.h:2467
0x616fed build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc/cp/decl.c:15857
0x9aafec cp_parser_enumerator_definition
../../gcc/cp/parser.c:19585
0x9aafec cp_parser_enumerator_list
../../gcc/cp/parser.c:19514
0x9aafec cp_parser_enum_specifier
../../gcc/cp/parser.c:19444
0x9aafec cp_parser_type_specifier
../../gcc/cp/parser.c:17769
0x9ab50e cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14436
0x9d2fe5 cp_parser_single_declaration
../../gcc/cp/parser.c:29499
0x9d4300 cp_parser_explicit_specialization
../../gcc/cp/parser.c:17689
0x9d776d cp_parser_declaration
../../gcc/cp/parser.c:13456
0x9d7d2b cp_parser_translation_unit
../../gcc/cp/parser.c:4793
0x9d7d2b c_parse_file()
../../gcc/cp/parser.c:44081
0xaf2e9d c_common_parse_file()
../../gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
My gcc version is
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/
--enable-languages=c,c++ CC=gcc CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200801 (experimental) (GCC)
Thanks,
Haoxin
[Bug c++/96442] New: ICE in tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have record_type in int_fits_type_p, at tree.c:8954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96442
Bug ID: 96442
Summary: ICE in tree check: expected integer_type or
enumeral_type or boolean_type or real_type or
fixed_point_type, have record_type in int_fits_type_p,
at tree.c:8954
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, reduced by C-Vise, makes GCC-trunk ICE and makes released GCC
versions "confused by early errors".
Input:
//small.cc
enum struct a : struct {};
template enum class a : class c{};
enum struct a {b};
Command:
g++ small.cc
Output:
small.cc:1:25: error: underlying type ‘’ of ‘a’ must be an
integral type
1 | enum struct a : struct {};
| ^
small.cc:3:13: error: different underlying type in enum ‘enum class a’
3 | enum struct a {b};
| ^
small.cc:1:25: note: previous definition here
1 | enum struct a : struct {};
| ^
small.cc:3:16: internal compiler error: tree check: expected integer_type or
enumeral_type or boolean_type or real_type or fixed_point_type, have
record_type in int_fits_type_p, at tree.c:8954
3 | enum struct a {b};
|^
0x7c7fd7 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9687
0x7ceec0 tree_check5(tree_node const*, char const*, int, char const*,
tree_code, tree_code, tree_code, tree_code, tree_code)
../../gcc/tree.h:3650
0x7ceec0 int_fits_type_p(tree_node const*, tree_node const*)
../../gcc/tree.c:8954
0x919b9a build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc/cp/decl.c:15906
0x9aafec cp_parser_enumerator_definition
../../gcc/cp/parser.c:19585
0x9aafec cp_parser_enumerator_list
../../gcc/cp/parser.c:19514
0x9aafec cp_parser_enum_specifier
../../gcc/cp/parser.c:19444
0x9aafec cp_parser_type_specifier
../../gcc/cp/parser.c:17769
0x9ab50e cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14436
0x9ac2c1 cp_parser_simple_declaration
../../gcc/cp/parser.c:13690
0x9d763e cp_parser_declaration
../../gcc/cp/parser.c:13510
0x9d7d2b cp_parser_translation_unit
../../gcc/cp/parser.c:4793
0x9d7d2b c_parse_file()
../../gcc/cp/parser.c:44081
0xaf2e9d c_common_parse_file()
../../gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
My gcc version is
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/
--enable-languages=c,c++ CC=gcc CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200801 (experimental) (GCC)
Thanks,
Haoxin
[Bug c++/96477] New: GCC accepts attribute 'const' as an attribute pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96477
Bug ID: 96477
Summary: GCC accepts attribute 'const' as an attribute pack
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
Following code might be a invalid code? GCC accepts it while Clang or ICC
rejects it.
Code:
[[gnu::const ... ]] int foo (){ return 0;}
Every version from GCC-6.1 onwards behaves the same.
Thanks,
Haoxin
[Bug c++/96478] New: GCC accepts enum definition in alignas()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96478
Bug ID: 96478
Summary: GCC accepts enum definition in alignas()
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code might be a invalid code, but GCC accepts it well. Other mainstream
compilers reject this code.
Code:
namespace {
template int foo(){return 0;}
template <>
alignas (enum e{}) int foo();
}
Output in Clang:
error: '(anonymous namespace)::e' cannot be defined in a type specifier
Output in ICC:
error: type definition is not allowed
Every version from GCC-6.1 onwards behaves the same.
Thanks,
Haoxin
[Bug c++/96553] New: ICE in unexpected expression ‘__alignof__ (auto:1)’ of kind alignof_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96553
Bug ID: 96553
Summary: ICE in unexpected expression ‘__alignof__ (auto:1)’ of
kind alignof_expr
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, reduced by C-Vise, makes GCC-trunk ICE and released versions
"confused by earlier errors, bailing out".
Input:
//small.cc
class Test{
Test || ( alignas (auto) enum{});
};
Command:
g++ small.cc
Output:
small.cc:2:34: warning: use of ‘auto’ in parameter declaration only available
with ‘-fconcepts-ts’
2 | Test || ( alignas (auto) enum{});
| ^~~~
small.cc:2:40: error: types may not be defined in parameter types
2 | Test || ( alignas (auto) enum{});
|^~~~
small.cc:2:45: internal compiler error: unexpected expression ‘__alignof__
(auto:1)’ of kind alignof_expr
2 | Test || ( alignas (auto) enum{});
| ^
0x8e014c cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6567
0x8e068f cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:6772
0x8e4aab maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.c:7045
0x95075b cp_check_const_attributes(tree_node*)
../../gcc/cp/decl2.c:1428
0x955b72 cp_check_const_attributes(tree_node*)
../../gcc/cp/decl2.c:1416
0x955b72 cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/cp/decl2.c:1584
0x9f27a4 cp_parser_parameter_declaration_list
../../gcc/cp/parser.c:22725
0x9f2b21 cp_parser_parameter_declaration_clause
../../gcc/cp/parser.c:22622
0x9df4f1 cp_parser_direct_declarator
../../gcc/cp/parser.c:21299
0x9df4f1 cp_parser_declarator
../../gcc/cp/parser.c:21163
0x9df045 cp_parser_declarator
../../gcc/cp/parser.c:21141
0x9fe4ce cp_parser_member_declaration
../../gcc/cp/parser.c:25291
0x9d0ea8 cp_parser_member_specification_opt
../../gcc/cp/parser.c:24904
0x9d0ea8 cp_parser_class_specifier_1
../../gcc/cp/parser.c:24001
0x9d3143 cp_parser_class_specifier
../../gcc/cp/parser.c:24308
0x9d3143 cp_parser_type_specifier
../../gcc/cp/parser.c:17811
0x9d40be cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14436
0x9d4e71 cp_parser_simple_declaration
../../gcc/cp/parser.c:13690
0xa002fe cp_parser_declaration
../../gcc/cp/parser.c:13510
0xa009db cp_parser_translation_unit
../../gcc/cp/parser.c:4793
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
My GCC version is updated on 2020-08-08.
Thanks,
Haoxin
[Bug c++/96552] New: GCC accepts "alignas(auto)" in function parameter list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96552
Bug ID: 96552
Summary: GCC accepts "alignas(auto)" in function parameter list
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
Following code is invalid I think, the "alignas" shouldn't be in function
parameter. I guess GCC only finds a "auto" in function parameter list rather
than "alignas(auto)", also "alignas(auto)" itself is invalid.
Code:
class Test{
Test || (alignas(auto) int);
};
While Clang says "error: 'auto' not allowed here".
Every version from GCC-6.1 upwards behaves the same.
Thanks,
Haoxin
[Bug c++/96465] New: ICE in tsubst_function_decl, at cp/pt.c:13669
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96465
Bug ID: 96465
Summary: ICE in tsubst_function_decl, at cp/pt.c:13669
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, similar with bug 96464 code, makes GCC-7.1 onwards versions ICE or
"confused by earlier errors". It seems that GCC have some room to enhance its
error-recovery on this case.
Input
//small.cc
void foo(){
auto var = [] (class b...) {};
}
Command:
g++ small.cc
Output:
small.cc: In function ‘void foo()’:
small.cc:2:26: error: ‘b’ is not a class template
2 | auto var = [] (class b...) {};
| ^
small.cc:1:6: internal compiler error: in tsubst_function_decl, at
cp/pt.c:13669
1 | void foo(){
| ^~~
0x66004a tsubst_function_decl
../../gcc/cp/pt.c:13669
0xa00832 tsubst_decl
../../gcc/cp/pt.c:14216
0xa0c74f lookup_template_class_1
../../gcc/cp/pt.c:9852
0xa0e813 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:10139
0xa0e813 tsubst_aggr_type
../../gcc/cp/pt.c:13395
0x9c94ef cp_parser_parameter_declaration
../../gcc/cp/parser.c:22961
0x9c9a82 cp_parser_parameter_declaration_list
../../gcc/cp/parser.c:22681
0x9c9e81 cp_parser_parameter_declaration_clause
../../gcc/cp/parser.c:22608
0x9ca993 cp_parser_lambda_declarator_opt
../../gcc/cp/parser.c:11134
0x9b0831 cp_parser_lambda_expression
../../gcc/cp/parser.c:10665
0x9b18b0 cp_parser_primary_expression
../../gcc/cp/parser.c:5475
0x9bbdd5 cp_parser_postfix_expression
../../gcc/cp/parser.c:7328
0x99daaa cp_parser_binary_expression
../../gcc/cp/parser.c:9641
0x99f83e cp_parser_assignment_expression
../../gcc/cp/parser.c:9946
0x99e3bd cp_parser_constant_expression
../../gcc/cp/parser.c:10240
0x99ebe1 cp_parser_initializer_clause
../../gcc/cp/parser.c:23312
0x9a391c cp_parser_initializer
../../gcc/cp/parser.c:23250
0x9cc4ab cp_parser_init_declarator
../../gcc/cp/parser.c:20943
0x9ac3cc cp_parser_simple_declaration
../../gcc/cp/parser.c:13811
0x9ae42d cp_parser_declaration_statement
../../gcc/cp/parser.c:13249
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
My GCC version is
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/
--enable-languages=c,c++ CC=gcc CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200801 (experimental) (GCC)
Thanks,
Haoxin
[Bug c++/96462] [10/11 Regression] ICE in tree check: expected identifier_node, have bit_not_expr in find_namespace_slot, at cp/name-lookup.c:97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96462 --- Comment #2 from Haoxin Tu --- (In reply to Marek Polacek from comment #1) > Confirmed. Hi, Marek. Thanks for your quick response! Best, Haoxin
[Bug c++/96464] New: GCC allows 'auto' in template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96464
Bug ID: 96464
Summary: GCC allows 'auto' in template argument
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code is invalid code I guess, but GCC-6.0 onwards versions accept it.
$cat small.cc
template class b {};
void foo(){
auto var = [] (class b...) {};
}
$g++ -c small.cc
//nothing
$clang++ -c small.cc
small.cc:3:28: error: 'auto' not allowed in template argument
auto var = [] (class b...) {};
^~~~
1 error generated.
Thanks,
Haoxin
[Bug c++/96467] New: [8/9/10/11 Regression] in finish_member_declaration, at cp/semantics.c:3240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96467
Bug ID: 96467
Summary: [8/9/10/11 Regression] in finish_member_declaration,
at cp/semantics.c:3240
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code makes GCC-9.1 onwards versions ICE without any error messages. I
guess this case is more seriously because this makes released versions ICE
rather than "confused by earlier errors".
Input:
//small.cc
union a;
a :: b () alignas (enum {c});
Command:
g++ small.cc
Output:
small.cc:2:26: internal compiler error: in finish_member_declaration, at
cp/semantics.c:3240
2 | a :: b () alignas (enum {c});
| ^
0x5c82c0 finish_member_declaration(tree_node*)
../../gcc/cp/semantics.c:3240
0x67d578 build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc/cp/decl.c:15887
0x6e8b47 cp_parser_enumerator_definition
../../gcc/cp/parser.c:19493
0x6e8b47 cp_parser_enumerator_list
../../gcc/cp/parser.c:19422
0x6e8b47 cp_parser_enum_specifier
../../gcc/cp/parser.c:19353
0x6e8b47 cp_parser_type_specifier
../../gcc/cp/parser.c:17683
0x6fb6f9 cp_parser_type_specifier_seq
../../gcc/cp/parser.c:22386
0x6f5c84 cp_parser_type_id_1
../../gcc/cp/parser.c:22203
0x6f5ecf cp_parser_type_id
../../gcc/cp/parser.c:22282
0x6f5ecf cp_parser_std_attribute_spec
../../gcc/cp/parser.c:27079
0x6f5ecf cp_parser_std_attribute_spec_seq
../../gcc/cp/parser.c:27142
0x6f3b43 cp_parser_direct_declarator
../../gcc/cp/parser.c:21234
0x6f3b43 cp_parser_declarator
../../gcc/cp/parser.c:21057
0x706577 cp_parser_init_declarator
../../gcc/cp/parser.c:20557
0x6e9c32 cp_parser_simple_declaration
../../gcc/cp/parser.c:13734
0x70f952 cp_parser_declaration
../../gcc/cp/parser.c:13433
0x710074 cp_parser_translation_unit
../../gcc/cp/parser.c:4734
0x710074 c_parse_file()
../../gcc/cp/parser.c:43975
0x7d84fb c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
My GCC version is
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/
--enable-languages=c,c++ CC=gcc CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200801 (experimental) (GCC)
Thanks,
Haoxin
[Bug c++/96462] New: [10/11 Regression] ICE in tree check: expected identifier_node, have bit_not_expr in find_namespace_slot, at cp/name-lookup.c:97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96462
Bug ID: 96462
Summary: [10/11 Regression] ICE in tree check: expected
identifier_node, have bit_not_expr in
find_namespace_slot, at cp/name-lookup.c:97
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code makes GCC-trunk ICE without emitting any error messages, while other
released versions compile it well.
Input:
//small.cc
enum a {};
using a:: ~ a;
Command:
g++ small.cc
Output:
small.cc:2:13: internal compiler error: tree check: expected identifier_node,
have bit_not_expr in find_namespace_slot, at cp/name-lookup.c:97
2 | using a:: ~ a;
| ^
0x7c7fd7 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9687
0x63f701 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3303
0x63f701 find_namespace_slot
../../gcc/cp/name-lookup.c:97
0x983071 name_lookup::search_namespace_only(tree_node*)
../../gcc/cp/name-lookup.c:544
0x983132 name_lookup::search_namespace(tree_node*)
../../gcc/cp/name-lookup.c:561
0x983132 name_lookup::search_namespace(tree_node*)
../../gcc/cp/name-lookup.c:554
0x983226 name_lookup::search_qualified(tree_node*, bool)
../../gcc/cp/name-lookup.c:622
0x983226 name_lookup::search_qualified(tree_node*, bool)
../../gcc/cp/name-lookup.c:614
0x986a1b qualified_namespace_lookup
../../gcc/cp/name-lookup.c:6045
0x986b8d lookup_using_decl
../../gcc/cp/name-lookup.c:4619
0x987070 finish_nonmember_using_decl(tree_node*, tree_node*)
../../gcc/cp/name-lookup.c:5132
0x9c7fd2 cp_parser_using_declaration
../../gcc/cp/parser.c:20025
0x9d763e cp_parser_declaration
../../gcc/cp/parser.c:13510
0x9d7d2b cp_parser_translation_unit
../../gcc/cp/parser.c:4793
0x9d7d2b c_parse_file()
../../gcc/cp/parser.c:44081
0xaf2e9d c_common_parse_file()
../../gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
My GCC version is
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/
--enable-languages=c,c++ CC=gcc CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200801 (experimental) (GCC)
[Bug c++/96110] New: Function declarator with a trailing return type "auto" should be allowed in try-catch block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96110
Bug ID: 96110
Summary: Function declarator with a trailing return type "auto"
should be allowed in try-catch block
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
The code test.cc
int main(){
try {}
catch (auto foo() -> auto) {}
return 0;
}
might should be allowed in GCC.
$g++ test.cc
test.cc: In function 'int main()':
test.cc:8:12: error: 'auto' parameter not permitted in this context
8 | catch (auto foo() -> auto) {}
|^~~~
Other compilers, clang, or icc accepts this well.
All versions from 6.1 to trunk behave the same.
Thanks,
Haoxin
[Bug c++/96097] ICE in dependent_type_p, at cp/pt.c:26326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96097 Haoxin Tu changed: What|Removed |Added CC||haoxintu at gmail dot com --- Comment #3 from Haoxin Tu --- (In reply to Martin Liška from comment #2) > Confirmed, clang accepts the code. GCC ICEs for all revisions. Hi, I just realized I have reported an ice-on-invalid version in bug 95931 with the same symptom in the trunk. Maybe you can consider them together. Thanks, Haoxin
[Bug c++/95972] ICE in check_member_template, at cp/decl2.c:570
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95972
--- Comment #2 from Haoxin Tu ---
Update a new case.
Input:
int a() { [] ( auto class {int b()}}
Output:
: In function 'int a()':
:1:27: error: types may not be defined in parameter types
1 | int a() { [] ( auto class {int b()}}
| ^
:1:34: internal compiler error: in check_member_template, at
cp/decl2.c:568
1 | int a() { [] ( auto class {int b()}}
| ^
[Bug c++/96137] New: [11 Regression] GCC hang on in invalid function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96137
Bug ID: 96137
Summary: [11 Regression] GCC hang on in invalid function
definition
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This simple code makes GCC-trunk hang on. The memory seems ok, only with
endless compiling.
$cat bug.cc
void a () { .operator b }
$g++ bug.cc
bug.cc: In function ‘void a()’:
bug.cc:1:13: error: expected primary-expression before ‘.’ token
1 | void a () { .operator b }
| ^
...
I tested the trunk version:
GCC version 11.0.0 20200708 (experimental) (GCC)
The GCC-10 or GCC-9 compiles this as normal. I guess this is a regression
issue?
Thanks,
Haoxin
[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96137 --- Comment #1 from Haoxin Tu --- Also, I want to know are those cases (invalid code but makes GCC hang on) worth reporting? If those cases can help improve the GCC FE or its performance, I will continue to file more reports. Otherwise, I will just stop doing that. Thanks
[Bug c++/96116] New: GCC accepts "enum struct/class" in reference to enumeration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96116 Bug ID: 96116 Summary: GCC accepts "enum struct/class" in reference to enumeration Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- Hi,all. This code, might be an invalid code, but GCC accepts it. $cat test.cc using alias1 = enum struct E1; using alias2 = enum class E2; While in clang: $clang++ test.cc test.cc:1:21: error: reference to enumeration must use 'enum' not 'enum struct' [-Welaborated-enum-class] using alias1 = enum struct E1; ^~~ test.cc:2:21: error: reference to enumeration must use 'enum' not 'enum class' [-Welaborated-enum-class] using alias2 = enum class E2; ^~ 2 errors generated. Here is a related bug report in llvm: https://bugs.llvm.org/show_bug.cgi?id=46603 They suggested that ""enum class" can only be used when defining an enumeration or as part of a standalone forward declaration" Versions from 6.1 to trunk behave the same. So is this an invalid code for GCC? Thanks, Haoxin
[Bug c++/96118] New: GCC accepts invalid combination of two type specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96118 Bug ID: 96118 Summary: GCC accepts invalid combination of two type specifiers Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- Hi, all. This code, combines a typedef specifier and a normal type specifier, might be an invalid code. $cat test.cc typedef long typedef_long; typedef_long long var = 10; GCC accept this well. While in clang: error: 'long type-name' is invalid in icc: error: invalid combination of type specifiers in msvc: error C2628: 'typedef_long' followed by 'long' is illegal (did you forget a ';'?) All versions from GCC 4.0 to trunk behave the same. Thanks, Haoxin
[Bug c++/96119] New: GCC accepts invalid qualifier in a try-catch block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96119
Bug ID: 96119
Summary: GCC accepts invalid qualifier in a try-catch block
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code might be an invalid code, but GCC accepts this well.
$cat test.cc
int main(){
try {}
catch (int () & ){}
return 0;
}
While in Clang, it says:
error: non-member function cannot have '&' qualifier
In ICC:
error: a ref-qualifier is not allowed here
All GCC versions from 5.1 to trunk behave the same.
Is this also an invalid code for GCC or is there something I misunderstanding?
Thanks,
Haoxin
[Bug c++/96120] Ambiguity diagnostic message of "invalid use of type 'void' in parameter declaration"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96120 --- Comment #3 from Haoxin Tu --- (In reply to Jonathan Wakely from comment #1) > (In reply to Haoxin Tu from comment #0) > > GCC might emit the ambiguity diagnostic message on it. > > What does that mean? Apologize for my expression. I mean the meaning of the error message "invalid use of type ‘void’ in parameter declaration" is opposite with the valid grammar(it should be allowed in the first parameter). This might be not a bug, might be just an improvement? Thanks.
[Bug c++/96110] Function declarator with a trailing return type "auto" should be allowed in try-catch block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96110 --- Comment #5 from Haoxin Tu --- (In reply to Jonathan Wakely from comment #2) > This isn't specific to catch handlers, other compilers accept that nonsense > function declaration in various contexts, and GCC rejects them all: Thanks for your clarifying, this is a misunderstanding of mine.
[Bug c++/95972] ICE in check_member_template, at cp/decl2.c:570
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95972 --- Comment #4 from Haoxin Tu --- (In reply to Marek Polacek from comment #3) > You can still use creduce (I do), but it's good to try adding missing > parens/braces and similar to make the code more sensible. Yes, you are right. Thanks for you advise, and I am doing this like what you said.
[Bug c++/96120] New: Ambiguity diagnostic message of "invalid use of type 'void' in parameter declaration"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96120
Bug ID: 96120
Summary: Ambiguity diagnostic message of "invalid use of type
'void' in parameter declaration"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, test.cc, GCC might emit the ambiguity diagnostic message on it.
$cat test.cc
void foo1 (void) {}
void foo2 (void, int){}
$g++ -c test.cc
test.cc:2:12: error: invalid use of type ‘void’ in parameter declaration
2 | void foo2 (void, int){}
|^~~~
Apparently, "void" can be used in parameter declaration like line 1, but GCC
emits the ambiguity message on it. The output information conflicts with valid
grammar, so I guess users might be confused with this diagnostic.
I think clang handles better in this case
$clang++ -c test.cc
test.cc:2:11: error: 'void' must be the first and only parameter if specified
void foo2 (void, int){}
^
1 error generated.
Thanks,
Haoxin
[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96137 --- Comment #3 from Haoxin Tu --- (In reply to Marek Polacek from comment #2) > I would treat them just like ICEs. They are useful if the testcase isn't > complete garbage. This one is sort of useful because it shows that my > change above has a corner case that I didn't consider. Ok, I got it. Thank you, Marek.
[Bug c++/96077] GCC accepts ill-legal local enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077 --- Comment #2 from Haoxin Tu --- (In reply to Jonathan Wakely from comment #1) > It's not ideal to provide a testcase that doesn't compile for an > accepts-invalid bug. A testcase that actually compiles is a better > demonstration that the invalid code is accepted OK, I got it. Thank you Jonathan. I will do better next time.
[Bug c++/96082] New: GCC rejects the template disambiguator with "typename"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96082
Bug ID: 96082
Summary: GCC rejects the template disambiguator with "typename"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, test.cc, GCC rejects it in versions from 9.1 to trunk, but accepts
it from 8.3 to 4.8 versions.
$cat test.cc
template class A {};
int main () {
typename :: template A a;
}
$g++ test.cc
test.cc: In function ‘int main()’:
test.cc:3:26: error: ‘template’ must follow a nested-name-specifier
3 | typename :: template A a;
| ^~~
test.cc:3:26: error: expected ‘(’
3 | typename :: template A a;
| ^~~
|
I also tested in clang, icc, and msvc, they all accept this code.
[Bug c++/96145] New: Weird output in compiling a typedef union as a function return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96145
Bug ID: 96145
Summary: Weird output in compiling a typedef union as a
function return type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, test.cc, uses a typedef name of a union as a return type of a
function, the GCC compiled output might be weird.
$cat test.cc
typedef union{} typedef_union;
typename :: typedef_union foo1 () {}
$g++ -w test.cc
test.cc:2:13: error: 'class' tag used in naming 'union typedef_union'
[-fpermissive]
2 | typename :: typedef_union foo1 () {}
| ^
test.cc:1:17: note: 'union typedef_union' was previously declared here
1 | typedef union{} typedef_union;
| ^
Two things might be weird:
1. This code is a valid code I guess. Other mainstream compilers (I test this
in clang, ice, and mvsc) accept this by default, although the error can
disappear when adding "-fpermissive" option. Maybe is this a reject-valid
issue?
2. The output "class" tag is wrong. I don't use the "class" keyword in this
small code. Maybe is this a diagnostic issue?
I report this because of the related discussions in llvm:
https://bugs.llvm.org/show_bug.cgi?id=46645
Every version from 4.0 onwards behaves the same (I didn't test anything older).
Thanks,
Haoxin
[Bug c++/96182] New: GCC accepts constexpr function with no return-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96182
Bug ID: 96182
Summary: GCC accepts constexpr function with no
return-statement
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi,all.
This code, test.cc, is an invalid code I guess, but GCC accepts it.
$cat test.cc
constexpr int
foo()
{}
$g++ test.cc
test.cc: In function ‘constexpr int foo()’:
test.cc:3:2: warning: no return statement in function returning non-void
[-Wreturn-type]
3 | {}
| ^
GCC only emits normal -Wreturn-type warning and then accepts it.
Weirdly, this code is rejected under -std=c++11.
$g++ -std=c++11 test.cc
test.cc: In function ‘constexpr int foo()’:
test.cc:3:2: error: body of ‘constexpr’ function ‘constexpr int foo()’ not a
return-statement
3 | {}
| ^
test.cc:3:2: warning: no return statement in function returning non-void
[-type-Wreturn-type]
I think constexpr function is not a deprecated feature in c++14. I also test
this in Clang, it is rejected by both standards.
Every GCC versions from 5.1 to trunk behave the same.
Thanks,
Haoxin
[Bug c++/96183] New: GCC accepts "convert '' from 'void' to 'int'" at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96183
Bug ID: 96183
Summary: GCC accepts "convert '' from 'void'
to 'int'" at compile time
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi,all.
This code, test.cc, is an invalid code but GCC accepts it.
$cat test.cc
void
foo (
auto,
int var = throw )
{}
$g++ test.cc
test.cc:3:5: warning: use of ‘auto’ in parameter declaration only available
with ‘-fconcepts-ts’
3 | auto,
| ^~~~
When I add -fconcepts-ts, GCC accepts this without any diagnostic message.
While in clang
$clang++ -c test.cc
test.cc:3:5: error: 'auto' not allowed in function prototype
auto,
^~~~
test.cc:4:9: error: cannot initialize a parameter of type 'int' with an rvalue
of type 'void'
int var = throw )
^ ~
test.cc:4:9: note: passing argument to parameter 'var' here
2 errors generated.
The first error is ok because GCC emits an warning. I know when call foo() will
trigger the runtime error. But should GCC emit the error message like the
second error in clang at compile time? Or is this a intentional way when GCC
dealing with "auto" in function prototype?
Every GCC versions from 6.1 to trunk behave the same.
Thanks,
Haoxin
[Bug c++/96182] GCC accepts constexpr function with no return-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96182 --- Comment #2 from Haoxin Tu --- (In reply to Jakub Jelinek from comment #1) > The difference is that in C++11 the standard requires that the body of a > constexpr function is return expression, that is not the case of C++14 > anymore. > And, you'd get an error if you tried constexpr int a = foo (); i.e. when it > is evaluated in constant expression, but when it is only evaluated e.g. in > int b = foo (); it is a problem only at runtime. Thank you, Jakub. At runtime this must be a error. But I guess should it be rejected at compile time? Maybe reject this in compile time will help users to fix this issue early, like other mainstream compilers do. Just for a suggestion, please understand if anything I stated is unsuitable. Thanks.
[Bug c++/96184] New: GCC treats "use of local variable with automatic storage from containing function" differently in versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96184
Bug ID: 96184
Summary: GCC treats "use of local variable with automatic
storage from containing function" differently in
versions
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, GCC-trunk and other versions (etc., GCC-10) treat it differently.
$cat test.cc
int main(){
int a = 10;
int const b = 10;
auto p = [ ] () noexcept ( b ? 0 : a = b) { return 0;};
return 0;
}
$g++-trunk -std=c++14 test.cc
//nothing
$g++-10 -std=c++14 test.cc
test.cc: In function ‘int main()’:
test.cc:4:40: error: use of local variable with automatic storage from
containing function
4 | auto p = [ ] () noexcept ( b ? 0 : a = b) { return 0;};
|^
test.cc:2:9: note: ‘int a’ declared here
2 | int a = 10;
| ^
I am wondering is this a enhancement of GCC-trunk?
I also test this in other GCC versions. Weirdly, only GCC-9 or GCC-10 rejects
it while other versions from 6.1 to 8.3 (also trunk) accepts it.
I don't know how GCC deals with this case and this also makes me confused.
Thanks,
Haoxin
[Bug c++/96162] [11 Regression] ICE in discriminator_for_local_entity, at cp/mangle.c:1910
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96162
--- Comment #1 from Haoxin Tu ---
Add a more case.
$cat p.cc
#include
int a() {
for (static int & b) {}
}
$g++ p.cc
test.cc: In function ‘int a()’:
test.cc:3:24: error: expected ‘;’ before ‘)’ token
3 | for (static int & b) {}
|^
|;
test.cc:3:24: error: expected primary-expression before ‘)’ token
test.cc:3:24: error: expected ‘;’ before ‘)’ token
3 | for (static int & b) {}
|^
|;
during GIMPLE pass: *build_cgraph_edges
test.cc:3:23: internal compiler error: in discriminator_for_local_entity, at
cp/mangle.c:1910
3 | for (static int & b) {}
| ^
0x63316d discriminator_for_local_entity
../../gcc/cp/mangle.c:1910
This time GCC emits "during GIMPLE pass: *build_cgraph_edges" first and then
triggers the ICE.
[Bug c++/96210] New: Diagnostic message for using-directive in template definition should be more clear?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96210
Bug ID: 96210
Summary: Diagnostic message for using-directive in template
definition should be more clear?
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
Alias template is allowed since c++11 while using-directive is not. The
diagnostic message in using-directive used in template maybe not so clear in
GCC.
For example,
$cat test.cc
namespace N{ }
template using namespace N;
$g++ test.cc
test.cc:2:24: error: expected identifier before 'namespace'
2 | template using namespace N;
|^
:2:35: error: expected '{' before ';' token
2 | template using namespace N;
|
I guess users will be confused with above two error messages and may feel
hopeless to fix it according to the diagnostic information.
Clang might be better in parsing this code
$clang++ test.cc
test.cc:2:18: error: cannot template a using directive
template using namespace N;
~^
1 error generated.
I guess GCC should also recognize the using directive first and then tell users
this is not allowed in template definition.
Please understand if anything I presented is unsuitable.
Thanks,
Haoxin
[Bug c++/96207] New: GCC accepts "delete" function definition inside a class member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96207
Bug ID: 96207
Summary: GCC accepts "delete" function definition inside a
class member function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, test.cc, is an invalid code, GCC compiles it well, while other
mainstream compiles (clang,icc,and msvc) all reject it.
$cat test.cc
class A {
void foo1 () {
void foo2 () = delete ;
}
};
$g++ -c test.cc
test.cc: In member function ‘void A::foo1()’:
test.cc:3:20: warning: declaration of ‘void foo2()’ has ‘extern’ and is
initialized
3 | void foo2 () = delete ;
|^
GCC only emits a warning message (I also doubt that the meaning of this
message) and then accepts it.
Every Clang version from 6.x onwards behaves the same.
Thanks,
Haoxin
[Bug c++/96209] New: Redundant error message split out when adding "typename" keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96209
Bug ID: 96209
Summary: Redundant error message split out when adding
"typename" keyword
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, test1.cc and test2.cc ( they are in the same meaning I guess), are
invalid code with a little mistake, but the compiling output is different when
I add the "typename" keyword. Here are the examples:
$cat test1.cc
template class T{};
:: T < int ... >
foo ( ... )
{ }
$cat test2.cc
template class T{};
typename :: T < int ... >
foo ( ... )
{ }
$g++ -w test1.cc
test1.cc:2:12: error: expansion pattern ‘int’ contains no parameter packs
2 | :: T < int ... >
|^~~
test1.cc:2:16: error: template argument 1 is invalid
2 | :: T < int ... >
|^
$g++ -w test2.cc
test2.cc:2:21: error: expansion pattern ‘int’ contains no parameter packs
2 | typename :: T < int ... >
| ^~~
test2.cc:2:25: error: template argument 1 is invalid
2 | typename :: T < int ... >
| ^
test2.cc:3:1: error: ‘foo’ in namespace ‘::’ does not name a type
3 | foo ( ... )
| ^~~
test2.cc:3:7: error: expected unqualified-id before ‘...’ token
3 | foo ( ... )
| ^~~
test2.cc:3:6: error: expected ‘)’ before ‘...’ token
3 | foo ( ... )
| ~^~~~
| )
The first two message are ok in test2.cc. And the following message in
unnecessary and useless.
While in clang, only one error message ("error: pack expansion does not contain
any unexpanded parameter packs") is edited in both two cases.
I guess GCC has some room to improve this diagnostic case. Every GCC version
from 5.x onwards behaves the same.
Thanks,
Haoxin
[Bug c++/96057] New: -Wreturn-type warning message disappears with -O1 to -Os in unnamed namespace definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96057
Bug ID: 96057
Summary: -Wreturn-type warning message disappears with -O1 to
-Os in unnamed namespace definition
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This small code, bug.cc, the -Wreturn-type warning disappears when add -O1 or
higher optimization option.
$cat bug.cc
namespace {
int foo() { 1 ? 0 : throw 0 ; }
}
$g++ -c -Wreturn-type -O0 bug.cc
bug.cc: In function 'int {anonymous}::foo()':
bug.cc:2:35: warning: control reaches end of non-void function [-Wreturn-type]
2 | int foo() { 1 ? 0 : throw 0 ; }
|
$g++ -c -Wreturn-type -O1 bug.cc
//emit nothing with -O1 to -Os option
While in Clang, the output of -O0 to -Os is the same. For example,
$clang++ -c -Wreturn-type -O1 bug.cc
bug.cc:2:35: warning: non-void function does not return a value [-Wreturn-type]
int foo() { 1 ? 0 : throw 0 ; }
^
1 warning generated.
$g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/
--enable-languages=c,c++ CC=gcc CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200630 (experimental) (GCC)
[Bug c++/95945] ICE in poplevel, at cp/decl.c:585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95945
--- Comment #1 from Haoxin Tu ---
Add a more meaningful case
$cat p.cc
int a ( auto struct x { int b ();}) {}
$g++ -w p.cc
p.cc:1:23: error: types may not be defined in parameter types
1 | int a ( auto struct x { int b ();}) {}
| ^
p.cc:1:32: internal compiler error: in poplevel, at cp/decl.c:585
1 | int a ( auto struct x { int b ();}) {}
|^
0x683eae poplevel(int, int, int)
../../gcc/cp/decl.c:585
0xa45d68 end_template_decl()
../../gcc/cp/pt.c:4688
0x9f86c2 finish_fully_implicit_template
../../gcc/cp/parser.c:44280
0xa3a12a cp_parser_member_declaration
../../gcc/cp/parser.c:25414
0xa0e061 cp_parser_member_specification_opt
../../gcc/cp/parser.c:24850
0xa0e061 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23947
0xa10213 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0xa10213 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0xa11172 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
0xa2db8f cp_parser_parameter_declaration
../../gcc/cp/parser.c:22818
0xa2e582 cp_parser_parameter_declaration_list
../../gcc/cp/parser.c:22641
0xa2e95c cp_parser_parameter_declaration_clause
../../gcc/cp/parser.c:22568
0xa1bda7 cp_parser_direct_declarator
../../gcc/cp/parser.c:21245
0xa1bda7 cp_parser_declarator
../../gcc/cp/parser.c:21109
0xa30346 cp_parser_init_declarator
../../gcc/cp/parser.c:20609
0xa11e42 cp_parser_simple_declaration
../../gcc/cp/parser.c:13785
0xa3b0b6 cp_parser_declaration
../../gcc/cp/parser.c:13484
0xa3b7fa cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0xa3b7fa c_parse_file()
../../gcc/cp/parser.c:44043
0xb5473b c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/95927] ICE in cp_lexer_new_from_tokens, at cp/parser.c:701
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95927
--- Comment #1 from Haoxin Tu ---
Add a more meaningful case.
$cat p.cc
template struct a {};
class A {
struct a < struct x { void b ( ){}} >;
};
$g++ p.cc
p.cc:3:25: error: types may not be defined in template arguments
3 | struct a < struct x { void b ( ){}} >;
| ^
p.cc:3:40: error: expected ‘;’ after struct definition
3 | struct a < struct x { void b ( ){}} >;
|^
|;
p.cc:3:39: error: expected template-argument before ‘;’ token
3 | struct a < struct x { void b ( ){}} >;
| ^
p.cc:3:39: error: expected ‘>’ before ‘;’ token
p.cc:3:5: error: ‘struct a’ redeclared with different access
3 | struct a < struct x { void b ( ){}} >;
| ^~
p.cc:3:41: error: expected unqualified-id before ‘>’ token
3 | struct a < struct x { void b ( ){}} >;
| ^
p.cc:4:1: internal compiler error: in cp_lexer_new_from_tokens, at
cp/parser.c:701
4 | };
| ^
0x6adadc cp_parser_push_lexer_for_tokens
../../gcc/cp/parser.c:701
...
While in Clang
$clang++ p.cc
p.cc:3:23: error: 'x' cannot be defined in a type specifier
struct a < struct x { void b ( ){}} >;
^
1 error generated.
I guess Clang is performed better when parsing this case. GCC emits a lot of
error messages even throw an ICE, while Clang just emits one.
[Bug c++/95956] ICE in check_bases, at cp/class.c:1689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95956
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #1 from Haoxin Tu ---
Add a more readable case.
$cat p.cc
int a ( auto struct : decltype ( auto ) {{}}){}
$g++ -w p.cc
p.cc:1:41: error: types may not be defined in parameter types
1 | int a ( auto struct : decltype ( auto ) {{}}){}
| ^
p.cc:1:42: error: expected unqualified-id before ‘{’ token
1 | int a ( auto struct : decltype ( auto ) {{}}){}
| ^
p.cc:1:21: internal compiler error: in check_bases, at cp/class.c:1689
1 | int a ( auto struct : decltype ( auto ) {{}}){}
| ^
0x658963 check_bases
../../gcc/cp/class.c:1689
0x658963 check_bases_and_members
../../gcc/cp/class.c:5900
[Bug c++/95972] ICE in check_member_template, at cp/decl2.c:570
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95972
--- Comment #1 from Haoxin Tu ---
Hi, there.
I guess I shouldn't use C-Reduce to reduce my ICE on invalid code cases. After
using C-Reduce, the cases are more like a "garbage" code.
Here is a more readable code to reproduce the ICE.
$cat p.cc
int a() {
auto var = [] ( struct s{ int b( auto);} ){};
}
$g++ -w p.cc
p.cc: In function ‘int a()’:
p.cc:2:29: error: types may not be defined in parameter types
2 | auto var = [] ( struct s{ int b( auto);} ){};
| ^
p.cc:2:42: internal compiler error: in check_member_template, at cp/decl2.c:570
2 | auto var = [] ( struct s{ int b( auto);} ){};
| ^
0x6890c4 check_member_template(tree_node*)
../../gcc/cp/decl2.c:570
0xa41c20 finish_member_template_decl(tree_node*)
../../gcc/cp/pt.c:308
0x9f86ba finish_fully_implicit_template
../../gcc/cp/parser.c:44279
0xa3a12a cp_parser_member_declaration
../../gcc/cp/parser.c:25414
0xa0e061 cp_parser_member_specification_opt
../../gcc/cp/parser.c:24850
0xa0e061 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23947
0xa10213 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0xa10213 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0xa11172 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
0xa2db8f cp_parser_parameter_declaration
../../gcc/cp/parser.c:22818
0xa2e582 cp_parser_parameter_declaration_list
../../gcc/cp/parser.c:22641
0xa2e95c cp_parser_parameter_declaration_clause
../../gcc/cp/parser.c:22568
0xa2f34e cp_parser_lambda_declarator_opt
../../gcc/cp/parser.c:11102
0xa16fb8 cp_parser_lambda_expression
../../gcc/cp/parser.c:10633
0xa16fb8 cp_parser_primary_expression
../../gcc/cp/parser.c:5443
0xa21110 cp_parser_postfix_expression
../../gcc/cp/parser.c:7296
0xa03d6a cp_parser_binary_expression
../../gcc/cp/parser.c:9609
0xa058ce cp_parser_assignment_expression
../../gcc/cp/parser.c:9914
0xa0468d cp_parser_constant_expression
../../gcc/cp/parser.c:10208
0xa04df1 cp_parser_initializer_clause
../../gcc/cp/parser.c:23272
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/95955] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have union_type in int_fits_type_p, at tree.c:8952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95955
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #1 from Haoxin Tu ---
Add a more readable case
$cat p.c
enum class a : struct{};
template < template class A >
enum class a : union b {};
enum class a { c;}
$g++ p.cc
p.cc:1:23: error: underlying type ‘’ of ‘a’ must be an integral
type
1 | enum class a : struct{};
| ^
p.cc:4:12: error: different underlying type in enum ‘enum class a’
4 | enum class a { c;}
|^
p.cc:1:23: note: previous definition here
1 | enum class a : struct{};
| ^
p.cc:4:16: internal compiler error: tree check: expected integer_type or
enumeral_type or boolean_type or real_type or fixed_point_type, have union_type
in int_fits_type_p, at tree.c:8952
4 | enum class a { c;}
|^
[Bug c++/95931] ICE in dependent_type_p, at cp/pt.c:26326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95931
--- Comment #1 from Haoxin Tu ---
Add a more meaningful case.
$cat p.cc
void a() {
auto var = [] (auto, volatile b) {};
}
$g++ p.cc
p.cc: In function ‘void a()’:
p.cc:2:35: error: ‘b’ does not name a type
2 | auto var = [] (auto, volatile b) {};
| ^
p.cc:2:40: error: expected ‘)’ before ‘;’ token
2 | auto var = [] (auto, volatile b) {};
| ~^
|)
p.cc:2:40: internal compiler error: in dependent_type_p, at cp/pt.c:26326
0x6c0f63 dependent_type_p(tree_node*)
../../gcc/cp/pt.c:26326
While in Clang
$clang++ p.cc
p.cc:2:35: error: unknown type name 'b'
auto var = [] (auto, volatile b) {};
^
1 error generated.
Noted that why GCC emits "expected ‘)’ before ‘;’ token" and has an ICE on the
";"?
Also, this situation may happen in the real world when someone just leaves a
type specifier out by a mistake.
[Bug c++/95932] ICE in redeclare_class_template, at cp/pt.c:6231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95932
--- Comment #1 from Haoxin Tu ---
Add a more meaningful case.
$cat p.cc
template class a {};
template >
struct a < class b{}, struct b {}>;
$g++ p.cc
p.cc:2:28: error: expected ‘class’ or ‘typename’ before ‘>’ token
2 | template >
|^
p.cc:3:19: error: types may not be defined in template arguments
3 | struct a < class b{}, struct b {}>;
| ^
p.cc:3:30: internal compiler error: in redeclare_class_template, at
cp/pt.c:6231
3 | struct a < class b{}, struct b {}>;
| ^
0x6be12f redeclare_class_template(tree_node*, tree_node*, tree_node*)
../../gcc/cp/pt.c:6231
...
While in Clang
$clang++ p.cc
p.cc:2:28: error: template template parameter requires 'class' after the
parameter list
template >
^
class
p.cc:3:18: error: 'b' cannot be defined in a type specifier
struct a < class b{}, struct b {}>;
^
2 errors generated.
I guess this is also a possible issue that users may encounter in programming,
but it makes GCC crashed.
[Bug c++/96045] New: Wrong line and column diagnostic message in a class template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96045
Bug ID: 96045
Summary: Wrong line and column diagnostic message in a class
template instantiation
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This simple code, bug.cc, GCC-trunk can not emit the right diagnostic
information.
$cat bug.cc
template class A {};
struct A
$g++ -c bug.cc
bug.cc:3: error: expected unqualified-id at end of input
Noted that the number 3 is not a line number nor a column number.
While in Clang
$clang++ -c bug.cc
bug.cc:2:16: error: expected unqualified-id
struct A
^
1 error generated.
$g++ --version
g++ (GCC) 11.0.0 20200630 (experimental)
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.
[Bug c++/96068] New: Extra semicolon outside of a function should be allowed after c++11?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96068
Bug ID: 96068
Summary: Extra semicolon outside of a function should be
allowed after c++11?
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
As the summary, extra ";" should be allowed in GCC after -std=c++11 and
shouldn't give a diagnostic message about it? I know this is forbidden in
c++98.
For example,
$cat test.cc
void foo() { };
$g++ -c -std=c++98 -pedantic-errors test.cc
test.cc:1:16: error: extra ';' [-Wpedantic]
1 | void foo () { };
|^
$g++ -c -std=c++11 -pedantic-errors test.cc
test.cc:1:16: error: extra ';' [-Wpedantic]
1 | void foo () { };
|^
While in Clang, this is accepted in c++11 or later.
$clang++ -c -std=c++98 -pedantic-errors test.cc
test.cc:1:15: error: extra ';' outside of a function is a C++11 extension
[-Werror,-Wc++11-extra-semi]
void foo() { };
^
1 error generated.
There is also a related bug report in llvm:
https://bugs.llvm.org/show_bug.cgi?id=46288
They suggested that "If GCC rejects this under -pedantic-errors in C++11 or
later, I think that's a GCC bug."
I try to find a similar bug report in GCC but failed.
Did I miss something? Thank you very much.
[Bug c++/96048] New: ICE in get_local_decls, at cp/name-lookup.c:3591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96048
Bug ID: 96048
Summary: ICE in get_local_decls, at cp/name-lookup.c:3591
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This invalid code, bug.cc, makes GCC-trunk ICE.
$cat bug.cc
struct a {template class A;};
a : b ( auto ) ( class { });
$g++ -c -w bug.cc
bug.cc:2:3: error: found ‘:’ in nested-name-specifier, expected ‘::’
2 | a : b ( auto ) ( class { });
| ^
| ::
bug.cc:2:18: error: template definition of non-template ‘struct a::’
2 | a : b ( auto ) ( class { });
| ^
bug.cc:2:27: internal compiler error: in get_local_decls, at
cp/name-lookup.c:3591
2 | a : b ( auto ) ( class { });
| ^
0x63d349 get_local_decls()
../../gcc/cp/name-lookup.c:3591
0x97a185 pop_bindings_and_leave_scope()
../../gcc/cp/name-lookup.c:2065
0x9b0969 cp_parser_direct_declarator
../../gcc/cp/parser.c:21336
0x9b0969 cp_parser_declarator
../../gcc/cp/parser.c:21109
0x9c4ca6 cp_parser_init_declarator
../../gcc/cp/parser.c:20609
0x9a67a2 cp_parser_simple_declaration
../../gcc/cp/parser.c:13785
0x9cfa16 cp_parser_declaration
../../gcc/cp/parser.c:13484
0x9d015a cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0x9d015a c_parse_file()
../../gcc/cp/parser.c:44043
0xae920b c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
++ (GCC) 11.0.0 20200630 (experimental)
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.
[Bug c++/96162] New: [11 Regression] ICE in discriminator_for_local_entity, at cp/mangle.c:1910
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96162
Bug ID: 96162
Summary: [11 Regression] ICE in discriminator_for_local_entity,
at cp/mangle.c:1910
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, test.cc, is an invalid code, makes GCC-trunk ICE. Interestingly,
this code does not trigger other released GCC-10 or GCC-9 ICE (confused by
earlier errors, bailing out). I guess this is a special regression
error-recovery case that is different from others.
$cat test.cc
#include
void foo() {
for (thread_local int * a ){}
}
$g++ test.cc
test.cc: In function ‘void foo()’:
test.cc:3:30: error: expected ‘;’ before ‘)’ token
3 | for (thread_local int * a ){}
| ^~
| ;
test.cc:3:31: error: expected primary-expression before ‘)’ token
3 | for (thread_local int * a ){}
| ^
test.cc:3:30: error: expected ‘;’ before ‘)’ token
3 | for (thread_local int * a ){}
| ^~
| ;
test.cc: At global scope:
test.cc:3:29: internal compiler error: in discriminator_for_local_entity, at
cp/mangle.c:1910
3 | for (thread_local int * a ){}
| ^
0x69e943 discriminator_for_local_entity
../../gcc/cp/mangle.c:1910
0x9cdee8 write_local_name
../../gcc/cp/mangle.c:2019
0x9cdee8 write_name
../../gcc/cp/mangle.c:973
0x9d05a7 write_encoding
../../gcc/cp/mangle.c:825
0x9d5981 mangle_decl_string
../../gcc/cp/mangle.c:3858
0x9d5ba6 get_mangled_id
../../gcc/cp/mangle.c:3879
0x9d5ba6 mangle_decl(tree_node*)
../../gcc/cp/mangle.c:3917
0x12fca7d decl_assembler_name(tree_node*)
../../gcc/tree.c:708
0xbf17d9 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool)
../../gcc/symtab.c:174
0xbf193c symbol_table::symtab_initialize_asm_name_hash()
../../gcc/symtab.c:266
0xbf2334 symbol_table::symtab_initialize_asm_name_hash()
../../gcc/symtab.c:1033
0xbf2334 symtab_node::get_for_asmname(tree_node const*)
../../gcc/symtab.c:1021
0xc02e60 handle_alias_pairs
../../gcc/cgraphunit.c:1512
0xc08ccc symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2962
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/compilers/gcc/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure CC=gcc-10 CXX=g++-10
--prefix=/home/haoxin/compilers/gcc/build/ --enable-languages=c,c++
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200708 (experimental) (GCC)
Thanks,
Haoxin
[Bug c++/96077] New: GCC accepts ill-legal local enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077
Bug ID: 96077
Summary: GCC accepts ill-legal local enum definition
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, test.cc, has a grammar issue in "missing ')'", but GCC accepts it
well.
$cat test.cc
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 } g_e; //reject
int main () {
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 /* missing ")" here */ } l_e; //accept
return 0;
}
$g++ test.cc
test.cc:1:35: error: expected ‘)’ before ‘}’ token
1 | enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 } g_e; //reject
|~ ^~
| )
GCC only rejects line 1 but accepts line 3.
While in Clang
$clang++ test.cc
test.cc:1:36: error: expected ')'
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 } g_e; //reject
^
test.cc:1:28: note: to match this '('
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 } g_e; //reject
^
test.cc:3:63: error: expected ')'
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 /* missing ")" here */ } l_e; //accept
^
test.cc:3:32: note: to match this '('
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 /* missing ")" here */ } l_e; //accept
^
2 errors generated.
$g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/
--enable-languages=c,c++ CC=gcc CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200630 (experimental) (GCC)
[Bug c++/96103] New: Unclear diagnostic for a function return with "decltype(auto)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96103
Bug ID: 96103
Summary: Unclear diagnostic for a function return with
"decltype(auto)"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, "decltype(auto)" in return type is a c++14 extension and I guess GCC
might diagnose this better.
$cat test.cc
decltype(auto) foo () {}
$g++ -c -std=c++11 test.cc
test.cc:1:10: error: expected primary-expression before ‘auto’
1 | decltype(auto) foo () {}
| ^~~~
test.cc: In function ‘int foo()’:
test.cc:1:24: warning: no return statement in function returning non-void
[-Wreturn-type]
1 | decltype(auto) foo () {}
|^
$g++ -c -std=c++14 test.cc
//emits nothing
While in Clang:
$clang++ -c -std=c++11 test.cc
test.cc:1:10: warning: 'decltype(auto)' type specifier is a C++14 extension
[-Wc++14-extensions]
decltype(auto) foo () {}
^
test.cc:1:1: error: deduced return types are a C++14 extension
decltype(auto) foo () {}
^
1 warning and 1 error generated.
I guess users can not fix the code according to the errors emitted until they
realized this is a C++14 extension.
Should GCC recognizes the C++14 extension first when parsing this code and then
emits the appropriate diagnostic information?
Thanks,
Haoxin
[Bug c++/95742] New: Bad error message in parsing a function with "decltype()"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95742
Bug ID: 95742
Summary: Bad error message in parsing a function with
"decltype()"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
CC: redi at gcc dot gnu.org
Target Milestone: ---
This code test.cc, I think it's not a garbage input for GCC, but it parses
badly and emits some confusing error messages.
$cat test.cc
int foo( decltype(),int) { }
$g++-trunk -c -w test.cc
test.cc:1:19: error: expected primary-expression before ‘)’ token
1 | int foo( decltype(),int) { }
| ^
test.cc:1:10: error: expected primary-expression before ‘decltype’
1 | int foo( decltype(),int) { }
| ^~
test.cc:1:21: error: expected primary-expression before ‘int’
1 | int foo( decltype(),int) { }
| ^~~
test.cc:1:24: error: expression list treated as compound expression in
initializer [-fpermissive]
1 | int foo( decltype(),int) { }
|^
While in Clang
$clang++ -c -w test.cc
test.cc:1:19: error: expected expression
int foo( decltype(),int) { }
^
1 error generated.
When I change the code into test1.cc, GCC get following results:
$cat test1.cc
void foo( decltype(),int) { }
$g++-trunk -c -w test1.cc
test1.cc:1:6: error: variable or field ‘foo’ declared void
1 | void foo( decltype(),int) { }
| ^~~
test1.cc:1:20: error: expected primary-expression before ‘)’ token
1 | void foo( decltype(),int) { }
|^
test1.cc:1:11: error: expected primary-expression before ‘decltype’
1 | void foo( decltype(),int) { }
| ^~
test1.cc:1:22: error: expected primary-expression before ‘int’
1 | void foo( decltype(),int) { }
This time GCC emits "error: variable or field ‘foo’ declared void"?
Also in Clang
$clang++ -c -w test1.cc
test1.cc:1:20: error: expected expression
void foo( decltype(),int) { }
^
1 error generated.
I guess GCC might can not recognize the function definition correctly?
[Bug c++/95725] New: Confusing error diagnostic in an invalid template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725 Bug ID: 95725 Summary: Confusing error diagnostic in an invalid template Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- This code test.cc, makes GCC get confused while parsing. $cat test.cc template ’ before ‘;’ token test.cc:1:22: error: expected unqualified-id before ‘;’ token $g++-10 -w -c test.cc test.cc:1:20: error: expected primary-expression before ‘=’ token 1 | template ’ before ‘;’ token 1 | template ’ before ‘decltype’ 1 | template
[Bug c++/95724] bogue error : "expected '{' before ')' token"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95724 --- Comment #2 from Haoxin Tu --- (In reply to Martin Liška from comment #1) > For the next time, can you please add 'ice-on-invalid-code' keyword? I got it. So sorry for my mistake!
[Bug c++/95724] New: bogue error : "expected '{' before ')' token"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95724
Bug ID: 95724
Summary: bogue error : "expected '{' before ')' token"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code test.cc, GCC-trunk get a bogus error message and then get confused
with following code parsing.
$cat test.cc
template <(union : decltype(a = 0)>)
$g++-trunk -w -c test.cc
test.cc:1:11: error: expected identifier before ‘(’ token
1 | template <(union : decltype(a = 0)>)
| ^
test.cc:1:29: error: ‘a’ was not declared in this scope
1 | template <(union : decltype(a = 0)>)
| ^
test.cc:1:29: error: ‘a’ was not declared in this scope
test.cc:1:34: error: expected ‘{’ before ‘)’ token
1 | template <(union : decltype(a = 0)>)
| ^
test.cc:1:36: error: expected unqualified-id before ‘)’ token
1 | template <(union : decltype(a = 0)>)
|^
$g++-10 -w -c test.cc
test.cc:1:11: error: expected identifier before ‘(’ token
1 | template <(union : decltype(a = 0)>)
| ^
test.cc:1:29: error: ‘a’ was not declared in this scope
1 | template <(union : decltype(a = 0)>)
| ^
test.cc:1:29: error: ‘a’ was not declared in this scope
test.cc:1:35: error: expected ‘{’ before ‘>’ token
1 | template <(union : decltype(a = 0)>)
| ^
test.cc:1:35: error: expected ‘,’ or ‘...’ before ‘>’ token
test.cc:1:36: error: expected ‘>’ at end of input
1 | template <(union : decltype(a = 0)>)
|^
test.cc:1:36: error: expected unqualified-id at end of input
I guess GCC-trunk emits the bogus error message "expected ‘{’ before ‘)’
token", and the following error messages are inconsistent with GCC-10. So,
GCC-trunk might have something wrong with while parsing this code.
[Bug c++/95725] Confusing error diagnostic in an invalid template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725 --- Comment #2 from Haoxin Tu --- (In reply to Martin Liška from comment #1) > For the next time, can you please add 'ice-on-invalid-code' keyword? Ok, so sorry it's my fault. But this is a diagnostic issue I think? I will add "diagnostic" keywords next time.
[Bug c++/95723] New: GCC get confused while parsing a code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95723 Bug ID: 95723 Summary: GCC get confused while parsing a code Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- This code test.cc, GCC might get confused in parsing. $cat test.cc template friend foo ( decltype (b=c $g++-trunk -w test.cc test.cc:1:12: error: ‘a’ has not been declared 1 | template friend foo( decltype (b=c |^ test.cc:1:14: error: ‘friend’ used outside of class 1 | template friend foo( decltype (b=c | ^~ | -- test.cc:1:36: error: ‘b’ was not declared in this scope 1 | template friend foo( decltype (b=c |^ test.cc:1:36: error: ‘b’ was not declared in this scope test.cc:1:38: error: ‘c’ was not declared in this scope 1 | template friend foo( decltype (b=c | ^ test.cc:2: error: expected ‘,’ or ‘...’ at end of input test.cc:1:39: error: expected ‘)’ at end of input 1 | template friend foo( decltype (b=c |~ ^ | ) test.cc:2: error: expected initializer at end of input $g++-10 -w test.cc test.cc:1:12: error: ‘a’ has not been declared 1 | template friend foo( decltype (b=c |^ test.cc:1:14: error: ‘friend’ used outside of class 1 | template friend foo( decltype (b=c | ^~ | -- test.cc:1:36: error: ‘b’ was not declared in this scope 1 | template friend foo( decltype (b=c |^ test.cc:1:36: error: ‘b’ was not declared in this scope test.cc:1:38: error: ‘c’ was not declared in this scope 1 | template friend foo( decltype (b=c | ^ test.cc:1:36: error: ‘b’ was not declared in this scope 1 | template friend foo( decltype (b=c |^ test.cc:1:36: error: ‘b’ was not declared in this scope test.cc:1:38: error: ‘c’ was not declared in this scope 1 | template friend foo( decltype (b=c | ^ test.cc:1:36: error: ‘b’ was not declared in this scope 1 | template friend foo( decltype (b=c |^ test.cc:1:36: error: ‘b’ was not declared in this scope test.cc:1:38: error: ‘c’ was not declared in this scope 1 | template friend foo( decltype (b=c | ^ test.cc:1:21: error: ISO C++ forbids declaration of ‘foo’ with no type [-fpermissive] 1 | template friend foo( decltype (b=c | ^~~ test.cc:1:36: error: ‘b’ was not declared in this scope 1 | template friend foo( decltype (b=c |^ test.cc:1:36: error: ‘b’ was not declared in this scope test.cc:1:38: error: ‘c’ was not declared in this scope 1 | template friend foo( decltype (b=c | ^ test.cc:1:39: error: expected ‘)’ at end of input 1 | template friend foo( decltype (b=c | ~ ~^ | ) test.cc:1:26: error: expected primary-expression before ‘decltype’ 1 | template friend foo( decltype (b=c | ^ test.cc:1:39: error: expected ‘;’ at end of input 1 | template friend foo( decltype (b=c | ~^ | ; I am sure that some error messages in GCC-10 are duplicated. I am also wondering why GCC-trunk emits "error: expected initializer at end of input", that's so confusing.
[Bug c++/95744] New: Duplicate error message in a simple decltype specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95744 Bug ID: 95744 Summary: Duplicate error message in a simple decltype specifier Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com CC: mpolacek at gcc dot gnu.org, redi at gcc dot gnu.org Target Milestone: --- The test.cc includes a very simple valid decltype specifier with an undeclared variable(I am definitely sure), but GCC emits two duplicated error messages on it. $cat test.cc decltype(var) i = 100; $g++-trunk -c -w test.cc test.cc:1:10: error: ‘var’ was not declared in this scope 1 | decltype(var) i = 100; | ^~~ test.cc:1:10: error: ‘var’ was not declared in this scope While in clang $clang++ -c -w test.cc test.cc:1:10: error: use of undeclared identifier 'var' decltype(var) i = 100; ^ 1 error generated. My GCC version is $g++-trunk --version g++ (GCC) 11.0.0 20200605 (experimental) 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.
[Bug c++/95831] New: Wrong line number in " -Wconversion" warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95831
Bug ID: 95831
Summary: Wrong line number in " -Wconversion" warning message
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
Target Milestone: ---
This code, bug.cc, GCC might emit the wrong line number of the "-Wconversion"
warning.
$cat bug.cc
unsigned a = 0;
void foo (
short param1 = a,
short param2 = a,
char param3 = a)
{}
$g++ -Wconversion -c bug.cc
bug.cc:6:20: warning: conversion from 'unsigned int' to 'short int' may change
value [-Wconversion]
6 | char param3 = a)
|^
bug.cc:6:20: warning: conversion from 'unsigned int' to 'short int' may change
value [-Wconversion]
bug.cc:6:20: warning: conversion from 'unsigned int' to 'char' may change value
[-Wconversion]
Compiler returned: 0
While in Clang:
$clang++ -Wconversion -c bug.cc
bug.cc:3:21: warning: implicit conversion loses integer precision: 'unsigned
int' to 'short' [-Wimplicit-int-conversion]
short param1 = a,
~ ^
bug.cc:4:21: warning: implicit conversion loses integer precision: 'unsigned
int' to 'short' [-Wimplicit-int-conversion]
short param2 = a,
~ ^
bug.cc:5:19: warning: implicit conversion loses integer precision: 'unsigned
int' to 'char' [-Wimplicit-int-conversion]
char param3 = a)
~ ^
3 warnings generated.
Reproduced in godblot: https://godbolt.org/z/AoGkVQ
Noted that I have tested it in almost all GCC versions, they all have this
issue. I guess maybe someone have reported this already, but I can't find one.
[Bug c++/95872] New: Duplicated warning message in "-Wlogical-op"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95872 Bug ID: 95872 Summary: Duplicated warning message in "-Wlogical-op" Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com CC: mpolacek at gcc dot gnu.org Target Milestone: --- This code, bug.cc, GCC emits two duplicated warning messages about it. $cat bug.cc int a = 10; decltype(( a or a ) ? 1:0) var = 0; $g++ -c -Wlogical-op bug.cc bug.cc:2:14: warning: logical 'or' of equal expressions [-Wlogical-op] 2 | decltype(( a or a ) ? 1:0) var = 0; |~~^~~~ bug.cc:2:14: warning: logical 'or' of equal expressions [-Wlogical-op] All GCC-6 to GCC-trunk versions have this issue.
[Bug c++/95873] New: Duplicated warning message "'class' tag used in naming 'union a'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95873
Bug ID: 95873
Summary: Duplicated warning message "'class' tag used in naming
'union a'"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
Target Milestone: ---
This code, bug.cc, GCC emits two duplicated warning messages.
$cat bug.cc
union a{};
auto var = new (typename :: a );
$g++ -c -fpermissive bug.cc
bug.cc:2:29: warning: 'class' tag used in naming 'union a' [-fpermissive]
2 | auto var = new (typename :: a );
| ^
bug.cc:1:7: note: 'union a' was previously declared here
1 | union a{};
| ^
bug.cc:2:29: warning: 'class' tag used in naming 'union a' [-fpermissive]
2 | auto var = new (typename :: a );
| ^
bug.cc:1:7: note: 'union a' was previously declared here
1 | union a{};
| ^
All GCC-6 to GCC-trunk versions have this issue.
[Bug c++/95871] New: Duplicated error message : "the value is not usable in a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95871
Bug ID: 95871
Summary: Duplicated error message : "the value is not usable in
a constant expression"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
Target Milestone: ---
This code, bug.cc, GCC emits two duplicated error messages in "the value of ‘a’
is not usable in a constant expression".
$cat bug.cc
long a = 10;
enum E { emator_1 = a } enum_var;
$g++ -c bug.cc
bug.cc:2:21: error: the value of ‘a’ is not usable in a constant expression
2 | enum E { emator_1 = a } enum_var;
| ^
bug.cc:1:6: note: ‘long int a’ is not const
1 | long a = 10;
| ^
bug.cc:2:21: error: the value of ‘a’ is not usable in a constant expression
2 | enum E { emator_1 = a } enum_var;
| ^
bug.cc:1:6: note: ‘long int a’ is not const
1 | long a = 10;
| ^
bug.cc:2:21: error: enumerator value for ‘emator_1’ is not an integer constant
2 | enum E { emator_1 = a } enum_var;
|
While in clang
$clang++ -c bug.cc
bug.cc:2:21: error: expression is not an integral constant expression
enum E { emator_1 = a } enum_var;
^
bug.cc:2:21: note: read of non-const variable 'a' is not allowed in a constant
expression
bug.cc:1:6: note: declared here
long a = 10;
^
1 error generated.
I have tested in almost all GCC versions, they all have this issue.
[Bug c++/95875] New: Misleading error message "invalid use of incomplete type"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95875
Bug ID: 95875
Summary: Misleading error message "invalid use of incomplete
type"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
Target Milestone: ---
$cat bug.cc
class A:
public
A,
A,
A
{} g_class;
$g++ -c bug.cc
bug.cc:5:1: error: invalid use of incomplete type ‘class A’
5 | A
| ^
bug.cc:1:7: note: forward declaration of ‘class A’
1 | class A:
| ^
bug.cc:5:1: error: invalid use of incomplete type ‘class A’
5 | A
| ^
bug.cc:1:7: note: forward declaration of ‘class A’
1 | class A:
| ^
bug.cc:5:1: error: invalid use of incomplete type ‘class A’
5 | A
| ^
bug.cc:1:7: note: forward declaration of ‘class A’
1 | class A:
| ^
While in clang
$clang++ -c bug.cc
bug.cc:3:1: error: base class has incomplete type
A,
^
bug.cc:1:7: note: definition of 'A' is not complete until the closing '}'
class A:
^
1 error generated.
I doubt that how GCC deals with this case. I guess there might be two
situations:
1. GCC gives the wrong line number.
2. GCC just emits the duplicated messages.
I guess GCC might have the second issue. I have tested in almost all GCC
versions, and they all have this issue.
[Bug c++/95892] Wrong line number in "-Wsign-conversion" warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95892 --- Comment #3 from Haoxin Tu --- (In reply to Jonathan Wakely from comment #1) > This is a well-known issue where diagnostics in function parameter-lists all > have the location of the closing brace. Thank you, Jonathan. I guess bug 95831 has the same issue, too.
[Bug c++/95809] GCC treats inline namespace declaration as "ambiguous"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95809 --- Comment #3 from Haoxin Tu --- (In reply to Nathan Sidwell from comment #2) > yup, dr2061 made that ill-formed. > > p1701 (wg21.link/p1701) documents the behaviour and it appears EWG is > exploring another avenue to resolve the underlying problem 2061 was > attempting to fix. Thank you, Nathan, so this is a valid code, right?
[Bug c++/95932] New: ICE in redeclare_class_template, at cp/pt.c:6231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95932
Bug ID: 95932
Summary: ICE in redeclare_class_template, at cp/pt.c:6231
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE.
$cat bug.cc
template > struct a < class b{}, struct b {
$g++ bug.cc
bug.cc:1:19: error: expected ‘<’ before ‘>>’ token
1 | template > struct a < class b{}, struct b {
| ^~
bug.cc:1:19: error: expected identifier before ‘>>’ token
bug.cc:1:19: error: expected ‘>’ before ‘>>’ token
bug.cc:1:19: error: expected ‘class’ or ‘typename’ before ‘>>’ token
bug.cc:1:19: error: expected identifier before ‘>>’ token
bug.cc:1:19: error: expected ‘>’ before ‘>>’ token
bug.cc:1:29: error: ‘a’ is not a class template
1 | template > struct a < class b{}, struct b {
| ^
bug.cc:1:40: error: types may not be defined in template arguments
1 | template > struct a < class b{}, struct b {
|^
bug.cc:1:51: internal compiler error: in redeclare_class_template, at
cp/pt.c:6231
1 | template > struct a < class b{}, struct b {
| ^
0x652319 redeclare_class_template(tree_node*, tree_node*, tree_node*)
../../gcc/cp/pt.c:6231
0x8fb2e7 xref_tag_1
../../gcc/cp/decl.c:15043
0x8fb440 xref_tag(tag_types, tree_node*, tag_scope, bool)
../../gcc/cp/decl.c:15085
0x9a1584 cp_parser_class_head
../../gcc/cp/parser.c:24658
0x9a1584 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23880
0x9a1aa3 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0x9a1aa3 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0x9b6b53 cp_parser_type_specifier_seq
../../gcc/cp/parser.c:22439
0x9afa94 cp_parser_type_id_1
../../gcc/cp/parser.c:22256
0x9b2603 cp_parser_template_type_arg
../../gcc/cp/parser.c:22347
0x9b6ccf cp_parser_template_argument
../../gcc/cp/parser.c:17235
0x9b6ccf cp_parser_template_argument_list
../../gcc/cp/parser.c:17146
0x9b6ccf cp_parser_enclosed_template_argument_list
../../gcc/cp/parser.c:29832
0x9b8cd0 cp_parser_check_for_invalid_template_id
../../gcc/cp/parser.c:3202
0x99ff18 cp_parser_check_for_invalid_template_id
../../gcc/cp/parser.c:3181
0x99ff18 cp_parser_class_head
../../gcc/cp/parser.c:24437
0x99ff18 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23880
0x9a1aa3 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0x9a1aa3 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0x9a2a02 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
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.
[Bug c++/95925] New: ICE in xref_basetypes, at cp/decl.c:15169
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95925 Bug ID: 95925 Summary: ICE in xref_basetypes, at cp/decl.c:15169 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- This code, bug.cc, reduced by C-Reduce, makes GCC ICE. $cat bug.cc class a; template https://gcc.gnu.org/bugs/> for instructions. $g++ --version g++ (GCC) 11.0.0 20200626 (experimental) 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.
[Bug c++/95927] New: ICE in cp_lexer_new_from_tokens, at cp/parser.c:701
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95927
Bug ID: 95927
Summary: ICE in cp_lexer_new_from_tokens, at cp/parser.c:701
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, reduced by C-Reduce, makes GCC ICE.
$cat bug.cc
class {
struct a < struct { b ( {
$g++ bug.cc
bug.cc:2:8: error: ‘a’ is not a class template
2 | struct a < struct { b ( {
|^
bug.cc:2:19: error: types may not be defined in template arguments
2 | struct a < struct { b ( {
| ^
bug.cc:2:25: error: expected identifier before ‘{’ token
2 | struct a < struct { b ( {
| ^
bug.cc:2:24: error: expected ‘)’ before ‘{’ token
2 | struct a < struct { b ( {
| ~^~
|)
bug.cc:2:21: error: ISO C++ forbids declaration of ‘b’ with no type
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-fpermissive-fpermissive]8;;]
2 | struct a < struct { b ( {
| ^
bug.cc:3: error: expected ‘}’ at end of input
bug.cc:2:19: note: to match this ‘{’
2 | struct a < struct { b ( {
| ^
bug.cc:3: error: expected template-argument at end of input
bug.cc:3: error: expected ‘>’ at end of input
bug.cc:3: error: expected ‘{’ or ‘:’ at end of input
bug.cc:3: error: expected ‘{’ at end of input
bug.cc:3: error: expected unqualified-id at end of input
bug.cc:3: error: expected ‘}’ at end of input
bug.cc:1:7: note: to match this ‘{’
1 | class {
| ^
bug.cc:3: internal compiler error: in cp_lexer_new_from_tokens, at
cp/parser.c:701
0x641d4d cp_parser_push_lexer_for_tokens
../../gcc/cp/parser.c:701
0x9c2bc5 cp_parser_late_parsing_for_member
../../gcc/cp/parser.c:29944
0x9a0ccb cp_parser_class_specifier_1
../../gcc/cp/parser.c:24230
0x9a1aa3 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0x9a1aa3 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0x9a2a02 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
0x9a35c1 cp_parser_simple_declaration
../../gcc/cp/parser.c:13664
0x9cc926 cp_parser_declaration
../../gcc/cp/parser.c:13484
0x9cd06a cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0x9cd06a c_parse_file()
../../gcc/cp/parser.c:44043
0xae4dbb c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
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.
[Bug c++/95930] New: ICE: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95930
Bug ID: 95930
Summary: ICE: Segmentation fault signal terminated program
cc1plus
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE with Segmentation
fault signal terminated program cc1plus.
$cat bug.cc
long a = [] ( class {
$g++ bug.cc
bug.cc:1:24: error: types may not be defined in parameter types
1 | long a = [] ( class {
|^
bug.cc:2: error: expected ‘}’ at end of input
bug.cc:1:24: note: to match this ‘{’
1 | long a = [] ( class {
|^
bug.cc:2: error: expected ‘,’ or ‘...’ at end of input
bug.cc:1:25: error: expected ‘)’ at end of input
1 | long a = [] ( class {
|~^
| )
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
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.
[Bug c++/95931] New: ICE in dependent_type_p, at cp/pt.c:26326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95931
Bug ID: 95931
Summary: ICE in dependent_type_p, at cp/pt.c:26326
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE.
$cat bug.cc
void a { [] (auto, volatile b
$g++ bug.cc
bug.cc:1:6: error: variable or field ‘a’ declared void
1 | void a { [] (auto, volatile b
| ^
bug.cc:1:29: error: ‘b’ does not name a type
1 | void a { [] (auto, volatile b
| ^
bug.cc:2: error: expected ‘,’ or ‘...’ at end of input
bug.cc:1:30: error: expected ‘)’ at end of input
1 | void a { [] (auto, volatile b
| ~^
| )
bug.cc:2: internal compiler error: in dependent_type_p, at cp/pt.c:26326
0x6551ca dependent_type_p(tree_node*)
../../gcc/cp/pt.c:26326
0x8fc1bb require_complete_types_for_parms
../../gcc/cp/decl.c:13832
0x8fc1bb check_function_type
../../gcc/cp/decl.c:16043
0x8fc1bb start_preparsed_function(tree_node*, tree_node*, int)
../../gcc/cp/decl.c:16257
0x956a15 start_lambda_function(tree_node*, tree_node*)
../../gcc/cp/lambda.c:1425
0x9a912b cp_parser_lambda_body
../../gcc/cp/parser.c:11264
0x9a912b cp_parser_lambda_expression
../../gcc/cp/parser.c:10640
0x9a912b cp_parser_primary_expression
../../gcc/cp/parser.c:5443
0x9b2960 cp_parser_postfix_expression
../../gcc/cp/parser.c:7296
0x99564a cp_parser_binary_expression
../../gcc/cp/parser.c:9609
0x9971ae cp_parser_assignment_expression
../../gcc/cp/parser.c:9914
0x995f6d cp_parser_constant_expression
../../gcc/cp/parser.c:10208
0x9966d1 cp_parser_initializer_clause
../../gcc/cp/parser.c:23272
0x99683a cp_parser_initializer_list
../../gcc/cp/parser.c:23550
0x99683a cp_parser_braced_list
../../gcc/cp/parser.c:23311
0x99aa3a cp_parser_initializer
../../gcc/cp/parser.c:23228
0x9c259b cp_parser_init_declarator
../../gcc/cp/parser.c:20903
0x9a36d2 cp_parser_simple_declaration
../../gcc/cp/parser.c:13785
0x9cc926 cp_parser_declaration
../../gcc/cp/parser.c:13484
0x9cd06a cp_parser_translation_unit
../../gcc/cp/parser.c:4761
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
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.
[Bug c++/95935] New: ICE : Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95935
Bug ID: 95935
Summary: ICE : Segmentation fault
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE with Segmentation
fault.
$cat bug.cc
enum struct a;
template enum struct a {
$g++ bug.cc
bug.cc:2:36: error: expected ‘}’ before ‘;’ token
2 | template ’ before ‘;’ token
bug.cc:2:36: error: expected unqualified-id before ‘;’ token
bug.cc:4: error: expected identifier at end of input
bug.cc:4: error: expected ‘}’ at end of input
bug.cc:3:27: note: to match this ‘{’
3 | template <> enum struct a {
| ^
bug.cc:2:35: internal compiler error: Segmentation fault
2 | template https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
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.
[Bug c++/95954] New: ICE: unexpected expression ‘(a)’ of kind paren_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95954 Bug ID: 95954 Summary: ICE: unexpected expression ‘(a)’ of kind paren_expr Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: error-recovery, ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE. $cat bug.cc short a; thread_local b ( auto , = ( a ; $g++ -w bug.cc bug.cc:2:25: error: expected identifier before ‘=’ token 2 | thread_local b ( auto , = ( a ; | ^ bug.cc:2:30: error: expected ‘)’ before ‘;’ token 2 | thread_local b ( auto , = ( a ; | ~ ^~ | ) bug.cc:2:30: error: expected ‘)’ before ‘;’ token 2 | thread_local b ( auto , = ( a ; |~ ^~ | ) bug.cc:2:14: error: ISO C++ forbids declaration of ‘b’ with no type []8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-fpermissive-fpermissive]8;;] 2 | thread_local b ( auto , = ( a ; | ^ bug.cc:2:31: internal compiler error: unexpected expression ‘(a)’ of kind paren_expr 2 | thread_local b ( auto , = ( a ; | ^ 0x8b06d4 cxx_eval_constant_expression ../../gcc/cp/constexpr.c:6503 0x8b0c1f cxx_eval_outermost_constant_expr ../../gcc/cp/constexpr.c:6708 0x8b500b maybe_constant_value(tree_node*, tree_node*, bool) ../../gcc/cp/constexpr.c:6981 0x8ddc74 cp_fully_fold(tree_node*) ../../gcc/cp/cp-gimplify.c:2464 0x8e51cf cp_convert_and_check(tree_node*, tree_node*, int) ../../gcc/cp/cvt.c:661 0x8724df convert_like_real ../../gcc/cp/call.c:7865 0x873c29 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int) ../../gcc/cp/call.c:11870 0x8f887f check_default_argument(tree_node*, tree_node*, int) ../../gcc/cp/decl.c:13923 0x8f8edf grokparms(tree_node*, tree_node**) ../../gcc/cp/decl.c:14111 0x90a23b grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*, decl_context, int, tree_node**) ../../gcc/cp/decl.c:12393 0x915628 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) ../../gcc/cp/decl.c:5233 0x9c1e6d cp_parser_init_declarator ../../gcc/cp/parser.c:20818 0x9a36d2 cp_parser_simple_declaration ../../gcc/cp/parser.c:13785 0x9cc926 cp_parser_declaration ../../gcc/cp/parser.c:13484 0x9cd06a cp_parser_translation_unit ../../gcc/cp/parser.c:4761 0x9cd06a c_parse_file() ../../gcc/cp/parser.c:44043 0xae4dbb c_common_parse_file() ../../gcc/c-family/c-opts.c:1190 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $g++ --version g++ (GCC) 11.0.0 20200626 (experimental) 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.
[Bug c++/95956] New: ICE in check_bases, at cp/class.c:1689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95956
Bug ID: 95956
Summary: ICE in check_bases, at cp/class.c:1689
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE.
$cat bug.cc
a ( auto struct : decltype ( auto ) { {
$g++ bug.cc
bug.cc:1:5: warning: use of ‘auto’ in parameter declaration only available with
‘-fconcepts-ts’
1 | a ( auto struct : decltype ( auto ) { {
| ^~~~
bug.cc:1:38: error: types may not be defined in parameter types
1 | a ( auto struct : decltype ( auto ) { {
| ^
bug.cc:1:40: error: expected unqualified-id before ‘{’ token
1 | a ( auto struct : decltype ( auto ) { {
|^
bug.cc:2: error: expected ‘}’ at end of input
bug.cc:1:38: note: to match this ‘{’
1 | a ( auto struct : decltype ( auto ) { {
| ^
bug.cc:1:17: internal compiler error: in check_bases, at cp/class.c:1689
1 | a ( auto struct : decltype ( auto ) { {
| ^
0x5ed0ac check_bases
../../gcc/cp/class.c:1689
0x5ed0ac check_bases_and_members
../../gcc/cp/class.c:5900
0x89eca3 finish_struct_1(tree_node*)
../../gcc/cp/class.c:7269
0x8a06d4 finish_struct(tree_node*, tree_node*)
../../gcc/cp/class.c:7573
0x99f973 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23955
0x9a1aa3 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0x9a1aa3 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0x9a2a02 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
0x9bf3ef cp_parser_parameter_declaration
../../gcc/cp/parser.c:22818
0x9bfdd2 cp_parser_parameter_declaration_list
../../gcc/cp/parser.c:22641
0x9c01bc cp_parser_parameter_declaration_clause
../../gcc/cp/parser.c:22568
0x9ad617 cp_parser_direct_declarator
../../gcc/cp/parser.c:21245
0x9ad617 cp_parser_declarator
../../gcc/cp/parser.c:21109
0x9c1ba6 cp_parser_init_declarator
../../gcc/cp/parser.c:20609
0x9a36d2 cp_parser_simple_declaration
../../gcc/cp/parser.c:13785
0x9cc926 cp_parser_declaration
../../gcc/cp/parser.c:13484
0x9cd06a cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0x9cd06a c_parse_file()
../../gcc/cp/parser.c:44043
0xae4dbb c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
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.
[Bug c++/95955] New: ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have union_type in int_fits_type_p, at tree.c:8952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95955
Bug ID: 95955
Summary: ICE: tree check: expected integer_type or
enumeral_type or boolean_type or real_type or
fixed_point_type, have union_type in int_fits_type_p,
at tree.c:8952
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE.
$cat bug.cc
enum class a : struct {}
template < < > > enum class a : union b {}
enum class a { c
$g++ bug.cc
bug.cc:1:25: error: expected ‘;’ after struct definition
1 | enum class a : struct {}
| ^
| ;
bug.cc:1:24: error: underlying type ‘’ of ‘a’ must be an
integral type
1 | enum class a : struct {}
|^
bug.cc:2:12: error: expected identifier before ‘<’ token
2 | template < < > > enum class a : union b {}
|^
bug.cc:2:12: error: expected ‘>’ before ‘<’ token
bug.cc:2:43: error: expected ‘;’ after union definition
2 | template < < > > enum class a : union b {}
| ^
| ;
bug.cc:3:12: error: different underlying type in enum ‘enum class a’
3 | enum class a { c
|^
bug.cc:1:24: note: previous definition here
1 | enum class a : struct {}
|^
bug.cc:3:16: internal compiler error: tree check: expected integer_type or
enumeral_type or boolean_type or real_type or fixed_point_type, have union_type
in int_fits_type_p, at tree.c:8952
3 | enum class a { c
|^
0x7c2dcf tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9685
0x7c9ce1 tree_check5(tree_node const*, char const*, int, char const*,
tree_code, tree_code, tree_code, tree_code, tree_code)
../../gcc/tree.h:3648
0x7c9ce1 int_fits_type_p(tree_node const*, tree_node const*)
../../gcc/tree.c:8952
0x911daa build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc/cp/decl.c:15906
0x9a2447 cp_parser_enumerator_definition
../../gcc/cp/parser.c:19545
0x9a2447 cp_parser_enumerator_list
../../gcc/cp/parser.c:19474
0x9a2447 cp_parser_enum_specifier
../../gcc/cp/parser.c:19405
0x9a2447 cp_parser_type_specifier
../../gcc/cp/parser.c:17734
0x9a2a02 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
0x9a35c1 cp_parser_simple_declaration
../../gcc/cp/parser.c:13664
0x9cc926 cp_parser_declaration
../../gcc/cp/parser.c:13484
0x9cd06a cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0x9cd06a c_parse_file()
../../gcc/cp/parser.c:44043
0xae4dbb c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
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.
