Hi!
On Mon, 23 Nov 2015 18:34:30 +0300, Ilya Verbin wrote:
> On Mon, Nov 23, 2015 at 16:31:42 +0100, Richard Biener wrote:
> > I think it also causes the following and one related ICE
> >
> > FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal compiler
> > error)
> >
> > /space/rguen
>
> Might be a bit expensive though. It also reminds me of all the
> ICEs we have PRs for WRT the type verifier. Remember we are in stage3
> now so rather than introducing new issues you should spend some time
> fixing the existing ones you caused ;)) (just look for bugs
> CCed to hubi...@gcc.g
On Tue, 24 Nov 2015, Jan Hubicka wrote:
> > > Now alias set of the initialization is alias set of "struct a". The alias
> > > set
> > > of of the pointer store is "float *". We ask alias oracle if "struct a"
> > > can
> > > conflict with "float *" and answer is no, because "int *" (component of
On Tue, Nov 24, 2015 at 07:10:01AM +0100, Jan Hubicka wrote:
> > On November 23, 2015 5:50:25 PM GMT+01:00, Jan Hubicka
> > wrote:
> > >>
> > >> I think it also causes the following and one related ICE
> > >>
> > >> FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal
> > >compiler
>
> > Now alias set of the initialization is alias set of "struct a". The alias
> > set
> > of of the pointer store is "float *". We ask alias oracle if "struct a" can
> > conflict with "float *" and answer is no, because "int *" (component of
> > struct
> > b) and "float *" are not conflicting.
On Tue, 24 Nov 2015, Jan Hubicka wrote:
> > On November 23, 2015 5:50:25 PM GMT+01:00, Jan Hubicka
> > wrote:
> > >>
> > >> I think it also causes the following and one related ICE
> > >>
> > >> FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal
> > >compiler
> > >> error)
> > >>
On Mon, 23 Nov 2015, Jan Hubicka wrote:
> >
> > Please in future leave patches for review again if you do such
> > big changes before committing...
>
> Uhm, sorry, next time I will be more cureful. It seemed rather easy after
> debugging it but indeed it is somewhat surprising issue.
> >
> > I
> On November 23, 2015 5:50:25 PM GMT+01:00, Jan Hubicka wrote:
> >>
> >> I think it also causes the following and one related ICE
> >>
> >> FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal
> >compiler
> >> error)
> >>
> >>
> >/space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.dg/v
> I don't understand why we need this (testcase?) because get_alias_set ()
> is supposed to do the alias-set of pointer globbing for us.
Hi,
After some experimentation I managed to derive self contained testcase (other
than GCC itself).
struct a/b/c gets the same TYPE_CANONICAL which is different
> > You are right, TYPE_NONALIASED_COMPONENT is the wrong way. I will fix it
> > and try to come up with a testcase (TYPE_NONALIASED_COMPONENT is quite
> > rarely used beast)
>
> It's only used in Ada as far as I know, but is quite sensitive and quickly
> leads to wrong code if not handled prope
On November 23, 2015 5:50:25 PM GMT+01:00, Jan Hubicka wrote:
>>
>> I think it also causes the following and one related ICE
>>
>> FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal
>compiler
>> error)
>>
>>
>/space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.dg/vect/pr62021.c:7:1:
>
>
> Please in future leave patches for review again if you do such
> big changes before committing...
Uhm, sorry, next time I will be more cureful. It seemed rather easy after
debugging it but indeed it is somewhat surprising issue.
>
> I don't understand why we need this (testcase?) because ge
>
> I think it also causes the following and one related ICE
>
> FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal compiler
> error)
>
> /space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.dg/vect/pr62021.c:7:1:
> internal compiler error: in get_alias_set, at alias.c:880^M
> 0x7528a7
On Mon, Nov 23, 2015 at 16:31:42 +0100, Richard Biener wrote:
> I think it also causes the following and one related ICE
>
> FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal compiler
> error)
>
> /space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.dg/vect/pr62021.c:7:1:
> internal co
On Mon, 23 Nov 2015, Martin Jambor wrote:
> Hi,
>
> On Mon, Nov 23, 2015 at 12:00:25AM +0100, Jan Hubicka wrote:
> > Hi,
> > here is updated patch which I finally comitted today. It addresses all the
> > comments
> > and also fixes one nasty bug that really cost me a lot of time to
> > underst
Hi,
On Mon, Nov 23, 2015 at 12:00:25AM +0100, Jan Hubicka wrote:
> Hi,
> here is updated patch which I finally comitted today. It addresses all the
> comments
> and also fixes one nasty bug that really cost me a lot of time to understand.
>
> + /* LTO type merging does not make any diffe
On Mon, 23 Nov 2015, Jan Hubicka wrote:
> Hi,
> here is updated patch which I finally comitted today. It addresses all the
> comments
> and also fixes one nasty bug that really cost me a lot of time to understand.
>
> + /* LTO type merging does not make any difference between
> +
> You are right, TYPE_NONALIASED_COMPONENT is the wrong way. I will fix it
> and try to come up with a testcase (TYPE_NONALIASED_COMPONENT is quite
> rarely used beast)
It's only used in Ada as far as I know, but is quite sensitive and quickly
leads to wrong code if not handled properly in my ex
> > + tree t = TREE_TYPE (field);
> > + if (in_lto_p)
> > + {
> > + /* VECTOR_TYPE and ARRAY_TYPE share the alias set with their
> > + element type and that type has to be normalized to void *,
> > + too, in the case it is a pointer. */
> > +
> + tree t = TREE_TYPE (field);
> + if (in_lto_p)
> + {
> + /* VECTOR_TYPE and ARRAY_TYPE share the alias set with their
> +element type and that type has to be normalized to void *,
> +too, in the case it is a pointer. */
> +
Hi,
here is updated patch which I finally comitted today. It addresses all the
comments
and also fixes one nasty bug that really cost me a lot of time to understand.
+ /* LTO type merging does not make any difference between
+component pointer types. We may have
+
+
> > On 11/11/2015 10:21 AM, Richard Biener wrote:
> > >On Tue, 10 Nov 2015, Jan Hubicka wrote:
> > >>The reason is that TYPE_CANONICAL is initialized in get_alias_set that
> > >>may be
> > >>called before we finish all merging and then it is more fine grained than
> > >>what
> > >>we need here (i
> On 11/11/2015 10:21 AM, Richard Biener wrote:
> >On Tue, 10 Nov 2015, Jan Hubicka wrote:
> >>The reason is that TYPE_CANONICAL is initialized in get_alias_set that may
> >>be
> >>called before we finish all merging and then it is more fine grained than
> >>what
> >>we need here (i.e. TYPE_CANON
On 11/11/2015 10:21 AM, Richard Biener wrote:
On Tue, 10 Nov 2015, Jan Hubicka wrote:
The reason is that TYPE_CANONICAL is initialized in get_alias_set that may be
called before we finish all merging and then it is more fine grained than what
we need here (i.e. TYPE_CANONICAL of pointers to two
On Tue, 10 Nov 2015, Jan Hubicka wrote:
> > > Index: tree.c
> > > ===
> > > --- tree.c(revision 229968)
> > > +++ tree.c(working copy)
> > > @@ -13198,6 +13198,7 @@ gimple_canonical_types_compatible_p (con
> > >/*
> > Index: tree.c
> > ===
> > --- tree.c (revision 229968)
> > +++ tree.c (working copy)
> > @@ -13198,6 +13198,7 @@ gimple_canonical_types_compatible_p (con
> >/* If the types have been previously registered and found equal
> >
On Sun, 8 Nov 2015, Jan Hubicka wrote:
> Hi,
> this patch adds basic TBAA for pointers to LTO. The basic scheme is simple;
> because TYPE_CANONICAL is not really needed by get_alias_set, we completely
> drop the caluclation of these (which also saves about 50% canonical type hash
> searches) and
Hi,
this patch adds basic TBAA for pointers to LTO. The basic scheme is simple;
because TYPE_CANONICAL is not really needed by get_alias_set, we completely
drop the caluclation of these (which also saves about 50% canonical type hash
searches) and update get_alias_set to not punt on pointers with
28 matches
Mail list logo
