Re: [PATCH] cp: fix location comparison in member_name_cmp
On Wed, 20 Sep 2017, Nathan Sidwell wrote:
> > You can use the gcc_assert mentioned in the previous email on GCC
> > bootstrap/regtest to find examples. For me, the following example breaks
> > (no
> > command line flags needed, just bare 'cc1plus t.i'):
> >
> > struct
> > {
> >int a, b, c, d;
> >union
> > {
> >int e;
> > };
> > } s;
> >
> > 1436 gcc_assert (DECL_SOURCE_LOCATION (a) != DECL_SOURCE_LOCATION (b));
>
> Where are these two decls for the same type being generated? The bug seems to
> be there.
Don't ask me, I'm not a C++ frontend maintainer ;)
The patch in the opening message of this thread doesn't affect functionality
and is required to unblock qsort checking work. Can I install it on trunk?
If anyone wants to investigate how such decls appear in the first place, that
can be done independently of this patch.
Thanks.
Alexander
Re: [PATCH] cp: fix location comparison in member_name_cmp
On 09/19/2017 06:07 AM, Alexander Monakov wrote:
On Tue, 19 Sep 2017, Nathan Sidwell wrote:
After recent changes, the member_name_cmp qsort comparator can indicate
A < B < A (i.e. lacks anti-commutativity) for distinct TYPE_DECL nodes
that have the same source location. If their order doesn't matter, the
comparator should return 0.
Where do we get such type decls?
The first instance that tripped qsort checking for me was in PCH generation.
I think by adding
What source example generates such type decls? That you've encountered this
suggests one of the invariants I was presuming is not true.
You can use the gcc_assert mentioned in the previous email on GCC
bootstrap/regtest to find examples. For me, the following example breaks (no
command line flags needed, just bare 'cc1plus t.i'):
struct
{
int a, b, c, d;
union
{
int e;
};
} s;
1436 gcc_assert (DECL_SOURCE_LOCATION (a) != DECL_SOURCE_LOCATION (b));
Where are these two decls for the same type being generated? The bug
seems to be there.
nathan
--
Nathan Sidwell
Re: [PATCH] cp: fix location comparison in member_name_cmp
On Tue, 19 Sep 2017, Nathan Sidwell wrote:
> > > > After recent changes, the member_name_cmp qsort comparator can indicate
> > > > A < B < A (i.e. lacks anti-commutativity) for distinct TYPE_DECL nodes
> > > > that have the same source location. If their order doesn't matter, the
> > > > comparator should return 0.
> > >
> > > Where do we get such type decls?
> >
> > The first instance that tripped qsort checking for me was in PCH generation.
> > I think by adding
>
> What source example generates such type decls? That you've encountered this
> suggests one of the invariants I was presuming is not true.
You can use the gcc_assert mentioned in the previous email on GCC
bootstrap/regtest to find examples. For me, the following example breaks (no
command line flags needed, just bare 'cc1plus t.i'):
struct
{
int a, b, c, d;
union
{
int e;
};
} s;
1436 gcc_assert (DECL_SOURCE_LOCATION (a) != DECL_SOURCE_LOCATION (b));
(gdb) call debug_tree(a)
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x719f7348
fields
nonlocal decl_3 SI t.i:6:11 size
unit-size
align:32 warn_if_not_align:0 offset_align 128
offset
bit-offset context
chain > context
full-name "union::"
chain >
nonlocal decl_4 VOID t.i:5:5
align:1 warn_if_not_align:0 context
result unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x719f7348 fields context
full-name "union::"
chain >
>
$1 = 10
(gdb) call debug_tree(b)
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x719f7348
fields
nonlocal decl_3 SI t.i:6:11 size
unit-size
align:32 warn_if_not_align:0 offset_align 128
offset
bit-offset context
chain > context
full-name "union::"
chain >
decl_2 decl_5 VOID t.i:5:5
align:8 warn_if_not_align:0 context >
$2 = 10
Re: [PATCH] cp: fix location comparison in member_name_cmp
On 09/19/2017 07:25 AM, Alexander Monakov wrote: On Tue, 19 Sep 2017, Nathan Sidwell wrote: On 09/19/2017 07:06 AM, Alexander Monakov wrote: Hi, After recent changes, the member_name_cmp qsort comparator can indicate A < B < A (i.e. lacks anti-commutativity) for distinct TYPE_DECL nodes that have the same source location. If their order doesn't matter, the comparator should return 0. Where do we get such type decls? The first instance that tripped qsort checking for me was in PCH generation. I think by adding What source example generates such type decls? That you've encountered this suggests one of the invariants I was presuming is not true. nathan -- Nathan Sidwell
Re: [PATCH] cp: fix location comparison in member_name_cmp
On Tue, 19 Sep 2017, Nathan Sidwell wrote: > On 09/19/2017 07:06 AM, Alexander Monakov wrote: > > Hi, > > > > After recent changes, the member_name_cmp qsort comparator can indicate > > A < B < A (i.e. lacks anti-commutativity) for distinct TYPE_DECL nodes > > that have the same source location. If their order doesn't matter, the > > comparator should return 0. > > Where do we get such type decls? The first instance that tripped qsort checking for me was in PCH generation. I think by adding gcc_assert (DECL_SOURCE_LOCATION (a) != DECL_SOURCE_LOCATION (b)); at the appropriate point in this comparator you can see for yourself. Thanks. Alexander
Re: [PATCH] cp: fix location comparison in member_name_cmp
On 09/19/2017 07:06 AM, Alexander Monakov wrote: Hi, After recent changes, the member_name_cmp qsort comparator can indicate A < B < A (i.e. lacks anti-commutativity) for distinct TYPE_DECL nodes that have the same source location. If their order doesn't matter, the comparator should return 0. Where do we get such type decls? nathan -- Nathan Sidwell
