Started between 20221009 and 20221016, with file gcc.dg/pr69627.c : $ cat z1.cc void foo () { float t[2] = { 1, 2 }; int const *s = 0; t[1] / s; } void bar () { float t[2] = { 1, 2 }; int const *s[2] = { 0, 0 }; t[1] / s[0]; } $ g++-13-20221023 -c z1.cc -m32 -std=c++0x z1.cc: In function 'void foo()': z1.cc:6:10: internal compiler error: in cp_build_binary_op, at cp/typeck.cc:6181 6 | t[1] / s; | ^ 0xb45e49 cp_build_binary_op(op_location_t const&, tree_code, tree_node*, tree_node*, int) ../../gcc/cp/typeck.cc:6181 0x81f755 build_new_op(op_location_t const&, tree_code, int, tree_node*, tree_node*, tree_node*, tree_node*, tree_node**, int) ../../gcc/cp/call.cc:7094 0xb2e48d build_x_binary_op(op_location_t const&, tree_code, tree_node*, tree_code, tree_node*, tree_code, tree_node*, tree_node**, int) ../../gcc/cp/typeck.cc:4722 0x9ec893 cp_parser_binary_expression ../../gcc/cp/parser.cc:10266 0x9ed404 cp_parser_assignment_expression ../../gcc/cp/parser.cc:10427 0x9efa02 cp_parser_expression ../../gcc/cp/parser.cc:10597 0x9f3b87 cp_parser_expression_statement ../../gcc/cp/parser.cc:12702 0xa03a44 cp_parser_statement ../../gcc/cp/parser.cc:12491 0xa04c34 cp_parser_statement_seq_opt ../../gcc/cp/parser.cc:12853 0xa04d17 cp_parser_compound_statement ../../gcc/cp/parser.cc:12805 0xa2d220 cp_parser_function_body ../../gcc/cp/parser.cc:25179 0xa2d220 cp_parser_ctor_initializer_opt_and_function_body ../../gcc/cp/parser.cc:25230 0xa2d89a cp_parser_function_definition_after_declarator ../../gcc/cp/parser.cc:31387 0xa2eddc cp_parser_function_definition_from_specifiers_and_declarator ../../gcc/cp/parser.cc:31304 0xa2eddc cp_parser_init_declarator ../../gcc/cp/parser.cc:22633 0xa01892 cp_parser_simple_declaration ../../gcc/cp/parser.cc:15284 0xa3679b cp_parser_declaration ../../gcc/cp/parser.cc:14970 0xa372b8 cp_parser_translation_unit ../../gcc/cp/parser.cc:5076 0xa372b8 c_parse_file() ../../gcc/cp/parser.cc:48856 0xbcfb01 c_common_parse_file() ../../gcc/c-family/c-opts.cc:1247
-m32 -fexcess-precision=standard So most likely caused by r13-3290-g98e341130f8798 . Confirmed.
Created attachment 53771 [details] gcc13-pr107383.patch Untested fix.
*** Bug 107382 has been marked as a duplicate of this bug. ***
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:bfb7994a9fb0b10767d12b8d670c081014ad8b01 commit r13-3522-gbfb7994a9fb0b10767d12b8d670c081014ad8b01 Author: Jakub Jelinek <jakub@redhat.com> Date: Thu Oct 27 10:24:45 2022 +0200 c++: Fix excess precision related ICE on invalid binop [PR107382, PR107383] The following tests ICE in the gcc_assert (common); in cp_build_binary_op. I've missed that while for * common is set always, while for +, - and / it is in some cases not. If it is not, then if (!result_type && arithmetic_types_p && (shorten || common || short_compare)) condition is false, then the following if (may_need_excess_precision && (orig_type0 != type0 || orig_type1 != type1) && build_type == NULL_TREE) would fail the assertion there and if there wouldn't be excess precision, if (code == SPACESHIP_EXPR) would be false (for SPACESHIP_EXPR we always have build_type set like for other comparisons) and then trigger if (!result_type) { if (complain & tf_error) { binary_op_rich_location richloc (location, orig_op0, orig_op1, true); error_at (&richloc, "invalid operands of types %qT and %qT to binary %qO", TREE_TYPE (orig_op0), TREE_TYPE (orig_op1), code); } return error_mark_node; } So, if result_type is NULL, we don't really need to compute semantic_result_type because nothing will use it anyway and can get fall through into the error/return error_mark_node; case. 2022-10-27 Jakub Jelinek <jakub@redhat.com> PR c++/107382 PR c++/107383 * typeck.cc (cp_build_binary_op): Don't compute semantic_result_type if result_type is NULL. * g++.dg/diagnostic/bad-binary-ops2.C: New test.
Fixed.