Hi Ramana,
Thanks for the reply. I agree on your point. And take a look a the
new patch.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index f8436b30b37..97bc82272af 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -7328,7 +7328,10 @@ canonicalize_type_argument (tree arg,
tsubst_flags_t complain)
if (!arg || arg == error_mark_node || arg == TYPE_CANONICAL (arg))
return arg;
bool removed_attributes = false;
- tree canon = strip_typedefs (arg, &removed_attributes);
+ bool *premove_attributes = NULL;
+ if (complain & tf_warning)
+premove_attributes = &removed_attributes;
+ tree canon = strip_typedefs (arg, premove_attributes);
if (removed_attributes
&& (complain & tf_warning))
warning (OPT_Wignored_attributes,
2017-06-17 4:57 GMT+08:00 ramana at gcc dot gnu.org :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80986
>
> Ramana Radhakrishnan changed:
>
>What|Removed |Added
>
> CC||ramana at gcc dot gnu.org
>
> --- Comment #4 from Ramana Radhakrishnan ---
> (In reply to linzj from comment #2)
>> I have found the cause of this bug.
>> In 5.3, the function strip_typedefs only use
>> result = cp_build_type_attribute_variant (result, TYPE_ATTRIBUTES (t));
>> but in 6.3 remove_attributes prediction get invovled:
>> if (TYPE_ATTRIBUTES (t))
>> {
>> if (remove_attributes)
>> result = apply_identity_attributes (result, TYPE_ATTRIBUTES (t),
>>remove_attributes);
>> else
>> result = cp_build_type_attribute_variant (result, TYPE_ATTRIBUTES (t));
>> }
>> and unfortunately the pcs attribute is declared as
>> { "pcs", 1, 1, false, true, true, arm_handle_pcs_attribute,
>> false },
>> which affects_type_identity field is set to false, cause
>> apply_identity_attributes
>> drop this attribute.
>
>
> Does affects_type_identity cause other user visible changes ? For e.g. based
> on
> a cursory look it appears to affect mangling in C++. The comment in
> tree-core.h
> simply says this affects the type's identity presumably implying that this
> additionally adds value to the type's identity.
>
> Almost all attributes I see in the front-ends or other backends has this set
> to
> false and I'm certainly not happy switching this to true without understanding
> the ramifications.
>
> In the use case that is considered here, I can see that it makes a difference
> however without understanding what else can change I'm not happy with the
> patch
> going in.
>
> --
> You are receiving this mail because:
> You reported the bug.
