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 tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure Date: Thu, 28 Jul 2022 08:07:07 +0000 [thread overview] Message-ID: <bug-106457-4-xNnZs6jsBB@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-106457-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2022-07-28 Ever confirmed|0 |1 --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- e[0][0] should be handled here: tree ref_to_array = ref; while (handled_component_p (ref)) { ... /* If we have a multi-dimensional array we do not consider a non-innermost dimension as flex array if the whole multi-dimensional array is at struct end. Same for an array of aggregates with a trailing array member. */ else if (TREE_CODE (ref) == ARRAY_REF) return false; maybe you are refering to e[0]? In that case the issue is that we fail to consider the case when there is no known padding. One would be if DECL_P (TREE_OPERAND (ref_to_array, 0)), if the whole object is the array itself. Thus diff --git a/gcc/tree.cc b/gcc/tree.cc index 84000dd8b69..aaac7610f9c 100644 --- a/gcc/tree.cc +++ b/gcc/tree.cc @@ -12778,6 +12778,10 @@ array_at_struct_end_p (tree ref) && DECL_SIZE_UNIT (ref) && TREE_CODE (DECL_SIZE_UNIT (ref)) == INTEGER_CST) { + /* If the object itself is the array it is not at struct end. */ + if (DECL_P (TREE_OPERAND (ref_to_array, 0))) + return false; + /* Check whether the array domain covers all of the available padding. */ poly_int64 offset; we might be able to play tricks with alignment as well, if the alignment of the object is the same or less as that of the array element alignment (not sure if we can trust the alignment of the array element type here), there's no room for padding. But maybe that breaks in strange cases.
next prev parent reply other threads:[~2022-07-28 8:07 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-07-27 18:43 [Bug tree-optimization/106457] New: " qinzhao at gcc dot gnu.org 2022-07-28 8:07 ` rguenth at gcc dot gnu.org [this message] 2022-07-28 12:35 ` [Bug tree-optimization/106457] " cvs-commit at gcc dot gnu.org 2022-07-28 12:36 ` rguenth at gcc dot gnu.org 2022-08-01 21:11 ` qinzhao at gcc dot gnu.org 2022-08-01 21:13 ` qinzhao at gcc dot gnu.org 2022-08-04 17:59 ` qinzhao at gcc dot gnu.org 2022-08-08 15:13 ` qinzhao at gcc dot gnu.org 2022-08-09 14:11 ` qinzhao at gcc dot gnu.org 2022-08-09 14:16 ` qinzhao 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-106457-4-xNnZs6jsBB@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).