Hi.
Honza can you please fix this:
gcc/ipa-devirt.c:1616:12: warning: implicit conversion of NULL constant to
'bool' [-Wnull-conversion]
Thanks,
Martin
atc...@gcc.gnu.org>; Richard Biener ; d...@dcepelik.cz;
> Martin Liška
> Subject: Re: Use ODR for canonical types construction in LTO
>
> Hi,
> this patch fixes the ICE. Problem is that va_arg type is pre-streamed and thus
> at stream-in time we have main variant constructe
Hi,
this patch fixes the ICE. Problem is that va_arg type is pre-streamed
and thus at stream-in time we have main variant constructed by LTO FE
which is !CXX_ODR_P while vairants are ones comming from C++ FE which
are ODR. It is safe to drop the flags here since we only care about
main variants an
On Mon, Jun 24, 2019 at 1:46 PM Jan Hubicka wrote:
> >
> > I thought I remembered someone's recent-ish work to treat specially
> > types containing a char array, but I'm not finding it now.
> >
> > > For dynamically allocated memory as well as for stack space after stack
> > > slot sharing done in
e-
> From: Jan Hubicka
> Sent: Thursday, June 27, 2019 2:29 PM
> To: JiangNing OS
> Cc: Eric Botcazou ; Christophe Lyon
> ; gcc Patches ;
> Richard Biener ; d...@dcepelik.cz; Martin Liška
>
> Subject: Re: Use ODR for canonical types construction in LTO
>
> > Hi,
> On Thu, 27 Jun 2019, Jan Hubicka wrote:
>
> > Hi,
> > here is update patch I am re-testing. Ok if it suceeds?
>
> + if (!type_in_anonymous_namespace_p (t))
> + hash = htab_hash_string (IDENTIFIER_POINTER
> + (DECL_ASSEMBLER_NAME
> +
On Thu, 27 Jun 2019, Jan Hubicka wrote:
> Hi,
> here is update patch I am re-testing. Ok if it suceeds?
+ if (!type_in_anonymous_namespace_p (t))
+ hash = htab_hash_string (IDENTIFIER_POINTER
+ (DECL_ASSEMBLER_NAME
+
Hi,
here is update patch I am re-testing. Ok if it suceeds?
Orace quary stats finished in meantime.
Alias oracle query stats:
refs_may_alias_p: 39232255 disambiguations, 47436580 queries
ref_maybe_used_by_call_p: 59801 disambiguations, 39811399 queries
call_may_clobber_ref_p: 5967 disambigu
> > Actually this was intended to be prevail in both cases, but it is
> > harmless. The difference here is that anonymous types have
> > DECL_ASSEMBLED_NAME , so if we inserted them to the hash
> > table based on names they will all conflict.
> >
> > Anonymous namespace types never have duplicate
On Thu, 27 Jun 2019, Jan Hubicka wrote:
> > > + if (RECORD_OR_UNION_TYPE_P (t)
> > > + && odr_type_p (t) && !odr_type_violation_reported_p (t))
> > > +{
> > > + /* Here we rely on fact that all non-ODR types was inserted into
> > > + canonical type hash and thus we can safely detec
> > + if (RECORD_OR_UNION_TYPE_P (t)
> > + && odr_type_p (t) && !odr_type_violation_reported_p (t))
> > +{
> > + /* Here we rely on fact that all non-ODR types was inserted into
> > +canonical type hash and thus we can safely detect conflicts between
> > +ODR types and intero
On Thu, 27 Jun 2019, Jan Hubicka wrote:
> Hi,
> this is updated patch for ODR based canonical type calculation. It makes use
> of TYPE_CXX_ODR_P instead of doing the guesswork and while thinking how to get
> rid of the quadratic behaviour of the hash I noticed that all the logic fits
> quite natu
Hi,
this is updated patch for ODR based canonical type calculation. It makes use
of TYPE_CXX_ODR_P instead of doing the guesswork and while thinking how to get
rid of the quadratic behaviour of the hash I noticed that all the logic fits
quite naturally into gimple_register_canonical_type_1.
We on
ror: lto-wrapper failed
> collect2: error: ld returned 1 exit status
>
> Thanks,
> -Jiangning
>
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org
> > On Behalf Of Christophe Lyon
> > Sent: Tuesday, June 25, 2019 8:30 PM
> > To: Jan Hubicka
urned 1 exit status
Thanks,
-Jiangning
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org
> On Behalf Of Christophe Lyon
> Sent: Tuesday, June 25, 2019 8:30 PM
> To: Jan Hubicka
> Cc: Eric Botcazou ; gcc Patches patc...@gcc.gnu.org>; Richard Biener ;
Hi,
On Tue, 25 Jun 2019 at 10:20, Jan Hubicka wrote:
>
> > > * gcc-interface/decl.c (gnat_to_gnu_entity): Check that
> > > type is array or integer prior checking string flag.
> >
> > The test for array is superfluous here.
> >
> > > * gcc-interface/gigi.h (gnat_signed_type_for,
> >
> > * gcc-interface/decl.c (gnat_to_gnu_entity): Check that
> > type is array or integer prior checking string flag.
>
> The test for array is superfluous here.
>
> > * gcc-interface/gigi.h (gnat_signed_type_for,
> > maybe_character_value): Likewise.
>
> Wrong ChangeLog, the firs
> * gcc-interface/decl.c (gnat_to_gnu_entity): Check that
> type is array or integer prior checking string flag.
The test for array is superfluous here.
> * gcc-interface/gigi.h (gnat_signed_type_for,
> maybe_character_value): Likewise.
Wrong ChangeLog, the first modified
Hi,
>
> I thought I remembered someone's recent-ish work to treat specially
> types containing a char array, but I'm not finding it now.
>
> > For dynamically allocated memory as well as for stack space after stack
> > slot sharing done in cfgexpand I see this is necessary since we do not
> > pre
On Mon, Jun 24, 2019 at 1:23 PM Richard Biener wrote:
> On Mon, 24 Jun 2019, Jason Merrill wrote:
>
> > On Mon, Jun 24, 2019 at 12:40 PM Jason Merrill wrote:
> > > On Mon, Jun 24, 2019 at 11:57 AM Jan Hubicka wrote:
> > > >
> > > > > > > As
> > > > > > >
> > > > > > > class a var;
> > > > > >
On Mon, 24 Jun 2019, Jason Merrill wrote:
> On Mon, Jun 24, 2019 at 12:40 PM Jason Merrill wrote:
> > On Mon, Jun 24, 2019 at 11:57 AM Jan Hubicka wrote:
> > >
> > > > > > As
> > > > > >
> > > > > > class a var;
> > > > > > class b:a {} *bptr;
> > > > > >
> > > > > > var.foo;
> > > > > >
>
On Mon, Jun 24, 2019 at 12:40 PM Jason Merrill wrote:
> On Mon, Jun 24, 2019 at 11:57 AM Jan Hubicka wrote:
> >
> > > > > As
> > > > >
> > > > > class a var;
> > > > > class b:a {} *bptr;
> > > > >
> > > > > var.foo;
> > > > >
> > > > > Expanding this as var.as_base_a.foo would make access
On Mon, Jun 24, 2019 at 11:57 AM Jan Hubicka wrote:
>
> Hi,
> thanks for comitting the patch!
> > > > As
> > > >
> > > > class a var;
> > > > class b:a {} *bptr;
> > > >
> > > > var.foo;
> > > >
> > > > Expanding this as var.as_base_a.foo would make access path oracle to
> > > > disambiguate
Hi,
thanks for comitting the patch!
> > > As
> > >
> > > class a var;
> > > class b:a {} *bptr;
> > >
> > > var.foo;
> > >
> > > Expanding this as var.as_base_a.foo would make access path oracle to
> > > disambiguate it from bptr->as_base_b->as_base_a.foo which is wrong with
> > > gimple memo
On Mon, Jun 24, 2019 at 7:28 AM Richard Biener wrote:
> On Mon, 24 Jun 2019, Jan Hubicka wrote:
>
> > > > This simple (untested) patch doesn't avoid creating the unnecessary
> > > > as-base types, but it should avoid using them in a way that causes
> > > > them to be streamed, and should let them
On Mon, 24 Jun 2019, Jan Hubicka wrote:
> > Hi,
> > here is patch that adds TYPE_ODR_P to determine type that comply C++
> > ODR rules (i.e. ODR types themselves or structures/unions derived
> > from them).
> > I have decided to use STRING_FLAG which have meaning only for integers
> > and arrays w
> On Mon, 24 Jun 2019, Jan Hubicka wrote:
>
> > > > This simple (untested) patch doesn't avoid creating the unnecessary
> > > > as-base types, but it should avoid using them in a way that causes
> > > > them to be streamed, and should let them be discarded by GC.
> > > > Thoughts?
> > >
> > > Loo
On Mon, 24 Jun 2019, Jan Hubicka wrote:
> > > This simple (untested) patch doesn't avoid creating the unnecessary
> > > as-base types, but it should avoid using them in a way that causes
> > > them to be streamed, and should let them be discarded by GC.
> > > Thoughts?
> >
> > Looks better than H
> > This simple (untested) patch doesn't avoid creating the unnecessary
> > as-base types, but it should avoid using them in a way that causes
> > them to be streamed, and should let them be discarded by GC.
> > Thoughts?
>
> Looks better than Honzas patch fixing a single place.
I wonder if we ca
> Hi,
> here is patch that adds TYPE_ODR_P to determine type that comply C++
> ODR rules (i.e. ODR types themselves or structures/unions derived
> from them).
> I have decided to use STRING_FLAG which have meaning only for integers
> and arrays which forced me to add type checks on places where
> w
On 6/20/19 11:49 AM, Richard Biener wrote:
On June 20, 2019 4:06:58 PM GMT+02:00, Nathan Sidwell wrote:
On 6/20/19 9:37 AM, Richard Biener wrote:
I've spent some thoughts on this and I wonder whether we can
re-implement classtype-as-base with fake inheritance (which would
also solve the TBAA
On June 20, 2019 4:06:58 PM GMT+02:00, Nathan Sidwell wrote:
>On 6/20/19 9:37 AM, Richard Biener wrote:
>
>> I've spent some thoughts on this and I wonder whether we can
>> re-implement classtype-as-base with fake inheritance (which would
>> also solve the TBAA alias set issue in a natural way).
On 6/20/19 9:37 AM, Richard Biener wrote:
I've spent some thoughts on this and I wonder whether we can
re-implement classtype-as-base with fake inheritance (which would
also solve the TBAA alias set issue in a natural way). That is,
we'd lay out structs as-base and make instances of it use a
c
> > This simple (untested) patch doesn't avoid creating the unnecessary
> > as-base types, but it should avoid using them in a way that causes
> > them to be streamed, and should let them be discarded by GC.
> > Thoughts?
>
> Looks better than Honzas patch fixing a single place.
Indeed, I think i
On Thu, 20 Jun 2019, Jason Merrill wrote:
> On Wed, Jun 19, 2019 at 2:47 PM Nathan Sidwell wrote:
> >
> > On 6/19/19 1:53 PM, Jan Hubicka wrote:
> > -ctype = CLASSTYPE_AS_BASE (ctype);
> > +{
> > + if (!tree_int_cst_equal (TYPE_SIZE (ctype),
> > +
> On 6/19/19 1:53 PM, Jan Hubicka wrote:
> > > > > -ctype = CLASSTYPE_AS_BASE (ctype);
> > > > > +{
> > > > > + if (!tree_int_cst_equal (TYPE_SIZE (ctype),
> > > > > +TYPE_SIZE (CLASSTYPE_AS_BASE (ctype
> > > > > +ctype = CLASSTYPE_AS_BASE (ctype
On 6/20/19 12:34 AM, Jason Merrill wrote:
On Wed, Jun 19, 2019 at 2:47 PM Nathan Sidwell wrote:
This simple (untested) patch doesn't avoid creating the unnecessary
as-base types, but it should avoid using them in a way that causes
them to be streamed, and should let them be discarded by GC.
T
On Wed, Jun 19, 2019 at 2:47 PM Nathan Sidwell wrote:
>
> On 6/19/19 1:53 PM, Jan Hubicka wrote:
> -ctype = CLASSTYPE_AS_BASE (ctype);
> +{
> + if (!tree_int_cst_equal (TYPE_SIZE (ctype),
> + TYPE_SIZE (CLASSTYPE_AS_BASE (ctype
> +
On 6/19/19 1:53 PM, Jan Hubicka wrote:
-ctype = CLASSTYPE_AS_BASE (ctype);
+{
+ if (!tree_int_cst_equal (TYPE_SIZE (ctype),
+ TYPE_SIZE (CLASSTYPE_AS_BASE (ctype
+ctype = CLASSTYPE_AS_BASE (ctype);
+}
tree clobber = build_clobber (cty
> > > -ctype = CLASSTYPE_AS_BASE (ctype);
> > > +{
> > > + if (!tree_int_cst_equal (TYPE_SIZE (ctype),
> > > +TYPE_SIZE (CLASSTYPE_AS_BASE (ctype
> > > +ctype = CLASSTYPE_AS_BASE (ctype);
> > > +}
> > > tree clobber = build_clobber (ctype);
>
On 6/19/19 9:28 AM, Jan Hubicka wrote:
Jason,
I also wonder if something like this would make sense:
* decl.c (build_clobber_this): Use original basetype if they
match.
Index: decl.c
===
--- decl.c (revision 27
> Jason,
> I also wonder if something like this would make sense:
>
> * decl.c (build_clobber_this): Use original basetype if they
> match.
>
> Index: decl.c
> ===
> --- decl.c(revision 272381)
> +++ decl.c(workin
Jason,
I also wonder if something like this would make sense:
* decl.c (build_clobber_this): Use original basetype if they
match.
Index: decl.c
===
--- decl.c (revision 272381)
+++ decl.c (working copy)
@@ -
Hi,
Jason, this is about C++ frontend producing two copies of same type with
different TYPE_CANONICAL but same get_alias_set. Since the types are
structurally different, this does not go well with LTO which no longer
sees they are same. They are created in
if (CLASSTYPE_NON_LAYOUT_POD_P (t) ||
>
> ICK. Can you please solve the C++ issue differently? The patch
> also seems to do many other things ...
If you refer to the fact that C++ seem to create non-ODR types that are
structurally equivalent to ODR types, i tracked it down. Testcase is
testsuite/g++.dg/lto/20080904_0.C
compiled wi
Hi,
here is patch that adds TYPE_ODR_P to determine type that comply C++
ODR rules (i.e. ODR types themselves or structures/unions derived
from them).
I have decided to use STRING_FLAG which have meaning only for integers
and arrays which forced me to add type checks on places where
we check STRING
> > Step 2 remain same.
> > Additional step 3 registers all odr derived types into canonical type hash.
> > This requires canonical type hash to play well with ODR types (i.e. not
> > consider them equivalent based on structural equivalety).
> >
> > The decision on whether given type has ODR based
On Mon, 3 Jun 2019, Jan Hubicka wrote:
> Hi,
> this patch makes LTO to use ODR names when building canonical types.
> Theoretically this is easy task because every ODR type is unique and
> it is enough to fill in the hash with the ODR names and compare them.
>
> In reality we want to be more care
> * alias.c (record_component_aliases): Honor odr_based_tbaa_p.
> * ipa-devirt.c (odr_type_d): Add tbaa_enabled field.
> (get_odr_type): Return NULL when odr_type_hash is NULL.
> (enable_odr_based_tbaa): New function.
> (odr_based_tbaa_p): New function.
> (set_ty
49 matches
Mail list logo
