diff options
author | Richard Sandiford <richard.sandiford@arm.com> | 2021-04-15 11:37:39 +0100 |
---|---|---|
committer | Richard Sandiford <richard.sandiford@arm.com> | 2021-04-15 11:37:39 +0100 |
commit | 1696fc1ea01d5c9dce96b5d3122921aab9308f59 (patch) | |
tree | 03a93ad7246ef1ee6eba98377f272be3c4314124 /gcc/attribs.c | |
parent | a3317f7b3c02907a122f89879e5b6e90c386e64d (diff) | |
download | gcc-1696fc1ea01d5c9dce96b5d3122921aab9308f59.zip gcc-1696fc1ea01d5c9dce96b5d3122921aab9308f59.tar.gz gcc-1696fc1ea01d5c9dce96b5d3122921aab9308f59.tar.bz2 |
c++: Tweak merging of vector attributes that affect type identity [PR98852]
<arm_neon.h> types are distinct from GNU vector types in at least
their mangling. However, there used to be nothing explicit in the
VECTOR_TYPE itself to indicate the difference: we simply treated them
as distinct TYPE_MAIN_VARIANTs. This caused problems like the ones
reported in PR95726.
The fix for that PR was to add type attributes to the <arm_neon.h>
types, in order to maintain the distinction between them and GNU
vectors. However, this in turn caused PR98852, where cp_common_type
would merge the type attributes from the two source types and attach
the result to the common type. For example:
unsigned vector with no attribute + signed vector with attribute X
would get converted to:
unsigned vector with attribute X
That isn't what we want in this case, since X describes the mangling
of the original type. But even if we dropped the mangling from X and
worked it out from context, we would still have a situation in which
the common type was provably distinct from both of the source types:
it would take its <arm_neon.h>-ness from one side and its signedness
from the other. I guess there are other cases where the common type
doesn't match either side, but I'm not sure it's the obvious behaviour
here. It's also different from GCC 10.1 and earlier, where the unsigned
vector “won” in its original form.
This patch instead merges only the attributes that don't affect type
identity. For now I've restricted it to vector types, since we're so
close to GCC 11, but it might make sense to use this elsewhere.
I've tried to audit the C and target-specific attributes to look for
other types that might be affected by this, but I couldn't see any.
The closest was s390_vector_bool, but the handler for that attribute
changes the type node and drops the attribute itself
(*no_add_attrs = true).
gcc/
PR c++/98852
* attribs.h (restrict_type_identity_attributes_to): Declare.
* attribs.c (restrict_type_identity_attributes_to): New function.
gcc/cp/
PR c++/98852
* typeck.c (merge_type_attributes_from): New function.
(cp_common_type): Use it for vector types.
Diffstat (limited to 'gcc/attribs.c')
-rw-r--r-- | gcc/attribs.c | 23 |
1 files changed, 23 insertions, 0 deletions
diff --git a/gcc/attribs.c b/gcc/attribs.c index 2fb2954..3ffa1b6 100644 --- a/gcc/attribs.c +++ b/gcc/attribs.c @@ -1420,6 +1420,29 @@ affects_type_identity_attributes (tree attrs, bool value) return remove_attributes_matching (attrs, predicate); } +/* Remove attributes that affect type identity from ATTRS unless the + same attributes occur in OK_ATTRS. */ + +tree +restrict_type_identity_attributes_to (tree attrs, tree ok_attrs) +{ + auto predicate = [ok_attrs](const_tree attr, + const attribute_spec *as) -> bool + { + if (!as || !as->affects_type_identity) + return true; + + for (tree ok_attr = lookup_attribute (as->name, ok_attrs); + ok_attr; + ok_attr = lookup_attribute (as->name, TREE_CHAIN (ok_attr))) + if (simple_cst_equal (TREE_VALUE (ok_attr), TREE_VALUE (attr)) == 1) + return true; + + return false; + }; + return remove_attributes_matching (attrs, predicate); +} + /* Return a type like TTYPE except that its TYPE_ATTRIBUTE is ATTRIBUTE. |