Re: [PATCH] PR63300 'const volatile' sometimes stripped in debug info.

[Andreas Arnez <arnez at linux dot vnet dot ibm dot com>]

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.