> Hi Honza,
>
> My current patch set for AArch64 VLA omp codegen started failing on
> gcc.dg/gomp/pr87898.c after this. I traced it back to
> 'move_sese_region_to_fn' in tree/cfg.cc not setting count for the bb
> created.
>
> I was able to 'fix' it locally by setting the count of the new bb to th
> From: Sergei Trofimovich
>
> r14-3459-g0c78240fd7d519 "Check that passes do not forget to define profile"
> exposed check failures in cases when gcc produces uninitialized profile
> probabilities. In case of PR/111559 uninitialized profile is generated
> by edges executed 0 times reported by IP
>
> Like Wahlen et al this implementation records coverage in fixed-size
> bitsets which gcov knows how to interpret. This is very fast, but
> introduces a limit on the number of terms in a single boolean
> expression, the number of bits in a gcov_unsigned_type (which is
> typedef'd to uint64_t),
Hi,
can you please also squash those changes which fixes patch #1
so it is easier to review?
Honza
> From: Jørgen Kvalsvik
>
> ---
> gcc/gcov.cc | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/gcov.cc b/gcc/gcov.cc
> index 274f2fc5d9f..35be97cf5ac 100644
> --- a/g
> diff --git a/gcc/ipa-utils.cc b/gcc/ipa-utils.cc
> index 956c6294fd7..1355ccac6f0 100644
> --- a/gcc/ipa-utils.cc
> +++ b/gcc/ipa-utils.cc
> @@ -651,13 +651,16 @@ ipa_merge_profiles (struct cgraph_node *dst,
> {
> edge srce = EDGE_SUCC (srcbb, i);
> e
> PR 57 points to another place where IPA-CP collected aggregate
> compile-time constants need to be filtered, in addition to the one
> place that already does this in ipa-sra. In order to re-use code,
> this patch turns the common bit into a template.
>
> The functionality is still covered b
> gcc/ChangeLog:
>
> 2023-09-19 Martin Jambor
>
> PR ipa/57
> * ipa-prop.h (struct ipa_argagg_value): Newf flag killed.
> * ipa-modref.cc (ipcp_argagg_and_kill_overlap_p): New function.
> (update_signature): Mark any any IPA-CP aggregate constants at
> positio
> On Thu, Oct 05, 2023 at 03:04:55PM +0200, Jan Hubicka wrote:
> > > diff --git a/gcc/ipa-utils.cc b/gcc/ipa-utils.cc
> > > index 956c6294fd7..1355ccac6f0 100644
> > > --- a/gcc/ipa-utils.cc
> > > +++ b/gcc/ipa-utils.cc
> > > @@ -651,13 +651,1
> On 05/10/2023 22:39, Jørgen Kvalsvik wrote:
> > On 05/10/2023 21:59, Jan Hubicka wrote:
> > > >
> > > > Like Wahlen et al this implementation records coverage in fixed-size
> > > > bitsets which gcov knows how to interpret. This is very fast, bu
> Hi!
>
> The following patch removes ipa_bits struct pointer/vector from ipa
> jump functions and ipa cp transformations.
>
> The reason is because the struct uses widest_int to represent
> mask/value pair, which in the RFC patches to allow larger precisions
> for wide_int/widest_int is GC unfri
> The support to elide calls to allocation functions in DCE runs into
> the issue that when implementations are discovered noreturn we end
> up DCEing the calls anyway, leaving blocks without termination and
> without outgoing edges which is both invalid IL and wrong-code when
> as in the example t
c block.
>
> Bootstrapped and regression tested on aarch64-unknown-linux-gnu and
> x86_64-pc-linux-gnu.
This is OK,
thanks!
Honza
>
> On 04/10/2023 12:02, Jan Hubicka wrote:
> > > Hi Honza,
> > >
> > > My current patch set for AArch64 VLA omp codegen sta
Hi,
this is another field that I believe needs no streaming. I however think we
are pretty
much done with low hanging fruit.
lto-bootstrapped/regtested x86_64-linux, OK?
Honza
* lto-streamer-out.c (DFS::DFS_write_tree_body): Do not stream
DECL_FCONTEXT
(hash_tree): Do n
Hi,
this patch adds dump file for WPA streaming process. It uses the new
dump file code for parittions.
Bootstrapped/regtsted x86_64-linux, will commit it shortly.
Honza
* lto.c (do_stream_out): Add PART parameter; open dump file.
(stream_out): Add PART parameter; pass it to do_s
> > > > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > > > index 9e46b7b136f..762ab89fc9e 100644
> > > > --- a/gcc/config/i386/i386.c
> > > > +++ b/gcc/config/i386/i386.c
> > > > @@ -137,17 +137,22 @@ const struct processor_costs *ix86_cost = NULL;
> > > > #define m_CORE2 (HOST_W
> > We have also noticed that benchmarks on skylake are not good compared to
> > haswell, this nicely explains it. I think this is -march=native regression
> > compared to GCC versions that did not suppored better CPUs than Haswell.
> > So it
> > would be nice to backport it.
>
> Yes, we should
Hi,
since we now mention the problem with Intel tuning, I tought we also may mention
the LTO link-time issue that was fixed. It was mentioned by several folks at
the phoronix forum. (Basicaly sometimes the partition size has overlfown which
made partitioner to put every symbol into separate pariti
> Hi.
>
> This is implementation of new built-in that can be used for more fine
> tweaking of probability. Micro benchmark is attached as part of the PR.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
It reasonale to me to add the fatur
> Hi.
>
> Following patch implements new predictors that annotates malloc-like
> functions.
> These almost every time return a non-null value.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
> Martin
>
> gcc/ChangeLog:
>
> 2018-07-26
> Hi.
>
> As requested in the PR, I would like to add value profiling for
> BUILT_IN_MEMMOVE.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Martin
>
> gcc/ChangeLog:
>
> 2018-07-31 Martin Liska
>
> PR value-prof/35543
>
> Hi.
>
> This is format clean-up of value transformations that can happen.
> It makes it easier to grep them and find how many were actually
> applied.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Martin
>
> gcc/ChangeLog:
>
> 2018-07
> This patch teaches libiberty to output X86-64 Relocations.
Hello,
for actual patch submission you will need to add changelog :)
> diff --git a/libiberty/simple-object-elf.c b/libiberty/simple-object-elf.c
> index 86b7a27dc74..0bbaf4b489f 100644
> --- a/libiberty/simple-object-elf.c
> +++ b/libibe
Hello,
thanks for the patch.
Overall it looks in right direction except for the code duplication in
output_die and friends.
> +/* Given a die and id, produce the appropriate abbreviations
> + directly to lto object file */
> +
> +static void
> +output_die_abbrevs_to_object_file(unsigned long abb
> > > + output_data_to_object_file (1, 0);
> > > + output_data_to_object_file (1, 0);
> >
> > So this basically renames dw2_asm_output_data to
> > output_data_to_object_file and similarly for other output functions.
> >
> > What would be main problems of making dw2_asm_* functions to do the
> > r
> On 1/21/21 9:25 AM, Richard Biener wrote:
> > On Wed, Jan 20, 2021 at 5:25 PM Martin Liška wrote:
> > >
> > > On 1/20/21 5:00 PM, Jan Hubicka wrote:
> > > > There are two thinks that I would like to discuss first
> > > >1) I think the
>
> Plus I'm planning to send one more patch that will ignore time profile when
> -fprofile-reproduce != serial.
Why you need to disable time profiling?
Honza
istina ; Martin Jambor
> > ; Richard Sandiford ;
> > luoxhu via Gcc-patches
> > Cc: seg...@kernel.crashing.org; wschm...@linux.ibm.com;
> > li...@gcc.gnu.org; Jan Hubicka ; dje@gmail.com
> > Subject: Re: [PATCH] ipa-inline: Improve growth accumulation for recursive
> > cal
> On 1/21/21 3:01 PM, Jan Hubicka wrote:
> > >
> > > Plus I'm planning to send one more patch that will ignore time profile
> > > when -fprofile-reproduce != serial.
> >
> > Why you need to disable time profiling?
>
> Because you can hav
> On 1/21/21 7:45 PM, Jan Hubicka wrote:
> > For this reason we merge by computing average, which is stable over
> > reordering the indices
>
> Looking at the implementation, we merge by using minimum value:
>
> /* Time profiles are merged so that minimum from a
> diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
> index b401f0817a3..042c03d819e 100644
> --- a/gcc/cgraphunit.c
> +++ b/gcc/cgraphunit.c
> @@ -1961,8 +1961,9 @@ expand_all_functions (void)
>}
>
>/* First output functions with time profile in specified order. */
> - qsort (tp_fir
> > This will become more common problem for multithreaded profiles where
> > one needs to annotate locking and busy waiting loops in them for example
> > (or the scheduler responsible for executing paralle tasks).
> >
> > I can see this to be practically achievable but we probably want to
> > pro
> On Thu, 2021-01-14 at 15:00 +0100, Jan Hubicka wrote:
> > > On Wed, Jan 13, 2021 at 11:04 PM David Malcolm via Gcc-patches
> > > wrote:
> > > > gimple.h has this comment for gimple's uid field:
> > > >
> > > > /* UID of this state
> On 1/21/21 8:03 PM, Jan Hubicka wrote:
> > What exactly is suggested?
>
> This one.
>
> Martin
> From 22bbf5342f2b73fad6c0286541bba6699c617380 Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Thu, 21 Jan 2021 09:02:31 +0100
> Subject: [PATCH 1/2] Resto
> On 1/21/21 2:46 PM, Jan Hubicka wrote:
> > I think easy way to get users of this option is to make profile not
> > reproducible by default and modify packages to use right reproducibility
> > option when reproducible builds are intended. It is not feature that
> >
> On 1/21/21 8:13 PM, Martin Liška wrote:
> > Yes, it will be a better place!
> >
> > Martin
>
> There's an updated version of the patch.
>
> Thoughts?
> Thanks,
> Martin
> From 0be300d1d69e98624f7be5b54931126965f1436e Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Fri, 22 Jan 2021 14:0
> Hello.
>
> AS mentioned here, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461#c25, I
> like
> what Richard suggested. So instead of usage of malloc, we should use mmap
> memory
> chunks that serve as a memory pool for struct gcov_kvp.
>
> Malloc is used as a fallback when mmap is not avail
> diff --git a/Makefile.in b/Makefile.in
> index 247cb9c8711..03785200dc7 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -565,7 +565,7 @@ STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
> STAGEtrain_CFLAGS = $(filter-out -fchecking=1,$(STAGE3_CFLAGS))
> STAGEtrain_TFLAGS = $(filter-out -fchecking=1,$
> On 1/22/21 2:38 PM, Jan Hubicka wrote:
> > This looks like reasonable solution for Linux (i was thinking of it too)
> > but I wonder what about setups w/o mmap support, like mingw32?
>
> The code still uses malloc approach then.
>
> > I think we need some fallb
>
> I remember we had issues with streaming running in parallel with
> threads. Can't we get here corruption without atomic updates of nndoes
> and the next pointer?
>
> I also remember that these parlalel updates was pretty bad, because if
> you have multithreaded concurent update of very frequ
> On Fri, Jan 22, 2021 at 2:42 PM Martin Liška wrote:
> >
> > On 1/22/21 2:38 PM, Jan Hubicka wrote:
> > > This looks like reasonable solution for Linux (i was thinking of it too)
> > > but I wonder what about setups w/o mmap support, like mingw32?
> >
>
> > It is definitly doable (gcov machinery is quite flexible WRT having more
> > types of counters).
>
> Yes, that would introduce back the dropped TOPN counters which I intentionally
> dropped.
We could bring back topn counters or the easier dominating vlaue ones
and add command line option. Ho
> >
> > I would make this go in separately from the feature itself (it is build
> > machinery change).
>
> All right.
>
> > Especially since you say it does not reach
> > reproducibility anyway until we patch hashtables?
>
> Yep, I'm testing a patch that should improve the reproducible build.
>
> gcc/ChangeLog:
>
> PR gcov-profile/98739
> * common.opt: Add missing sign symbol.
> * value-prof.c (get_nth_most_common_value): Restore handling
> of PROFILE_REPRODUCIBILITY_PARALLEL_RUNS and
> PROFILE_REPRODUCIBILITY_MULTITHREADED.
>
> libgcc/ChangeLog:
>
>
> I've just installed the patch.
>
> About the negative total value. Something similar can handle it:
> diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
> index df08e882dd7..ddc688509bd 100644
> --- a/libgcc/libgcov.h
> +++ b/libgcc/libgcov.h
> @@ -443,7 +443,13 @@ gcov_topn_add_value (gcov_type *
> On 1/21/21 7:40 PM, Martin Liška wrote:
> > Most of the changes are in known contexts:
>
> I've made some progress here, but still I'm unable to get a reproducible
> build.
> Now I see difference in:
>
>161/ 649: cp/decl.o: different
>180/ 649: cp/parser.o: different
>262/ 64
> On Tue, Jan 26, 2021 at 10:03:16AM +0100, Richard Biener wrote:
> > > In 4.8 and earlier we used to fold the following to 0 during GENERIC
> > > folding,
> > > but we don't do that anymore because ctor_for_folding etc. has been
> > > turned into a
> > > GIMPLE centric API, but as the testcase s
> On Tue, Jan 26, 2021 at 10:55:35AM +0100, Jan Hubicka wrote:
> > > On Tue, Jan 26, 2021 at 10:03:16AM +0100, Richard Biener wrote:
> > > > > In 4.8 and earlier we used to fold the following to 0 during GENERIC
> > > > > folding,
> > > > &
> This removes adding very expensive DF problems which we do not
> use and which somehow cause 5GB of memory to leak.
Impressive :)
>
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
>
> 2021-01-29 Richard Biener
>
> PR rtl-optimization/98863
> * config/i386/i386-featur
> On Fri, 29 Jan 2021, Jan Hubicka wrote:
>
> > > This removes adding very expensive DF problems which we do not
> > > use and which somehow cause 5GB of memory to leak.
Reading through the logs, isn't the leak just caused by tings going to
memory pool th
> From: Sergei Trofimovich
>
> Before the change RVO gimple statements were treated as local
> stores by modres analysis. But in practice RVO escapes target.
>
> 2021-01-30 Sergei Trofimovich
>
> gcc/ChangeLog:
>
> PR tree-optimization/98499
> * ipa-modref.c: treat RVO conservat
reference_vars_to_consider before re-allocating it.
> (ipa_reference_write_optimization_summary): Use vec_free
> and NULL reference_vars_to_consider.
Hi,
this is version I commited after discussion on the PR
(it makes it more explicit that reference_vars_to_consider are used
durin
> Hello.
>
> AS mentioned here, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461#c25, I
> like
> what Richard suggested. So instead of usage of malloc, we should use mmap
> memory
> chunks that serve as a memory pool for struct gcov_kvp.
>
> Malloc is used as a fallback when mmap is not avail
>
> libgcc/ChangeLog:
>
> PR gcov-profile/99105
> * libgcov-driver.c (write_top_counters): Rename to ...
> (write_topn_counters): ... this.
> (write_one_data): Pre-allocate buffer for number of items
> in the corresponding linked lists.
> * libgcov-merge.c (__g
> .../gcc.dg/tree-prof/indir-call-prof-malloc.c | 2 +-
> gcc/testsuite/gcc.dg/tree-prof/pr97461.c | 2 +-
> libgcc/libgcov-driver.c | 56 ---
> 3 files changed, 50 insertions(+), 10 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/tree-prof/indir-ca
e point to be skipped.
This is improved patch I have bootstrapped/regtested x86_64-linux and I
am collecting stats for (it should have minimal effect on overal
effectivity of modref).
Honza
gcc/ChangeLog:
2021-08-11 Jan Hubicka
Alexandre Oliva
* ipa-modref.c (modr
x86_64-linux. Comitted.
gcc/ChangeLog:
2021-08-12 Jan Hubicka
* ipa-split.c (consider_split): Fix condition testing void functions.
diff --git a/gcc/ipa-split.c b/gcc/ipa-split.c
index 5e918ee3fbf..c68577d04a9 100644
--- a/gcc/ipa-split.c
+++ b/gcc/ipa-split.c
@@ -546,8 +546,9
02 queries
pt_solutions_intersect: 1391917 disambiguations, 14665265 queries
I think it is mostly due to better heandling of EAF_NODIRECTESCAPE.
Honza
gcc/ChangeLog:
2021-08-12 Jan Hubicka
* ipa-modref.c (dump_eaf_flags): Dump EAF_NOREAD.
(implicit_const_eaf_flags, implicit_pure
> Hello.
>
> Right now, target_clone pass complains when a target_clone function is an
> alias.
> That happens when localalias is created by callgraph. I think we should not
> create
> such aliases as we won't benefit much from it in case of target_clones.
>
> Patch can bootstrap on x86_64-linu
> Hi.
>
> This is a first part fixing the PR. It makes sense making "naked" functions
> "noipa".
> What's missing is IPA MOD pass support where the pass should not optimize fns
> with "noipa" attributes.
>
> @Honza: Can you please implement that?
Hmm, I had patch for that somewhere, will do tha
> Hi.
>
> We already have a IPA modref debug counter, but it's only used in
> tree-ssa-alias,
> which is only a part of what IPA modref does. I used the dbg counter in
> isolation
> of PR101949.
>
> Ready for master?
OK,
thanks!
Honza
>
> gcc/ChangeLog:
>
> * dbgcnt.def (DEBUG_COUNTER)
> Hello.
>
> As showed in the PR, returning (EAF_NOCLOBBER | EAF_NOESCAPE) for an argument
> that is a function pointer is problematic. Doing such a function call is a
> clobber.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Ma
> Good hint. I added hash based on object file name (I don't want to handle
> proper string escaping) and -frandom-seed.
>
> What do you think about the patch?
Sorry for taking so long - I remember I was sending reply earlier but it
seems I only wrote it and never sent.
> Thanks,
> Martin
> From
>
> for gcc/ChangeLog
>
> * ipa-modref.c (analyze_function): Skip debug stmts.
> * tree-inline.c (estimate_num_insn): Consider builtins even
> without a cgraph_node.
OK, thanks for looking into this issue!
(for mainline and release brances bit later)
> ---
> gcc/ipa-modref.c
ortant (or
can be implemented by special casing in unified code).
Honza
gcc/ChangeLog:
2021-08-22 Jan Hubicka
Martin Liska
* ipa-modref.c (analyze_ssa_name_flags): Indirect call implies
~EAF_NOCLOBBER.
gcc/testsuite/ChangeLog:
2021-08-22 Jan Hubicka
Hi,
while looking at Martin's patch I also noticed that return slots are
handled but overactively. We only care if the SSA name we analyze is
base of return slot.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
gcc/ChangeLog:
* ipa-modref.c (analyze_ssa_name_flags): Improve handli
> Hello.
>
> Thanks for working on that. But have really run the test-cases as the newly
> added test still aborts as it used to before you installed this patch?
Eh, sorry, I had earlier version of patch that did
if (gimple_call_fn (use_stmt) == name)
lattice[index].merge (
Hi,
>
> Why does it "punish" -fno-ipa-pta? It merely "punishes" modref of
> no longer claiming that we do not alter the instruction stream pointed
> to by a->foo, sth that shouldn't be very common.
For example
struct a {
void (*foo)();
void *bar;
}
fn(struct a *a)
{
a->foo();
}
With Mari
> Looks like the existing check using has_gimple_body_p isn't enough
> at LTRANS time but I need to check in_other_partition as well.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> OK?
>
> Thanks,
> Richard.
>
> 2021-08-23 Richard Biener
>
> PR ipa/97565
>
>
> Any strong opinions?
>
> Richard.
>
> 2021-08-23 Richard Biener
>
> * doc/invoke.texi (vect-inner-loop-cost-factor): Remove
> documentation.
> * params.opt (--param vect-inner-loop-cost-factor): Remove.
> * tree-vect-loop.c (_loop_vec_info::_loop_vec_info):
>
(release checking), however code that does a lot of array/fields
initialization may hit the limit easily.
gcc/ChangeLog:
2021-08-23 Jan Hubicka
* ipa-modref-tree.h (modref_access_node::range_info_useful_p):
Improve range compare.
(modref_access_node::contains): New member
> >
> > I noticed loop-doloop.c use _int version and likely_max, maybe you want
> > that here?
> >
> > est_niter = get_estimated_loop_iterations_int (loop);
> > if (est_niter == -1)
> > est_niter = get_likely_max_loop_iterations_int (loop)
>
> I think that are two different things - ge
Hi,
this patch adds logic needed to merge neighbouring accesses in ipa-modref
summaries. This helps analyzing array initializers and similar code. It is
bit of work, since it breaks the fact that modref tree makes a good lattice for
dataflow: the access ranges can be extended indefinitely. For t
>
> This patch is causing ICEs on arm:
> FAIL: g++.dg/torture/pr89303.C -O1 (internal compiler error)
> FAIL: g++.dg/torture/pr89303.C -O1 (test for excess errors)
It happens on 32bit arches only it seems. For some reason we end up
merging
access: Parm 0 param offset:12 offset:0 size:96
> On 8/26/21 10:33, Christophe Lyon via Gcc-patches wrote:
> > Can you have a look?
>
> Please create a PR for it.
I have fix, so perhaps there is no need for PR :)
I am testing the following - the problem was that try_merge_with missed
some merges because how unoredered_remove handles the vector.
Hi,
this patch makes insertion to modref access tree smarter when --param
modref-max-bases and moredref-max-refs are hit. Instead of giving up
we either give up on base alias set (make it equal to ref) or turn the
alias set to 0. This lets us to track useful info on quite large
functions, such as
>
> commit f075b8c5adcf9cb6336563c472c8d624c54184db
> Author: Jan Hubicka
> Date: Thu Aug 26 15:33:56 2021 +0200
>
> Fix off-by-one error in try_merge_with
>
> gcc/ChangeLog:
>
> * ipa-modref-tree.h (modref_ref_node::verify): New
> On Aug 22, 2021, Jan Hubicka wrote:
>
> > OK, thanks for looking into this issue!
>
> Thanks, I've finally installed it in the trunk.
>
> > It seems that analye_stmt indeed does not skip debug stmts. It is very
> > odd we got so far without hitting bu
Hi,
this should be final bit of the fancy access merging. We limit number of
accesses to 16 and on the overflow we currently just throw away the whole
table. This patch instead looks for closest pair of entries in the table and
merge them (losing some precision). This is not very often during no
> On Mon, Sep 14, 2020 at 09:31:52AM +0200, Richard Biener wrote:
> > But does it make any noticable difference in the end? Using
>
> Yes.
>
> > bp_pack_var_len_unsigned just causes us to [u]leb encode half-bytes
> > rather than full bytes. Using hardcoded 8/16/32/64 makes it still
> > dependen
Hi,
this patch fixes rather old bug that prevents ipa-reference to wrok
across partition boundary. What happens is that availability code
thinks that function is not available and thus we ignore the summary we
stream.
Bootstrapped/regtested x86_64-linux. Comitted.
I have a testcase that I will s
with incrementally.
Bootstrapped/regtested x86_64-linux including ada, d and go. I plan to commit
it after bit more testing tomorrow.
2020-09-19 David Cepelik
Jan Hubicka
* Makefile.in: Add ipa-modref.c and ipa-modref-tree.c.
* alias.c: (reference_alias_ptr_type_1
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
> 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 impro
> 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 s
> >
> > 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 *)&am + 24B] = {};
Hi,
these testcases now fails because they contains an invalid type puning
that happens via const VALUE_TYPE *v pointer. Since the check function
is noinline, modref is needed to trigger the wrong code.
I think it is easiest to fix it by no-strict-aliasing.
Regtested x86_64-linux, OK?
* g
> 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,
> > > >
> > (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 --param=ggc-mi
> On Tue, Sep 22, 2020 at 10:13:46AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > --- gcc/params.opt.jj 2020-09-21 11:15:53.816516949 +0200
> > +++ gcc/params.opt 2020-09-22 09:59:37.121115589 +0200
> > @@ -882,7 +882,7 @@ Maximum number of refs stored in each mo
> >
> > -param=modref-
>
> 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 inves
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 test
> 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-modr
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.
* ipa-modref-tr
> 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[
> 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:
> > > nonrepresentabl
>
> 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
> a
Hi,
this is first of cleanup patches for mod-ref interfaces. It removes code
duplication between ipa-pure-const and ipa-modref that both wants to check
whether given memory access can interfere with memory acesses before function
call or after function return.
I pulled the logic out to refs_local
> > +/* Return true if T is a pointer pointing to memory location that is local
> > + for the function (that means, dead after return) or read-only. */
> > +
> > +bool
> > +points_to_local_or_readonly_memory_p (tree t)
> > +{
> > + /*if (!POINTER_TYPE_P (TREE_TYPE (t)))
> > +return false; *
> I see the following UBSAN errors:
>
> ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr96806.C
> -std=c++11 -O -fipa-cp -fipa-cp-clone --param=ipa-cp-max-recursive-depth=94
> --param=logical-op-non-short-circuit=0
> /home/marxin/Programming/gcc2/gcc/ipa-cp.c:3866:20: runtime
> On Wed, Sep 23, 2020 at 11:55 AM Jan Hubicka wrote:
> >
> > > > +/* Return true if T is a pointer pointing to memory location that is
> > > > local
> > > > + for the function (that means, dead after retu
1 - 100 of 5201 matches
Mail list logo
