[Bug libstdc++/113121] New: failed to load pendings for ‘std::__format::__do_vformat_to’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113121 Bug ID: 113121 Summary: failed to load pendings for ‘std::__format::__do_vformat_to’ Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: saifi.khan at nishan dot io Target Milestone: --- built and working with g++ (GCC) 14.0.0 20231222 (experimental). When I attempt to compile header unit of with the following command g++ -std=c++23 -v -g3 -fmodules-ts -x c++-system-header print errors out /opt/gcc/include/c++/14.0.0/print: In constructor ‘std::basic_format_arg<_Context>::basic_format_arg() [with _Context = std::basic_format_context, char>]’: /opt/gcc/include/c++/14.0.0/print:55:56: error: recursive lazy load 55 | vprint_nonunicode(FILE* __stream, string_view __fmt, format_args __args) |^~~ /opt/gcc/include/c++/14.0.0/print:55:56: fatal error: failed to load pendings for ‘std::__format::__do_vformat_to’ With an earlier build 20231217, I did not encounter any error while trying to compile the header unit, instead when i compile test code. Please see https://gcc.gnu.org/pipermail/gcc-help/2023-December/143109.html
[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467 Saifi Khan changed: What|Removed |Added CC||saifi.khan at nishan dot io --- Comment #3 from Saifi Khan --- (In reply to jpakkane from comment #2) > It would be preferable to have the default work out of the box than having > every end user having to add compiler flags to make things work. > > Ninja is the most popular underlying build system for modules, having it > work by default would make things easier for many people. as an end user, i'd prefer to explicitly add compiler flag instead of getting pinja, hazel, teson or some such by default !
[Bug debug/108917] ICE when specifying optimization level and debuging for C++ contracts code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108917 --- Comment #2 from Saifi Khan --- Compiling with gcc version 14.0.0 20230531 and executing the ELF binary. coredumpctl info 239557 Coredump Stack Trace #0 0x7f5f739b226c n/a (libc.so.6 + 0x8926c) #1 0x7f5f73962a08 raise (libc.so.6 + 0x39a08) #2 0x7f5f7394b538 abort (libc.so.6 + 0x22538) #3 0x7f5f73cabc5b _ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6 + 0xabc5b) #4 0x7f5f73cde50a _ZN10__cxxabiv111__terminateEPFvvE (libstdc++.so.6 + 0xde50a) #5 0x7f5f73cde575 _ZSt9terminatev (libstdc++.so.6 + 0xde575) #6 0x560c5dc3b7c8 _Z1gi (a.out + 0x17c8) #7 0x560c5dc3b73d _Z1gi (a.out + 0x173d) #8 0x560c5dc3b7d8 _Z4testv (a.out + 0x17d8) #9 0x560c5dc3b7e4 main (a.out + 0x17e4) #10 0x7f5f7394c850 n/a (libc.so.6 + 0x23850) #11 0x7f5f7394c90a __libc_start_main (libc.so.6 + 0x2390a) #12 0x560c5dc3b655 _start (a.out + 0x1655) ELF object binary architecture: AMD x86-64 coredumpctl gdb ./a.out [New LWP 239557] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Core was generated by `./a.out'. Program terminated with signal SIGABRT, Aborted. #0 0x7f5f739b226c in ?? () from /usr/lib/libc.so.6 (gdb) bt #0 0x7f5f739b226c in ?? () from /usr/lib/libc.so.6 #1 0x7f5f73962a08 in raise () from /usr/lib/libc.so.6 #2 0x7f5f7394b538 in abort () from /usr/lib/libc.so.6 #3 0x7f5f73cabc5b in __gnu_cxx::__verbose_terminate_handler () at /opt/gcc/src/libstdc++-v3/libsupc++/vterminate.cc:95 #4 0x7f5f73cde50a in __cxxabiv1::__terminate (handler=) at /opt/gcc/src/libstdc++-v3/libsupc++/eh_terminate.cc:48 #5 0x7f5f73cde575 in std::terminate () at /opt/gcc/src/libstdc++-v3/libsupc++/eh_terminate.cc:58 #6 0x560c5dc3b7c8 in g (j=, j=) at contract_01.cc:13 #7 0x560c5dc3b73d in g (j=5) at contract_01.cc:8 #8 0x560c5dc3b7d8 in test () at contract_01.cc:18 #9 0x560c5dc3b7e4 in main () at contract_01.cc:26
[Bug c++/110056] New: ICE on trying to generate header unit for 'execution'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110056 Bug ID: 110056 Summary: ICE on trying to generate header unit for 'execution' Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: saifi.khan at nishan dot io Target Milestone: --- ENV AMD64 x86_64 64-bit Linux 6.3.5 glibc 2.37-3 gcc version 14.0.0 20230531 (experimental) CMD g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header execution OUTPUT In file included from /opt/gcc/include/c++/14.0.0/pstl/parallel_backend_serial.h:16, from /opt/gcc/include/c++/14.0.0/pstl/parallel_backend.h:14, from /opt/gcc/include/c++/14.0.0/pstl/algorithm_impl.h:22, from /opt/gcc/include/c++/14.0.0/pstl/glue_execution_defs.h:50, from /opt/gcc/include/c++/14.0.0/execution:34: /opt/gcc/include/c++/14.0.0/numeric: In function ‘constexpr std::common_type_t<_Tp1, _Tp2> std::lcm(_Mn, _Nn)’: /opt/gcc/include/c++/14.0.0/numeric:193:13: internal compiler error: in lookup_mark, at cp/tree.cc:2467 193 | if (__is_constant_evaluated()) | ^~~ 0x7acd8c lookup_mark(tree_node*, bool) /opt/gcc/src/gcc/cp/tree.cc:2467 0xb61c7c name_lookup::dedup(bool) /opt/gcc/src/gcc/cp/name-lookup.cc:481 0xb61c7c name_lookup::dedup(bool) /opt/gcc/src/gcc/cp/name-lookup.cc:476 0xb61c7c name_lookup::search_namespace_only(tree_node*) /opt/gcc/src/gcc/cp/name-lookup.cc:949 0xb631cb name_lookup::search_unqualified(tree_node*, cp_binding_level*) /opt/gcc/src/gcc/cp/name-lookup.cc:1142 0xb67a37 lookup_name(tree_node*, LOOK_where, LOOK_want) /opt/gcc/src/gcc/cp/name-lookup.cc:7564 0xb78d3a lookup_name(tree_node*, LOOK_want) /opt/gcc/src/gcc/cp/name-lookup.h:402 0xb78d3a cp_parser_lookup_name /opt/gcc/src/gcc/cp/parser.cc:31412 0xbaad49 cp_parser_class_name /opt/gcc/src/gcc/cp/parser.cc:26003 0xbab03c cp_parser_type_name /opt/gcc/src/gcc/cp/parser.cc:20333 0xbbbe77 cp_parser_simple_type_specifier /opt/gcc/src/gcc/cp/parser.cc:20024 0xb91805 cp_parser_type_specifier /opt/gcc/src/gcc/cp/parser.cc:19614 0xb935d4 cp_parser_decl_specifier_seq /opt/gcc/src/gcc/cp/parser.cc:16089 0xbb4fb1 cp_parser_condition /opt/gcc/src/gcc/cp/parser.cc:13486 0xbc5494 cp_parser_selection_statement /opt/gcc/src/gcc/cp/parser.cc:13243 0xb9741b cp_parser_statement /opt/gcc/src/gcc/cp/parser.cc:12410 0xbc4a91 cp_parser_implicitly_scoped_statement /opt/gcc/src/gcc/cp/parser.cc:14578 0xbc5714 cp_parser_selection_statement /opt/gcc/src/gcc/cp/parser.cc:13276 0xb9741b cp_parser_statement /opt/gcc/src/gcc/cp/parser.cc:12410 0xb9808e cp_parser_statement_seq_opt /opt/gcc/src/gcc/cp/parser.cc:13000
[Bug libstdc++/109965] rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 --- Comment #5 from Saifi Khan --- raised the issue with doxygen project folks. https://github.com/doxygen/doxygen/issues/10093 There is no direct solution or workaround as per response.
[Bug c++/109981] New: ICE encountered while generating header units in the given sequence in a script
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109981 Bug ID: 109981 Summary: ICE encountered while generating header units in the given sequence in a script Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: saifi.khan at nishan dot io Target Milestone: --- Created attachment 55163 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55163=edit script used to generate header units ENV gcc (GCC) 14.0.0 20230525 (experimental) wrote a Perl script to wrap the generation of the header units. Please see the attached script file. The following is the trace of the processing along with the ICE. --- header-unit 'execution' --- g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header algorithm g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header array g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header charconv g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header chrono g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header concepts g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header expected g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header execution In file included from /opt/gcc/include/c++/14.0.0/pstl/unseq_backend_simd.h:15, from /opt/gcc/include/c++/14.0.0/pstl/memory_impl.h:15, from /opt/gcc/include/c++/14.0.0/pstl/algorithm_impl.h:20, from /opt/gcc/include/c++/14.0.0/pstl/glue_execution_defs.h:50, from /opt/gcc/include/c++/14.0.0/execution:34: /opt/gcc/include/c++/14.0.0/pstl/utils.h: In function ‘typename std::result_of<_Fp()>::type __pstl::__internal::__except_handler(_Fp)’: /opt/gcc/include/c++/14.0.0/pstl/utils.h:35:14: internal compiler error: in install_entity, at cp/module.cc:7630 35 | std::__terminate(); // Good bye according to the standard [algorithms.parallel.exceptions] | ^~~ 0x74db56 trees_in::install_entity(tree_node*) /opt/gcc/src/gcc/cp/module.cc:7630 0xb4c154 trees_in::decl_value() /opt/gcc/src/gcc/cp/module.cc:8144 0xb45b57 trees_in::tree_node(bool) /opt/gcc/src/gcc/cp/module.cc:9344 0xb4dabb module_state::read_cluster(unsigned int) /opt/gcc/src/gcc/cp/module.cc:15022 0xb4e025 module_state::load_section(unsigned int, binding_slot*) /opt/gcc/src/gcc/cp/module.cc:18394 0xb4e0f2 module_state::lazy_load(unsigned int, binding_slot*) /opt/gcc/src/gcc/cp/module.cc:19065 0xb46b7f trees_in::tree_node(bool) /opt/gcc/src/gcc/cp/module.cc:9888 0xb4d829 module_state::read_cluster(unsigned int) /opt/gcc/src/gcc/cp/module.cc:14928 0xb4e025 module_state::load_section(unsigned int, binding_slot*) /opt/gcc/src/gcc/cp/module.cc:18394 0xb4e22c lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*) /opt/gcc/src/gcc/cp/module.cc:19102 0xb609b5 name_lookup::search_namespace_only(tree_node*) /opt/gcc/src/gcc/cp/name-lookup.cc:919 0xb60bc2 name_lookup::search_namespace(tree_node*) /opt/gcc/src/gcc/cp/name-lookup.cc:1005 0xb60bc2 name_lookup::search_namespace(tree_node*) /opt/gcc/src/gcc/cp/name-lookup.cc:998 0xb60cc1 name_lookup::search_qualified(tree_node*, bool) /opt/gcc/src/gcc/cp/name-lookup.cc:1066 0xb65384 qualified_namespace_lookup /opt/gcc/src/gcc/cp/name-lookup.cc:6921 0xb66560 lookup_qualified_name(tree_node*, tree_node*, LOOK_want, bool) /opt/gcc/src/gcc/cp/name-lookup.cc:6882 0xb77d21 cp_parser_lookup_name /opt/gcc/src/gcc/cp/parser.cc:31291 0xba9be9 cp_parser_class_name /opt/gcc/src/gcc/cp/parser.cc:26003 0xba9edc cp_parser_type_name /opt/gcc/src/gcc/cp/parser.cc:20333 0xbbad17 cp_parser_simple_type_specifier /opt/gcc/src/gcc/cp/parser.cc:20024 Next, i pushed the execution file to the last, then it errors out on 'span' --- header unit 'span' --- In file included from /opt/gcc/include/c++/14.0.0/span:44: /opt/gcc/include/c++/14.0.0/bits/ranges_base.h:140:27: error: ‘__class_or_enum’ was not declared in this scope 140 | concept __adl_end = __class_or_enum> | ^~~ /opt/gcc/include/c++/14.0.0/bits/ranges_base.h:140:65: error: expected primary-expression before ‘>’ token 140 | concept __adl_end = __class_or_enum> | ^~ /opt/gcc/include/c++/14.0.0/bits/ranges_base.h:141:12: error: expected identifier before ‘requires’ 141 | && requires(_Tp& __t) |^~~~ /opt/gcc/include/c++/14.0.0/bits/ranges_base.h:190:30: error: ‘__class_or_enum’ was not declared in this scope 190 | concept __adl_rbegin = __class_or_enum>
[Bug libstdc++/109965] rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 --- Comment #3 from Saifi Khan --- Trying the 'custom' layout approach that you suggested. The file modified is /opt/gcc/src/libstdc++-v3/doc/doxygen/DoxygenLayout.xml
[Bug libstdc++/109965] rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 --- Comment #2 from Saifi Khan --- Yes, you are right. Doxygen has 'Modules' hard-coded everywhere in the code as they have used the word as an organizing principle. It starts with enum Kind defined in LayoutNavEntry https://raw.githubusercontent.com/doxygen/doxygen/master/src/layout.h All the string-literals related to usage of word 'Modules' are hard-coded in this file. https://raw.githubusercontent.com/doxygen/doxygen/master/src/translator_en.h Modules Modules List Modules Index There are additional entries with regard to the usage of the term in Fortran which may be skipped. There are multiple translator files on a per-language (human spoken language) basis. Short of re-compiling the doxygen code with string literal changed to "Components" i can't seem to find any other way.
[Bug libstdc++/109965] New: rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 Bug ID: 109965 Summary: rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: saifi.khan at nishan dot io Target Milestone: --- Created attachment 55154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55154=edit Tree view as seen by user of documentation and contents under 'Modules'. This relates to doxygen generated 'libstdc++ source documentation' The documentation uses the term 'Modules' on its first page https://softwarehub.sourceforge.io/libstdcxx/api/ and on the said 'Modules' page https://softwarehub.sourceforge.io/libstdcxx/api/modules.html The 'contents' under the 'Modules' tree view are Algorithms Atomics Concurrency Containers Diagnostics Extensions File System I/O Iterators Locales Numerics Random Number Generation Ranges Regular Expressions Strings Technical Specifications Utilities A review of the word 'Modules' here is warranted to avoid confusion with the use of an identical word 'modules' in the context of C++ modules. Perhaps the word 'Modules' may be renamed to 'Categories' as used in the context of an organizing principle.
[Bug c++/109953] New: segmentation fault with import "functional" during program execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109953
Bug ID: 109953
Summary: segmentation fault with import "functional" during
program execution
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: saifi.khan at nishan dot io
Target Milestone: ---
environment GNU/Linux 6.3.3 gcc 14.0.0 glibc 2.37-3
command 'g++ -std=c++23 -v -g3 -Wall -fmodules-ts'
Here is the program
import "iostream";
import "functional";
import "string_view";
auto test (std::string_view sv) -> void {
std::cout << sv.substr (std::size_t {0}, std::size_t {8})
<< '\n';
}
auto main () -> int {
test ("Free Software Community");
return 0;
}
When the program is executed, it encounters a segmentation fault.
The stack trace is as follows
Program received signal SIGSEGV, Segmentation fault.
0x5344 in std::min (__a=@0x7fffe0d8: 8,
__b=@0x7fffe0f8: 23) at /opt/gcc/include/c++/14.0.0/bits/stl_algobase.h:238
238 if (__b < __a)
(gdb) bt
#0 0x5344 in std::min (__a=@0x7fffe0d8: 8,
__b=@0x7fffe0f8: 23) at /opt/gcc/include/c++/14.0.0/bits/stl_algobase.h:238
#1 0x53bf in std::basic_string_view
>::substr (this=0x7fffe130, __pos=0, __n=8)
at /opt/gcc/include/c++/14.0.0/string_view:336
#2 0x51c4 in test (sv="Free Software Community") at
str_view_01.cc:10
#3 0x5230 in main () at str_view_01.cc:16
(gdb)
NOTE
when the line 'import "functional";' is commented out and the program is
re-compiled. It executes and prints the expected result "Free Sof".
[Bug c++/109946] New: linker error undefined reference to `vtable for std::bad_expected_access'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109946
Bug ID: 109946
Summary: linker error undefined reference to `vtable for
std::bad_expected_access'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: saifi.khan at nishan dot io
Target Milestone: ---
Environment: Archlinux kernel 6.3.2 glibc 2.37 gcc 13.1 gcc 14.0.0
Consider the following code
import "iostream";
import "string";
import "string_view";
import "expected";
import "charconv";
import "system_error";
namespace parser {
enum class error {
input_invalid
, overflow
};
auto logic (std::string_view str) -> std::expected {
int value {0};
std::from_chars_result result { std::from_chars (str.begin (), str.end
(), value) };
if (result.ec == std::errc{}) {
return value;
}
else if (result.ec == std::errc::invalid_argument) {
return std::unexpected {error::input_invalid};
}
else if (result.ec == std::errc::result_out_of_range) {
return std::unexpected {error::overflow};
}
}
}
auto test () -> void {
std::string str { "9876dairy" };
const auto result { parser::logic (str) };
if (result.has_value ()) {
std::cout << result.value ()
<< '\n';
}
else if (result.error () == parser::error::input_invalid) {
std::cout << "E: input invalid"
<< '\n';
}
else if (result.error () == parser::error::overflow) {
std::cout << "overflow"
<< '\n';
}
else {
std::cout << "unexpected"
<< '\n';
}
}
The code compiles and program work fine with
- gcc 13.1.1
- gcc 14.0.0
as long as i don't use the option -fmodules-ts.
When using the -fmodules-ts flag, the following linker error is seen:
/usr/bin/ld: /tmp/cchUGnbx.o: warning: relocation against
`_ZTVSt19bad_expected_accessIvE' in read-only section
`.text._ZNSt19bad_expected_accessIvED2Ev[_ZNSt19bad_expected_accessIvED5Ev]'
/usr/bin/ld: /tmp/cchUGnbx.o: in function
`std::bad_expected_access::bad_expected_access()':
/opt/gcc/include/c++/14.0.0/expected:80: undefined reference to `vtable for
std::bad_expected_access'
/usr/bin/ld: /tmp/cchUGnbx.o: in function
`std::bad_expected_access::~bad_expected_access()':
/opt/gcc/include/c++/14.0.0/expected:85: undefined reference to `vtable for
std::bad_expected_access'
/usr/bin/ld:
/tmp/cchUGnbx.o:(.data.rel.ro._ZTISt19bad_expected_accessIN6parser5errorEE[_ZTISt19bad_expected_accessIN6parser5errorEE]+0x10):
undefined reference to `typeinfo for std::bad_expected_access'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
[Bug c++/109859] New: ICE on concept mis-typed as template type parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109859
Bug ID: 109859
Summary: ICE on concept mis-typed as template type parameter
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: saifi.khan at nishan dot io
Target Milestone: ---
while exploring ranges, i mis-typed the code as follows.
should have written
template
--
#include
template
int fn (R);
int main () {;}
--
using gcc version 14.0.0 20230514 (experimental) (GCC)
g++ -std=c++23 file.cc
--
output is
file.cc:3:37: internal compiler error: in cp_parser_placeholder_type_specifier,
at cp/parser.cc:20242
3 | template
| ^~~
0x75a5de cp_parser_placeholder_type_specifier
/opt/gcc/src/gcc/cp/parser.cc:20242
0xbb9e11 cp_parser_simple_type_specifier
/opt/gcc/src/gcc/cp/parser.cc:20079
0xb8ec55 cp_parser_type_specifier
/opt/gcc/src/gcc/cp/parser.cc:19614
0xba3e42 cp_parser_type_specifier_seq
/opt/gcc/src/gcc/cp/parser.cc:24615
0xba1a3d cp_parser_type_id_1
/opt/gcc/src/gcc/cp/parser.cc:24412
0xba1d50 cp_parser_type_id
/opt/gcc/src/gcc/cp/parser.cc:24511
0xba1d50 cp_parser_default_type_template_argument
/opt/gcc/src/gcc/cp/parser.cc:17963
0xbb5617 cp_parser_type_parameter
/opt/gcc/src/gcc/cp/parser.cc:18199
0xbb46d4 cp_parser_template_parameter
/opt/gcc/src/gcc/cp/parser.cc:18080
0xbb46d4 cp_parser_template_parameter_list
/opt/gcc/src/gcc/cp/parser.cc:17679
0xbc6ce7 cp_parser_explicit_template_declaration
/opt/gcc/src/gcc/cp/parser.cc:32382
0xbc9a95 cp_parser_declaration
/opt/gcc/src/gcc/cp/parser.cc:15050
0xbca553 cp_parser_toplevel_declaration
/opt/gcc/src/gcc/cp/parser.cc:15142
0xbca553 cp_parser_translation_unit
/opt/gcc/src/gcc/cp/parser.cc:5131
0xbca553 c_parse_file()
/opt/gcc/src/gcc/cp/parser.cc:49635
0xd17685 c_common_parse_file()
/opt/gcc/src/gcc/c-family/c-opts.cc:1248
---
Thanks for your time !
[Bug c++/108917] New: ICE when specifying optimization level for C++ contracts code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108917
Bug ID: 108917
Summary: ICE when specifying optimization level for C++
contracts code
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: saifi.khan at nishan dot io
Target Milestone: ---
Environment
- Linux 6.1.0-3-amd64 x86_64 GNU/Linux
- Debian GLIBC 2.36-8) 2.36
- gcc version 13.0.1 20230215 (experimental) (GCC)
was working through p2680r1 example with the code as follows.
---
auto f (int i) -> int {
return i + 100;
}
int g (int j) [[pre: f (j) < j ]] {
int r { j - f (j)};
return 2 * r;
}
auto test () -> void {
g (5);
}
---
:: g++ -std=c++23 -fcontracts contract_01.cc
:: ./a.out
contract violation in function g at contract_01.cc:8: f (j) < j
terminate called without an active exception
Aborted
::
But this doesn't work !
:: g++ -std=c++23 -O3 -g2 -fcontracts contract_01.cc
during RTL pass: final
contract_01.cc: In function ‘int g(int)’:
contract_01.cc:13:1: internal compiler error: in gen_inlined_subroutine_die, at
dwarf2out.cc:25002
13 | }
| ^
0x7d40a5 gen_inlined_subroutine_die
/opt/gcc/src/gcc/dwarf2out.cc:25002
0x7d40a5 gen_block_die
/opt/gcc/src/gcc/dwarf2out.cc:26487
0xe3b3ca decls_for_scope
/opt/gcc/src/gcc/dwarf2out.cc:26612
0xe18c93 gen_subprogram_die
/opt/gcc/src/gcc/dwarf2out.cc:24086
0xe1d82f gen_decl_die
/opt/gcc/src/gcc/dwarf2out.cc:27020
0xe1e60a dwarf2out_decl
/opt/gcc/src/gcc/dwarf2out.cc:27598
0xe1ea62 dwarf2out_function_decl
/opt/gcc/src/gcc/dwarf2out.cc:27613
0xea23e7 rest_of_handle_final
/opt/gcc/src/gcc/final.cc:4274
0xea23e7 execute
/opt/gcc/src/gcc/final.cc:4318
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
