https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99835
--- Comment #2 from Jan Hubicka ---
> At -O3 the unused 'c' remains. Likely different (recursive?) inlining makes
> us
> process a cgraph cycle in different order and thus fail to elide the output
> of 'c' (it's output first at -O3).
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #5 from Jan Hubicka ---
> Btw, one solution would be to drop __always_inline__ after always-inline
> inlining
> and thus make it reliably not present for IPA inlining.
Removing it would make you to lose those errors, but we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #11 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
>
> --- Comment #10 from Richard Biener ---
> So like this.
>
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 80140757d16..447d9a920f7 100644
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #21 from Jan Hubicka ---
> FYI, I have today bootstrapped it as well in rpm build on
> {x86_64,i686,powerpc64le}-linux, both your patch and just trunk without the
> workaround I've been using before. The latter failed to bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #19 from Jan Hubicka ---
> Honza, any progress with this?
> If you want, I can test the patch too...
Sorry, it bootstrapped, so I will commit it.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #13 from Jan Hubicka ---
> And please remeasure with the AppArmor disabled.
> It may slow down each I/O-related syscall rapidly!
I tried disabling apparmor and it does not make much difference..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #12 from Jan Hubicka ---
> Ah, yeah, that will make a big difference.
> So clang is using 'make check', running a test-suite for a PGO build, right?
It uses
make check-llvm
make check-clang
and then it rebuilds whole llvm with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #9 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
>
> --- Comment #8 from Martin Liška ---
> This is what I see for GCC PGO in train stage. It's from perf top:
>
>4.33% cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #7 from Jan Hubicka ---
> > Because user apps may do funny thins with stdio such as they do with
> > malloc. Fewer library stuff we rely on, the less likely we will hit the
> > problems. So I am not sure if simply fixing i/o isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #5 from Jan Hubicka ---
> > So it effectively replaces gcov's own buffered I/O by stdio. First I am
> > not sure how safe it is (as we had a lot of fun about using malloc)
>
> Why is not safe? We use filesystem locking for .gcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96252
--- Comment #6 from Jan Hubicka ---
Thinking of it, perhaps also inliner could take a hint that it is
inlining a tail call and do not produce unnecesary copy of the
functio parameter passed by value.
More generally, mod/ref has good chance to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #3 from Jan Hubicka ---
> A small improvement can be achieved by the removal of libgcov I/O buffering:
> https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=5a17015c096012b9e43a8dd45768a8d5fb3a3aee
So it effectively replaces gcov's own
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
--- Comment #6 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
>
> --- Comment #5 from Martin Liška ---
> (In reply to Jan Hubicka from comment #3)
> > > I've just tried to reproduce it:
> > > ../configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
--- Comment #3 from Jan Hubicka ---
> I've just tried to reproduce it:
> ../configure --with-build-config=bootstrap-lto --enable-checking=release
> --disable-plugin
>
> But the build is fine for me.
On our dhcp230 (zen III machine) it works if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346
--- Comment #7 from Jan Hubicka ---
I tested yesterday this one (which makes the lifetime bit more explicit
- during propagation it is for dumps only). Sorry for not posting it
earlier. I just wanted to double check tha tleak is gone.
diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98925
--- Comment #1 from Jan Hubicka ---
> If I don't overstimate modref and alias analysis destructor should disappear
> completely in the example below (from https://gcc.gnu.org/PR98499#c4):
>
> struct string {
> char * _M_buf;
> // local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #12 from Jan Hubicka ---
> > Honza, any ideas on this?
> The comment on assert says
> /* In LTO mode we may have speculative edges set. */
> gcc_assert (in_lto_p || size_info->size == size_info->self_size);
>
> Which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #11 from Jan Hubicka ---
> Honza, any ideas on this?
The comment on assert says
/* In LTO mode we may have speculative edges set. */
gcc_assert (in_lto_p || size_info->size == size_info->self_size);
Which seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98330
--- Comment #8 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98330
>
> --- Comment #4 from Richard Biener ---
> So modref allocates a fnspec_summary for an unknown indirect call (NULL
> callee)
> but then in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98173
--- Comment #2 from Jan Hubicka ---
> PTA certainly can increase register pressure by means of more disambiguations
> and thus more store-motion or PRE. But you hardly can blame PTA for that ;)
It seems microarch specific, so it also can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172
--- Comment #5 from Jan Hubicka ---
> Hmm, but rep movsb is only fast starting with Zen3 IIRC.
Yep, I think we need to support zen1/2 well. I think we can regress
buldozers somehwat though.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172
--- Comment #4 from Jan Hubicka ---
> > What kind of updates you propose?
>
> For one thing, memcpy/memset should be expanded to REP MOVSB/STOSB, never
> MOVSL/MOVSQ.
For core cost tables we use:
/* core_cost should produce code tuned for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241
--- Comment #11 from Jan Hubicka ---
> @Marek: The callgraph checking error is correct.
> If you disable it, you will likely see duplicate assembler names in GAS. And
> that's the error that 2 symbol names clash.
Indeed, there are two lambdas,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #5 from Jan Hubicka ---
> So, shouldn't the code match what the comment says?
> /* If the call is to a replaceable operator delete and results
> from a delete expression as opposed to a direct call to
> such operator,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
--- Comment #19 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
>
> --- Comment #18 from Martin Sebor ---
> Let me explain how this works. The VLA bounds in function parameters are used
> in two ways:
> 1) in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
--- Comment #15 from Jan Hubicka ---
> I'm not sure I understand correctly what you mean by "avoiding the attribute
> for VLA types would likely also be good (are those handled in any reasonable
> way?)" As I explain in the thread at the link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97867
--- Comment #8 from Jan Hubicka ---
>
> FWIW, did you configure with --enable-host-shared ? Forgetting to enable that
> is the usual source of weird errors when building libgccjit.
I think it does not let you to build it otherwise, but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97915
--- Comment #1 from Jan Hubicka ---
Hi,
this ought to be fixed by g:0862d007b564eca8c9a48fca0e689dd3f90db828
sorry for the breakage. OBJ_TYPE_REF in obj-C frontend is odd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
--- Comment #7 from Jan Hubicka ---
> Fixed d7ab349c44f
Thanks, my original intention was to mostly track the fact that we do not want
to warn about fields of va_list type that is internal to compiler though
:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #11 from Jan Hubicka ---
This patch fixes the issue by making the conflict with C type sticky via
clearing the CXX bit. I checked that it recovers profiledbootstrap,
hwoever I want to look into the code tomorrow bit more to be sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #10 from Jan Hubicka ---
So I think I know what happens. It is actually the pre-existing
problem I mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559017.html
the iterator is small type consiting of two pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #15 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
>
> --- Comment #14 from Martin Sebor ---
> Created attachment 49572
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49572=edit
> Patch under
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #9 from Jan Hubicka ---
The checking enabled build ICEs for me at same spot as for you
0x01475505 <+165>: punpcklqdq %xmm2,%xmm3
0x01475509 <+169>: movaps %xmm3,0x30(%rsp)
0x0147550e <+174>:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #13 from Jan Hubicka ---
> I agree we should just rename default_is_empty_type to is_empty_type, export
> it, declare in tree.h and use it instead that complicated test. TYPE_EMPTY_P
> isn't something tree-ssa-uninit.c should care
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #11 from Jan Hubicka ---
> Note i686-linux bootstrap is still broken in r11-5062 - the PR97853 error.
Yes, as discussed earlier (but perhaps lost in other coments) we need
fix for the targetm.calls.empty_record_p (type) divergence.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #7 from Jan Hubicka ---
It seems to crash on quite few locaitons but always related to indirect
calls. So perhaps there is some sort of weird relation to indirect call
profiling or devirutalization...
I am going to move my build to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #4 from Jan Hubicka ---
> > Yep, I already worked out it is ipa-icf...
> > Do you have easy way to bisect what merge is causing the failure?
>
> Working on that will send details soon.
Great, thanks. In meantime I will check if I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #2 from Jan Hubicka ---
> I see a similar bootstrap failure that's with:
>
> ../configure --enable-languages=c,c++,lto --prefix=/home/marxin/bin/gcc
> --disable-multilib --without-isl --disable-libsanitizer
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97695
--- Comment #5 from Jan Hubicka ---
I see you have patch, too :)
However we do not want to copy clone info to every inline clone (since
the body is materialized just once). The problem is that in case the
offline copy is removed we move clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
--- Comment #10 from Jan Hubicka ---
> It needs to refer to the DW_TAG_formal_parameter DIEs, and only the PARM_DECLs
> map to those.
It has problem with the partitioning (if we call a callee from different
parititon) and also if the callee is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652
--- Comment #10 from Jan Hubicka ---
> > Aha, that will be the wrong jump function from ipa-cp I mentioned in
> > earlier comment. We should not believe that root is not written to as
> > we derive now from TBAA in push_8.
>
> But -fno-ipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652
--- Comment #7 from Jan Hubicka ---
> And it looks like something (inlining) inserts __builtin_unreachable () calls
> that eventually make us optimize this to an endless loop.
>
> pdt_14.f03.081i.inline:Introduced new external node
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
--- Comment #10 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
>
> --- Comment #9 from Iain Buclaw ---
> (In reply to Jan Hubicka from comment #8)
> > > Current workaround I'm using locally for the time being is to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
--- Comment #8 from Jan Hubicka ---
> Current workaround I'm using locally for the time being is to call
> thunk_info::process_early_thunks if the particular branch where this ICE
> happens is hit.
Why D frontend needs to expand the thunk early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
--- Comment #5 from Jan Hubicka ---
Hi,
this patch fixes the ICE, though I think we do have a design issue here
while producing debug info across ltrans boundary.
Martin, Jakub: as discussed on IRC it would be nice to add predicate
when the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97593
--- Comment #4 from Jan Hubicka ---
> I see.
> Can you please take care of it?
I will - as a natural punishment for cleaning this up :))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586
--- Comment #15 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586
>
> --- Comment #14 from Martin Liška ---
> (In reply to Jan Hubicka from comment #13)
> > Created attachment 49450 [details]
> > fix
> >
> > > Yes, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586
--- Comment #13 from Jan Hubicka ---
> Yes, I noticed that right now :) Please attach me the patch here.
Sorry for bogus patch. This one has chance to work.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586
--- Comment #11 from Jan Hubicka ---
> Hi,
> this is patch that moves updates to WPA time. Does it work for you?
Actually it won't help, since it updates only non-lto summary. I am
testing better patch, sorry for that.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586
--- Comment #10 from Jan Hubicka ---
Hi,
this is patch that moves updates to WPA time. Does it work for you?
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586
--- Comment #8 from Jan Hubicka ---
> So the _bfd_safe_read_leb128.constprop removes the first unused argument:
>
...
>
> But the analysis is bogus:
>
> ipa-modref: call to _bfd_safe_read_leb128.constprop/17919 does not clobber
> ref:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #54 from Jan Hubicka ---
> > It goes from 1 to 1<<63, so each of tests translates to a range.
>
> Yes, but these ranges are very large, nothing for a jump table or a bit-test.
Yep, but theoretically you can recover the decision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #52 from Jan Hubicka ---
> I don't see how can if-to-switch conversion pass help us here. It's designed
> to
> identify compact intervals. In this case we see:
>
>:
> _16 = _2 & 576460752303423488;
> if (_16 == 0)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #37 from Jan Hubicka ---
Hi,
this implements the heuristics increasing bounds for functions having
__builtin_constant_p on parameters. Note that for get_order this is
still not enough, since we increase the bound twice if hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #36 from Jan Hubicka ---
> Find attached the temporary files for net/core/skbuff.c, as it is indeed what
> initially triggered my focus on this issue. I don't expect such a function at
> all:
>
> 0cc8 :
> cc8: 48 00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #35 from Jan Hubicka ---
>
> Original asm is:
>
> __attribute__ ((noinline))
> int fls64(__u64 x)
> {
> int bitpos = -1;
> asm("bsrq %1,%q0"
> : "+r" (bitpos)
> : "rm" (x));
> return bitpos + 1;
> }
>
> There seems to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #34 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #33 from Jakub Jelinek ---
> (In reply to Jan Hubicka from comment #32)
> > get_order is a wrapper around ffs64. This can be implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #32 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #31 from Segher Boessenkool ---
> (In reply to Jan Hubicka from comment #27)
> > It is because --param inline-insns-single was reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #27 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #23 from Christophe Leroy ---
> (In reply to Jan Hubicka from comment #19)
> >
> > It is always possible to always_inline functions that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #22 from Jan Hubicka ---
> Maybe better just have a match.pd rule that would fold
> y = z binop cst;
> x = __builtin_constant_p (y);
> to
> x = __builtin_constant_p (z);
> and let SCCVN do the rest (or do it in fwprop or whatever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #20 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #19 from Jan Hubicka ---
> get_order unwinds to:
>
>[local count: 1073741824]:
> _1 = __builtin_constant_p (size_68(D));
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #17 from Jan Hubicka ---
> The following happens:
>
> get_order is called by kmalloc_large which is called in kmalloc. And kmalloc
> calls the function for larger allocations. Problem is that we eliminate all
> calls to get_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461
--- Comment #9 from Jan Hubicka ---
>
> They have the very same problem when I disable a statically pre-allocated
> buffers with -mllvm -vp-static-alloc=0:
>
> Program received signal SIGILL, Illegal instruction.
> 0x004014e6 in calloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461
--- Comment #7 from Jan Hubicka ---
> No. The only thing we support is a recursive malloc as seen in:
> ./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
>
> It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
--- Comment #10 from Jan Hubicka ---
> Unsharing the expression in the front end, before it's added to the attribute,
> prevents this ICE, but I wouldn't expect that to be necessary. From what
> little I know about how garbage collection in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97403
--- Comment #1 from Jan Hubicka ---
In general it seems to me that ancestor fuction does not serve much use:
it could be replaced by passthrough with POINTER_PLUS parameter and
handle same information.
However it may make sense to have special
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97356
--- Comment #2 from Jan Hubicka ---
> It's a known fallout..
The abort is about missed optimization - the patch was aiming to fix
wrong code issue on dealII and x264.
The testcase should work again after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #6 from Jan Hubicka ---
Hi,
the following patch should let us to pinpoint the wrong disambiguation.
With -fdump-tree-all-details we should also see the difference in dump
file.
Honza
diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #3 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
>
> --- Comment #2 from Martin Liška ---
> Created attachment 49314
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49314=edit
> Debug counter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97235
--- Comment #2 from Jan Hubicka ---
I am testing this fix. Problem is that when modref is disabled we never
relase ipa-prop datastructures.
2020-09-30 Jan Hubicka
* ipa-fnsummary.c: (pass_free_fnsummary:execute): Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #32 from Jan Hubicka ---
>
> Honza - you put the finger to it, can't we refactor things so we apply
> this update in the caller after all stmts were processed?
The clone tree issue should not be too hard to solve. We need to keep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97181
--- Comment #3 from Jan Hubicka ---
> and then inline btsum.0. Notice how the possibility of level < 0 is left
> untouched ... [I think there are no unsigned types in fortran]
>
> That said, I don't think IPA-CP/VRP do this kind of "evolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97159
--- Comment #3 from Jan Hubicka ---
Recursion is handled in normal compilation (we analyze the function and
while hitting the recursive call we skip the summary). I suppose here
the problem is missing LTO and offloading.
With LTO lto summaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #20 from Jan Hubicka ---
> OK, will do, but, at least superficially, our situation seems very similar to
> this one, so I thought it would be better to keep this one going. But, again,
> I'll open the new one as soon as I can make a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #18 from Jan Hubicka ---
> I've just subscribed to this bug because we see bug slow downs in our project
> when switching from 8.3 to 10.2 (89% slower in an important use case, 30%
> slowdown more or less across the board), without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #10 from Jan Hubicka ---
> We could also punt: when enable-link-mutex we could artificially up the job
> number for make to account for the waiting link steps. I.e. when normally -jN
> was given, the link step could be done under
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #5 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
>
> --- Comment #4 from Martin Liška ---
> > > For jobserver they are still running even though they sleep.
> > Aha, so it is extra locking mechanizm we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #3 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
>
> --- Comment #2 from Martin Liška ---
> (In reply to Jan Hubicka from comment #1)
> > > As seen
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96615
--- Comment #2 from Jan Hubicka ---
> Even not with -ffinite-loops. The reason is that finiteness of loops is
> determined by frontends now and recorded in loop->finite_p but the loop
> only appears after tail-recursion optimization. I guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #1 from Jan Hubicka ---
> As seen
> here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg
>
> each blocking linking of a GCC front-end leads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #15 from Jan Hubicka ---
> I think, this inliner change needs to be reverted. People expect -O2 to
> produce
> decently optimized binaries, and starting with gcc 10.x it doesn't deliver.
> -O3
> traditionally enabled optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #11 from Jan Hubicka ---
>
> Maybe you want to use same GCC version as phoronix used (GCC 10.2)?
OK, I will give it a try, but there are no inliner changes in gcc 10.2
compared to 10.1.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548
--- Comment #3 from Jan Hubicka ---
> I think Honza ran into this himself.
Yep, i converted code to use wide-ints. But it is nice to have short
testcase.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94472
--- Comment #9 from Jan Hubicka ---
> --- Comment #8 from Richard Biener ---
> Oh, and bugfixing requires to first understand the bug. Especially for
> performance related issues understanding what goes wrong is important.
> I see no analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #13 from Jan Hubicka ---
> Which ARM target has 16-bit int?
> I don't see INT_TYPE_SIZE nor SHORT_TYPE_SIZE defined in config/arm/*, neither
> BITS_PER_WORD, so all depends on UNITS_PER_WORD, which is 4 and thus short is
> 16-bit and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #12 from Jan Hubicka ---
> Having said that, I am not sure where to best fix this so late in the
> GCC 10 development cycle.
So the problem is that thunk is expanded on the adjusted decl but we
still keep the adjustments and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93398
--- Comment #9 from Jan Hubicka ---
Also forgot to mention, it is also quite possible that some of the small
divergences propagate themselves into differences in the histogram and
thus differences in hot/cold decisions in completely unrelated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93398
--- Comment #8 from Jan Hubicka ---
The divergence for non-randomization seems under control. But it also
seems that the divergence for randomized build is way too common to be
explained by differences in number of conflicts for hashtables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92599
--- Comment #8 from Jan Hubicka ---
I am testing the following fix. it was indeed a call_stmt hash getting
out of sync. I will need to refactor the code next stage1 as it got
quite ugly (it was not pretty before the mutli-target speculation was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93318
--- Comment #4 from Jan Hubicka ---
Ok,
I managed to reproduce the crash locally (it was not that easy)
At the point of failure the node passes verification and I suppose
problem is that the call stmt hash contains indirect call while it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
--- Comment #8 from Jan Hubicka ---
> @Richi:
>
> About the param_max_fields_for_field_sensitive:
> Do I understand it correctly that the param is used in IPA PTA for global
> variables? If so, we can't easily use Optimization keyword as the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
--- Comment #11 from Jan Hubicka ---
> xxx.localalias is gcc-generated as a noninterposable alias to xxx. But I guess
> target node returned by xxx.localalias->function_symbol() is not xxx. A simple
that ought to return xxx unless the target of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
--- Comment #7 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
>
> --- Comment #6 from fxue at gcc dot gnu.org ---
> Could you share how you build clang with PGO, and train workload?
It needs a lot of patience. If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711
--- Comment #6 from Jan Hubicka ---
With GCC9 like inliner parameters I get 308MB binary, so it is still
somehwat bigger.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92508
--- Comment #18 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92508
>
> --- Comment #17 from Martin Liška ---
> (In reply to Jan Hubicka from comment #14)
> > > Did you use bootstrap-lto-lean (and not bootstrap-lto)?
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92508
--- Comment #14 from Jan Hubicka ---
> Did you use bootstrap-lto-lean (and not bootstrap-lto)?
OK, I finally managed to reproduce and debug this.
It is triggered by fact that bootstrap-lean is not training objc and
other frontends which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92508
--- Comment #12 from Jan Hubicka ---
> It still fails for me with the current trunk:
>
> $ ../configure --prefix=/tmp/gcc/ --disable-multilib --without-isl
> --disable-libsanitizer --with-build-config=bootstrap-lto-lean
> $ make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92508
--- Comment #10 from Jan Hubicka ---
> I would like to push this issue as it breaks current lto-bootstrap-lean and I
> can't do periodic testing in openSUSE..
I tought this one is fixed by r278222 which eliminated the divergence in
roudoff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #38 from Jan Hubicka ---
Hi,
I am attaching prototype patch. It implements "symver" attribute which
can be attached to a definition such as:
hubicka@lomikamen-jh:/aux/hubicka/trunk5/build4/gcc$ cat t.c
__attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92454
--- Comment #5 from Jan Hubicka ---
> I've bootstrapped the patch and am going to commit it.
Thanks, in meanwhile I bootstrapped it too :)
101 - 200 of 1190 matches
Mail list logo
