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


On Tue, 17 Jan 2012, Ian Lance Taylor wrote:

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.

Thanks a lot for this detailed analysis, which explains much. I definitely should have looked at the history (though it wouldn't have been as clear as your explanation).


I am not sure what the right approach is. The current middle-end code as a speed optimization is strange. Other than that, there really is a problem only if we want to allow attributes that affect the type in other places than targets. If we don't, we can leave things as they are (possibly with a rename/comment). If we do, we would somehow need a way to specify which attributes are handled by the targets, either by adding a new property to attributes, or by making TARGET_COMP_TYPE_ATTRIBUTES return the attributes it doesn't know (or forward them to some generic comparison function).

The example I am considering is the extern "C" property of some function types in C++. It is a calling convention specifier, not specific to any target, although the current ABI says it has no effect. In my prototype patch for bug 2316, I reuse the minval field to store this property, and I then need to adapt quite a few functions to preserve it. Using an attribute seems to make sense and would reuse more existing mechanisms (though it may have drawbacks too).

--
Marc Glisse


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