From: Martin Sebor <msebor@gmail.com>
To: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: [committed] build a zero element array type that renders as T[0] in diagnostics
Date: Wed, 23 Sep 2020 15:39:08 -0600 [thread overview]
Message-ID: <bdecb04d-7c13-c9e5-213e-92d10097770d@gmail.com> (raw)
One of the recently added -Warray-bounds tests fails in ILP32
because the warning code calls build_array_type_nelts(type, zero)
and naively expects it to create an array type that renders as
type[0] in warnings. While that works in LP64, it apparently
isn't enough to produce such a type in other configurations.
I have committed the patch below following the C front-end
approach of creating a zero-element array that does render as
expected regardless of data models.
Martin
commit 67aeddb785ddcc8688ee5736ecab3c81de34a214 (HEAD -> master,
origin/master, origin/HEAD)
Author: Martin Sebor <msebor@redhat.com>
Date: Wed Sep 23 15:19:13 2020 -0600
Build a zero element array type that reliably renders as T[0] in
diagnostcs.
gcc/ChangeLog:
* gimple-array-bounds.cc (build_zero_elt_array_type): New
function.
(array_bounds_checker::check_mem_ref): Call it.
diff --git a/gcc/gimple-array-bounds.cc b/gcc/gimple-array-bounds.cc
index b93ef7a7b74..ab638ba249f 100644
--- a/gcc/gimple-array-bounds.cc
+++ b/gcc/gimple-array-bounds.cc
@@ -372,6 +372,20 @@ array_bounds_checker::check_array_ref (location_t
location, tree ref,
return warned;
}
+/* Hack around the internal representation constraints and build a zero
+ element array type that actually renders as T[0] in diagnostcs. */
+
+static tree
+build_zero_elt_array_type (tree eltype)
+{
+ tree idxtype = build_range_type (sizetype, size_zero_node, NULL_TREE);
+ tree arrtype = build_array_type (eltype, idxtype);
+ arrtype = build_distinct_type_copy (TYPE_MAIN_VARIANT (arrtype));
+ TYPE_SIZE (arrtype) = bitsize_zero_node;
+ TYPE_SIZE_UNIT (arrtype) = size_zero_node;
+ return arrtype;
+}
+
/* Checks one MEM_REF in REF, located at LOCATION, for out-of-bounds
references to string constants. If VRP can determine that the array
subscript is a constant, check if it is outside valid range.
@@ -547,7 +561,10 @@ array_bounds_checker::check_mem_ref (location_t
location, tree ref,
return false;
offset_int nelts = arrbounds[1] / eltsize;
- reftype = build_array_type_nelts (reftype, nelts.to_uhwi ());
+ if (nelts == 0)
+ reftype = build_zero_elt_array_type (reftype);
+ else
+ reftype = build_array_type_nelts (reftype, nelts.to_uhwi ());
}
else if (TREE_CODE (arg) == ADDR_EXPR)
{
reply other threads:[~2020-09-23 21:39 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=bdecb04d-7c13-c9e5-213e-92d10097770d@gmail.com \
--to=msebor@gmail.com \
--cc=gcc-patches@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: link
Be 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).