public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/112830] internal compiler error: in convert_memory_address_addr_space_1, at explow.cc:302 Date: Tue, 05 Dec 2023 10:54:55 +0000 [thread overview] Message-ID: <bug-112830-4-4fW83aA7Bi@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-112830-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112830 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ebotcazou at gcc dot gnu.org --- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> --- I'm struggling in creating test coverage for the *VLA = {} gimplification to memset. If I convince the C frontend to accept void bar (int n, __seg_fs void *p) { typedef struct { char t[n]; } T; *(__seg_fs T *)p = (T) {}; } with diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc index df9a07928b5..a94270b6065 100644 --- a/gcc/c/c-parser.cc +++ b/gcc/c/c-parser.cc @@ -12223,12 +12223,7 @@ c_parser_postfix_expression_after_paren_type (c_parser *parser, || (scspecs && scspecs->storage_class == csc_static) || constexpr_p), constexpr_p, &richloc); type = groktypename (type_name, &type_expr, &type_expr_const); - if (type != error_mark_node && C_TYPE_VARIABLE_SIZE (type)) - { - error_at (type_loc, "compound literal has variable size"); - type = error_mark_node; - } - else if (TREE_CODE (type) == FUNCTION_TYPE) + if (TREE_CODE (type) == FUNCTION_TYPE) { error_at (type_loc, "compound literal has function type"); type = error_mark_node; @@ -12257,6 +12252,13 @@ c_parser_postfix_expression_after_paren_type (c_parser *parser, finish_init (); maybe_warn_string_init (type_loc, type, init); + if (type != error_mark_node + && C_TYPE_VARIABLE_SIZE (type) + && CONSTRUCTOR_NELTS (init.value) != 0) + { + error_at (type_loc, "compound literal has variable size"); + type = error_mark_node; + } if (type != error_mark_node && !ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (type)) && current_function_decl) then I see the gimplifier fails to wrap the CONSTRUCTOR inside a WITH_SIZE_EXPR which could be fixed with diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc index a1d5ee28cbe..ae339c4a82a 100644 --- a/gcc/gimplify.cc +++ b/gcc/gimplify.cc @@ -5787,6 +5787,7 @@ gimplify_init_constructor (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p, tree rhs = TREE_OPERAND (*expr_p, 1); if (want_value && object == lhs) lhs = unshare_expr (lhs); + maybe_with_size_expr (&rhs); gassign *init = gimple_build_assign (lhs, rhs); gimplify_seq_add_stmt (pre_p, init); } diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc index a075fa38fba..e81b3f6ba72 100644 --- a/gcc/tree-cfg.cc +++ b/gcc/tree-cfg.cc @@ -3363,7 +3363,10 @@ verify_types_in_gimple_reference (tree expr, bool require_lvalue) } if (!require_lvalue - && (is_gimple_reg (expr) || is_gimple_min_invariant (expr))) + && (is_gimple_reg (expr) + || is_gimple_min_invariant (expr) + || (TREE_CODE (expr) == CONSTRUCTOR + && CONSTRUCTOR_NELTS (expr) == 0))) return false; if (TREE_CODE (expr) != SSA_NAME && is_gimple_id (expr)) but then of course RTL expansion isn't prepared for this - we run into store_expr expanding the CTOR but it would require special-casing such RHS to eventually either call store_constructor or clear_storage_hints directly. Does Ada have support for address-spaces and is there a way to construct a testcase that requires clearing of a VLA object in another address-space?
next prev parent reply other threads:[~2023-12-05 10:54 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-12-03 12:22 [Bug middle-end/112830] New: " gjl at gcc dot gnu.org 2023-12-03 12:37 ` [Bug middle-end/112830] " gjl at gcc dot gnu.org 2023-12-03 22:17 ` pinskia at gcc dot gnu.org 2023-12-04 7:06 ` rguenth at gcc dot gnu.org 2023-12-04 8:40 ` rguenth at gcc dot gnu.org 2023-12-04 9:07 ` rguenth at gcc dot gnu.org 2023-12-04 9:08 ` rguenth at gcc dot gnu.org 2023-12-04 9:27 ` rguenth at gcc dot gnu.org 2023-12-04 11:56 ` rguenth at gcc dot gnu.org 2023-12-04 19:19 ` gjl at gcc dot gnu.org 2023-12-05 9:48 ` rguenth at gcc dot gnu.org 2023-12-05 10:54 ` rguenth at gcc dot gnu.org [this message] 2023-12-05 11:31 ` ebotcazou at gcc dot gnu.org 2023-12-05 13:55 ` cvs-commit at gcc dot gnu.org 2023-12-05 13:56 ` rguenth at gcc dot gnu.org 2023-12-05 20:46 ` gjl at gcc dot gnu.org 2023-12-06 7:33 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-112830-4-4fW83aA7Bi@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).