https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #35 from Jan Hubicka ---
> Any progress on that issue?
> Just hit that issue trying to build NetworkManager
>
> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/278
I am working on a patch for symver attribute,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92454
--- Comment #2 from Jan Hubicka ---
This is the usual problem of trying to process node with no summary
attached to it. The following fixes the ICE, but I am not sure if there
is a cleaner approach.
Martin, i suppose the issue here is with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92279
--- Comment #4 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92279
>
> --- Comment #3 from Martin Liška ---
> Created attachment 47208
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47208=edit
> Reproducer
>
> So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92406
--- Comment #6 from Jan Hubicka ---
> > Hi,
> > does this patch fix the problem?
> > Honza
>
> Yes, it fixed the issue.
Great, thanks. I was overzealous here with getting rid of get_create :)
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92394
--- Comment #5 from Jan Hubicka ---
> I don't like making operand_equal_p deviate more and more from "GENERIC"
> syntactic compare to semantic one as "lossy" as GIMPLE.
What would be a preferred solution here then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91576
--- Comment #10 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91576
probably just need -fno-inline-functions and --param inline-insns-auto-O2= to reproduce again?
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92037
--- Comment #5 from Jan Hubicka ---
It is lifetime dse issue in symbol table construction. I am testing
* cgraph.c (symbol_table_test::symbol_table_test): Use ggc_alloc
rather than ggc_alloc_cleared to alloc symbol table.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92037
--- Comment #4 from Jan Hubicka ---
> Started with Honza's r276469 (git mirror 047f91509cb) but that likely only
> exposed some latent issue. Given where the segfault takes place, perhaps the
> symbol_table needs re-initialization in between
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92002
--- Comment #2 from Jan Hubicka ---
It is patch enabling auto-inlining at -O2, so we have another false
positive I guess. I fixed couple of them which reproduced during x86-64
bootstrap for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #28 from Jan Hubicka ---
> Thanks! That fixes the benchmark build (and the rest of SPEC builds fine with
> -flto). It also bootstraps and tests on aarch64-none-linux-gnu fine.
Thanks! My testing concluded independently so I went
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #25 from Jan Hubicka ---
> --- Comment #24 from ktkachov at gcc dot gnu.org ---
> Thanks. Unfortunately I still see the ICE building 507.cactuBSSN_r on aarch64
> with -flto in the same place:
> 995 gcc_assert (TYPE_NAME (t1)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #20 from Jan Hubicka ---
> Still seeing this today building cactuBSSN_r with -flto
Sorry for that - I had some unexpected developments after cauldron.
I am back from vacation now and will fix it ASAP.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #12 from Jan Hubicka ---
> Created attachment 46765
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46765=edit
> clear TYPE_NAME in free_lang_data for anonymous types
>
> Perhaps like this?
It seems that this will disable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140
--- Comment #14 from Jan Hubicka ---
> @Honza: Can we close this?
Array simplification is still disabled - we need to figure how how to
represent them...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #10 from Jan Hubicka ---
> >
> > They aren't in the anonymous namespace, but they are themselves anonymous,
> > so they have no linkage. The standard says,
> >
> > A type without linkage shall not be used as the type of a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #7 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
>
> --- Comment #5 from Martin Liška ---
> (In reply to Jan Hubicka from comment #3)
> > Author: hubicka
> > Date: Mon Jul 29 08:18:38 2019
> > New
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91176
--- Comment #7 from Jan Hubicka ---
> FWIW I don't think it was a latent bug though. Previously all we did
> with debug insns was estimate their size and speed, which are guaranteed
> to come back as zero and thus have no effect. The reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91176
--- Comment #5 from Jan Hubicka ---
I suppose it is previously latent problem that we do not skip debug
statements. Does something like this help?
Index: ipa-fnsummary.c
===
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027
--- Comment #3 from Jan Hubicka ---
Hi,
this patch triggers another confusion in ipa-devirt.
It tries to build type inheritnace graph but since D frotnend produces
only functions with DECL_VIRTUAL but no BINFOs and other things it
segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027
--- Comment #2 from Jan Hubicka ---
Hi,
the reason is that type "struct C264" has DECL_ASSEMBLER_NAME (TYPE_NAME
(type))
set to
which makes LTO to consider this type to be C++ type conforming ODR
rule.
I am not really fluent with d. Does d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91006
--- Comment #2 from Jan Hubicka ---
Martin,
I also guess an interesting question is why extra MEM_REF prevents
ipa-sra from considering the function argument dead?
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90990
--- Comment #8 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90990
>
> --- Comment #7 from Martin Liška ---
> So before we stream LTO byte code, we have:
>
> BEFORE:
>
> Released 0 names, 0.00%, removed 0 holes
> A::A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90990
--- Comment #6 from Jan Hubicka ---
> Tell me how and I can ;)
I think we want to know how the statement gets created
So i would just watchpoint its LHS and see when the component refs
sneeks in.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90990
--- Comment #1 from Jan Hubicka ---
Thanks. I however do not know why we do not like component refs in
clobbers. It simply says that we are killing part of a structure?
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90978
--- Comment #3 from Jan Hubicka ---
> Guess this is https://gcc.gnu.org/ml/gcc-patches/2010-06/msg00410.html but the
> gcc_unreachable () calls weren't in the patch posted to gcc-patches.
It indeed seems like debugging session leftover. Given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #30 from Jan Hubicka ---
Hi,
this patch makes Fortran logicals to become C unsigned types of
corresponding size. I think it is better than making them signed
because the globbing will affect aliasing within Fortran programs as
well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873
--- Comment #9 from Jan Hubicka ---
Hi,
I am testing rather obvious fix
* tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Fix TMR check.
Index: tree-ssa-alias.c
===
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889
--- Comment #9 from Jan Hubicka ---
> The gcc_unreachable in ipcp_verify_propagated_values gets tripped over
> if there is a TOP lattice in any of the IPA-CP scalar constant
> propagation lattices after the propagation.
>
> All non-local nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889
--- Comment #5 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889
>
> Eric Botcazou changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90720
--- Comment #2 from Jan Hubicka ---
> I get the same failure on Linux/x86_64 when compiling/linking with
> -fno-use-linker-plugin.
>
> This is the same behaviour as in PR lto/89884.
>
> It seems quite bad that gcc silently creates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #27 from Jan Hubicka ---
>
> I think that's reasonably easy to do for LTO. We'd want to keep
> the default boolean_type_node size BOOLEAN_TYPEs separate but
> can glob larger ones with integer types in the canonical type
> merging.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #23 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
>
> --- Comment #21 from Thomas Koenig ---
> (In reply to Jan Hubicka from comment #20)
> > OK, the mismatched declaration types are:
> > void (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #14 from Jan Hubicka ---
>
> Yeah, I do remember this. I think we settled on the above
> (previously you had dim[7] in the library I think) to be
> compatible. Still a C simple testcase complains:
>
> typedef struct { int ndim;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90303
--- Comment #5 from Jan Hubicka ---
I see, i suppose we may lose some optimizations in early opts because of
this but your patch is safe and I don't think the missed optimizations
are very important (if they are we should avoid having structural
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90303
--- Comment #3 from Jan Hubicka ---
> This comes from build_type_attribute_qual_variant:
> 1159 if (ntype != dtype)
> 1160/* This variant was already in the hash table, don't mess with
> 1161 TYPE_CANONICAL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #28 from Jan Hubicka ---
> The recent regression is we no longer throw them away plentiful during CFG
> cleanup and now they pile up during inlining.
>
> I agree full DCE with liveness will be expensive for usually little gain. Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #10 from Jan Hubicka ---
Hi,
the file was too large for bugzilla
so I uploaded it to
http://www.ucw.cz/~hubicka/Unified_cpp_dom_events0-8.ii.xz
and posted link in comment #2 :)
The agressive variant helps (I did not try to other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87554
--- Comment #11 from Jan Hubicka ---
> > The constructor indeed looks broken to me: it should not have naked
> > var_decl. So I am changing component to C++
>
> I agree that the C++ front end is wrong here, but I also wonder why cgraph is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924
--- Comment #4 from Jan Hubicka ---
And to answer the question about why GCC produces more code, it is
actually speculative devirtualization of the call. GCC determines
the most likely target and inlines it.
foo_virtual(Aint*):
# this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89692
--- Comment #6 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89692
>
> --- Comment #5 from Jakub Jelinek ---
> There is:
> fld_worklist_push (TYPE_MAIN_VARIANT (t), fld);
> /* Do not walk TYPE_NEXT_VARIANT.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330
--- Comment #5 from Jan Hubicka ---
> Let me see if I can add the respective usefulness test to the code
> deciding to speculate.
I see, it is mine, sorry for blaming you :)
One alternative would be also to put the indirect part of pseculative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89307
--- Comment #6 from Jan Hubicka ---
> Ah now, it's really doing sampling. I guess it can lead to quite some profile
> inconsistencies..
Yep, it is not coolest solution. I would not worry too much about
precision loss unless you get some weird
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525
--- Comment #17 from Jan Hubicka ---
> GNU extern inline is an extension, so is covered by whatever we define (or
> should have defined). We've never required that the out of line and inline
> definitions are the same or in any way similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194
--- Comment #11 from Jan Hubicka ---
Well, I am working on gradual improvements in the inlining decisions,
but since the PR is not very specific, we never will be perfect :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88711
--- Comment #8 from Jan Hubicka ---
> "I committed a patch that causes a regression in the Fortran
> testsuite. Clearly, the problem is with Fortran not my patch.
> I don't care about Fortran or respect those that work on the
> Fortran FE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #33 from Jan Hubicka ---
Hi,
I am testing the following fix: since we already decided about mangling
we are in fact safe to remove everything that does not have assembler
name on it.
Honza
Index: tree.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #32 from Jan Hubicka ---
> I guess we might end up streaming stuff we don't need. Can't we simply
> remove the assert? We do build the copy using the main variant type
> so this seems to be just a consistency check.
The consistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295
--- Comment #9 from Jan Hubicka ---
Note that Mark also got an crash in the wrapper
#0 0x0046527f in simple_object_elf_copy_lto_debug_sections
(sobj=, dobj=, pfn=,
err=) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88049
--- Comment #3 from Jan Hubicka ---
> > We ICE on the fact that _ZTV1aIN12_GLOBAL__N_11fEE which is vtable for
> > anonymous namespace type but it has EXTERNAL flag set.
> >
> > Jason, why this happens? I am changing type to C++: if there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88933
--- Comment #16 from Jan Hubicka ---
Looks OK. I would move delete_unreachable_blocks_update_callgraph
to tree-cfgcleanup since it is no longer inliner specific. We probably
also can sanity check that TODO_cfgcleanup is not done by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88933
--- Comment #14 from Jan Hubicka ---
> I'm currently testing this fix.
Cleanup_cfg does other transformations that makes profile to change and
statements move within bbs. Just use the unreachable block removal
infrastructure we already have and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88933
--- Comment #11 from Jan Hubicka ---
Actually, looking at Martin's patch, I guess ipcp transfrom should do
the same as inliner - do not cleanup cfg but call
delete_unreachable_blocks_update_callgraph
and then go with SSA update via TODO.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88933
--- Comment #10 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88933
>
> Martin Jambor changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936
--- Comment #7 from Jan Hubicka ---
Hi,
there is ipa_reduced_postorder that will compute SCCs and store scc
index.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900
--- Comment #2 from Jan Hubicka ---
> What a surprise, started with r267883. I'll carry on bisection with --param
> inline-unit-growth=40.
Well, I guess I can't claim that this is not gcc bug but it is the
benchmark that is broken :)
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995
--- Comment #16 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995
>
> Richard Biener changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #30 from Jan Hubicka ---
We may still want to backport to gcc 7 branch. The ICF bug at least
exists there as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #20 from Jan Hubicka ---
> Looking at our nightly spec runs, the bzip2 degradation has indeed been
> cleaned
> up. But it looks like 175.vpr degraded another 2% or so over the last couple
> days.
Knowing what inline decision matters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677
--- Comment #11 from Jan Hubicka ---
>
> I guess the FE needs the info. But yes, dropping TREE_READONLY
> for TYPE_NEEDS_CONSTRUCTION decls at some point may make sense.
>
> Generally it would be nice to know (for alias analysis) that
> an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #28 from Jan Hubicka ---
> > I already did printf debugging and indeed we only need to decide how to
> > adjust type_with_linkage_p so it returns false for all Ada types. Maybe
> > cleanest would be to add flag to TYPE_DECL which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #15 from Jan Hubicka ---
> I tested with a GCC snapshot (at r267505). I can now build all mysqld with LTO
> and get exactly one LTO warning, and it's a true positive (two Bison parsers
> that we haven't managed to untangle yet).
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677
--- Comment #9 from Jan Hubicka ---
> https://gcc.gnu
> -> You can't simply remove this flag. You could set it to true
> conservatively.
> Or we could stop marking globals that need constructing TREE_READONLY.
I see, I was under impression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #26 from Jan Hubicka ---
> Run the gnat.dg testsuite and copy-and-paste the command line from the log
> file
> without the -q option in the middle. You'll get:
>
> /home/eric/build/gcc/native/gcc/xgcc -c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702
--- Comment #6 from Jan Hubicka ---
> You could also add match.pd rules merging stuff pair-wise...
>
> How's this a regression btw?
I was comparing with GCC 6 build where inlining apparently happened.
I believe inlining happens again - I am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702
--- Comment #4 from Jan Hubicka ---
> The only pass that can do about this (at least right now) is reassoc (both 1
> and 2), which is too late for inlining. So, either teach fnsplit not to
> separate multiple if comparisons of the same variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702
--- Comment #2 from Jan Hubicka ---
> With what options? I'm getting 3 bit tests both with -O2 and -O3, both when
> using C and C++. And get that also if I rewrite the function to use a switch
> instead.
-O2 -flto and then look into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677
--- Comment #4 from Jan Hubicka ---
This drops TYPE_NEEDS_CONSTRUCTING. I checked the uses
jan@skylake:~/trunk/gcc> grep TYPE_NEEDS_CONSTRU *.c
gimplify.c: || TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (decl
print-tree.c: if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #24 from Jan Hubicka ---
> Patch needs ">>>" to be repaced by "> > >" to bootstrap, but then I get 756
> mismatches building firefox, while previously it was 1300 and before the
> rebuild_type_inheritance_graph 6273, so we are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88626
--- Comment #6 from Jan Hubicka ---
> Maybe a heuristic that gives a "bonus" for inlining a function that contains
> __builtin_constant_p (only if the argument looks like it depends on the
> function parameters?) would be easier? I don't know if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88600
--- Comment #2 from Jan Hubicka ---
> Applying the attribute to V rather than T works:
>
> template
> using V __attribute__ ((__vector_size (8))) = T;
Very cool, I did managed to work that out. Should it work the clang way
too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #14 from Jan Hubicka ---
> Yeah. Note that the debug stmt differences _might_ be explained by
> ICF in case ICF ignores debug stmts when merging. But since the
> ICF dumps are ordered differently it's hard to see actual decision
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #11 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
>
> --- Comment #10 from Richard Biener ---
> Hmm, IPA ICF dumps show differences like
>
> - false returned: 'references to virtual tables can not be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88550
--- Comment #2 from Jan Hubicka ---
Dump file produced by the linker with -fdump-ipa-cgraph --save-temps (it
may end up in /tmp) would help to at least have clue what kind of symbol
caused the crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #19 from Jan Hubicka ---
Yeap, the warnings was written at the time all C++ types had TYPE_NAMEs
and other types used IDENTIFIER_NODE. I have chnaged it for memory use
reaosns so only main variants have IDENTIFIER_NODE. Usually we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86004
--- Comment #12 from Jan Hubicka ---
Thanks a lot for looking into this. Indeed disabling the tests is
probably good idea, so the patch looks good to me. Somewhere we should
document minimal binutils release supporting incremental link...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297
--- Comment #6 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297
>
> --- Comment #5 from michael.ploujnikov at oracle dot com ---
> (In reply to Richard Biener from comment #3)
> > So before the patch we were just lucky,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88302
--- Comment #3 from Jan Hubicka ---
> The way GCC exports internal API for plugins, all functions are externally
> visible. Unless plugins are disabled, the linker receives -rdynamic and so all
> non-static functions appear in the ELF dynamic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88272
--- Comment #2 from Jan Hubicka ---
> Where do we set the cut-off? ;)
-fuser-patience=
I would cut it off for things that are obviously derived from sign of
64bit value :)) Those are most common.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
--- Comment #9 from Jan Hubicka ---
> @@ -11,7 +11,7 @@ struct test {
>
> extern struct test s;
>
> -int main1 ()
> +__attribute__((noipa)) int main1 ()
> {
>int i;
>
> We want to test the vectorizer behavior, not depend on how many
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140
--- Comment #5 from Jan Hubicka ---
> diff --git a/gcc/tree.c b/gcc/tree.c
> index 39a92464414..a39e611292a 100644
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -5201,6 +5201,15 @@ fld_process_array_type (tree t, tree t2, hash_map tree> *map,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87988
--- Comment #6 from Jan Hubicka ---
>
> Honza - can you test the effect of this patch please?
Thanks! I am just redoing the tests (rebuilding firefoxes with updated
tree), so i will do that today or tomorrow.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88112
--- Comment #3 from Jan Hubicka ---
>
> Honza? Eric?
I am not sure I fully understand the problem here, but
why we end up streaming ungimplified type at first place?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #6 from Jan Hubicka ---
I think we have separate PR for this ICE. It is the ODR violation
confusing the walk of duplicates. It needs to stop assuming that all
duplicates are same TREE_CODE of type.
I will cook up patch.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65502
--- Comment #7 from Jan Hubicka ---
> Can the bug be marked as resolved?
I think to fully resolve we still want to teach DCE to replace
pure/const destructor by clobber when removing it. This should
not be too hard to do because destructors are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #55 from Jan Hubicka ---
> Can the bug be marked as resolved?
I think with the location cache we only made this problem less visible
and for really large programs linemap still can overflow and behave
funy, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #4 from Jan Hubicka ---
ICE fixed, but lets keep the PR open to track the fact that warning is
quite confused.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #17 from Jan Hubicka ---
> I don't see the miscompilation any longer, may I close it?
Yes, it was fixed by
* tree.c (fld_type_variant): Copy canonical type.
(fld_incomplete_type_of): Check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88010
--- Comment #4 from Jan Hubicka ---
> Yep, GCC considers attributes to be part of the definition of a function for
> IPA passes. We are not consitent here (i.e. warning attributes on aliases
> counts), so it makes sense to support this (and is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #82 from Jan Hubicka ---
> > Yep, this is because they used to be arrays indexed by symbol UIDs which
> > Martin converted to hash tables. Inliner happily calls summary_get each
> > time it needs the summary. I have some patches to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #80 from Jan Hubicka ---
>
> flat perf profile:
>
> Samples: 510K of event 'instructions:p', Event count (approx.): 715615147320
>
> Overhead Samples Command Shared Object Symbol
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87885
--- Comment #3 from Jan Hubicka ---
OK, I now recall. The intend was really to have three values
- profile before pass was run (which you can see from stats of previous
pass)
- profile after pass was run
- profile after cleanups
This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87868
--- Comment #2 from Jan Hubicka ---
I am attaching testcase and patch I am lto-botstrapping now. It copies
canonical from original type which is important for us to not lose TBAA
during ealry opts as well.
typedef struct rtx_def *rtx;
typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #7 from Jan Hubicka ---
> If we have less MEM_REFs then we probably strip them because we think they
> reference equal types.
>
> I think I already told you that given that MEM_REFs use pointer types
> to carry alignment info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87754
--- Comment #6 from Jan Hubicka ---
Hi,
this patch fixes the ICE as well as the template. I will commit it after LTO
bootstrap converges.
Honza
* ipa-devirt.c (odr_subtypes_equivalent_p): Fix recursion.
(warn_types_mismatch):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158
--- Comment #5 from Jan Hubicka ---
>
> Which is caused by --param ggc-min-heapsize=1 which is used by first
> invocation
> of the compilation. Honza, do you call ggc_collect before streaming out?
So we have IL representation diverging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615
--- Comment #7 from Jan Hubicka ---
> Looks like the IPA-CP stmt walking is still unbound?
There is also walking in ipa-fnsummary that is unbound, perhaps that is the
problem...
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375
--- Comment #8 from Jan Hubicka ---
> > This breaks Linux kernel LTO builds. I currently have a workaround
> > (disabling LTO for that file), but I don't think your "is not common"
> > argument is valid.
>
> Well, I guess pushing LTO into Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
--- Comment #6 from Jan Hubicka ---
> But this change to sreal seems very unlikely to cause that.
> Are we sure about the bisection to r263981?
Sreals are used to estimate profile which in turn may affect decision
of function splitting &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517
--- Comment #7 from Jan Hubicka ---
Hi,
I am attaching patch I am testing and also table generated by a script that
walks through individual combinations of options. The combination rules are as
follows.
I tried to take into account that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517
--- Comment #6 from Jan Hubicka ---
The problem is logic in lto-wrapper (which is mine)
/* Merge PIC options:
-fPIC + -fpic = -fpic
201 - 300 of 1190 matches
Mail list logo
