On Thu, 29 Oct 2020, Jan Hubicka wrote:
> > Hi,
> > this is patch I am using to fix the assumed_alias_type.f90 failure by
> > simply arranging alias set 0 for the problematic array descriptor.
> >
> > I am not sure this is the best option, but I suppose it is better than
> > setting all array
> Hi,
> this is patch I am using to fix the assumed_alias_type.f90 failure by
> simply arranging alias set 0 for the problematic array descriptor.
>
> I am not sure this is the best option, but I suppose it is better than
> setting all array descritors to have same canonical type (as done by
>
On Fri, 23 Oct 2020 11:54:08 +0200
Bernhard Reutner-Fischer via Fortran wrote:
> On 16 October 2020 11:20:23 CEST, Richard Biener wrote:
>
> >IMHO the cleanest way would be to swap the CAF token field and
> >the dim[] field (which is an ABI change for -fcoarray)
>
> I think coarrays are new
On 16 October 2020 11:20:23 CEST, Richard Biener wrote:
>IMHO the cleanest way would be to swap the CAF token field and
>the dim[] field (which is an ABI change for -fcoarray)
I think coarrays are new anyway so I suppose an ABI break is fine?
On Fri, 16 Oct 2020, Richard Biener wrote:
> On Fri, 16 Oct 2020, Richard Biener wrote:
>
> > On Fri, 16 Oct 2020, Jan Hubicka wrote:
> >
> > > Hi,
> > > I am slowly getting finished with the fn spec changes on trunk and then
> > > would like to proceed with modref. Sadly still get the
On Fri, 16 Oct 2020, Richard Biener wrote:
> On Fri, 16 Oct 2020, Jan Hubicka wrote:
>
> > Hi,
> > I am slowly getting finished with the fn spec changes on trunk and then
> > would like to proceed with modref. Sadly still get the assumed_type
> > failuere and in addition to that:
> > FAIL:
On Fri, 16 Oct 2020, Jan Hubicka wrote:
> Hi,
> I am slowly getting finished with the fn spec changes on trunk and then
> would like to proceed with modref. Sadly still get the assumed_type
> failuere and in addition to that:
> FAIL: gfortran.dg/finalize_25.f90 -O2 execution test
> FAIL:
Hi,
I am slowly getting finished with the fn spec changes on trunk and then
would like to proceed with modref. Sadly still get the assumed_type
failuere and in addition to that:
FAIL: gfortran.dg/finalize_25.f90 -O2 execution test
FAIL: gfortran.dg/finalize_25.f90 -O3 -fomit-frame-pointer
> On 9/21/20 10:10 AM, Richard Biener wrote:
>
> > > I see, so you would expect call to alsize to initialize things in
> > > array15_unkonwn type? That would work too.
> > Yes, that's my expectation. But let's see what fortran folks say.
>
> RFC patch attached; I think the following should
On Thu, 2020-09-24 at 08:30 +0200, Jan Hubicka wrote:
> Hi,
> This patch makes ggc_delete to be paired with ggc_alloc_no_dtor.
> I copy same scheme as used by Martin in ipa-fnsummary, that is
> creating a
> static member function create_ggc hidding the ugly bits and using it
> in
> ipa-modref.c.
>
Hi,
This patch makes ggc_delete to be paired with ggc_alloc_no_dtor.
I copy same scheme as used by Martin in ipa-fnsummary, that is creating a
static member function create_ggc hidding the ugly bits and using it in
ipa-modref.c.
I also noticed that modref-tree leaks memory on destruction/collapse
>
> Summarizing what's going on:
>
> We have a use-after-ggc_delete happening with the finalizers code.
>
> analyze_function has:
>
> summaries = new (ggc_alloc ())
>modref_summaries (symtab);
>
> ggc_alloc (as opposed to ggc_alloc_no_dtor) uses need_finalization_p
>
On Tue, 2020-09-22 at 22:23 +0200, Jan Hubicka wrote:
> > On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote:
> > > David,
> > > with jit I get the following:
> > > /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed:
> > > nonrepresentable section on output
> > > collect2: error: ld
On Tue, 2020-09-22 at 22:24 +0200, Jan Hubicka wrote:
> > On Tue, 2020-09-22 at 16:13 -0400, David Malcolm wrote:
> > > On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote:
> > > > David,
> > > > with jit I get the following:
> > > > /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed:
> > >
> On Tue, 2020-09-22 at 16:13 -0400, David Malcolm wrote:
> > On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote:
> > > David,
> > > with jit I get the following:
> > > /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed:
> > > nonrepresentable section on output
> > > collect2: error: ld
> On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote:
> > David,
> > with jit I get the following:
> > /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed:
> > nonrepresentable section on output
> > collect2: error: ld returned 1 exit status
> > make[3]: *** [../../gcc/jit/Make-lang.in:121:
On Tue, 2020-09-22 at 16:13 -0400, David Malcolm wrote:
> On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote:
> > David,
> > with jit I get the following:
> > /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed:
> > nonrepresentable section on output
> > collect2: error: ld returned 1 exit
Hello,
this patch fixes the selftests and destructor issue noticed by David
(Malcolm). According to David jit still crashes at different but I am
hitting different build failure in libjit that I will need to analyze
tomorrow.
Bootstrapped/regtested x86_64-linux, comitted.
*
On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote:
> David,
> with jit I get the following:
> /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed:
> nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> make[3]: *** [../../gcc/jit/Make-lang.in:121:
> On Sun, 2020-09-20 at 19:30 +0200, Jan Hubicka wrote:
> > >
>
> [...]
>
> > > Should new C++ source files have a .cc suffix, rather than .c?
> > >
> > > [...]
> > >
> > > > + $(srcdir)/ipa-modref.h $(srcdir)/ipa-modref.c \
> > >
> > > ...which would affect this^
>
David,
with jit I get the following:
/usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed: nonrepresentable
section on output
collect2: error: ld returned 1 exit status
make[3]: *** [../../gcc/jit/Make-lang.in:121: libgccjit.so.0.0.1] Error
Is there a fix/workaround?
Patch I am trying to
>
> Thanks; with that it survives the first in-process iteration, but then
> dies inside the 3rd in-process iteration, on a different finalizer.
> I'm beginning to suspect a pre-existing bad interaction between
> finalizers and jit which perhaps this patch has exposed.
>
> I'll continue to
On Tue, 2020-09-22 at 09:07 +0200, Jan Hubicka wrote:
> > > (gdb) p summaries
> > > $3 = (fast_function_summary *) 0x0
> > >
> > > I'm still investigating (but may have to call halt for the
> > > night), but
> > > this could be an underlying issue with the new passes; the jit
> > > testsuite runs
On 9/21/20 10:10 AM, Richard Biener wrote:
I see, so you would expect call to alsize to initialize things in
array15_unkonwn type? That would work too.
Yes, that's my expectation. But let's see what fortran folks say.
RFC patch attached; I think the following should work, but I am not
sure
> > (gdb) p summaries
> > $3 = (fast_function_summary *) 0x0
> >
> > I'm still investigating (but may have to call halt for the night), but
> > this could be an underlying issue with the new passes; the jit
> > testsuite runs with the equivalent of:
> >
> > --param=ggc-min-expand=0
> On Sun, 2020-09-20 at 19:30 +0200, Jan Hubicka wrote:
> > > On Sun, 2020-09-20 at 00:32 +0200, Jan Hubicka wrote:
> > > > Hi,
> > > > this is cleaned up version of the patch. I removed unfinished
> > > > bits,
> > > > fixed
> > > > propagation, cleaned it up and fixed fallout.
> > >
> > >
On Sun, 2020-09-20 at 19:30 +0200, Jan Hubicka wrote:
> > On Sun, 2020-09-20 at 00:32 +0200, Jan Hubicka wrote:
> > > Hi,
> > > this is cleaned up version of the patch. I removed unfinished
> > > bits,
> > > fixed
> > > propagation, cleaned it up and fixed fallout.
> >
> > [...]
> >
> > > While
On Mon, 21 Sep 2020, Jan Hubicka wrote:
> > >
> > > The problem is:
> > >
> > > alsize (struct array15_unknown & restrict a)
> > > {
> > > ...
> > > _2 = *a_13(D).dtype.rank;
> > > _3 = (integer(kind=8)) _2;
> > > ...
> > > }
> > > }
> > > and in main:
> > >
> > > struct
> >
> > The problem is:
> >
> > alsize (struct array15_unknown & restrict a)
> > {
> > ...
> > _2 = *a_13(D).dtype.rank;
> > _3 = (integer(kind=8)) _2;
> > ...
> > }
> > }
> > and in main:
> >
> > struct array02_integer(kind=4) am;
> >:
> > MEM [(struct dtype_type *) + 24B] = {};
>
On Mon, 21 Sep 2020, Jan Hubicka wrote:
> > On Sun, 20 Sep 2020, Jan Hubicka wrote:
> >
> > > Hi,
> > > this is patch I am using to fix the assumed_alias_type.f90 failure by
> > > simply arranging alias set 0 for the problematic array descriptor.
> >
> > There's no such named testcase on trunk.
> On Sun, 20 Sep 2020, Jan Hubicka wrote:
>
> > Hi,
> > this is patch I am using to fix the assumed_alias_type.f90 failure by
> > simply arranging alias set 0 for the problematic array descriptor.
>
> There's no such named testcase on trunk. Can you be more specific
> as to the problem at hand?
On Sun, 20 Sep 2020, Jan Hubicka wrote:
> Hi,
> this is patch I am using to fix the assumed_alias_type.f90 failure by
> simply arranging alias set 0 for the problematic array descriptor.
There's no such named testcase on trunk. Can you be more specific
as to the problem at hand? It looks like
On Sun, 2020-09-20 at 19:30 +0200, Jan Hubicka wrote:
> >
[...]
> > Should new C++ source files have a .cc suffix, rather than .c?
> >
> > [...]
> >
> > > + $(srcdir)/ipa-modref.h $(srcdir)/ipa-modref.c \
> >
> > ...which would affect this^
>
> I was wondering about
> On Sun, 2020-09-20 at 00:32 +0200, Jan Hubicka wrote:
> > Hi,
> > this is cleaned up version of the patch. I removed unfinished bits,
> > fixed
> > propagation, cleaned it up and fixed fallout.
>
> [...]
>
> > While there are several areas for improvements but I think it is not
> > in shape
>
On Sun, 2020-09-20 at 00:32 +0200, Jan Hubicka wrote:
> Hi,
> this is cleaned up version of the patch. I removed unfinished bits,
> fixed
> propagation, cleaned it up and fixed fallout.
[...]
> While there are several areas for improvements but I think it is not
> in shape
> for mainline and
Hi,
this is patch I am using to fix the assumed_alias_type.f90 failure by
simply arranging alias set 0 for the problematic array descriptor.
I am not sure this is the best option, but I suppose it is better than
setting all array descritors to have same canonical type (as done by
LTO)?
Honza
Hi,
this is cleaned up version of the patch. I removed unfinished bits, fixed
propagation, cleaned it up and fixed fallout.
At present modref does bare minimum of what it can do and only collects
base/ref alias sets of accesses to disambiguate uding them. I have followup
patches adding more
Dear GCC developers,
Below you may find a patch which implements two new optimization
passes, called "modref" and "ipa_modref", which operate on GIMPLE and
during WPO, respectively.
What the passes do is fairly simple: for each analyzed function, they
collect information about loads and stores
38 matches
Mail list logo
