On Tue, Sep 23 2014, Mark Wielaard wrote: > On Mon, Sep 22, 2014 at 10:59:38AM +0200, Andreas Arnez wrote: >> > + sub_qual = TYPE_QUAL_RESTRICT; >> > + if ((sub_quals & ~sub_qual) != TYPE_UNQUALIFIED >> > + && get_qualified_type (type, sub_quals & ~sub_qual) != NULL_TREE) >> > + return true; >> > + >> > + sub_qual = TYPE_QUAL_CONST & TYPE_QUAL_VOLATILE; >> >> You probably mean '|' instead of '&' here. > > Eep. Yes (3x). > > But then I tried to write a testcase to show the cases that fail > because of this typo. And failed, everything works fine. That is > because these checks are bogus. sub_quals contains at most 2 qualifiers. > const, volatile and restrict, minus the qual we are interested in. > And subtracting two always results in the empty set. So I removed > those 3 cases.
Right, the checks were bogus. But from looking at the code before adding restrict, I guess it was intended to *minimze* the number of generated DIEs. If we keep that goal, maybe the function should actually return the "rank" of the found sub-qualified type (i.e., the number of matching sub-qualifiers) and the caller should follow the path with the highest rank. Then the checks would be needed again, and they would even have to be doubled for 'atomic'. Without such handling there are cases where more DIEs than necessary are created, e.g. if we have the following types: some_base_t *const some_base_t *volatile restrict some_base_t *const volatile restrict Then the latter is based on the first instead of the second, although this requires one more DIE.
