[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

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 > --- a/

[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached

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 ignore

[Bug ipa/99835] missed optimization for dead code elimination at -O3 (vs. -O1)

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). > > Fixin

[Bug ipa/99835] missed optimization for dead code elimination at -O3 (vs. -O1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99835 --- Comment #4 from Jan Hubicka --- > But inside a SCC the order is arbitrary anyway. Note I'd only re-order SCCs > and keep the postordering the same otherwise. We compile leaf functions first to be able to propagated to their callers. In ord

[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 --- Comment #7 from Jan Hubicka --- > Yeah, and then maybe diagnose this "ODR violation". Still I think we do have this kinds of divergence (like glibcs fortification), so I am not sure we want to warn by default. > > __attribute__((__always_i

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #23 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 > > --- Comment #21 from Matthias Klose --- > building with trunk 20210330 using these parameters didn't succeed: > > make[1]: Entering directory '/packa

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #25 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 > > --- Comment #23 from Jan Hubicka --- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 > > > > --- Comment #21 from Matthias Klose --- > > buil

[Bug ipa/99309] [10/11 Regression] Segmentation fault with __builtin_constant_p usage at -O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309 --- Comment #7 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309 > > --- Comment #6 from Jakub Jelinek --- > (In reply to Jan Hubicka from comment #5) > > As discussed, I can prepare patch to make inliner to redirect > >

[Bug lto/99898] Possible LTO object incompatibility on gcc-10 branch

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99898 --- Comment #5 from Jan Hubicka --- > The LTO minor saw a bump around Sep 10 last year already so the object files > must be younger or LTO should complain. > > I'm not aware of any specific change where we forgot the bumping but there > were >

[Bug lto/99898] Possible LTO object incompatibility on gcc-10 branch

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99898 --- Comment #6 from Jan Hubicka --- > I only reacall backporting the streaming fixes early in gcc10 timeframe > (August) that was reason for the September bump. > Didn't we backport some new command line options/params breaking > streaming of opt

[Bug lto/99898] Possible LTO object incompatibility on gcc-10 branch

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99898 --- Comment #8 from Jan Hubicka --- > Any *.opt changes can break the streaming of optimization or target option > nodes. > And from experience with gcc plugins we have such changes ~ each month even on > release branches. It may make sense to ad

[Bug lto/99898] Possible LTO object incompatibility on gcc-10 branch

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99898 --- Comment #10 from Jan Hubicka --- > Many of the *.opt changes are target specific, so you'd need to test it also > across all targets, and furthermore it depends on what exactly is being > saved/restored, many options might be at the same spot

[Bug middle-end/99857] [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99857 --- Comment #4 from Jan Hubicka --- > Honza stated that he's "looking into it", > . I do just got distracted by easter. Problem has to be release_body happening mid offloading st

[Bug analyzer/98599] [11 Regression] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599 --- Comment #15 from Jan Hubicka --- > Should be fixed by the above patch, though it's more of a workaround for now; > am still not sure about what's going on with clones. I undestand it now. The problem is that fixup is missed for one gimple b

[Bug tree-optimization/97356] [11 regression] several test case failures after r11-3748

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/pipermail/gcc-patches

[Bug ipa/97403] Ancestor jump function should be generalized

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 p

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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 > static

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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 lat

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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 (_1

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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 else

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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 for

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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 00

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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 applie

[Bug ipa/97445] Some fonctions marked static inline in Linux kernel are not inlined

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) > goto

[Bug ipa/97445] Some fonctions marked static inline in Linux kernel are not inlined

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 table

[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803

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: > bytes

[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803

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

[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803

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

[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803

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

[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803

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 no

[Bug ipa/97593] [11 Regression] ICE in gt_pch_nx, at symbol-summary.h:290 since r11-4329-g67f3791f7d133214

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 :))

[Bug c/97578] ice during IPA pass: inline

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 body

[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk

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

[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk

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 ca

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

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 > (__builtin

[Bug ipa/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

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 d

[Bug c/97578] ice during IPA pass: inline

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 co

[Bug ipa/97695] [11 Regression] wrong code at -O3 on x86_64-pc-linux-gnu since r11-4587-gae7a23a3fab74.

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 in

[Bug bootstrap/97857] [11 Regression] profiledbootstrap broken freeing speculative call summary since r11-4987-g602c6cfc79ce4ae61e277107e0a60079c1a93a97

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 > --with-build-config=boot

[Bug bootstrap/97857] [11 Regression] profiledbootstrap broken freeing speculative call summary since r11-4987-g602c6cfc79ce4ae61e277107e0a60079c1a93a97

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 ca

[Bug bootstrap/97857] [11 Regression] profiledbootstrap broken freeing speculative call summary since r11-4987-g602c6cfc79ce4ae61e277107e0a60079c1a93a97

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

[Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized

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. It

[Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized

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 ab

[Bug bootstrap/97857] [11 Regression] profiledbootstrap broken freeing speculative call summary since r11-4987-g602c6cfc79ce4ae61e277107e0a60079c1a93a97

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>: cal

[Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized

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&action=edit > Patch unde

[Bug bootstrap/97857] [11 Regression] profiledbootstrap broken freeing speculative call summary since r11-4987-g602c6cfc79ce4ae61e277107e0a60079c1a93a97

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

[Bug bootstrap/97857] [11 Regression] profiledbootstrap broken freeing speculative call summary since r11-4987-g602c6cfc79ce4ae61e277107e0a60079c1a93a97

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 t

[Bug bootstrap/97858] [11 regression] Bogus warnings about va_list during profiledbootstrap

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 :)

[Bug tree-optimization/97915] ICE in get_odr_type, at ipa-devirt.c:1930 in pre

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.

[Bug jit/97867] [11 Regression] thunk_info::release breaks function calls in libgccjit

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 belie

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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 ab

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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 fron

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

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, then

[Bug c++/91241] [8/9/10/11 Regression] internal compiler error: symtab_node::verify failed

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, bu

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

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 Core

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

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

[Bug middle-end/98173] -fno-tree-pta improves tfft2 benchmark by 50% on zen and -march=natie.

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 just

[Bug ipa/97181] Inlining of leaf case in recursion

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 a

[Bug middle-end/55135] Segfault of gcc on a big file

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 t

[Bug ipa/97235] [11 Regression] ICE in duplicate, at ipa-prop.c:4251 since r11-3478-gada353b87909fd6c

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 ipa_f

[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054

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&action=edit > Debug counte

[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054

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 inde

[Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574

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 compute_parm_

[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux

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 expecte

[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux

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

[Bug tree-optimization/98925] Extend modref to handle return slot optimization

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 sto

[Bug ipa/97346] IPA reference reference_vars_to_consider leaks

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 --git

[Bug middle-end/99097] profiledbootstrap fails with LTO and disabled plugin

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 y

[Bug middle-end/99097] profiledbootstrap fails with LTO and disabled plugin

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 --with-build

[Bug gcov-profile/99105] profile streaming scales poorly to projects with many source files

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 buff

[Bug ipa/96252] [10/11 Regression] mis-optimization where identical functions have very different codegen since gcc 10

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 de

[Bug gcov-profile/99105] profile streaming scales poorly to projects with many source files

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 fil

[Bug gcov-profile/99105] profile streaming scales poorly to projects with many source files

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 b

[Bug gcov-profile/99105] profile streaming scales poorly to projects with many source files

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

[Bug gcov-profile/99105] profile streaming scales poorly to projects with many source files

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 in

[Bug gcov-profile/99105] profile streaming scales poorly to projects with many source files

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..

[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux

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

[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux

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 on

[Bug c/100483] Extend -fno-semantic-interposition to global variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483 --- Comment #6 from Jan Hubicka --- > Thanks for the clarification. I misinterpreted the documentation. > Then it seems that -fno-semantic-interposition is a very safe optimization for > distributions to default to. Closing as intended. Basical

[Bug fortran/100724] -fwhole-program breaks module use

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 --- Comment #6 from Jan Hubicka --- > Could the manual entry for -fwhole-program just be amended to clarify that > it's > a fallback for when a linker plugin isn't available for -flto. That may be > what it was intended to say, but it's not cl

[Bug tree-optimization/107467] [12/13 Regression] Miscompilation involing -Os , -flto and -fno-strict-aliasing since r12-656-ga564da506f52be66

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107467 --- Comment #9 from Jan Hubicka --- > > so it's ICFed compare_pairs having modref TBAA info that makes the > stores dead. I suppose ICF needs to reset / alter the modref summaries? Well, matching that ICF does should be enough to verify that

[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950 --- Comment #9 from Jan Hubicka --- > > Feel free to grab my initial patch in c#0 and upstream it. I tried that some > time ago in the following email thread: > https://gcc.gnu.org/pipermail/gcc/2021-May/236096.html Actually I was shooting for

[Bug tree-optimization/108552] Linux i386 kernel 5.14 memory corruption for pre_compound_page() when gcov is enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552 --- Comment #39 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552 > > --- Comment #35 from Vladimir Makarov --- > (In reply to Jakub Jelinek from comment #34) > > Seems right now DECL_NONALIASED is only used on these c

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 --- Comment #20 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 > > --- Comment #17 from rguenther at suse dot de --- > On Mon, 20 Feb 2023, jakub at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bu

[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118 --- Comment #8 from Jan Hubicka --- > > the synthesised functions (actor, destroy) are intended to be TU-local. > the ramp function is what remains of the user's original function after the > coroutine body is outlined - so that has the origina

[Bug c++/108887] [13 Regression] ICE in process_function_and_variable_attributes since r13-3601

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887 --- Comment #5 from Jan Hubicka --- > Perhaps, but shouldn't we also unlink_from_assembler_name_hash (node, false);? > I think the point of the current removal is that we've discovered the mangling > alias clashes with some other symbol. cgraph_

[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118 --- Comment #13 from Jan Hubicka --- > So .. for promotion of target expression temporaries to frame vars, one of: > - a) we need to find a different way to name them I think we can just count number of fields within a given frame type? Honza

[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118 --- Comment #15 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118 > > --- Comment #14 from Iain Sandoe --- > (In reply to Jan Hubicka from comment #13) > > > So .. for promotion of target expression temporaries to fram

[Bug c++/108887] [13 Regression] ICE in process_function_and_variable_attributes since r13-3601

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887 --- Comment #8 from Jan Hubicka --- > Also, reset() is only defined in cgraph_node, and I need it to work on both > functions and variables. Aha, this is a good point. I forgot that. I will make reset() working on symbols in general. I think i

[Bug middle-end/106408] PRE with infinite loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106408 --- Comment #2 from Jan Hubicka --- > + /* If block is a loop that is possibly infinite we should not > +hoist across it. */ > + if (block->loop_father->header == block > + && !finite_loop_p (block->loop_father)) > +

[Bug ipa/106991] new+delete pair not optimized by g++ at -O3 but optimized at -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106991 --- Comment #2 from Jan Hubicka --- > Looks like inlining decisions decide to inline new but not delete but for -Os > we inline none and elide the new/delete pair. > > Maybe we can devise some inline hints to keep pairs? Inliner is mostly buil

[Bug tree-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 --- Comment #4 from Jan Hubicka --- > Started with r5-6477-g3620b606822f80863488ca4883542d848d41f9f9 This only affects early inlining decisions, so it may be useful to bisect this with --param early-inlining-insns=14 Honza

[Bug ipa/102581] [12 Regression] ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2 since r12-3202-gf5ff3a8ed4ca9173

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581 --- Comment #7 from Jan Hubicka --- Hi, the problem is that we assume that merge is symmetric (merging a to b succeeds if and only if merging b to a succeeds). There was one symetrical path missing in the (fancy and bit ugly) logic on what we ca

[Bug ipa/102581] [12 Regression] ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2 since r12-3202-gf5ff3a8ed4ca9173

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581 --- Comment #8 from Jan Hubicka --- Actually, this is shorter patch - we already should notice that one range is contained in other, but we give up too early. Honza diff --git a/gcc/ipa-modref-tree.h b/gcc/ipa-modref-tree.h index 6a9ed5ce54b..

[Bug c++/107597] LTO causes static inline variables to get a non-uniqued global symbol

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107597 --- Comment #2 from Jan Hubicka --- Hi, What happens is that we read the symbol as: Visibility: externally_visible semantic_interposition prevailing_def_ironly_exp public weak comdat comdat_group:_ZN12NonTemplated1xE one_only While in visibili

  1   2   3   >