[Bug c++/99239] [modules] internal compiler error: in duplicate_decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99239 --- Comment #1 from Alexander Lelyakin --- About half of sequences of headers producing segmentation fault are stopped on . However there are another variants: g++ -std=c++20 -fmodules-ts -x c++-system-header stdexcept g++ -std=c++20 -fmodules-ts -x c++-system-header locale /usr/local/include/c++/11.0.1/locale: internal compiler error: Segmentation fault 0x10fee8f crash_signal ../../gcc/gcc/toplev.c:327 0x6deab8 trees_out::get_tag(tree_node*) ../../gcc/gcc/cp/module.cc:4783 0x6deab8 trees_out::ref_node(tree_node*) ../../gcc/gcc/cp/module.cc:7090 0x6deab8 trees_out::ref_node(tree_node*) ../../gcc/gcc/cp/module.cc:7073 0xa5dfdc trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:8978 0xa5fec9 trees_out::type_node(tree_node*) ../../gcc/gcc/cp/module.cc:8701 0xa5e3da trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9061 0xa5fccc trees_out::type_node(tree_node*) ../../gcc/gcc/cp/module.cc:8619 0xa5e3da trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9061 0xa60104 trees_out::type_node(tree_node*) ../../gcc/gcc/cp/module.cc:8728 0xa5e3da trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9061 0xa5ed0f trees_out::core_vals(tree_node*) ../../gcc/gcc/cp/module.cc:5993 0xa5fbec trees_out::tree_node_vals(tree_node*) ../../gcc/gcc/cp/module.cc:7053 0xa5fbec trees_out::fn_parms_init(tree_node*) ../../gcc/gcc/cp/module.cc:9992 0xa5c4c4 trees_out::decl_value(tree_node*, depset*) ../../gcc/gcc/cp/module.cc:7625 0xa63fd1 depset::hash::find_dependencies(module_state*) ../../gcc/gcc/cp/module.cc:13169 0xa64668 module_state::write(elf_out*, cpp_reader*) ../../gcc/gcc/cp/module.cc:17644 0xa65aff finish_module_processing(cpp_reader*) ../../gcc/gcc/cp/module.cc:19884 0x9f901b c_parse_final_cleanups() ../../gcc/gcc/cp/decl2.c:5175 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++ (GCC) 11.0.1 20210308 (experimental) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/99238] [modules] internal compiler error: segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99238 --- Comment #2 from Alexander Lelyakin --- Even shorter sequence: g++ -std=c++20 -fmodules-ts -x c++-system-header stdexcept g++ -std=c++20 -fmodules-ts -x c++-system-header stop_token /usr/local/include/c++/11.0.1/stop_token: internal compiler error: Segmentation fault 0x10fee8f crash_signal ../../gcc/gcc/toplev.c:327 0x6deab8 trees_out::get_tag(tree_node*) ../../gcc/gcc/cp/module.cc:4783 0x6deab8 trees_out::ref_node(tree_node*) ../../gcc/gcc/cp/module.cc:7090 0x6deab8 trees_out::ref_node(tree_node*) ../../gcc/gcc/cp/module.cc:7073 0xa5dfdc trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:8978 0xa5fec9 trees_out::type_node(tree_node*) ../../gcc/gcc/cp/module.cc:8701 0xa5e3da trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9061 0xa5cbda trees_out::tree_node_vals(tree_node*) ../../gcc/gcc/cp/module.cc:7053 0xa5cbda trees_out::decl_value(tree_node*, depset*) ../../gcc/gcc/cp/module.cc:7640 0xa5d1ab trees_out::decl_node(tree_node*, walk_kind) ../../gcc/gcc/cp/module.cc:8549 0xa5e1a2 trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9104 0xa5e66d trees_out::vec_chained_decls(tree_node*) ../../gcc/gcc/cp/module.cc:4879 0xa6255b trees_out::write_class_def(tree_node*) ../../gcc/gcc/cp/module.cc:11642 0xa6424c depset::hash::find_dependencies(module_state*) ../../gcc/gcc/cp/module.cc:13172 0xa64668 module_state::write(elf_out*, cpp_reader*) ../../gcc/gcc/cp/module.cc:17644 0xa65aff finish_module_processing(cpp_reader*) ../../gcc/gcc/cp/module.cc:19884 0x9f901b c_parse_final_cleanups() ../../gcc/gcc/cp/decl2.c:5175 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++ (GCC) 11.0.1 20210308 (experimental) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/99484] New: [modules] ICE same canonical type node for different types ‘void’ and ‘std::__void_t<_Op<_Args ...> >’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99484
Bug ID: 99484
Summary: [modules] ICE same canonical type node for different
types ‘void’ and ‘std::__void_t<_Op<_Args ...> >’
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexander.lelyakin at googlemail dot com
Target Milestone: ---
g++ -std=c++20 -fmodules-ts -x c++-system-header cstdalign
g++ -std=c++20 -fmodules-ts -x c++-system-header cuchar
g++ -std=c++20 -fmodules-ts -x c++-system-header filesystem
g++ -std=c++20 -fmodules-ts -x c++-system-header type_traits
g++ -std=c++20 -fmodules-ts -x c++-system-header clocale
g++ -std=c++20 -fmodules-ts -x c++-system-header cstdarg
g++ -std=c++20 -fmodules-ts -x c++-system-header complex
g++ -std=c++20 -fmodules-ts -x c++-system-header cfloat
g++ -std=c++20 -fmodules-ts -x c++-system-header iomanip
In module /usr/local/include/c++/11.0.1/type_traits, imported at
/usr/local/include/c++/11.0.1/bits/move.h:57,
included from /usr/local/include/c++/11.0.1/bits/stl_pair.h:59,
from /usr/local/include/c++/11.0.1/bits/stl_algobase.h:64,
from /usr/local/include/c++/11.0.1/bits/char_traits.h:39,
from /usr/local/include/c++/11.0.1/string:40,
from /usr/local/include/c++/11.0.1/bits/locale_classes.h:40,
from /usr/local/include/c++/11.0.1/bits/ios_base.h:41,
from /usr/local/include/c++/11.0.1/iomanip:40:
/usr/local/include/c++/11.0.1/type_traits: In substitution of ‘template class _Op, class ... _Args> using __detected_or_t
= typename std::__detected_or<_Default, _Op, _Args ...>::type [with _Default =
typename std::__get_first_arg<_Tp>::type; _Op =
std::pointer_traits<_Ptr>::__element_type; _Args = {_Ptr}]’:
/usr/local/include/c++/11.0.1/bits/ptr_traits.h:105:65: required from here
/usr/local/include/c++/11.0.1/type_traits:2565:11: internal compiler error:
same canonical type node for different types ‘void’ and
‘std::__void_t<_Op<_Args ...> >’
2565 | using __detected_or_t
| ^~~
0xb7f5fd comptypes(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:1554
0xae491f template_args_equal(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/pt.c:9207
0xae4478 template_args_equal(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/pt.c:9170
0xae4478 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
../../gcc/gcc/cp/pt.c:9254
0xae4478 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
../../gcc/gcc/cp/pt.c:9234
0xaedd93 spec_hasher::equal(spec_entry*, spec_entry*)
../../gcc/gcc/cp/pt.c:1725
0xb338b6 hash_table::verify(spec_entry*
const&, unsigned int)
../../gcc/gcc/hash-table.h:1032
0xb33e5e hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
../../gcc/gcc/hash-table.h:968
0xaf0d3b add_mergeable_specialization(bool, spec_entry*, tree_node*, unsigned
int)
../../gcc/gcc/cp/pt.c:30018
0xa6ec5f trees_in::decl_value()
../../gcc/gcc/cp/module.cc:8068
0xa66d17 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9174
0xa6d36b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14858
0xa6d86d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18125
0xa6d92f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18779
0xa70b67 lazy_load_pendings(tree_node*)
../../gcc/gcc/cp/module.cc:18872
0xb2017f lookup_template_class_1
../../gcc/gcc/cp/pt.c:9799
0xb22516 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:10237
0xb22516 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:13572
0xb16883 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:16033
0xb012a0 tsubst_decl
../../gcc/gcc/cp/pt.c:14798
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++ (GCC) 11.0.1 20210308 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/99483] New: [modules] ICE tree check: expected tree_vec, have bind_expr in lookup_template_class_1, at cp/pt.c:9803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99483 Bug ID: 99483 Summary: [modules] ICE tree check: expected tree_vec, have bind_expr in lookup_template_class_1, at cp/pt.c:9803 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alexander.lelyakin at googlemail dot com Target Milestone: --- g++ -std=c++20 -fmodules-ts -x c++-system-header system_error g++ -std=c++20 -fmodules-ts -x c++-system-header atomic g++ -std=c++20 -fmodules-ts -x c++-system-header typeinfo g++ -std=c++20 -fmodules-ts -x c++-system-header string g++ -std=c++20 -fmodules-ts -x c++-system-header list g++ -std=c++20 -fmodules-ts -x c++-system-header bitset /usr/local/include/c++/11.0.1/bitset:760:80: internal compiler error: tree check: expected tree_vec, have bind_expr in lookup_template_class_1, at cp/pt.c:9803 760 | _M_check_initial_position(const std::basic_string<_CharT, _Traits, _Alloc>& __s, | ^ 0x875ba8 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9814 0x71d266 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/gcc/tree.h:3353 0x71d266 lookup_template_class_1 ../../gcc/gcc/cp/pt.c:9803 0xb21d6c lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../gcc/gcc/cp/pt.c:10237 0xb49ffb finish_template_type(tree_node*, tree_node*, int) ../../gcc/gcc/cp/semantics.c:3498 0xabbf41 cp_parser_template_id ../../gcc/gcc/cp/parser.c:17444 0xabc12b cp_parser_class_name ../../gcc/gcc/cp/parser.c:24671 0xab36ba cp_parser_qualifying_entity ../../gcc/gcc/cp/parser.c:6994 0xab36ba cp_parser_nested_name_specifier_opt ../../gcc/gcc/cp/parser.c:6676 0xac8e14 cp_parser_simple_type_specifier ../../gcc/gcc/cp/parser.c:18837 0xaa7bad cp_parser_type_specifier ../../gcc/gcc/cp/parser.c:18495 0xaa8ba9 cp_parser_decl_specifier_seq ../../gcc/gcc/cp/parser.c:15041 0xac39ce cp_parser_parameter_declaration ../../gcc/gcc/cp/parser.c:23731 0xac43a2 cp_parser_parameter_declaration_list ../../gcc/gcc/cp/parser.c:23548 0xac47f1 cp_parser_parameter_declaration_clause ../../gcc/gcc/cp/parser.c:23475 0xab5933 cp_parser_direct_declarator ../../gcc/gcc/cp/parser.c:22124 0xab5933 cp_parser_declarator ../../gcc/gcc/cp/parser.c:21987 0xaccb78 cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:21485 0xad39ab cp_parser_single_declaration ../../gcc/gcc/cp/parser.c:30493 0xad3b16 cp_parser_template_declaration_after_parameters ../../gcc/gcc/cp/parser.c:30065 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++ (GCC) 11.0.1 20210308 (experimental) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/99482] New: [modules] ICE tree check: expected tree_vec, have addr_expr in lookup_template_class_1, at cp/pt.c:9803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99482 Bug ID: 99482 Summary: [modules] ICE tree check: expected tree_vec, have addr_expr in lookup_template_class_1, at cp/pt.c:9803 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alexander.lelyakin at googlemail dot com Target Milestone: --- g++ -std=c++20 -fmodules-ts -x c++-system-header exception g++ -std=c++20 -fmodules-ts -x c++-system-header cstring g++ -std=c++20 -fmodules-ts -x c++-system-header future g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_set g++ -std=c++20 -fmodules-ts -x c++-system-header istream g++ -std=c++20 -fmodules-ts -x c++-system-header string_view g++ -std=c++20 -fmodules-ts -x c++-system-header mutex g++ -std=c++20 -fmodules-ts -x c++-system-header charconv g++ -std=c++20 -fmodules-ts -x c++-system-header atomic g++ -std=c++20 -fmodules-ts -x c++-system-header ctime g++ -std=c++20 -fmodules-ts -x c++-system-header iterator g++ -std=c++20 -fmodules-ts -x c++-system-header limits g++ -std=c++20 -fmodules-ts -x c++-system-header numeric g++ -std=c++20 -fmodules-ts -x c++-system-header utility g++ -std=c++20 -fmodules-ts -x c++-system-header numbers g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm In file included from /usr/local/include/c++/11.0.1/bits/ranges_algobase.h:38, from /usr/local/include/c++/11.0.1/bits/ranges_algo.h:35, from /usr/local/include/c++/11.0.1/algorithm:64: /usr/local/include/c++/11.0.1/bits/invoke.h:54:43: internal compiler error: tree check: expected tree_vec, have addr_expr in lookup_template_class_1, at cp/pt.c:9803 54 | __invfwd(typename remove_reference<_Tp>::type& __t) noexcept | ^ 0x875ba8 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9814 0x71d266 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/gcc/tree.h:3353 0x71d266 lookup_template_class_1 ../../gcc/gcc/cp/pt.c:9803 0xb21d6c lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../gcc/gcc/cp/pt.c:10237 0xb49ffb finish_template_type(tree_node*, tree_node*, int) ../../gcc/gcc/cp/semantics.c:3498 0xabbf41 cp_parser_template_id ../../gcc/gcc/cp/parser.c:17444 0xabc12b cp_parser_class_name ../../gcc/gcc/cp/parser.c:24671 0xab36ba cp_parser_qualifying_entity ../../gcc/gcc/cp/parser.c:6994 0xab36ba cp_parser_nested_name_specifier_opt ../../gcc/gcc/cp/parser.c:6676 0xac24cf cp_parser_nested_name_specifier ../../gcc/gcc/cp/parser.c:6920 0xac24cf cp_parser_elaborated_type_specifier ../../gcc/gcc/cp/parser.c:19419 0xaa7b55 cp_parser_type_specifier ../../gcc/gcc/cp/parser.c:18445 0xaa8ba9 cp_parser_decl_specifier_seq ../../gcc/gcc/cp/parser.c:15041 0xac39ce cp_parser_parameter_declaration ../../gcc/gcc/cp/parser.c:23731 0xac43a2 cp_parser_parameter_declaration_list ../../gcc/gcc/cp/parser.c:23548 0xac47f1 cp_parser_parameter_declaration_clause ../../gcc/gcc/cp/parser.c:23475 0xab5933 cp_parser_direct_declarator ../../gcc/gcc/cp/parser.c:22124 0xab5933 cp_parser_declarator ../../gcc/gcc/cp/parser.c:21987 0xab54b1 cp_parser_declarator ../../gcc/gcc/cp/parser.c:21965 0xaccb78 cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:21485 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++ (GCC) 11.0.1 20210308 (experimental) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/99481] New: [modules] ICE tree check: expected template_decl, have function_decl in decl_value, at cp/module.cc:7938
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99481 Bug ID: 99481 Summary: [modules] ICE tree check: expected template_decl, have function_decl in decl_value, at cp/module.cc:7938 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alexander.lelyakin at googlemail dot com Target Milestone: --- g++ -std=c++20 -fmodules-ts -x c++-system-header functional g++ -std=c++20 -fmodules-ts -x c++-system-header streambuf g++ -std=c++20 -fmodules-ts -x c++-system-header execution In file included from /usr/local/include/c++/11.0.1/bits/ranges_algo.h:35, from /usr/local/include/c++/11.0.1/algorithm:64, from /usr/local/include/c++/11.0.1/pstl/algorithm_impl.h:17, from /usr/local/include/c++/11.0.1/pstl/glue_execution_defs.h:50, from /usr/local/include/c++/11.0.1/execution:32: /usr/local/include/c++/11.0.1/bits/ranges_algobase.h:55:59: internal compiler error: tree check: expected template_decl, have function_decl in decl_value, at cp/module.cc:7938 55 | _Container>> = true; | ^~ 0x875ba8 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9814 0x6e61c9 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/gcc/tree.h:3353 0x6e61c9 trees_in::decl_value() ../../gcc/gcc/cp/module.cc:7938 0xa66d17 trees_in::tree_node(bool) ../../gcc/gcc/cp/module.cc:9174 0xa6d36b module_state::read_cluster(unsigned int) ../../gcc/gcc/cp/module.cc:14858 0xa6d86d module_state::load_section(unsigned int, binding_slot*) ../../gcc/gcc/cp/module.cc:18125 0xa6d92f module_state::lazy_load(unsigned int, binding_slot*) ../../gcc/gcc/cp/module.cc:18779 0xa67b80 trees_in::tree_node(bool) ../../gcc/gcc/cp/module.cc:9685 0xa6de67 trees_in::decl_container() ../../gcc/gcc/cp/module.cc:10301 0xa6de67 trees_in::decl_value() ../../gcc/gcc/cp/module.cc:7903 0xa66d17 trees_in::tree_node(bool) ../../gcc/gcc/cp/module.cc:9174 0xa6d36b module_state::read_cluster(unsigned int) ../../gcc/gcc/cp/module.cc:14858 0xa6d86d module_state::load_section(unsigned int, binding_slot*) ../../gcc/gcc/cp/module.cc:18125 0xa6d92f module_state::lazy_load(unsigned int, binding_slot*) ../../gcc/gcc/cp/module.cc:18779 0xa67b80 trees_in::tree_node(bool) ../../gcc/gcc/cp/module.cc:9685 0xa66c89 trees_in::tree_node(bool) ../../gcc/gcc/cp/module.cc:9224 0xa675bd trees_in::tree_node(bool) ../../gcc/gcc/cp/module.cc:9367 0xa69095 trees_in::core_vals(tree_node*) ../../gcc/gcc/cp/module.cc:6630 0xa663e7 trees_in::tree_node_vals(tree_node*) ../../gcc/gcc/cp/module.cc:7060 0xa663e7 trees_in::tree_value() ../../gcc/gcc/cp/module.cc:8951 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++ (GCC) 11.0.1 20210308 (experimental) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/99480] New: [modules] ICE in import_entity_index, at cp/module.cc:3952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99480
Bug ID: 99480
Summary: [modules] ICE in import_entity_index, at
cp/module.cc:3952
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexander.lelyakin at googlemail dot com
Target Milestone: ---
g++ -std=c++20 -fmodules-ts -x c++-system-header memory
g++ -std=c++20 -fmodules-ts -x c++-system-header execution
In file included from /usr/local/include/c++/11.0.1/pstl/parallel_impl.h:13,
from /usr/local/include/c++/11.0.1/pstl/algorithm_impl.h:23,
from
/usr/local/include/c++/11.0.1/pstl/glue_execution_defs.h:50,
from /usr/local/include/c++/11.0.1/execution:32:
/usr/local/include/c++/11.0.1/atomic:415:5: internal compiler error: in
import_entity_index, at cp/module.cc:3952
415 | {
| ^
0x6dbec6 import_entity_index
../../gcc/gcc/cp/module.cc:3952
0x6dbec6 import_entity_index
../../gcc/gcc/cp/module.cc:3947
0xa53bd2 module_may_redeclare(tree_node*)
../../gcc/gcc/cp/module.cc:18453
0xb49920 begin_class_definition(tree_node*)
../../gcc/gcc/cp/semantics.c:3269
0xaa5680 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:24849
0xaa7c13 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:25172
0xaa7c13 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:18419
0xaa8ba9 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:15041
0xad3796 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:30402
0xad3b16 cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:30065
0xad42c0 cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:30331
0xad69e9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14047
0xad5fb9 cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14145
0xad5fb9 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:13933
0xad6452 cp_parser_namespace_body
../../gcc/gcc/cp/parser.c:20433
0xad6452 cp_parser_namespace_definition
../../gcc/gcc/cp/parser.c:20411
0xad6ba8 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14096
0xad73fc cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14145
0xad73fc cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4936
0xad73fc c_parse_file()
../../gcc/gcc/cp/parser.c:45231
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++ (GCC) 11.0.1 20210308 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/99479] New: [modules] ICE Aborted signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99479 Bug ID: 99479 Summary: [modules] ICE Aborted signal terminated program cc1plus Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alexander.lelyakin at googlemail dot com Target Milestone: --- g++ -std=c++20 -fmodules-ts -x c++-system-header iostream g++ -std=c++20 -fmodules-ts -x c++-system-header cstdbool g++ -std=c++20 -fmodules-ts -x c++-system-header complex g++ -std=c++20 -fmodules-ts -x c++-system-header coroutine g++ -std=c++20 -fmodules-ts -x c++-system-header condition_variable g++ -std=c++20 -fmodules-ts -x c++-system-header future corrupted double-linked list corrupted double-linked list g++: internal compiler error: Aborted signal terminated program cc1plus Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. g++ (GCC) 11.0.1 20210308 (experimental) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/99478] New: ICE when decltype lambda in template list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99478
Bug ID: 99478
Summary: ICE when decltype lambda in template list
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
The following code will trigger ICE on gcc-9.1 ~ gcc-trunk with "-std=c++2a"
mode:
template auto f() {}
int main() { f<{}>(); }
(godbolt: https://godbolt.org/z/dEP5PT)
[Bug target/99070] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99070 acsawdey at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from acsawdey at gcc dot gnu.org --- Fixed in trunk.
[Bug target/99070] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99070 --- Comment #5 from CVS Commits --- The master branch has been updated by Aaron Sawdey : https://gcc.gnu.org/g:9433c844c8bcf0166567943b45576ce0b131 commit r11-7570-g9433c844c8bcf0166567943b45576ce0b131 Author: Aaron Sawdey Date: Sun Mar 7 14:47:31 2021 -0600 Tighten predicates for p10 ld/cmpi fusion PR99070 is caused by a fusion pattern matching that the individual instructions do not match when it is split later. In this case the ld+cmpi patterns were allowing a d-form load address, which the split condition would rightly split, however that left us with something that could not be matched by a ds-form ld instruction, hence the ICE. This only happened if the target cpu was not power10 -- if we were targeting power10 then a prefixed pld instruction would get generated because that can handle d-form. However this is not optimal code either. So the solution is a new predicate (ds_form_mem_operand) that only accepts what we can take as for a ds-form load. Then a small modification of the genfusion.pl script changes the relevant ld+cmpi patterns to use the new predicate. gcc/ChangeLog PR target/99070 * config/rs6000/predicates.md (ds_form_mem_operand) New predicate. * config/rs6000/genfusion.pl (gen_ld_cmpi_p10) Use ds_form_mem_operand in ld/lwa patterns. * config/rs6000/fusion.md: Regenerate file.
[Bug tree-optimization/99475] [10/11 Regression] bogus -Warray-bounds accessing an array element of empty structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99475 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566450.html
[Bug fortran/99477] New: CONTIGUOUS assumed-shape dummy not working with associate construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99477 Bug ID: 99477 Summary: CONTIGUOUS assumed-shape dummy not working with associate construct Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- Created attachment 50335 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50335=edit Example program I think I've stumbled on a bug with gfortran's handling of the CONTIGUOUS attribute in assumed-shape dummy arguments, when the actual argument is an array slice set up using an ASSOCIATE construct. The example program demonstrates the issue. When compiled with gfortran 10.2.0, I get the following output: 1 3 5 7 9 1 3 5 7 9 1 2 3 4 5 1 3 5 7 9 (note the third line, which has only stride 1). Whereas, I believe the output should be 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 The issue goes away if I remove the CONTIGUOUS attribute from the function argument. cheers, Rich
[Bug go/99458] libgo doesn't build against latest glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99458 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- Fixed, I hope.
[Bug go/99458] libgo doesn't build against latest glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99458 --- Comment #3 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:d5d3f15a0e04c30d5dbec09b56c14ad923a3e8da commit r11-7569-gd5d3f15a0e04c30d5dbec09b56c14ad923a3e8da Author: Ian Lance Taylor Date: Mon Mar 8 13:58:14 2021 -0800 runtime: cast SIGSTKSZ to uintptr In newer versions of glibc it is long, which causes a signed comparison warning. Fixes PR go/99458
[Bug go/99458] libgo doesn't build against latest glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99458 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:3c8e29c81b789db8a49616e0d36d16f869cf442a commit r10-9424-g3c8e29c81b789db8a49616e0d36d16f869cf442a Author: Ian Lance Taylor Date: Mon Mar 8 15:23:40 2021 -0800 runtime: cast SIGSTKSZ to uintptr PR go/99458 * libgo/runtime/proc.c: cast SIGSTKSZ to uintptr In newer versions of glibc it is long, which causes a signed comparison warning.
[Bug go/99458] libgo doesn't build against latest glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99458 --- Comment #1 from CVS Commits --- The releases/gcc-9 branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:1a543ca52392b7aea135f47ac244485fcea0d267 commit r9-9275-g1a543ca52392b7aea135f47ac244485fcea0d267 Author: Ian Lance Taylor Date: Mon Mar 8 15:24:06 2021 -0800 runtime: cast SIGSTKSZ to uintptr PR go/99458 * libgo/runtime/proc.c: cast SIGSTKSZ to uintptr In newer versions of glibc it is long, which causes a signed comparison warning.
[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |8.2 Status|WAITING |RESOLVED --- Comment #3 from Andrew Pinski --- so clsoing as fixed as GCC 7.x (and before) are no longer supported.
[Bug sanitizer/99476] New: 'PATH_MAX' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99476 Bug ID: 99476 Summary: 'PATH_MAX' was not declared in this scope Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live 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: --- Created attachment 50334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50334=edit sanitizers do not find PATH_MAX and use linux headers I try to cross compile gcc from windows to freebsd. PATH_MAX does not exist.
[Bug fortran/99205] [10/11 Regression] Out of memory with undefined character length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205 --- Comment #2 from anlauf at gcc dot gnu.org --- This fixes the testcase and passes regtesting: diff --git a/gcc/fortran/data.c b/gcc/fortran/data.c index 25e97930169..71e2552025d 100644 --- a/gcc/fortran/data.c +++ b/gcc/fortran/data.c @@ -595,6 +595,9 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue, mpz_t index, /* An initializer has to be constant. */ if (lvalue->ts.u.cl->length == NULL && !(ref && ref->u.ss.length != NULL)) return false; + if (lvalue->ts.u.cl->length + && lvalue->ts.u.cl->length->expr_type != EXPR_CONSTANT) + return false; expr = create_character_initializer (init, last_ts, ref, rvalue); if (!expr) return false;
[Bug tree-optimization/99475] [10/11 Regression] bogus -Warray-bounds accessing an array element of empty structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99475 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.0 Status|UNCONFIRMED |NEW Known to work||9.3.0 Blocks||56456 Last reconfirmed||2021-03-08 Keywords||diagnostic Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Bisection points to commit d893b683f40884cd00b5beb392566ecc7b67f721: Author: Martin Sebor Date: Thu Jul 19 23:36:34 2018 + PR tree-optimization/84047 - missing -Warray-bounds on an out-of-bounds index into an array PR tree-optimization/84047 - missing -Warray-bounds on an out-of-bounds index into an array PR tree-optimization/83776 - missing -Warray-bounds indexing past the end of a string literal gcc/ChangeLog: PR tree-optimization/84047 PR tree-optimization/83776 * tree-vrp.c (vrp_prop::check_mem_ref): New function. (check_array_bounds): Call it. gcc/testsuite/ChangeLog: PR tree-optimization/83776 PR tree-optimization/84047 * gcc.dg/Warray-bounds-29.c: New test. * gcc.dg/Warray-bounds-30.c: New test. * gcc.dg/Warray-bounds-31.c: New test. * gcc.dg/Warray-bounds-32.c: New test. From-SVN: r262893 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug tree-optimization/99475] New: [10/11 Regression] bogus -Warray-bounds accessing an array element of empty structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99475
Bug ID: 99475
Summary: [10/11 Regression] bogus -Warray-bounds accessing an
array element of empty structs
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
An indirect access to an element of an array of empty structs through a pointer
to such an element triggers a spurious -Warray-bounds warning:
$ cat v.c && gcc -O2 -S -Wall v.c
struct S { } a[5];
void f (void)
{
a[1] = (struct S) { }; // okay
}
void g (void)
{
struct S *p = [0];
p[1] = (struct S) { }; // bogus -Warray-bounds
}
v.c: In function ‘g’:
v.c:11:4: warning: array subscript 0 is outside array bounds of ‘struct S[5]’
[-Warray-bounds]
11 | p[1] = (struct S) { };
| ~^~~
v.c:1:14: note: while referencing ‘a’
1 | struct S { } a[5];
| ^
[Bug c/99454] internal compiler error: kernel module tg3 tg3_start_xmit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #4 from Vladimir Makarov --- I've reproduced it. Sorry for all the troubles. I'll try to fix it tomorrow.
[Bug c++/99460] [C++20] Template with complex non-type argument re-uses different specialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99460 --- Comment #2 from mexon --- For completeness, output from change a18ebd6c439: vagrant@ubuntu-groovy:~$ g++ -v -save-temps -Wall --std=c++2a builder_simplified.cpp Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/home/vagrant/install-gcc/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/vagrant/install-gcc --disable-nls --enable-languages=c,c++ --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.1 20210307 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=c++20' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' /home/vagrant/install-gcc/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/cc1plus -E -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE builder_simplified.cpp -mtune=generic -march=x86-64 -std=c++20 -Wall -fpch-preprocess -o a-builder_simplified.ii ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../include/c++/11.0.1 /home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../include/c++/11.0.1/x86_64-pc-linux-gnu /home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../include/c++/11.0.1/backward /home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/include /usr/local/include /home/vagrant/install-gcc/include /home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=c++20' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' /home/vagrant/install-gcc/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/cc1plus -fpreprocessed a-builder_simplified.ii -quiet -dumpdir a- -dumpbase builder_simplified.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -Wall -std=c++20 -version -o a-builder_simplified.s GNU C++20 (GCC) version 11.0.1 20210307 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 11.0.1 20210307 (experimental), GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++20 (GCC) version 11.0.1 20210307 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 11.0.1 20210307 (experimental), GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 95262a810cbe258ee31ada9b2568b963 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=c++20' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' as -v --64 -o a-builder_simplified.o a-builder_simplified.s GNU assembler version 2.35.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.35.1 COMPILER_PATH=/home/vagrant/install-gcc/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/:/home/vagrant/install-gcc/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/:/home/vagrant/install-gcc/libexec/gcc/x86_64-pc-linux-gnu/:/home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/:/home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/ LIBRARY_PATH=/home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/:/home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=c++20' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.' /home/vagrant/install-gcc/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/collect2 -plugin /home/vagrant/install-gcc/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/liblto_plugin.so -plugin-opt=/home/vagrant/install-gcc/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper -plugin-opt=-fresolution=a.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/crt1.o /lib/x86_64-linux-gnu/crti.o /home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/crtbegin.o -L/home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1 -L/home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/home/vagrant/install-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../.. a-builder_simplified.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334 --- Comment #2 from AJ D --- The problem seems to have been addressed in gcc-8.x, at least in this particular function. I could reproduce this issue in gcc-7.4, but not with gcc-8.2, as can be seen below. Will have to check if this issue is showing up in any other functions. odcphy-vg-1294> module load gcc/7.4.0 odcphy-vg-1294> ./reproduce.csh 02f0 0044 02f4 FDE cie= pc=6570..680a LOC CFA rbx rbp r12 r13 r14 r15 ra 6570 rsp+8u u u u u u c-8 6575 r10+0u u u u u u c-8 657e r10+0u exp u u u u c-8 6589 r10+0u exp exp exp exp exp c-8 658e exp u exp exp exp exp exp c-8 6592 exp exp exp exp exp exp exp c-8 65f5 r10+0exp exp exp exp exp exp c-8 6602 rsp+8exp exp exp exp exp exp c-8 6608 exp exp exp exp exp exp exp c-8 odcphy-vg-1294> odcphy-vg-1294> module load gcc/8.2.0 odcphy-vg-1294> ./reproduce.csh 02c8 0034 02cc FDE cie= pc=6450..676f LOC CFA rbx rbp r12 r13 r14 r15 ra 6450 rsp+8u u u u u u c-8 6451 rsp+16 u c-16 u u u u c-8 6454 rbp+16 u c-16 u u u u c-8 645a rbp+16 u c-16 u c-40 c-32 c-24 c-8 645f rbp+16 u c-16 c-48 c-40 c-32 c-24 c-8 6463 rbp+16 c-56 c-16 c-48 c-40 c-32 c-24 c-8 6518 rsp+8c-56 c-16 c-48 c-40 c-32 c-24 c-8 6520 rbp+16 c-56 c-16 c-48 c-40 c-32 c-24 c-8 6550 rsp+8c-56 c-16 c-48 c-40 c-32 c-24 c-8 odcphy-vg-1294>
[Bug tree-optimization/99473] redundant conditional zero-initialization not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99473 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-03-08 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Confirmed, I think there are other bugs dealing with this same thing. g3 should have been caught by cstore but I don't see why it is not. Also g2 needs commoning by sinking rather commoning by pulling.
[Bug tree-optimization/99474] New: missing warning on an out of bounds VLA access by a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99474
Bug ID: 99474
Summary: missing warning on an out of bounds VLA access by a
pointer
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The out of bounds access in both functions below should be diagnosed by
-Warray-bounds but only the first one is.
$ cat v.c && gcc -O2 -S -Wall v.c
void f (void*);
void g (void)
{
int a[5];
int *p = [0];
p[5] = 0;// -Warray-bounds (good)
f (a);
}
void h (int n)
{
if (n > 5)
n = 5;
int a[n];
int *p = [0];
p[5] = 0;// missing warning
f (a);
}
v.c: In function ‘g’:
v.c:7:4: warning: array subscript 5 is outside array bounds of ‘int[5]’
[-Warray-bounds]
7 | p[5] = 0;// -Warray-bounds (good)
| ~^~~
v.c:5:7: note: while referencing ‘a’
5 | int a[5];
| ^
[Bug fortran/99205] [10/11 Regression] Out of memory with undefined character length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-03-08 Status|UNCONFIRMED |NEW Known to work||9.3.1 Known to fail||10.2.1, 11.0 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. gcc-9 gave: pr99205.f90:2:12: 2 | character(l) :: c(2) |1 Error: Variable 'l' cannot appear in the expression at (1) pr99205.f90:2:22: 2 | character(l) :: c(2) | 1 Error: 'c' at (1) must have constant character length in this context pr99205.f90:3:16: 3 | data c /'a', 'b'/ |1 Warning: Initialization string at (1) was truncated to fit the variable (0/1)
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 Philippe Blain changed: What|Removed |Added CC||levraiphilippeblain at gmail dot c ||om --- Comment #3 from Philippe Blain --- I searched for other *-gdb.py files on my system and looked at the build process for these projetcs, and found one interesting example for libisl, where it looks like they rely on the libtool *.la file to get the right name for the (shared or not) library: https://repo.or.cz/isl.git/blob/HEAD:/Makefile.am#l611 Maybe something similar could be done?
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 --- Comment #28 from Iain Sandoe --- (In reply to Iain Sandoe from comment #27) > for Darwin x86 > > * the test at line 83 fails, and with some more debugging stuff inserted and > the abort removed, there are 66 cases where the strings do not agree, so a > bug in libc (probably) .. I'm doing seem more tests on a newer system > version. repeated on macOS11 (Darwin20) - the fails are for precisions 1, 5, 9 and 13 (if there's any significance to that) with a pattern that looks like this: begin 9.2p-11003, printf_buffer 0x9.1p-11003 FAILED: prec has value 1 -- begin 9.1a2b4p-11003, printf_buffer 0x9.1a2b3p-11003 FAILED: prec has value 5 -- begin 9.1a2b3c4d6p-11003, printf_buffer 0x9.1a2b3c4d5p-11003 FAILED: prec has value 9 -- begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003 FAILED: prec has value 13 -- begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003 FAILED: prec has value 13 -- begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003 FAILED: prec has value 13 (and similarly for the other values that fail, not read the code enough yet to figure out why we get the three cases for 13...).
[Bug libstdc++/99433] [11 Regression] custom friend pipe-operator| conflicts with range adaptor?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99433
gcc-bugs at marehr dot dialup.fu-berlin.de changed:
What|Removed |Added
Summary|custom friend |[11 Regression] custom
|pipe-operator| conflicts|friend pipe-operator|
|with range adaptor? |conflicts with range
||adaptor?
Component|c++ |libstdc++
--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Hello gcc-team,
I got the code more recuced to:
```c++
namespace std
{
template _Up __declval(int);
template auto declval() noexcept -> decltype(__declval<_Tp>(0));
} // namespace std
namespace std::ranges
{
struct view_base {};
template
class view_interface : public view_base {};
} // namespace std::ranges
namespace std::ranges::views::__adaptor
{
template
struct _RangeAdaptorClosure;
template
struct _RangeAdaptor
{
_Callable _M_callable;
constexpr _RangeAdaptor(const _Callable & __callable)
: _M_callable{__callable}
{}
template
constexpr auto operator()(_Args &&...__args) const
{
auto __closure = [... __args(__args)](_Range &&__r) {
return _Callable{}(__r, __args...);
};
using _ClosureType = decltype(__closure);
return _RangeAdaptorClosure{__closure};
}
};
template
struct _RangeAdaptorClosure : public _RangeAdaptor<_Callable>
{
template
requires requires {declval<_Callable>()(declval<_Range>());}
friend constexpr auto operator|(_Range &&__r, const _RangeAdaptorClosure
&__o);
};
template
_RangeAdaptorClosure(_Callable) -> _RangeAdaptorClosure<_Callable>;
} // namespace std::ranges::views::__adaptor
namespace std::ranges
{
template
class transform_view : public view_interface> {};
} // namespace std::ranges
namespace std::ranges::views
{
inline constexpr __adaptor::_RangeAdaptor transform =
[](auto &&__r, auto &&__f)
{
return transform_view{__r, __f};
};
} // namespace std::ranges::views
namespace std
{
namespace views = ranges::views;
template class vector {};
} // namespace std
template
struct deep
{
underlying_adaptor_t adaptor;
template
friend auto operator|(range_t , deep const ) {
return 0;
}
};
template
deep(underlying_adaptor_t && adaptor) -> deep;
inline auto const complement = deep{std::views::transform([]() {})};
std::vector> foo;
auto v = foo | complement;
```
See https://godbolt.org/z/51d9da
AFAIS the problem is that
```c++
template
requires requires {declval<_Callable>()(declval<_Range>());}
std::ranges::views::__adaptor::_RangeAdaptorClosure::operator|(_Range &&__r,
const _RangeAdaptorClosure &__o)
```
does not constraint the second argument to be `_RangeAdaptorClosure &__o`.
If I see this correctly, this is the same issue as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97704 (which was marked invalid).
Just that this time your std-lib implementation is at fault. I still find it
insane that a non-template argument that does not fit is somehow considered in
a requires expression, since this effectively forbids to use constraints on non
template or partial template functions, but it is as it is, and it would be
cool if the std-lib implementation plays by the same rules.
(Why isn't a constraint with the type added implicitly to the requires clause
in these cases? That seems to be a workaround anyway...)
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Rainer Orth ---
> Unfortunately, I'm still seeing the ICE reported in PR target/99432 on
> i386-pc-solaris2.11.
While I could build yesterday's tree with the PR 99378 patch included on
sparc-sun-solaris2.11, today with the PR 99422 patch in tree as well,
bootstrap is broken:
a-ztflau.adb: In function 'Ada.Float_Wide_Wide_Text_Io.Aux_Float.Puts':
a-ztflau.adb:132:8: error: insn does not satisfy its constraints:
(insn 174 39 180 2 (set (mem/c:DF (plus:SI (reg/f:SI 30 %fp)
(const_int -5216 [0xeba0])) [37 %sfp+-5216 S8 A64])
(reg:DF 40 %f8 [203])) "a-ztflau.adb":117:7 153 {*movdf_insn_sp32}
(nil))
during RTL pass: reload
+===GNAT BUG DETECTED==+
| 11.0.1 20210308 (experimental) [master revision
0d9a70ea3881c284b7689b691d54d047b55b486d] (sparc-sun-solaris2.11) GCC error:|
| in extract_constrain_insn, at recog.c:2670 |
| Error detected around a-ztflau.adb:132:8
Reverting both patches locally allowed both sparc-sun-solaris2.11 and
i386-pc-solaris2.11 bootstraps to succeed.
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 --- Comment #27 from Iain Sandoe --- for Darwin x86 * the test at line 83 fails, and with some more debugging stuff inserted and the abort removed, there are 66 cases where the strings do not agree, so a bug in libc (probably) .. I'm doing seem more tests on a newer system version. for Darwin PPC * the tests don't build currently, because the new symbols need adding to the library exports (patch incoming for that). However, with the symbol fix, there's then a different fail (round-trip) which I have yet to analyse.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 --- Comment #29 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bd85b4dd2dd7b00b6342ed1e33fb48035a3dcb61 commit r11-7564-gbd85b4dd2dd7b00b6342ed1e33fb48035a3dcb61 Author: Harald Anlauf Date: Mon Mar 8 21:59:20 2021 +0100 PR fortran/49278 - ICE when combining DATA with default initialization A variable with the PARAMETER attribute may not appear in a DATA statement. gcc/fortran/ChangeLog: PR fortran/49278 * data.c (gfc_assign_data_value): Reject variable with PARAMETER attribute in DATA statement. gcc/testsuite/ChangeLog: PR fortran/49278 * gfortran.dg/parameter_data.f90: New test.
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 --- Comment #16 from Khem Raj --- the kernel build failures still happen. I am re-opened #99454 and #99455
[Bug target/99434] std::bit_cast generates more instructions than __builtin_bit_cast and memcpy with -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99434
--- Comment #6 from cqwrteur ---
(In reply to Jakub Jelinek from comment #5)
> Testcase without includes:
> template
> constexpr _To
> bit_cast(const _From& __from) noexcept
> {
> return __builtin_bit_cast(_To, __from);
> }
>
> struct u64x2_t
> {
> #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
> unsigned long long high,low;
> #else
> unsigned long long low,high;
> #endif
> };
> u64x2_t umul5(unsigned long long a,unsigned long long b) noexcept
> {
> return bit_cast(static_cast<__uint128_t>(a)*b);
> }
>
> u64x2_t umul_builtin(unsigned long long a,unsigned long long b) noexcept
> {
> return __builtin_bit_cast(u64x2_t,static_cast<__uint128_t>(a)*b);
> }
did you fix the >>64 bug here? should I start another bug to report that?
The bit_cast/memcpy trick is to deal with the issue of. Probably can be
recognized early on than std::bit_cast?
std::uint64_t umul128(std::uint64_t a,std::uint64_t b,std::uint64_t& high)
noexcept
{
__uint128_t res{static_cast<__uint128_t>(a)*b};
high=static_cast(res>>64);
return static_cast(res);
}
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 98266, which changed state. Bug 98266 Summary: [11 Regression] bogus array subscript is partly outside array bounds on virtual inheritance https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98266 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/98266] [11 Regression] bogus array subscript is partly outside array bounds on virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98266 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Sebor --- Fixed in r11-7563.
[Bug middle-end/98266] [11 Regression] bogus array subscript is partly outside array bounds on virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98266 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:f3daa6c0fd8d79ae45eac2dd0f274da1aa71c958 commit r11-7563-gf3daa6c0fd8d79ae45eac2dd0f274da1aa71c958 Author: Martin Sebor Date: Mon Mar 8 13:37:21 2021 -0700 PR middle-end/98266 - bogus array subscript is partly outside array bounds on virtual inheritance gcc/ChangeLog: PR middle-end/98266 * gimple-array-bounds.cc (inbounds_vbase_memaccess_p): New function. (array_bounds_checker::check_array_bounds): Call it. gcc/testsuite/ChangeLog: PR middle-end/98266 * g++.dg/warn/Warray-bounds-15.C: New test. * g++.dg/warn/Warray-bounds-18.C: New test. * g++.dg/warn/Warray-bounds-19.C: New test. * g++.dg/warn/Warray-bounds-20.C: New test. * g++.dg/warn/Warray-bounds-21.C: New test.
[Bug tree-optimization/97631] [10 Regression] bogus "writing one too many bytes" warning for memcpy with strlen argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97631 Martin Sebor changed: What|Removed |Added Known to fail|11.0| Summary|[10/11 Regression] bogus|[10 Regression] bogus |"writing one too many |"writing one too many |bytes" warning for memcpy |bytes" warning for memcpy |with strlen argument|with strlen argument Known to work||11.0 --- Comment #4 from Martin Sebor --- Fixed in GCC 11.
[Bug tree-optimization/97631] [10/11 Regression] bogus "writing one too many bytes" warning for memcpy with strlen argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97631 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:7f5ff78ff3f971c11ec67f422b2fd34281db9123 commit r11-7562-g7f5ff78ff3f971c11ec67f422b2fd34281db9123 Author: Martin Sebor Date: Mon Mar 8 13:28:52 2021 -0700 PR middle-end/97631 - bogus "writing one too many bytes" warning for memcpy with strlen argument gcc/ChangeLog: PR middle-end/97631 * tree-ssa-strlen.c (maybe_warn_overflow): Test rawmem. (handle_builtin_stxncpy_strncat): Rename locals. Determine destination size from allocation calls. Issue a more appropriate kind of warning. (handle_builtin_memcpy): Pass true as rawmem to maybe_warn_overflow. (handle_builtin_memset): Same. gcc/testsuite/ChangeLog: PR middle-end/97631 * c-c++-common/Wstringop-overflow.c: Remove unexpected warnings. Add an xfail. * c-c++-common/Wstringop-truncation.c: Add expected warnings. * gcc.dg/Wstringop-overflow-10.c: Also enable -Wstringop-truncation. * gcc.dg/Wstringop-overflow-66.c: New test. * gcc.dg/tree-ssa/strncpy-2.c: Adjust expected warning.
[Bug c++/96268] class-type NTTP CTAD for string-literal aggregate fails on aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96268 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Marek Polacek --- Done.
[Bug c++/96268] class-type NTTP CTAD for string-literal aggregate fails on aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96268 --- Comment #6 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:b64551af5159ea30b5941ddd430001b13936822c commit r11-7561-gb64551af5159ea30b5941ddd430001b13936822c Author: Marek Polacek Date: Mon Mar 8 15:26:58 2021 -0500 c++: Add test for PR96268. This works since the recent r11-7102, but we didn't have a test for a template-argument context. gcc/testsuite/ChangeLog: PR c++/96268 * g++.dg/cpp2a/nontype-class41.C: New test.
[Bug tree-optimization/99473] New: redundant conditional zero-initialization not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99473
Bug ID: 99473
Summary: redundant conditional zero-initialization not
eliminated
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
All three functions below should result in equivalently optimal code (and,
ideally IL) but only g1() and g3() result in the same assembly, and only g1()
result in optimal, branchless GIMPLE.
$ cat x.c && gcc -O2 -S -Wall -o/dev/stdout x.c
void f (int*);
void g1 (int i)
{
int x;
if (i)
x = i;
else
x = 0;
f ();
}
void g2 (int i)
{
int x;
if (i) {
x = i;
f ();
}
else {
x = 0;
f ();
}
}
void g3 (int i)
{
int x = 0;
if (i)
x = i;
f ();
}
.file "x.c"
.text
.p2align 4
.globl g1
.type g1, @function
g1:
.LFB0:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movl%edi, 12(%rsp)
leaq12(%rsp), %rdi
callf
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size g1, .-g1
.p2align 4
.globl g2
.type g2, @function
g2:
.LFB1:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
testl %edi, %edi
je .L5
movl%edi, 12(%rsp)
leaq12(%rsp), %rdi
callf
addq$24, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
.L5:
.cfi_restore_state
leaq12(%rsp), %rdi
movl$0, 12(%rsp)
callf
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size g2, .-g2
.p2align 4
.globl g3
.type g3, @function
g3:
.LFB2:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movl%edi, 12(%rsp)
leaq12(%rsp), %rdi
callf
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE2:
.size g3, .-g3
.ident "GCC: (GNU) 11.0.1 20210308 (experimental)"
.section.note.GNU-stack,"",@progbits
[Bug c++/96268] class-type NTTP CTAD for string-literal aggregate fails on aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96268 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- Works since r11-7102. Will add the test, since we don't have it yet. Thanks Will!
[Bug c++/96268] class-type NTTP CTAD for string-literal aggregate fails on aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96268 --- Comment #4 from Will Wray --- This now appears fixed on 11 trunk
[Bug c++/99436] ICE in get_cxx_dialect_name, at cp/name-lookup.c:6955 when using modules on C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99436 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Nathan Sidwell --- bc56d27de97 2021-03-08 | C++: Enable c++2b module mode [PR 99436]
[Bug c++/99436] ICE in get_cxx_dialect_name, at cp/name-lookup.c:6955 when using modules on C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99436 --- Comment #1 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:bc56d27de97ecea813279ce5ba45b278dcccfe21 commit r11-7560-gbc56d27de97ecea813279ce5ba45b278dcccfe21 Author: Nathan Sidwell Date: Mon Mar 8 11:55:26 2021 -0800 C++: Enable c++2b module mode [PR 99436] This adds support for c++23 mode to modules, and enables such testing. PR c++/99436 gcc/cp/ * name-lookup.c (get_cxx_dialect_name): Add cxx23. gcc/testsuite/ * g++.dg/modules/modules.exp (MOD_STD_LIST): Add 2b.
[Bug fortran/99345] [11 Regression] ICE in doloop_contained_procedure_code, at fortran/frontend-passes.c:2464 since r11-2578-g27eac9ee6137a6b5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99345 --- Comment #10 from anlauf at gcc dot gnu.org --- Further reduced: DO iq = 1, nq CALL calc_upper_fan (iq) ENDDO CONTAINS SUBROUTINE calc_upper_fan (iq) INTEGER :: iq INTEGER :: recl INQUIRE(IOLENGTH=recl) iq END END
[Bug c++/99472] [modules] std=c++2b flag appears incompatible with C++20 module code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99472 --- Comment #2 from Nathan Sidwell --- indeed, also enabling modules test in 2b mode
[Bug c++/99472] [modules] std=c++2b flag appears incompatible with C++20 module code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99472 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2021-03-08 --- Comment #1 from Marek Polacek --- get_cxx_dialect_name doesn't handle C++23 yet. Looks like Nathan is on it.
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 --- Comment #15 from Gerald Pfeifer --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99438 still happens, i.e. i586-unknown-freebsd11.2. Is anyone able to successfully build any 32-bit x86 target?
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 --- Comment #26 from David Edelsohn --- By default, long double on AIX is the same as double (64 bits). One optionally can specify 128 bit long double and link with libc128.a to provide long double stdio. AIX float.h: #define DECIMAL_DIG37 I'm perfectly okay with libstdc++ skipping this test on AIX. I don't know how you want to skip it. I would suggest dg-require-effective-target longdouble128 Or you can skip the portions of the test that expect DECIMAL_DIG > 37.
[Bug c/99455] internal compiler error: In function 'prb_reserve_in_last' in linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99455 --- Comment #3 from Khem Raj --- Created attachment 50333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50333=edit testcase
[Bug c/99455] internal compiler error: In function 'prb_reserve_in_last' in linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99455 Khem Raj changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #2 from Khem Raj --- This is still reproducing with gcc built after fix for #99422 went in.
[Bug rtl-optimization/99469] ICE: qsort checking failed with selective scheduling on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99469 --- Comment #1 from Alex Coplan --- FWIW this is easy to reproduce with either csmith or yarpgen, so should be straightforward to procure a new testcase if the above goes latent.
[Bug c/99454] internal compiler error: kernel module tg3 tg3_start_xmit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454 Khem Raj changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED --- Comment #3 from Khem Raj --- This is not resolved with the fix for #99422 therefore I am re-opening. I tried with fresh build with head being https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0d9a70ea3881c284b7689b691d54d047b55b486d which includes the fix for #99422
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 --- Comment #14 from Vladimir Makarov --- *** Bug 99467 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/99467] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1006 since r11-7526-g9105757a59b89019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99467 Vladimir Makarov changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Vladimir Makarov --- I confirm it is a duplicate of PR99422. With the patch for PR99422, the crash is gone. *** This bug has been marked as a duplicate of bug 99422 ***
[Bug rtl-optimization/99467] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1006 since r11-7526-g9105757a59b89019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99467 Bug 99467 depends on bug 99461, which changed state. Bug 99461 Summary: [11 Regression] ICE in extract_constrain_insn, at recog.c:2670 since r11-7526-g9105757a59b89019 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99461 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 --- Comment #13 from Vladimir Makarov --- *** Bug 99461 has been marked as a duplicate of this bug. ***
[Bug target/99461] [11 Regression] ICE in extract_constrain_insn, at recog.c:2670 since r11-7526-g9105757a59b89019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99461 Vladimir Makarov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||vmakarov at gcc dot gnu.org --- Comment #3 from Vladimir Makarov --- It is a duplicate of PR99422. With patch for PR99422, the crash is gone. *** This bug has been marked as a duplicate of bug 99422 ***
[Bug target/99437] [11 Regression] Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,15'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99437 Khem Raj changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Khem Raj --- I can confirm that the above commit fixed the ICE
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #12 from Rainer Orth --- Unfortunately, I'm still seeing the ICE reported in PR target/99432 on i386-pc-solaris2.11.
[Bug c++/99468] [modules] awkward diagnostic for named-module inside header unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99468 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- 504450c708c 2021-03-08 | c++: Poor diagnostic in header-unit [PR 99468]
[Bug c++/99468] [modules] awkward diagnostic for named-module inside header unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99468 --- Comment #1 from Nathan Sidwell --- 504450c708c 2021-03-08 | c++: Poor diagnostic in header-unit [PR 99468]
Undeliverable mail: 何晓洁
Failed to deliver to '1918199...@qq.com' SMTP module(domain qq.com) reports: host mx3.qq.com says: 550 Mailbox unavailable or access denied [MLhHVHLXRmXTTUI3rSVMccYp7fj8wY1a3idftwzU/qu+syDwCgBm3oaSBHI0sB6T7g== IP: 8.19.118.54] Reporting-MTA: dns; stsh501.appriver.com Original-Recipient: rfc822;<1918199926@qq.com> Final-Recipient: rfc822;<1918199926@qq.com> Action: failed Status: 5.0.0 Remote-MTA: dns; qq.com Diagnostic-Code: smtp;host mx3.qq.com says: 550 Mailbox unavailable or access denied [MLhHVHLXRmXTTUI3rSVMccYp7fj8wY1a3idftwzU/qu+syDwCgBm3oaSBHI0sB6T7g== IP: 8.19.118.54] Received: by stsh501.appriver.com (CommuniGate Pro PIPE 6.2.15) with PIPE id 11891736; Mon, 08 Mar 2021 12:27:27 -0600 Received: from [69.159.199.89] (HELO AMT-EXCHANGE.AMT.local) by stsh501.appriver.com (CommuniGate Pro SMTP 6.2.15) with ESMTP id 11891702 for 1918199...@qq.com; Mon, 08 Mar 2021 12:27:24 -0600 Received: from AMT-EXCHANGE.AMT.local (10.0.0.251) by AMT-EXCHANGE.AMT.local (10.0.0.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Mon, 8 Mar 2021 13:27:02 -0500 Received: from SKY-20150219JSJ (60.189.193.209) by AMT-EXCHANGE.AMT.local (10.0.0.251) with Microsoft SMTP Server id 15.2.721.2 via Frontend Transport; Mon, 8 Mar 2021 13:27:01 -0500 X-GUID: C1BA85FB-8538-4771-85DD-C465C0FF87E2 X-Has-Attach: yes Subject: =?UTF-8?B?5L2V5pmT5rSB?= From: "gcc-bugs@gcc.gnu.org" To: 1918199926 <1918199...@qq.com> MIME-Version: 1.0 Date: Tue, 9 Mar 2021 02:27:05 +0800 Message-ID: <202103090227049456...@gcc.gnu.org> X-Mailer: Foxmail 7, 2, 5, 140[cn] Return-Path: gcc-bugs@gcc.gnu.org Content-Type: multipart/mixed; charset="UTF-8"; boundary="=_134_NextPart714932479909_=" X-Note: This Email was scanned by AppRiver SecureTide X-Note-AR-ScanTimeLocal: 03/08/2021 12:27:24 PM X-Note: SecureTide Build: 2/18/2021 6:23:18 PM UTC (2.18.2.0) X-Note: Filtered by 10.168.232.130 X-Policy: amtmachine.com X-Primary: amtmachine@amtmachine.com X-Note-Sender: gcc-bugs@gcc.gnu.org X-Note: VCH-CT/SI: 0-7002/SG:1 3/8/2021 12:26:59 PM X-Virus-Scan: V-X0H0M0 X-Note: ICH-CT/SI:0-1985/SG:1 3/8/2021 12:26:59 PM X-Note-SnifferID: 0 X-GBUdb-Analysis: 0, 69.159.199.89, Ugly c=1 p=-0.97866 Source White X-Signature-Violations: 0-0-0-10843-c X-Warn: ASIAN-CHR X-Note: Spam Tests Failed: ASIAN-CHR X-Country-Path: Canada-> X-Note-Sending-IP: 69.159.199.89 X-Note-Reverse-DNS: toroon12-1168099161.sdsl.bell.ca X-Note-Return-Path: gcc-bugs@gcc.gnu.org X-Note: User Rule Hits: X-Note: Global Rule Hits: G826 G827 G828 G829 G847 G848 G849 G921 G1256 G1269 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID
[Bug rtl-optimization/99470] Convert fixed index addition to array address offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99470 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > The reason why int is not equivalent because signed integer overflow is > undefined plus doing the math in 64bit or 32bit would cause a huge > difference in some cases. The cases is if a/b are negative.
[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959 --- Comment #18 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:cb25dea3ef2c7768007bffc56f0e31e1c42b44e2 commit r11-7558-gcb25dea3ef2c7768007bffc56f0e31e1c42b44e2 Author: Peter Bergner Date: Mon Mar 8 12:20:41 2021 -0600 rs6000: Fix invalid splits when using Altivec style addresses [PR98959] The rs6000_emit_le_vsx_* functions assume they are not passed an Altivec style "& ~16" address. However, some of our expanders and splitters do not verify we do not have an Altivec style address before calling those functions, leading to an ICE. The solution here is to guard the expanders and splitters to ensure we do not call them if we're given an Altivec style address. 2021-03-08 Peter Bergner gcc/ PR target/98959 * config/rs6000/rs6000.c (rs6000_emit_le_vsx_permute): Add an assert to ensure we do not have an Altivec style address. * config/rs6000/vsx.md (*vsx_le_perm_load_): Disable if passed an Altivec style address. (*vsx_le_perm_store_): Likewise. (splitters after *vsx_le_perm_store_): Likewise. (vsx_load_): Disable special expander if passed an Altivec style address. (vsx_store_): Likewise. gcc/testsuite/ PR target/98959 * gcc.target/powerpc/pr98959.c: New test.
[Bug rtl-optimization/99470] Convert fixed index addition to array address offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99470
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andrew Pinski ---
These functions have the same code gen though:
inline signed char arr[256];
bool f(unsigned long a, unsigned long b) {
return arr[a+128] == arr[b+128];
}
bool g(unsigned long a, unsigned long b) {
return (arr+128)[a] == (arr+128)[b];
}
- CUT -
The reason why int is not equivalent because signed integer overflow is
undefined plus doing the math in 64bit or 32bit would cause a huge difference
in some cases.
[Bug sanitizer/99418] sanitizer checks for accessing multidimentional VLA-array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99418
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #5 from Martin Sebor ---
The initialization of a reference binds it to the value of the initializer
expression. In both examples the [value of the] initializer expression is
undefined because it doesn't refer to an element of the array. One way to see
that is in a constexpr context which rejects undefined constructs with an error
(only with Clang; GCC doesn't reject invalid initialization of references
there, see also pr70151):
$ cat t.C && clang -S t.C
constexpr int a[2] = { 1, 2 };
constexpr const int = a[2];
t.C:2:26: warning: array index 2 is past the end of the array (which contains 2
elements) [-Warray-bounds]
constexpr const int = a[2];
^ ~
t.C:1:1: note: array 'a' declared here
constexpr int a[2] = { 1, 2 };
^
t.C:2:22: error: constexpr variable 'r' must be initialized by a constant
expression
constexpr const int = a[2];
^
t.C:2:22: note: dereferenced pointer past the end of subobject of 'a' is not a
constant expression
t.C:1:15: note: declared here
constexpr int a[2] = { 1, 2 };
^
1 warning and 1 error generated.
[Bug ipa/98834] [10/11 Regression] Code path incorrectly determined to be unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834 Martin Jambor changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Martin Jambor --- (In reply to Jakub Jelinek from comment #4) > Started with r10-3106-g46dfa8ad6c18feb45d35734eae38798edb7c38cd > Anyway, I wonder if this isn't similar to the cases where the inliner > optimistically assumed that __builtin_constant_p will fold to true but > didn't actually fold it that way, and then later on that didn't happen? It is exactly that. We have one __builtin_constant_p that is called if another, previous __builtin_constant_p returns false. Inlining assumes the previous one will be folded to true because it knows it is called on a constant, albeit one read from an aggregate, and therefore assumes the latter will never happen. But after inlining, the situation looks like this (some statements omitted): [local count: 1073741824]: MEM [(struct simdD.2582 *)&__xD.2752] = 0; MEM [(struct simdD.2582 *)&__xD.2752 + 4B] = 0; ... __xD.2820 = __xD.2752._M_dataD.2591; ... __xx_10 = MEM [(struct _TupleD.2456 *)&__xD.2820]; _11 = __builtin_constant_p (__xx_10); And we need a SRA + CCP to make the constant travel from the first assignment to the __builtin_constant_p (__xx_10). And SRA does take place only after VRP which already decides to fold __builtin_constant_p to false. A quick and dirty (and potentially regression causing) way to fix that is to declare __builtin_constant_p not working on aggregate values: diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c index 18bbae145b9..c319323b31e 100644 --- a/gcc/ipa-fnsummary.c +++ b/gcc/ipa-fnsummary.c @@ -1638,7 +1638,8 @@ set_cond_stmt_execution_predicate (struct ipa_func_body_info *fbi, || gimple_call_num_args (set_stmt) != 1) return; op2 = gimple_call_arg (set_stmt, 0); - if (!decompose_param_expr (fbi, set_stmt, op2, , _type, )) + if (!decompose_param_expr (fbi, set_stmt, op2, , _type, ) + || aggpos.agg_contents) return; if (!aggpos.by_ref) add_builtin_constant_p_parm (summary, index); (the last condition would then also need to be turned into a comment ...and possibly an assert). But it feels like too big a hammer. Alternatively, we could just resolve the builtin at IPA time. We'd need to store the predicate derived from its argument to ipa_call_summary and then at IPA time redirect it to some __builtin_true_p when IPA figures out it has to be true, which we would then redirect in cgraph_edge::redirect_call_stmt_to_callee. Honza, would that be a good idea?
[Bug c++/99472] New: [modules] std=c++2b flag appears incompatible with C++20 module code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99472 Bug ID: 99472 Summary: [modules] std=c++2b flag appears incompatible with C++20 module code Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wjwray at gmail dot com Target Milestone: --- Same as bug 99436, submitting with [modules] subject and CE link https://godbolt.org/z/8ME9d8 export module foo; This works: -std=c++20 -fmodules-ts This fails: -std=c++2b -fmodules-ts -> ICE This fails: -std=c++2b -> warning: keyword 'export' is enabled with '-fmodules-ts'
[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 99285, which changed state. Bug 99285 Summary: [modules] ICE canonical types differ for identical types ‘std::common_type... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99285 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/99285] [modules] ICE canonical types differ for identical types ‘std::common_type...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99285 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Nathan Sidwell --- ded6a1953dd 2021-03-08 | c++: Incorrect specialization hash table [PR 99285]
[Bug c++/99285] [modules] ICE canonical types differ for identical types ‘std::common_type...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99285 --- Comment #2 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:ded6a1953dd7f43229c44e5d0d17c264338a3f4c commit r11-7557-gded6a1953dd7f43229c44e5d0d17c264338a3f4c Author: Nathan Sidwell Date: Mon Mar 8 10:01:21 2021 -0800 c++: Incorrect specialization hash table [PR 99285] Class template partial specializations need to be in the specialization hash, but not all of them. This defers adding streamed-in entities to the hash table, in the same way I deferred adding the instantiation and specialization lists for 99170. PR c++/99285 gcc/cp/ * cp-tree.h (match_mergeable_specialization) (add_mergeable_specialization): Adjust parms. * module.cc (trees_in::decl_value): Adjust add_mergeable_specialization calls. (trees_out::key_mergeable): Adjust match_mergeable_specialization calls. (specialization_add): Likewise. * pt.c (match_mergeable_specialization): Do not insert. (add_mergeable_specialization): Add to hash table here. gcc/testsuite/ * g++.dg/modules/pr99285_a.H: New. * g++.dg/modules/pr99285_b.H: New.
[Bug rtl-optimization/99470] Convert fixed index addition to array address offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99470 --- Comment #1 from Andrew Pinski --- these two code are not equivalent at all due to overflows and such.
[Bug rtl-optimization/99421] ICE:in code_motion_process_successors, at sel-sched.c:6389 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421 --- Comment #5 from Martin Liška --- (In reply to qinzhao from comment #4) > (In reply to Martin Liška from comment #3) > > Confirmed, reduced test-case: > > > just curious, how did you reduce the testing case with -fprofile-use? (I Sure. I used C-Vise: https://github.com/marxin/cvise with a built cross compiler: cvise -c 'cp ~/Programming/gcc2/objdir/gcc/predict.gcda . && /home/marxin/Programming/gcc2/objdir/gcc/xgcc -B /home/marxin/Programming/gcc2/objdir/gcc/ -fprofile-use -fselective-scheduling -fselective-scheduling2 -fsel-sched-pipelining -g -O3 -fno-strict-aliasing -c predict.i 2>&1 | grep code_motion_process_successors' predict.i > tried Creduce, but failed) > another question, how to repeat the failure with this reduced testing case? Note that one can theoretically reduce also the .gcda file. I have an experimental pass for it in C-Vise and I will likely upstream it. Does it explain all your questions?
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 --- Comment #25 from Andreas Schwab --- I don't think this is wrong, as long as DECIMAL_DIG <= 37.
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #24 from Patrick Palka ---
(In reply to David Edelsohn from comment #23)
> The AIX failure is:
>
> printf_buffer=
> 1.
> 4426950408889633870046509400708600880
> 000
>
> to_chars_buffer=
> 1.
> 44269504088896338700465094007086008787155151367187500
> 000??/?P1.
> 4426950408889633870046509400708600880
> 000
>
> output_length=
> 102
>
> ./long_double.cc:194: void test02(): Assertion '!memcmp(printf_buffer,
> to_chars_buffer, output_length)' failed.
I managed to reproduce this issue on AIX (gcc119). It looks like the %e/%f/%g
specifiers (as well as %Le/%Lf/%Lg -- long double is equivalent to double)
never output more than 37 significant decimal digits on AIX.
For e.g.
printf("%.53e\n", 0x1.71547652b82fep+0);
printf("%.0f\n", 0x1.249ad2594c37dp+332);
x86 glibc printf outputs
1.44269504088896338700465094007086008787155151367187500e+00
1159028911097599180468360808563945281389781327557747838772170381060813469985856815104
and AIX printf outputs
1.4426950408889633870046509400708600880e+00
115902891109759918047
It seems to me the output of AIX printf is wrong/nonconforming here..
[Bug c++/99471] New: Allow conversion from array of unknown bound to actual known bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99471
Bug ID: 99471
Summary: Allow conversion from array of unknown bound to actual
known bound
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
P0388 "Permit conversions to arrays of unknown bound" in C++20
does not explicitly discuss conversion back from unknown bound
to the actual bound of the referenced object.
Discussion with Richard Smith suggests that it is (or should be)
allowed to static_cast back to the known bound:
int a[4]{1,2,3,4};
int ()[] = a; // P0388 conversion
int ()[4] = r; // error: cannot bind reference of type
//'int (&)[4]' to 'int []'
It is intended that this be allowed (c.f. also bug 93191 end discussion).
However, it requires the compiler to trace the reference back to its object.
Allowing this enables new non-templated array-accepting function apis:
https://godbolt.org/z/1x4Tzs
constexpr // marking constexpr gives better codegen
int sum(int()[]) // despite being not constant evaluated
{
auto& in = (int(&)[__builtin_object_size(x,0) / sizeof(int)])x;
int acc = 0;
for (int i : in)
acc += i;
return acc;
}
int main() {
int a[]{1,2,3,4};
return sum(a);// returns 10 (1+2+3+4)
}
Here, __builtin_object_size requires optimization flags of -O1 or greater
in order to chase back the referenced object and extract its size in bytes.
However, it is not constant evaluated so the C-style cast is casting to VLA.
If the size can indeed be extracted as an integral constant expression then
the cast is a static_cast, or implicit conversion, as above.
So, this 'bug' is two requests:
1. Allow static_cast from T(&)[] -> T(&)[N] where N is the actual size
(or pointer T(*)[] -> T(*)[N])
2. Provide a constant-evaluated builtin to extract the referenced object size
(strengthen __builtin_object_size if possible)
(Some sort of array_size builtin, as discussed for C, would be good here too.)
[Bug c/99420] New warning -Warray-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99420
--- Comment #3 from Martin Sebor ---
The false positive is caused by the local redeclaration of f1() in h() below
not having had the type attributes added to it describing the form of the
array. This happens because instead of merging the type attributes from the
previous declaration of f1() in g() into those in h() as is done for f0,
pushdecl() sets them to null (on lines 3525-3562 in c/c-decl.c). The
difference is due to pushdecl() treating redeclarations of entities that are in
scope (like f0) differently than those that aren't (like f1() in h()).
$ cat u.c && gcc -S -Wall u.c
void f0 (int [1]);
void f0 (int [1]); // okay
void g (void)
{
void f1 (int [1]);
}
void h (void)
{
void f1 (int [1]); // bogus -Warray-parameter
}
u.c: In function ‘h’:
u.c:11:12: warning: argument 1 of type ‘int[1]’ with mismatched bound
[-Warray-parameter=]
11 | void f1 (int [1]); // bogus -Warray-parameter
|^~~
u.c:6:12: note: previously declared as ‘int *’
6 | void f1 (int [1]);
|^~~
[Bug rtl-optimization/99467] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1006 since r11-7526-g9105757a59b89019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99467 Andrew Pinski changed: What|Removed |Added Version|unknown |11.0 Target Milestone|--- |11.0
[Bug c++/99465] Segmentation fault when put lambda into requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99465 --- Comment #2 from 康桓瑋 --- Here is the minimal reduced example: f() requires [ godbolt: https://godbolt.org/z/eMWxPj
[Bug c++/99470] New: Convert fixed index addition to array address offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99470
Bug ID: 99470
Summary: Convert fixed index addition to array address offset
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
These two functions do the same thing but f() is the cleaner source code
(especially when arr is a std::array) while g() generates better code:
https://gcc.godbolt.org/z/vTT399
#include
inline int8_t arr[256];
bool f(int a, int b) {
return arr[a+128] == arr[b+128];
}
bool g(int a, int b) {
return (arr+128)[a] == (arr+128)[b];
}
f(int, int):
sub edi, -128
sub esi, -128
lea rax, arr[rip]
movsx rdi, edi
movsx rsi, esi
movzx edx, BYTE PTR [rax+rsi]
cmp BYTE PTR [rax+rdi], dl
seteal
ret
g(int, int):
lea rax, arr[rip+128]
movsx rdi, edi
movsx rsi, esi
movzx edx, BYTE PTR [rax+rsi]
cmp BYTE PTR [rax+rdi], dl
seteal
ret
In addition to only doing the +128 once, it also ends up being completely free
in g() because the assembler (or linker?) folds the addition into the address
calculation by adjusting the offset of the rip-relative address. In the godbolt
link, you can see that when compiled to binary, the LEA instruction uses the
same form in both f() and g(), so the addition really is free in g().
[Bug target/99434] std::bit_cast generates more instructions than __builtin_bit_cast and memcpy with -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99434
--- Comment #5 from Jakub Jelinek ---
Testcase without includes:
template
constexpr _To
bit_cast(const _From& __from) noexcept
{
return __builtin_bit_cast(_To, __from);
}
struct u64x2_t
{
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
unsigned long long high,low;
#else
unsigned long long low,high;
#endif
};
u64x2_t umul5(unsigned long long a,unsigned long long b) noexcept
{
return bit_cast(static_cast<__uint128_t>(a)*b);
}
u64x2_t umul_builtin(unsigned long long a,unsigned long long b) noexcept
{
return __builtin_bit_cast(u64x2_t,static_cast<__uint128_t>(a)*b);
}
[Bug target/99434] std::bit_cast generates more instructions than __builtin_bit_cast and memcpy with -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99434
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jamborm at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-03-08
--- Comment #4 from Jakub Jelinek ---
The umul5 case in #c0 is worse because of SRA.
With -O2 -fno-tree-sra optimized dump looks like:
_3 = a_4(D) w* b_5(D);
D.2396 = VIEW_CONVERT_EXPR(_3);
D.2383 = D.2396;
return D.2383;
and
_3 = a_4(D) w* b_5(D);
D.2389 = VIEW_CONVERT_EXPR(_3);
return D.2389;
for the two functions and even when there is the superfluous copying we emit
the same assembly.
But with SRA the former becomes:
_3 = a_4(D) w* b_5(D);
D.2396 = VIEW_CONVERT_EXPR(_3);
SR.6_12 = D.2396.low;
SR.7_13 = D.2396.high;
D.2383.low = SR.6_12;
D.2383.high = SR.7_13;
return D.2383;
In the -fno-tree-sra case the IL just contains one extra TImode pseudo ->
pseudo
assignment which is shortly optimized away, so we have just:
(insn 7 4 13 2 (parallel [
(set (reg:TI 87)
(mult:TI (zero_extend:TI (reg:DI 89))
(zero_extend:TI (reg:DI 90
(clobber (reg:CC 17 flags))
]) "pr99434.C":23:66 426 {*umulditi3_1}
(expr_list:REG_DEAD (reg:DI 90)
(expr_list:REG_DEAD (reg:DI 89)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
(insn 13 7 14 2 (set (reg/i:TI 0 ax)
(reg:TI 87)) "pr99434.C":24:1 73 {*movti_internal}
(expr_list:REG_DEAD (reg:TI 87)
(nil)))
(insn 14 13 0 2 (use (reg/i:TI 0 ax)) "pr99434.C":24:1 -1
(nil))
before reload, while with SRA we have:
(insn 7 4 19 2 (parallel [
(set (reg:TI 90)
(mult:TI (zero_extend:TI (reg:DI 98))
(zero_extend:TI (reg:DI 99
(clobber (reg:CC 17 flags))
]) "pr99434.C":18:57 426 {*umulditi3_1}
(expr_list:REG_DEAD (reg:DI 99)
(expr_list:REG_DEAD (reg:DI 98)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
(insn 19 7 20 2 (set (reg:DI 92 [ D.2396 ])
(subreg:DI (reg:TI 90) 0)) "pr99434.C":5:40 74 {*movdi_internal}
(nil))
(insn 20 19 23 2 (set (reg:DI 93 [ D.2396+8 ])
(subreg:DI (reg:TI 90) 8)) "pr99434.C":5:40 74 {*movdi_internal}
(expr_list:REG_DEAD (reg:TI 90)
(nil)))
(insn 23 20 24 2 (set (reg:DI 0 ax)
(reg:DI 92 [ D.2396 ])) "pr99434.C":19:1 74 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 92 [ D.2396 ])
(nil)))
(insn 24 23 17 2 (set (reg:DI 1 dx [+8 ])
(reg:DI 93 [ D.2396+8 ])) "pr99434.C":19:1 74 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 93 [ D.2396+8 ])
(nil)))
(insn 17 24 0 2 (use (reg/i:TI 0 ax)) "pr99434.C":19:1 -1
(nil))
While in both cases we get the same (right) RA decisions about the umulditi3_1,
and the IRA decisions seems to be good too:
Popping a2(r90,l0) -- assign reg 0
Popping a4(r98,l0) -- assign reg 5
Popping a0(r93,l0) -- assign reg 1
Popping a1(r92,l0) -- assign reg 0
Popping a3(r99,l0) -- assign reg 4
for some reason LRA then decides to use different registers...
[Bug target/99378] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6710
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99378 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in |in |decompose_normal_address, |decompose_normal_address, |at rtlanal.c:6710 |at rtlanal.c:6710 | --- Comment #5 from Jakub Jelinek --- Yes. But note the https://gcc.gnu.org/g:04b4828c6dd215385fde6964a5e13da8a01a78ba commit r11-7554-g04b4828c6dd215385fde6964a5e13da8a01a78ba Author: Vladimir N. Makarov Date: Mon Mar 8 09:24:57 2021 -0500 [PR99422] LRA: Skip modifiers when processing memory address. Function process_address_1 can wrongly look at constraint modifiers instead of the 1st constraint itself. The patch solves the problem. gcc/ChangeLog: PR target/99422 * lra-constraints.c (skip_contraint_modifiers): New function. (process_address_1): Use it before lookup_constraint call. follow-up.
[Bug c++/94162] ICE [neg] bad return type in defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162
--- Comment #8 from Jakub Jelinek ---
Test from PR99429:
namespace std {
struct strong_ordering {
int _v;
constexpr strong_ordering (int v) :_v(v) {}
constexpr operator int (void) const { return _v; }
static const strong_ordering less;
static const strong_ordering equal;
static const strong_ordering greater;
};
constexpr strong_ordering strong_ordering::less = -1;
constexpr strong_ordering strong_ordering::equal = 0;
constexpr strong_ordering strong_ordering::greater = 1;
}
template
struct duration {
static constexpr const long period = N;
constexpr duration (void) = default;
constexpr duration (const duration& d) = default;
constexpr bool operator== (const duration& d) const = default;
constexpr bool operator<=> (const duration& d) const = default;
long _d;
};
using nanoseconds = duration<1>;
using microseconds = duration;
[Bug c++/94162] ICE [neg] bad return type in defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162 Jakub Jelinek changed: What|Removed |Added CC||msharov at users dot sourceforge.n ||et --- Comment #7 from Jakub Jelinek --- *** Bug 99429 has been marked as a duplicate of this bug. ***
[Bug c++/99429] [10/11 Regression] ICE for bool return from <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99429 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Jakub Jelinek --- Yes. *** This bug has been marked as a duplicate of bug 94162 ***
[Bug rtl-optimization/99469] New: ICE: qsort checking failed with selective scheduling on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99469
Bug ID: 99469
Summary: ICE: qsort checking failed with selective scheduling
on aarch64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat test.c
typedef struct {
int a[3];
} s;
s ss[1][5][8];
int g();
void h(s);
int foo(char *, ...);
void f() {
int a, b, c, d = 0;
if (g())
d = 1;
for (; a; a++) {
if (d)
foo("a", "");
h(ss[a][b][c]);
if (d)
foo("a");
}
}
$ aarch64-linux-gnu-gcc -c test.c -O2 -fselective-scheduling
-fselective-scheduling2 -fsel-sched-pipelining -mtune=cortex-a53
test.c: In function ‘f’:
test.c:21:1: error: qsort comparator not anti-symmetric: -1, -1
21 | }
| ^
during RTL pass: sched2
test.c:21:1: internal compiler error: qsort checking failed
0x1c2b727 qsort_chk_error
/home/alecop01/toolchain/src/gcc/gcc/vec.c:214
0x1c2bc7d qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*, void*), void*)
/home/alecop01/toolchain/src/gcc/gcc/vec.c:258
0x1c62d8e gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
/home/alecop01/toolchain/src/gcc/gcc/sort.cc:270
0xda2728 vec<_expr*, va_heap, vl_embed>::qsort(int (*)(void const*, void
const*))
/home/alecop01/toolchain/src/gcc/gcc/vec.h:1148
0xda2728 vec<_expr*, va_heap, vl_ptr>::qsort(int (*)(void const*, void const*))
/home/alecop01/toolchain/src/gcc/gcc/vec.h:2041
0xda2728 fill_vec_av_set
/home/alecop01/toolchain/src/gcc/gcc/sel-sched.c:3717
0xda65d2 fill_ready_list
/home/alecop01/toolchain/src/gcc/gcc/sel-sched.c:4014
0xda65d2 find_best_expr
/home/alecop01/toolchain/src/gcc/gcc/sel-sched.c:4374
0xda65d2 fill_insns
/home/alecop01/toolchain/src/gcc/gcc/sel-sched.c:5535
0xda65d2 schedule_on_fences
/home/alecop01/toolchain/src/gcc/gcc/sel-sched.c:7353
0xda65d2 sel_sched_region_2
/home/alecop01/toolchain/src/gcc/gcc/sel-sched.c:7491
0xda9508 sel_sched_region_1
/home/alecop01/toolchain/src/gcc/gcc/sel-sched.c:7533
0xda9e2f sel_sched_region(int)
/home/alecop01/toolchain/src/gcc/gcc/sel-sched.c:7634
0xdab3cf run_selective_scheduling()
/home/alecop01/toolchain/src/gcc/gcc/sel-sched.c:7720
0xd85b1c rest_of_handle_sched2
/home/alecop01/toolchain/src/gcc/gcc/sched-rgn.c:3738
0xd85b1c execute
/home/alecop01/toolchain/src/gcc/gcc/sched-rgn.c:3882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
Target|powerpc64*-linux-gnu, |powerpc64*-linux-gnu,
|sparc*-sun-solaris2.11 |sparc*-*-*
CC||ebotcazou at gcc dot gnu.org
--- Comment #30 from Eric Botcazou ---
AFAICS the code implicitly assumes that __float128 exists, which is *not* the
common case among 64-bit architectures since "long double" is generally
128-bit.
Tentative fix for the SPARC at least:
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 5c9258c65c3..ae359a07973 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -407,7 +407,10 @@ build_round_expr (tree arg, tree restype)
if (kind < 0)
gfc_internal_error ("Could not find real kind with at least %d bits",
resprec);
- arg = fold_convert (gfc_float128_type_node, arg);
+ if (gfc_real16_is_float128)
+ arg = fold_convert (gfc_float128_type_node, arg);
+ else
+ arg = fold_convert (long_double_type_node, arg);
fn = gfc_builtin_decl_for_float_kind (BUILT_IN_ROUND, kind);
}
else
[Bug c++/99468] New: [modules] awkward diagnostic for named-module inside header unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99468 Bug ID: 99468 Summary: [modules] awkward diagnostic for named-module inside header unit Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- We correctly reject a module-declaration appearing in a header-unit compilation. But the diagnostic is ... poor ./cc1plus -std=c++20 -fmodule-header -quiet constrained-partial-1_a.C constrained-partial-1_a.C:3:8: error: module already declared 3 | export module M; |^~ constrained-partial-1_a.C:3:8: note: module 'M' declared here
[Bug rtl-optimization/99462] Enhance scheduling to split instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99462 --- Comment #3 from Alexander Monakov --- (for context, the above patch was for PR 98856, but it's based on incorrect latency analysis, see bug 98856 comment #38 ) Right now schedulers cannot easily split instructions for that purpose, it would require computing dependency graph more accurately. Right now dependencies and priorities are computed with respect to instructions as a whole, intelligent splitting would require tracking latencies with respect to individual inputs. sel-sched does not split, but it can perform "renaming" which basically overcomes anti-dependencies by scheduling the desired instruction before the conflicting write (by choosing a different output register), and a reg-reg move later. I think on modern x86 profitability of such splitting is quite dubious, because it would increase the amount of instructions and uops flowing in the CPU front-end and entering the renamer (which is one of narrowest points in the pipeline). Especially on AMD, where not only load-op, but also load-op-store instructions are renamed as a single uop (which is then sent to two or three execution units). I think in common cases where overall critical path is unchanged (like in given examples of pinsrq and various load-op instruction) GCC should simply continue emitting the combined form.
[Bug c++/99456] [11 regression] ABI breakage with some static initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99456 --- Comment #11 from Nathan Sidwell --- gcc11-pr99456.patch looks good, can we add a scan-not for the _ZGV guard variables too? If the optimizer's turned on, I think __static_init... gets inlined into the global constructor, might be good to make sure that's not there either.
[Bug tree-optimization/98856] [11 Regression] botan AES-128/XTS is slower by ~17% since r11-6649-g285fa338b06b804e72997c4d876ecf08a9c083af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #38 from Alexander Monakov --- Late to the party, but latency analysis of vpinsrq starting from comment #18 is incorrect: its latency is different with respect to operands. For example, on Zen 2 latency with respect to GPR operand is long (6 cycles, one more that grp->xmm move latency), while latency with respect to XMM operand is just one cycle, same as punpcklqdq. See uops.info, which also shows that vpinsrq involves 2 uops, and it's easy to guess what they are: first uop is for gpr->xmm inter-unit move (latency 5), and the second is SSE merge: https://uops.info/html-instr/VPINSRQ_XMM_XMM_R64_I8.html https://uops.info/html-instr/VMOVD_XMM_R32.html So in the CPU backend there's not much difference between movq pinsrq and movq movq punpcklqdq both have same uops and overall latency (1 + movq latency). (though on Intel starting from Haswell pinsrq oddly has latency 2 w.r.t xmm operand, but on Ice Lake it is again 1 cycle).
[Bug ipa/99309] [10/11 Regression] Segmentation fault with __builtin_constant_p usage at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309 Marek Polacek changed: What|Removed |Added Component|c++ |ipa CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Moving into ipa then.
[Bug rtl-optimization/99421] ICE:in code_motion_process_successors, at sel-sched.c:6389 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421 --- Comment #4 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #3) > Confirmed, reduced test-case: > just curious, how did you reduce the testing case with -fprofile-use? (I tried Creduce, but failed) another question, how to repeat the failure with this reduced testing case?
[Bug c/99467] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1006 since r11-7526-g9105757a59b89019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99467 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-03-08 Ever confirmed|0 |1 Summary|ice in |[11 Regression] ICE in |lra_set_insn_recog_data, at |lra_set_insn_recog_data, at |lra.c:1006 |lra.c:1006 since ||r11-7526-g9105757a59b89019 CC||marxin at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r11-7526-g9105757a59b89019, likely dup of PR99461.
