Marc Glisse <marc.gli...@inria.fr> writes:
> I am trying to understand comp_type_attributes, which checks whether
> attributes are compatible. From what I understand, on many platforms,
> that function can only ever return 1. Indeed, it does some checks to
> know whether it can answer 1, and if not it forwards to the target,
> which by default just returns 1. It looks like it could directly
> forward to the target. Which would leave the pretty printer as the
> only user of the affects_type_identity property of an attribute...
>
> Now the reason I looked at this is because I was expecting a different
> behavior. I added a new (function type) attribute in a front-end and
> specified that it affects type identity. When comp_type_attributes
> sees this attribute in one type but not the other, it can't answer
> yes, so it forwards to the target. The target just answers yes by
> default (some check for their own attributes, but they ignore the
> rest).
>
> Is that what's supposed to happen? I can use another mechanism than
> attributes, but this looks suspicious.
When COMP_TYPE_ATTRIBUTES was introduced, it was a macro which could be
set in tm.h to check type attributes.
Fri May 6 14:05:00 1994 Stephen R. van den Berg
(b...@pool.informatik.rwth-aachen.de)
* tree.h (TYPE_ATTRIBUTES): New macro.
(struct tree_type): attributes, new field.
(precision): Move this field up for better alignment.
(attribute_list_{equal,contained}): Prototype for new functions.
(build_type_attribute_variant): Prototype for new function.
* c-parse.in: Rewrite attribute parsing; update the expected
conflicts and state numbers.
* tree.c (TYPE_HASH): Move definition to top of file.
(make_node): Add support for SET_DEFAULT_TYPE_ATTRIBUTES.
(build_type_attribute_variant): New function.
(type_hash_lookup): Check if the attributes match.
(attribute_list_{equal,contained}): New functions.
* c-typeck.c (common_type): Add attribute merging.
(comp_types): Use COMP_TYPE_ATTRIBUTES macro.
* print-tree.c (print_node): Print attributes.
* c-common.c (decl_attributes): Move the attribute
recognition and rejection here from c-parse.in.
(decl_attributes): Use VALID_MACHINE_ATTRIBUTE macro.
This was before there was a affects_type_identity field. Given that,
and given the assumption that most attributes were backend specific, a
default of 1 made sense.
The default has carried forward since then. The affects_type_identity
field was added in March 2011 as part of the fix for PR 12171, in order
to produce a better error message. Kai followed with a change to test
affects_type_identity in the new comp_type_attributes function:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01318.html
At that point I think it would have made sense to change the default of
TARGET_COMP_TYPE_ATTRIBUTES. Or, it should be renamed, since it is no
longer simply serving as a comparison, but is now serving to handle the
special case for which it was introduced, x86 calling convention
attributes.
So, no real answers here, but I agree that this is an area that could
use some cleanup.
Ian
