This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: comp_type_attributes


Marc Glisse <marc.glisse@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  (berg@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]