This is the mail archive of the 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: Query about the TREE_TYPE field

On 11/18/2014 09:40 AM, Jason Merrill wrote:
On 11/18/2014 09:26 AM, Andrew MacLeod wrote:
I was poking around attribs.c while trial running my tree-type-safety
stuff, and it triggered something in decl_attributes() that seems fishy
to me.  It looks like it was part of the fix for

decl_attributes() can be passed a tree node which is either decl or a
type, but we get to this little snippet:

       if (spec->type_required && DECL_P (*anode))
           anode = &TREE_TYPE (*anode);
/* Allow ATTR_FLAG_TYPE_IN_PLACE for the type's naming decl. */
           if (!(TREE_CODE (*anode) == TYPE_DECL
                 && *anode == TYPE_NAME (TYPE_MAIN_VARIANT
                                         (TREE_TYPE (*anode)))))
             flags &= ~(int) ATTR_FLAG_TYPE_IN_PLACE;

anode is changed to point to the TREE_TYPE of the original decl, and
*then* checks if it is a TYPE_DECL...   That doesnt seem right to me..
we can't have a TYPE_DECL as a TREE_TYPE can we?


is that code suppose to be checking is the original DECL is a TYPE_DECL
rather than the TREE_TYPE?

I think so.

Maybe the assignment to anode should be after the if instead of in front
of it?


Strange that the 35315 patch fixed the testcase with that change being a placebo...


Indeed. The condition is negated, so effectively it becomes an always true condition and the ATTR_FLAG_TYPE_IN_PLACE is always turned off when a DECL is passed and a type is required..

maybe that works most/all of the time? huh, that also means the code is the same as it was before the patch :-P

maybe one of the follow up patches in bugzilla supercede it?


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