> Hi,
> In function ref_maybe_used_by_call_p_1, there is below code snippet
> /* The following builtins do not read from memory. */
> case BUILT_IN_FREE:
> ...
>return false;
>
> I am confused because free function does read from (and even write to)
>
> ==5404== Conditional jump or move depends on uninitialised value(s)
> ==5404== at 0x25DAAD7: incorporate_penalties (ipa-cp.c:3282)
> ==5404== by 0x25DAAD7: good_cloning_opportunity_p(cgraph_node*, sreal,
> sreal, profile_count, int) (ipa-cp.c:3340)
I looked at this one (since it is in
> >
> > diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
> > index 42842d9466a..1d0c115465c 100644
> > --- a/gcc/ipa-prop.h
> > +++ b/gcc/ipa-prop.h
> > @@ -623,8 +623,8 @@ ipa_node_params::ipa_node_params ()
> > : descriptors (NULL), lattices (NULL), ipcp_orig_node (NULL),
> >known_csts (vNULL),
>
> I can confirm that zero-initializing node_is_self_scc prevents the
> uninitialised use warnings in incorporate_penalties (ipa-cp.c:3282)
Great, I will commit the patch. But I also wonder if there are any
remaining unitialized warnings in ipa code?
Honza
>
> Thanks,
> Zdenek
>
>
> Hello,
>
> I have a SIMPLE_IPA_PASS that parses the program multiple times. As it
> parses gimple, it builds a data structure with the information
> collected that will provide some invariants to future iterations over
> the program.
>
> I was looking into adding a new feature that would take
> Hi,
>
> I would like to use ipa_ref in the PASS_LIST all_late_ipa_passes to query
> the statement (ref->stmt) of where a global variable is used. However, I am
> having some problems achieving this.
>
> What I do is:
>
> 1. Check that ipa_ref->referring has a body and is not inlined.
> 2.
Hi,
>
>
> > On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote:
> >
> > Ankur,
> >> I was browsing the list of submitted GSoC projects this year and the
> >> project regarding bypassing assembler when generating LTO object files
> >> caught my eye.
> > I apologize for late reply. I would be very
> Hi!
>
> On 2023-09-07T19:00:49-0400, James Hu via Gcc wrote:
> > I noticed that adding incremental LTO was a GSoC project that was not
> > claimed this cycle (
> > https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-compiler-collection-gcc).
> > I was curious about working on
> Hello,
> I am working on a project to produce the LTO object file from the compiler
> directly. So far, we have
> correctly outputted .symtab along with various .debug sections. The only
> thing remaining is to
> correctly output attribute values and their corresponding values in the
>
> Hello,
Hi,
> I have almost completed the output of relocation entries. The only thing
> that remains is to output the corresponding symbols in .symtab. In my
> current design, I store the info about relocation entry and the symbol
> name. However, the problem I am facing with this approach is
Ankur,
> I was browsing the list of submitted GSoC projects this year and the
> project regarding bypassing assembler when generating LTO object files
> caught my eye.
I apologize for late reply. I would be very happy to mentor this
project.
>
> I already have a gcc built from source (sync-ed
Hello,
We are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Paris on September 16-18, 2022. We are looking forward
to meet you again after three years!
As for the previous instances, we have setup a wiki page for
details:
https://gcc.gnu.org/wiki/cauldron2022
> On Sat, May 14, 2022 at 7:03 PM Jan Hubicka via Gcc wrote:
> >
> > Hello,
> >
> > We are pleased to invite you all to the next GNU Tools Cauldron,
> > taking place in Paris on September 16-18, 2022. We are looking forward
> > to meet you again after three
> On Tue, Jul 26, 2022 at 4:13 PM Eugene Rozenfeld via Gcc
> wrote:
> >
> > Hello GCC community.
> >
> > I started this thread on the state of AutoFDO in GCC more than a year ago.
> > Here is the first message in the thread:
> > https://gcc.gnu.org/pipermail/gcc/2021-April/235860.html
> >
> >
Hello,
> Hello,
>
> We are pleased to invite you all to the next GNU Tools Cauldron,
> taking place in Paris on September 16-18, 2022. We are looking forward
> to meet you again after three years!
>
> As for the previous instances, we have setup a wiki page for
> details:
>
>
Hi,
>
> It seems to me that the most correct fix is to add to
> walk_polymorphic_call_targets a check that the obtained possible target
> is still referenced_from_vtable_p() - because the alias that was
> originally a virtual function is referenced from a vtable that at this
> point is also known
Hello,
> Hi! I've been interested in compiler development for a while, and would love
> to
> work with any of you as part of GSoC, or even just as a side-project on my
> own.
>
> I'm an 18 year-old student going into university next year with a passion for
> all
> things open source and low
Martin,
> Hello GCC community.
>
> After spending last decade (including my diploma thesis even more)
> of my life working on GCC, I decided to leave the project and try
> a different job. I would like to thank all the community members I had
> change to interact with, I learned so much and
Hello,
> While going through the patch and simple-object.c I understood that the
> file simple-object.c is used to handle the object file format. However,
> this file does not contain all the architecture information required for
> LTO object files, so the workaround used in the patch is to read
Hello,
> Thanks, Jan for the Reply! I have completed a draft proposal for this
> project. I will appreciate your's, Martin's, or anybody else feedback on
> the same.
> Here is the link to my proposal
> https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing
> Thanks to Martin, Honza, and Théo for your feedback. I have incorporated
> almost all of it, updated my proposal accordingly, and submitted it.
> Regarding grammar errors, I have fixed many, but there may still be some
> left (I could be better at grammar, to be honest :( ).
I could be better
> Hi,
>
> I have added the patch (
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623379.html ) on the
> devel/bypass-asm branch.
> Although I am able to build using the --disable-bootstrap option but while
> doing a bootstrapped build, I am getting these errors ( as warnings while
> doing
> Hi Everyone,
Hello,
> I am working on the GSOC project "Bypass Assembler when generating LTO
> object files." My mentors and I have decided to work on the ELF files
> first, so I will add .symtab along with the symbol __gnu_lto_slim to
> the ELF file as a first step.
> When I was going through
> > If I comment it out as above patch, then O3/PGO can get 16% and 12%
> > performance
> > improvement compared to O2 on x86.
> >
> > O2 O3 PGO
> > cycles 2,497,674,824 2,104,993,224 2,199,753,593
> > instructions
> Hi,
Hi,
I am sorry for late reaction.
> I am working on the GSOC project "Bypass Assembler when generating LTO
> object files." So as a first step, I am adding .symtab along with
> __gnu_lto_slim symbol into it so that at a later stage, it can be
> recognized that this object file has been
> > > +simple_object_write_add_symbol(simple_object_write *sobj, const char
> > *name,
> > > +size_t size, unsigned int align);
> >
> > Symbols has much more properties in addition to sizes and alignments.
> > We will eventually need to get dwarf writting, so we will need to
> > support them.
> On Dez 01 2023, Richard Biener via Gcc wrote:
>
> > Hmm, so why's it then referenced and not "GCed"?
>
> This has nothing to do with garbage collection. It's just the way
> libgcc avoids having too many source files. It would be exactly the
> same if every function were in its own file.
THe
> > The problem is testing. If gcc would re-number the basic blocks then
> > tests comparing hard-coded test paths would break, even though the path
> > coverage itself would be just fine (and presumably the change to the
> > basic block indices), which would add an unreasonable maintenance
> >
Hello,
we are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Prague, Czech Republic, on September 14-16, 2024.
As for the previous instances, we have setup a wiki page for
details:
https://gcc.gnu.org/wiki/cauldron2024
Like last year, we are having to charge
Hi,
I managed to commit an unrelatd change that was sitting my tree that
breaks bootstrap. I have reverted it now and checked bootstrap gets
past the failing point (still waiting for full bootstrap to
finish at x86_64-linux).
Honza
gcc/ChangeLog:
* ipa-modref-tree.h (struct
>
> Fortran has for a long time 'character(len=5), allocatable" or
> "character(len=*)". In the first case, the "5" can be ignored as both
> caller and callee know the length. In the second case, the length is
> determined by the argument, but it cannot be changed.
>
> Since a not-that-short
Hi,
>
> FAIL: gfortran.dg/deferred_type_param_6.f90 -O1 execution test
> FAIL: gfortran.dg/deferred_type_param_6.f90 -Os execution test
Sorry for the breakage. This time it seems like bug in Fortran FE
which was previously latent:
__attribute__((fn spec (". . R ")))
void subfunc
Hi,
this patch fixes two issues I noticed while proofreading the code.
First is that I have added conditional around setting of nonlocal and
escaped flags (since they may be set from solver) while keeping the
variable in assignment that is confusing.
Second is that we still do not set pt in the
Hi,
while updating compute_points_to_sets I missed that the code not only
sets the nonlocal/escaped flags but also initializes pt. With my
previous change if uses_global_memory is false pt is not updated
correctly which may lead to wrong code.
This is fixed by the following patch I comitted to
> Hi,
>
> PR 103449 revealed that when I was storing result of one hash_map
> lookup into another entry in the hash_map, I was still accessing the
> entry in the table, which meanwhile could get reallocated, making the
> accesses invalid-after-free.
>
> Fixed with the following, which also
> On Mon, Dec 6, 2021 at 4:03 PM Richard Biener
> wrote:
> >
> > On Mon, Dec 6, 2021 at 11:10 AM Richard Sandiford
> > wrote:
> > >
> > > Richard Biener writes:
> > > > On Sun, Dec 5, 2021 at 10:59 PM Richard Sandiford via Gcc-patches
> > > > wrote:
> > > >>
> > > >> When compiling an
Hi,
when adding support for static chain and return slot flags I forgot to update
early exit condition in modref_merge_call_site_flags. This yields to wrong
code as demonstrated by the Fortran testcase attached to PR (which I hope
someone will help me to turn into testuite one).
Hi,
in the testcase we fail to analyze SSA name because flag do_dataflow is set
and thus triggers early exist in analyze_ssa_name. Fixed by disabling
early exits when handling deferred names.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
2021-12-20 Jan Hubicka
PR
> Hi!
>
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html
> symtab: Fold == to 0 if folding_initializer [PR94716]
>
> patch. Thanks.
OK.
Note that with LTO partitioning it may happen that alias is defined in
one partition but used in another. We
> - /* Proportion second loop's bb counts except those dominated by false
> -branch to avoid drop 1s down. */
> - basic_block bbi_copy = get_bb_copy (false_edge->dest);
> - bbs2 = get_loop_body (loop2);
> - for (j = 0; j < loop2->num_nodes; j++)
> - if (bbs2[j] ==
> >
> > From: Xiong Hu Luo
> >
> > gcc/ChangeLog:
> >
> > * loop-invariant.c (find_invariants_bb): Check profile count
> > before motion.
> > (find_invariants_body): Add argument.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/loop-invariant-2.c: New.
OK,
thanks!
Honza
This is bit modified patch I am testing. I added pre-computation of the
number of accesses, enabled the path for const functions (in case they
have memory operand), initialized alias sets and clarified the logic
around every_* and global_memory_accesses
PR tree-optimization/103168
> (The -fno-semantic-interposition thing is probably the biggest performance gap
> between gcc -fpic and clang -fpic.)
Yep, it is often confusing to users (who do not understand what ELF
interposition is) that clang and gcc disagree on default flags here.
Recently -Ofast was extended to imply
Hi,
on exchange2 benchamrk we miss some useful propagation because modref gives
up very early on analyzing accesses through pointers. For example in
int test (int *a)
{
int i;
for (i=0; a[i];i++);
return i+a[i];
}
We are not able to determine that a[i] accesses are relative to a.
This is
Hi,
this testcase needs -fno-ipa-modref becuase otherwise it hits the issue
that complete loop unrolling leaves somewhat mismatched profile.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/testsuite/ChangeLog:
2021-11-21 Jan Hubicka
PR ipa/103264
*
Hi,
testcase modref-dse-4.c and modref-dse-5.c fails on some targets because they
depend on store merging. What really happens is that without store merging
we produce for kill_me combined write that is ao_ref with offset=0, size=32
and max_size=96. We have size != max_size becaue we do ont
> On Tue, Nov 23, 2021 at 6:52 AM Xionghu Luo wrote:
> >
> > r12-4526 cancelled jump thread path rotates loop. It exposes a issue in
> > profile-estimate when predict_extra_loop_exits, outer loop's exit edge
> > is marked as inner loop's extra loop exit and set with incorrect
> > prediction, then
The patch passed testing on x86_64-linux.
Hi,
while looking into the PR I also improved debug output in ipa-modref and
fixed ignore_nondeterminism predicate: looping pures and cont are still
deterministic.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
2021-11-21 Jan Hubicka
PR ipa/103052
*
Hi,
The testcase shows situation where there is non-trivial cycle in the callgraph
involving a noreturn call. This cycle is important for const function discovery
but not important for pure. IPA pure const uses same strongly connected
components for both propagations which makes it to get
Hi,
Modref tree template stores its own copy of param_moderf_max_bases, *_max_refs
and *_max_accesses values. This was done before we had per-function limits and
even back then it was bit dubious, so this patch removes it.
Bootstrapped/regtested x86_64-linux, will commit it shortly.
Honza
Needs -O2 -floop-unroll-and-jam --param early-inlining-insns=14
to fail, so I guess it may be issue with unrol-and-jam.
> > > I don't know what the guidance is on using vec in IPA passes
> > > but with respect to existing practice elsewhere, there are
> > > existing uses of vec and auto_vec with non-POD types and vec
> > > does work with them (see the vec_default_construct and
> > > vec_copy_construct templates,
> > >
> > > Isn't problem that the following code
> > >
> > >past_flags.reserve_exact (summary->arg_flags.length ());
> > >past_flags.splice (summary->arg_flags);
> > >past_retslot_flags = summary->retslot_flags;
> >
> > Aha, that makes sense.
> Hi.
>
> This is a refactoring I noticed.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * ipa-modref.c (analyze_function): Use fnode instead of repeated
> cgraph_node::get
> On 11/18/21 5:41 AM, Jan Hubicka via Gcc-patches wrote:
> > > modref_tree::merge(modref_tree*,
> > > vec*, modref_parm_map*, bool)
> > >
> > > is called with modref_parm_map chain_map;
> > >
> > > The variable has uninit
> On 11/18/21 19:22, Jan Hubicka wrote:
> > > Supported LTO compression algorithms: zlib zstd
> > > gcc version 12.0.0 2028 (experimental) (GCC)
> > > /usr/bin/ld: ./xxx.ltrans0.ltrans.o: warning: relocation against
> > > `lm_read_ctl_dict_size_n_lmclass_used' in read-only section `.text'
> >
> --- a/gcc/config/rs6000/predicates.md
> +++ b/gcc/config/rs6000/predicates.md
> @@ -1086,7 +1086,9 @@ (define_predicate "current_file_function_operand"
> (match_test "(DEFAULT_ABI != ABI_AIX || SYMBOL_REF_FUNCTION_P (op))
> && (SYMBOL_REF_LOCAL_P (op)
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * ipa-modref.c (analyze_function): Do not execute the code
> only if dump_file != NULL.
> ---
> gcc/ipa-modref.c | 14 +++---
> 1
> Supported LTO compression algorithms: zlib zstd
> gcc version 12.0.0 2028 (experimental) (GCC)
> /usr/bin/ld: ./xxx.ltrans0.ltrans.o: warning: relocation against
> `lm_read_ctl_dict_size_n_lmclass_used' in read-only section `.text'
> /usr/bin/ld: ./xxx.ltrans0.ltrans.o: relocation
> On Thu, Nov 18, 2021 at 2:07 PM Jan Hubicka wrote:
> >
> > > --- a/gcc/config/rs6000/predicates.md
> > > +++ b/gcc/config/rs6000/predicates.md
> > > @@ -1086,7 +1086,9 @@ (define_predicate "current_file_function_operand"
> > > (match_test "(DEFAULT_ABI != ABI_AIX ||
> Hi,
>
> On Fri, Nov 12 2021, Martin Jambor wrote:
> > Hi,
> >
> > using -fno-semantic-interposition has been reported by various people
> > to bring about considerable speed up at the cost of strict compliance
> > to the ELF symbol interposition rules See for example
> >
Hi,
this patch adds the IPA part of modref kill analysis. It just copies of
what local code did alrady. I did not manage to push out all patches
for modref I planned and I will wait for next stage1. This one however
I would like to push since it is quite simple and it makes no sense to
leave
Hi,
this patch fixes bug in streaming in modref access tree that now cause a failure
of gamess benchmark. The bug is quite old (present in GCC11 release) but it
needs quite interesting series of events to manifest. In particular
1) At lto time ISRA turns some parameters passed by reference to
> > Hi,
> >
> > On Fri, Nov 12 2021, Martin Jambor wrote:
> > > Hi,
> > >
> > > using -fno-semantic-interposition has been reported by various people
> > > to bring about considerable speed up at the cost of strict compliance
> > > to the ELF symbol interposition rules See for example
> > >
Hi,
this patch removes test for function not having call chain guarding
modref use in ref_maybe_used_by_call_p_1. It never made sense since
modref treats call chain accesses explicitly. It was however copied from
earlier check for ECF_CONST (which seems dubious too, but I would like
to discuss it
Hi,
I wrote script comparing modref pure/const discovery with ipa-pure-const
and found mistakes on both ends. I fixed ipa-pure-const in previous two
patches.
This plugs the case where modref was too optimistic in handling looping
pure consts which were previously missed due to early exits on
> On Thu, Nov 11, 2021 at 2:41 PM Jan Hubicka via Gcc-patches
> wrote:
> >
> > Hi,
> > We make self recursive functions as looping of fear of endless recursion.
> > This is done correctly for local pure/const and for non-trivial SCCs in
> > callgraph, b
Hi,
this patch enables the pure/const discovery in modref, so we newly can handle
some extra cases, for example:
struct a {int a,b,c;};
__attribute__ ((noinline))
int init (struct a *a)
{
a->a=1;
a->b=2;
a->c=3;
}
int const_fn ()
{
struct a a;
init ();
return a.a + a.b + a.c;
}
Here
Hi,
this patch fixes ipa-pure-const handling of noreturn flags. It is not
safe to set it for interposable symbols and we should also set it for
aliases (just like we do for other flags). This patch merely copies other
flag handling and implements it here.
Bootstrapped/regtested x86_64-linux,
> > Now afunc writes to __var_5_mma only indirectly so I think it is correct
> > that
> > we optimize the conditional out.
> >
> > Easy fix would be to add -fno-ipa-modref, but perhaps someone with
> > better understanding of Fortran would help me to improve the testcase so
> > the calls to
> > Hmm, I could try to do this, but possibly incrementally?
>
> You mean handle a argument specially for unknown param offset?
> Yeah, I guess so.
I think it is also pointer that was allocated and is going to be
freed...
>
> > Basically I want to have
> >
> > foo ()
> > decl = {}
> >
> > To
Hi,
We make self recursive functions as looping of fear of endless recursion.
This is done correctly for local pure/const and for non-trivial SCCs in
callgraph, but for trivial SCCs we miss the flag.
I think it is bad decision since infinite recursion will run out of stack,
but changing it upsets
The sanity check verifies that functions acessing parameter indirectly
also reads the parameter (otherwise the indirect reference can not
happen). This patch moves the check earlier and removes some overactive
flag cleaning on function call boundary which introduces the non-sential
situation. I
Hi,
the testcase tests for out of bound accesses warnings and with ipa-modref
improvements
it now triggers a new warning:
/aux/hubicka/trunk-git/gcc/testsuite/gfortran.dg/do_subscript_3.f90:11:9:
Warning: (1)
/aux/hubicka/trunk-git/gcc/testsuite/gfortran.dg/do_subscript_3.f90:10:47:
Warning:
Hi,
this patch fixes wrong compare in remap_params which triggers a wrong
code with my followup patch. This needs backporting to gcc11 as well
which I plan to do tomorrow.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
* ipa-modref-tree.h (modref_tree::remap_params): Fix
Hi,
this patch makes modref to also collect info whether function has side
effects. This allows pure/const function detection and also handling
functions which do store some memory in similar way as we handle
pure/consts now.
The code is symmetric to what ipa-pure-const does. Modref is actually
Hi,
this patch implements DSE using modref summaries: if function has no side
effects
besides storing to memory pointed to by its argument and if we can prove those
stores
to be dead, we can optimize out. So we handle for example:
volatile int *ptr;
struct a {
int a,b,c;
} a;
Hi,
this patch adds finalize method that is called once summary is computed
before it is used by optimizers. It adds convenient place to compute
various flags as one for DSE Richard asked for.
Bootstrapped/regtested x86_64-linux, will commit it shortly.
gcc/ChangeLog:
* ipa-modref.c
Hi,
this patch fixes ICE in sanity check of EAF flags determined: we can not
escape/clobber/return param indirectly w/o reading it.
I moved check earlier and fixed the wrong updates.
Boottrapped/regtested x86_64-linux, comitted.
Honza
PR tree-optimization/103175
* ipa-modref.c
> Hi,
>
> using -fno-semantic-interposition has been reported by various people
> to bring about considerable speed up at the cost of strict compliance
> to the ELF symbol interposition rules See for example
> https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
>
> As
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103211
>
> --- Comment #2 from Martin Liška ---
> Optimized dump differs for couple of functions in the same way:
>
> diff -u good bad
> --- good2021-11-12 17:42:36.995947103 +0100
> +++ bad 2021-11-12 17:41:56.728194961 +0100
> @@ -38,7
Hi,
this patch enables some ipa-sra on fortran by allowing signature changes on
functions
with "fn spec" attribute when ipa-modref is enabled. This is possible since
ipa-modref
knows how to preserve things we trace in fnspec and fnspec generated by fortran
forntend
are quite simple and can be
Hi,
this patch stores eaf flags from fnspec to modref summaries. THis makes
them survive signature changes and also improves IPA propagation in case
modref is not able to autodetect given flag.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
gcc/ChangeLog:
* attr-fnspec.h
Hi,
this patch moves member functions of modref_access_node from ipa-modref-tree.h
to ipa-modref-tree.c since they become long and not fitting for inlines anyway.
I also cleaned up the interface by making static insert method (which handles
inserting accesses into a vector and optimizing them)
Hi,
this patch whitelists attributes that are safe for attribute changes and
also makes access attribute dropped if function sigunature is changed.
We could do better by updating the attribute, but doing so seems to be
bit snowballing since with LTO the warnings produced seems bit confused.
We
> sheesh … EWRONGREVISEDPATCH
>
> > On 5 Nov 2021, at 13:08, Iain Sandoe wrote:
> >
> > I tried enabling this on x86-64-linux (just for interest) and it seems to
> > work
> > OK there too - but that testing revealed a thinko that didn’t show with a
> > a normal regstrap.
>
> … now with the
> > > + if (always_executed
> > > + && callee_summary->kills.length ()
> > > + && (!cfun->can_throw_non_call_exceptions
> > > + || !stmt_could_throw_p (cfun, stmt)))
> > > +{
> > > + /* Watch for self recursive updates. */
> > > + auto_vec saved_kills;
> > > +
> >
> chain_map isn't initialized.
>
> This caused:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103262
>
Hi,
this is patch I comitted that moves the misplaced hunk.
gcc/ChangeLog:
PR ipa/103262
* ipa-modref.c (merge_call_side_effects):
Works for me even with the 3 warnings.
hubicka@lomikamen:/aux/hubicka/trunk/build-lto2/gcc$ cat >tt.c
__attribute__ ((noinline,const))
infinite (int p)
{
if (p)
while (1);
return p;
}
__attribute__ ((noinline))
static void
test(int p, int *a)
{
int v = infinite (p);
if (*a && v)
Aha, but here is better example (reproduces same way).
In the former one I forgot const attribute which makes it invalid.
The testcase tests that ipa-sra is missing ECF_LOOPING_CONST_OR_PURE
check
static int
__attribute__ ((noinline))
infinite (int p)
{
if (p)
while (1);
return p;
}
> @@ -1,4 +1,3 @@
> -static int
> __attribute__ ((noinline,const))
> infinite (int p)
> {
Just for a record, it crahes with or without static int here for me :)
I run across it because the code tracking must access in ipa-sra is IMO
conceptually wrong. I noticed that because ipa-modref solves
Hi,
this is variant I comitted. Commonizing the code exposed that I can
drop memory walking when parameter passed is NULL (under assumption of
flag_delete_null_pointer_checks) since it can not point to useful
memory. This was already done in tree-ssa-alias, but not in
tree-ssa-dse. This needed
> Happens with UBSAN compiler for:
>
> $ gcc gcc/testsuite/gcc.c-torture/execute/pr71494.c -O1 -flto
> ...
> /home/marxin/Programming/gcc/gcc/ipa-modref-tree.h:550:33: runtime error: load
> of value 255, which is not a valid value for type 'bool'
> #0 0x18acc38 in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103230
>
> --- Comment #2 from Martin Liška ---
> > How do you build ubsan compiler?
>
> F="-O0 -g -fsanitize=undefined" ; make -j16 all-host -k CFLAGS="$F"
> CXXFLAGS="$F" LDFLAGS="$F"
>
> is the fastest approach.
Thanks, it is similar to what I
> On Linux/x86_64,
>
> 5aa91072e24c1e16a5ec641b48b64c9c9f199f13 is the first bad commit
> commit 5aa91072e24c1e16a5ec641b48b64c9c9f199f13
> Author: Jan Hubicka
> Date: Sat Nov 13 22:25:23 2021 +0100
>
> Implement DSE of dead functions calls storing memory.
>
> caused
>
> FAIL:
> Tested and pushed to master as obvious.
>
> Martin
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/tsan/free_race.c: Remove unnecessary -ldl.
> * c-c++-common/tsan/free_race2.c: Likewise.
Thank you, I cut it from the other testcase and forgot to remove
it. Patch is OK.
Honza
Hi,
this patch implements the cleanup suggested by Richard to move code
getting tree op from access_node and stmt to a common place. I also commonized
logic to build ao_ref. While I was on it I also replaced FOR_EACH_* by range
for since they reads better.
Bootstrapped/regtesed x86_64-linux,
> [659] %
> [659] % gcctk -O0 -w small.c
> [660] %
> [660] % gcctk -O1 -w small.c
> [661] % gcctk -O1 -w small.c
> [662] % gcctk -O1 -w small.c
> gcctk: internal compiler error: Segmentation fault signal terminated program
> cc1
> Please submit a full bug report,
> with preprocessed source if
>
> Not sure, tree-ssa-dse.c doesn't seem to handle MEM_REF with offset?
>
> VN has adjust_offsets_for_equal_base_address for this purpose. I
> agree that some common functionality like
>
> bool
> get_relative_extent_of (const ao_ref *base, const ao_ref *ref,
>
1 - 100 of 487 matches
Mail list logo
