On Wed, 2014-09-24 at 17:09 -0400, Jason Merrill wrote:
> On 09/24/2014 02:42 PM, Mark Wielaard wrote:
> > As my example shows even with older GCCs depending on whether a const
> > type or volatile type was encountered first a const volatile type comes
> > out either as a DIE chain const_type DIE -
On 09/24/2014 02:42 PM, Mark Wielaard wrote:
As my example shows even with older GCCs depending on whether a const
type or volatile type was encountered first a const volatile type comes
out either as a DIE chain const_type DIE -> volatile_type DIE -> type
DIE, or the other way around, in differe
On Wed, 2014-09-24 at 14:11 -0400, Jason Merrill wrote:
> > Anyway. I don't think this should hold up this specific bug fix. The
> > issue with type units vs qualified type DIEs has been there in all
> > previous versions of GCC (and only when using non-default flags). It
> > really comes from DWAR
On 09/24/2014 01:05 PM, Mark Wielaard wrote:
On Wed, 2014-09-24 at 10:47 -0400, Jason Merrill wrote:
On 09/23/2014 06:53 PM, Mark Wielaard wrote:
And for the default case (gcc doesn't
create type sections by default) the optimization is useful.
I'm skeptical. These DIEs are very small, and I
On Wed, 2014-09-24 at 10:47 -0400, Jason Merrill wrote:
> On 09/23/2014 06:53 PM, Mark Wielaard wrote:
> > And for the default case (gcc doesn't
> > create type sections by default) the optimization is useful.
>
> I'm skeptical. These DIEs are very small, and I wouldn't expect a hole
> in the qu
Hi Andreas,
On Wed, 2014-09-24 at 14:40 +0200, Andreas Arnez wrote:
> I changed the patch a bit further, to reduce unnecessary
> iterations and recursions, and tested it again.
Thanks for adding the tests and the testing. I think in general it is a
nicer and cleaner fix than I did. I do have a qu
On 09/23/2014 06:53 PM, Mark Wielaard wrote:
And for the default case (gcc doesn't
create type sections by default) the optimization is useful.
I'm skeptical. These DIEs are very small, and I wouldn't expect a hole
in the qualifier space like this to come up that often.
Jason
On Wed, Sep 24 2014, Jakub Jelinek wrote:
> On Wed, Sep 24, 2014 at 02:40:14PM +0200, Andreas Arnez wrote:
>> A few style aspects I'm not sure about:
>>
>> * Is it OK to use __builtin_popcount in tree.c?
>
> Definitely not, you can use popcount_hwi instead, which for GCC
> host compiler (>= 3.4)
On Wed, Sep 24, 2014 at 02:40:14PM +0200, Andreas Arnez wrote:
> A few style aspects I'm not sure about:
>
> * Is it OK to use __builtin_popcount in tree.c?
Definitely not, you can use popcount_hwi instead, which for GCC
host compiler (>= 3.4) will use __builtin_popcount*, otherwise
fallback to a
On Tue, Sep 23 2014, Mark Wielaard wrote:
> This certainly looks nicer than how I wrote it. It took me a while
> (again) to realize why this works. We rely on the fact that earlier in
> the function a match would have been found if there was already a fully
> qualified type available. So here we k
On Tue, Sep 23, 2014 at 05:12:12PM -0400, Jason Merrill wrote:
> On 09/23/2014 08:17 AM, Andreas Arnez wrote:
> >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
>
On 09/23/2014 08:17 AM, Andreas Arnez wrote:
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 instea
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 t
ng it by hand in dwarf2out.c is
certainly nice.
> -- >8 --
> Subject: [PATCH] PR63300 'const volatile' sometimes stripped in debug info.
>
> When adding DW_TAG_restrict_type the handling of multiple modifiers
> was adjusted incorrectly. This patch fixes it with the h
ing
>> sub-qualified type.
>>
> [...]
>
> Also note that the logic wouldn't scale too well for yet more
> qualifiers...
Considering this, I've tried a different approach below. What do you
think?
-- >8 --
Subject: [PATCH] PR63300 'const volatile'
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 & TY
On Sat, Sep 20 2014, Mark Wielaard wrote:
> When adding DW_TAG_restrict_type I made a mistake when updating the
> code that handled types with multiple modifiers. This patch fixes it
> by putting the logic for finding the "sub-qualified" type in a separate
> function and fall back to adding the mo
When adding DW_TAG_restrict_type I made a mistake when updating the
code that handled types with multiple modifiers. This patch fixes it
by putting the logic for finding the "sub-qualified" type in a separate
function and fall back to adding the modifiers separately if there is
no such existing typ
18 matches
Mail list logo
