summaryrefslogtreecommitdiff
path: root/gcc/attribs.h
diff options
context:
space:
mode:
authorRichard Sandiford <richard.sandiford@arm.com>2021-04-15 11:37:39 +0100
committerRichard Sandiford <richard.sandiford@arm.com>2021-04-15 11:37:39 +0100
commit1696fc1ea01d5c9dce96b5d3122921aab9308f59 (patch)
tree03a93ad7246ef1ee6eba98377f272be3c4314124 /gcc/attribs.h
parenta3317f7b3c02907a122f89879e5b6e90c386e64d (diff)
downloadgcc-1696fc1ea01d5c9dce96b5d3122921aab9308f59.tar.gz
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.h')
-rw-r--r--gcc/attribs.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/gcc/attribs.h b/gcc/attribs.h
index eadb1d0fac9..df78eb152f9 100644
--- a/gcc/attribs.h
+++ b/gcc/attribs.h
@@ -66,6 +66,7 @@ extern bool attribute_value_equal (const_tree, const_tree);
extern int comp_type_attributes (const_tree, const_tree);
extern tree affects_type_identity_attributes (tree, bool = true);
+extern tree restrict_type_identity_attributes_to (tree, tree);
/* Default versions of target-overridable functions. */
extern tree merge_decl_attributes (tree, tree);