Re: [Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space

Hi, with the attached patch that saves roughly 10 minutes of tree-into-ssa pass, I can compile with -O3 -fno-tree-fre -fno-tree-pre. Only without checking-enabled since we do incredibly deep dominator walks running out of stack space that can be considered as bug too. TER still manages to enfore

Re: [Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3

> In x86/x86-64 world one can be almost sure that the load+execute instruction > pair will execute (marginaly to noticeably) faster than move+load-and-execute > instruction pair as the more complex instructions are harder for on-chip > scheduling (they retire later).

Re: [Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space

Thank you for consideration, Live on entry/exit code shows up high on -O3 compilation time too (something like 30% of time without PRE/FRE I believe). So if it is self contained change, perhaps pushing it to mainline as PR fix would make sense. Honza

Re: [Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space

Hi, update at -O1 few patches later (different machine with "only" 500MB ram, so some swappin occurs, but we almost fit now): life analysis : 23.50 (20%) usr 0.00 ( 0%) sys 23.51 (17%) wall 2565 kB ( 2%) ggc inline heuristics : 0.60 ( 1%) usr 0.00 ( 0%) sys 0.60 ( 0%) wa

Re: i386.md:3705: error: undefined machine-specific constraint at this point: "Y"

> I just got this error building a cross-compiler from sparc-sun-solaris2.10 > targetted to i686-unknown-linux-gnu. This worked as recently as last > week: > > > build/genoutput ../../egcc-SVN20070216/gcc/config/i386/i386.md > insn-conditions.md > tmp-output.c > > config/i386/i386.md:3705: err

Re: [Bug tree-optimization/91322] [10 regression] alias-4 test failure

> 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 int is 32-bit. Hmm, you are right - I messed up target triplets. With arm-linux-gnueabi I

Re: [Bug lto/95548] ice in tree_to_shwi, at tree.c:7321

> I think Honza ran into this himself. Yep, i converted code to use wide-ints. But it is nice to have short testcase. Honza

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

> 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). > > Fixing that would need processing cgraph SCCs with an extra IPA phase in main > optimization s

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

> 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 add a simple test to our regular testers that either the new revision can consume old objec

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

> 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 > statically allocated buffer when we recursively entry allocate_gcov_kvp. > > However this is d

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

> > 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 (nmemb=1, size=8) at pr97461.c:103 > 103 if (malloc_depth != 0) __builtin_trap();

Re: [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 #23 from Christophe Leroy --- > (In reply to Jan Hubicka from comment #19) > > > > It is always possible to always_inline functions that are intended to be > > always inlined. > > Honza >

Re: [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 #31 from Segher Boessenkool --- > (In reply to Jan Hubicka from comment #27) > > It is because --param inline-insns-single was reduced for -O2 from 200 > > to 70. GCC 10 has newly different set of pa

Re: [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 #33 from Jakub Jelinek --- > (In reply to Jan Hubicka from comment #32) > > get_order is a wrapper around ffs64. This can be implemented w/o asm > > statement as follows: > > int > > m

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

> > 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 be bug in bsr{q} pattern. I can make GCC produce same > code with: > > __attribute__ ((n

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

still need the stronger hint though. gcc/ChangeLog: 2020-10-20 Jan Hubicka PR c/97445 * ipa-fnsummary.c (ipa_dump_hints): Handle INLINE_HINT_builtin_constant_p. (ipa_fn_summary::~ipa_fn_summary): Free builtin_constant_p_parms. (ipa_fn_summary_t

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

> 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_read alias sets: 7->7 > > The &bytes_read is always modified in the function (if it's n

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

Hi, this is patch that moves updates to WPA time. Does it work for you? Honza 2020-10-27 Jan Hubicka * ipa-modref.c (modref_summaries_lto::duplicate): Check that no clones happens after modref. (modref_transform): Rename to ... (update_signature): ... this

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

> 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

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

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 is really needed and avoid materializing if it is not. Can you add one? Something like

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

> 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 compiled before caller (as it should) we will call cgraph_node::release_body and that will l

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

will clean it up incrementally. gcc/ChangeLog: 2020-11-03 Jan Hubicka * cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Fix ICE with in dumping code. (cgraph_node::remove): Save clone info before releasing it and pass it to unregister. * cgraph.h

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

> 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=bootstrap-lto-lean && make profiledbootstrap > 'STAGE1_CFLAGS=-g -O2' > > started with r11-4

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

> > 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 can isolate one of the paths (constant access merging, variable access merging on the two o

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

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 faster machine. Honza

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

> 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 is not clear to me if simply calling the default implementation instead of the rather com

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

> 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 about, that is just whether the > backend decided it will not be passed at all. OK, perhaps

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

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>: callq 0x10949d0 ::iterator::slide()> 0x01475513 <+179>: mov%r12,0x20(%rsp

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

> 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 under test. > > The attached patch avoids the warning on aarch64. Let me finish testing it

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

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 that it does not disable more than it should. Honza diff --git a/gcc/ipa-utils.h b/gcc/ip

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

Hi, this ought to be fixed by g:0862d007b564eca8c9a48fca0e689dd3f90db828 sorry for the breakage. OBJ_TYPE_REF in obj-C frontend is odd.

Re: [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 #18 from Martin Sebor --- > Let me explain how this works. The VLA bounds in function parameters are used > in two ways: > 1) in the front end, to check function redeclarations involving arrays and > VLAs > for equivalence, >

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

> @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, but I think C++ FE should assign them different symbol names. Honza

Re: [Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

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

Re: [Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

> 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 that may or may not improve performance > (and historically, sometimes even break code), so

Re: [Bug bootstrap/96794] New: --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

> 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 to a wasted jobserver worker. Hmm, I am not sure how to interpret the graph. I can see th

Re: [Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

> 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 > > > here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab6

Re: [Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

> 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 add without jobserver > > knowledge. > > It's unrelated to jobserver, one can enable it wi

Re: [Bug tree-optimization/97159] [11 Regression] segfault in modref_may_conflict

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 (that include types) are streamed out while they are turned into non-lto summaries at ltr

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

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 index cf8775b2b66..07946a85ecc 100644 --- a/gcc/dbgcnt.def +++ b/gcc/dbgcnt.def @@ -171,6 +17

Re: [Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO

> 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 you have patch I can try it since I still have the train data and corresponding gcc tree. I

Re: [Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO

> 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 localalias is thunk that is not recursive. > thing we can do is to write a simple case to f

Re: [Bug c++/98330] [9/10/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 #4 from Richard Biener --- > So modref allocates a fnspec_summary for an unknown indirect call (NULL > callee) > but then in compute_parm_map calls function_or_virtual_thunk_symbol on > that NULL callee unconditionally. We hav

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

> 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 you make system linker ld, if system linker is gold (from tumbleweed) it fails GNU gold (

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

> 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-config=bootstrap-lto --enable-checking=release >

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

> 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 buffered I/O by stdio. First I am not sure how safe it is (as we had a lot of fun about usin

Re: [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 #8 from Martin Liška --- > This is what I see for GCC PGO in train stage. It's from perf top: > >4.33% cc1plus [.] > __gcov_indirect_call_profiler_v4 > ◆ >2.28

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

> 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 instrumented compiler. Honza

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

> 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 i686 > and passed it on x86_64 and powerpc64le, the former passed bootstrap on all > arch

Re: [Bug ipa/93318] [10 regression] Firefox LTO+FDO ICEs in speculative_call_info

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 supposed to contain direct call. Edge removal code probably replaces direct edge by indreict

Re: [Bug regression/55168] New: [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0

This actually looks like a previously latent issue in predict.c For all but estimate_num_iterations_int. It uses the funny definition of number of iterations (i.e. 0 means that loop will exit at first invocation of the exit condition and that is what it will be predicted with when nitercst == 1.

Re: [Bug lto/47188] New: Undefined reference errors when combining IR and non-IR object files

The bug seems to be that lto-symtab incorrectly sets resolution info of the callgraph node as unknown. Looking into it. Honza

Re: [Bug lto/47188] Undefined reference errors when combining IR and non-IR object files

This is driver bug. With -flto-partition=none it for whatever reason forgets about -fresolution: ../lto1 -quiet -dumpdir ./ -dumpbase prog -mtune=generic -march=x86-64 -auxbase-strip /tmp/cctgIO6R.lto.o -version -flto-partition=none -fuse-linker-plugin -fwhole-program -fdump-ipa-all-details @

Re: [Bug lto/47188] Undefined reference errors when combining IR and non-IR object files

The problem is that collect2 should be in LTO_MODE_NONE when plugin is used but it confuses itself and sets itself into LTO_MODE_LTO. Consequently compilation is done twice, once correctly with plugin and then once again with collect2 path. I am testing the attached patch. It will also make non-

Re: [Bug lto/44463] whopr does not work with weak functions

actually it might be as easy as walking alias pairs after decl merging and killing all pairs where decl has been replaced by different. This probably can be done at same time as we rewrite IL.

Re: [Bug lto/47205] New: GCC emits optimized out noinline function

> extern int foo(void); > > int main(void) > { > return foo() * 0; > } This is because gimple part of optimizers for some reason leads to the following in the optimized dump: main () { : foo (); return 0; } and only RTL optimizers do the trick. This is weird since pure/const detect funct

Re: [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests

> One failure is > > /tmp/ccJSP9PV.lto.o: In function `main':^M > ccWUIi0z.o:(.text.startup+0x1d): undefined reference to `g_ebp_save'^M > ccWUIi0z.o:(.text.startup+0x23): undefined reference to `g_esp_save'^M > ccWUIi0z.o:(.text.startup+0x3b): undefined reference to `g_edi'^M > ccWUIi0z.o:(.text.

Re: [Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32

What is the failure? Honza

Re: [Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32

> when configuring target-libgcc, > failed with xgcc cannot create executable > config.log shows 'liblto_plugin-0.dll not found' > maybe -fuse-linker-plugin option not handled correctly Yes, it seems that linker plugin handling on cygwin is not done well. Is linker plugin built for you and does th

Re: [Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32

> lto and linker plugin was OK in 20110101 snapshot > in which '-fuse-linker-plugin' was off by default > but in rev 168594, the option becomes on by default Yes, I've changed the default when linker is detected to have linker support and lto-plugin is build. > > this option causes checking LTOPL

Re: [Bug lto/47225] New: [4.6.0 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"

> > There is indeed no liblto_plugin.so found in my build tree. > > With r168592 I had the last confirmed successful build. Seems like plugin autodetection somehow screws up. Do you get the lto-plugin/Makefile configured? What is it building there? Honza

Re: [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests

> I tried > -int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX; > -int g_ebp, g_ebp_save, g_esp, g_esp_save; > +int g_edi __attribute__((externally_visible)) =INIT_EDI; > +int g_esi __attribute__((externally_visible)) =INIT_ESI; > +int g_ebx __attribute__((externally_visible)) = INIT_EBX; > +int

Re: [Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"

> I.e. only static library of lto-plugin gets built. Ahh, static library for lto-plugin is of course pointless thing. I guess we want to disable plugin when --disable-shared is passed. I will see if my autoconf-fu is on par to do so. Still, it is bit sad situation - you are right that you are no

Re: [Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32

Hi, is this dup of PR47225? I.e. is the --disable-shared the problem? Honza

Re: [Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"

Hi, since lto plugin already enables shared libiberty, this patch extends the machinery for plugin itself too. Does it fix your problem? I seem to be able to bootstrap (C only) with disable-shared. Index: configure === --- configure

Re: [Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32

Hi, I posed patch to the aforementioned PR, hopefully it will fix this one too.

Re: [Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

There is a lot of room for improvement in the WPA memory use, but I am not sure how much we can still fit in 4.6.0...

Re: [Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem

Consider the patch pre-approved if it passes testing. Thanks!

Re: [Bug lto/46905] -flto -fno-lto does not disable lto

> slim lto will take some time (next stage1) I was chatting about this with Diego yesterday and he seems to be fine with the basic slim LTO patch getting in. So it seems to me that we might get the slim LTO patch for 4.6.0 and flip the default for 4.7.0 > i also plan to drop most of the code bec

Re: [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222 > > I will take a look. But it still leaves: > > FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto line 12 arg1 == 1 > FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto line 14 arg1 == 1 > FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -flto-partition=none

Re: [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests

> > Run-time abort. Please check 32bit. OK, these reproduce to me. Adding "staitic" into the testcase as follows: /* PR middle-end/12210 */ /* Origin: Ossadchy Yury A. */ /* This used to fail on i686 because the argument was not copied to the right location by __builtin_apply after the dire

Re: [Bug driver/46760] LTO bootstrap doesn't work with FDO

> lto1: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > lto-wrapper: /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc What is the backtrace here? I built

Re: [Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"

> I don't think it is. I am building a cross-compiler (with build = host = > x86_64-apple-darwin10.6.0, target = i586-pc-mingw32) from unpatched GCC > revision 168626, and it's failing with the same symptoms. When configuring > libgcc, I get: > > > checking for suffix of object files... configure

Re: [Bug driver/46760] LTO bootstrap doesn't work with FDO

> I have been testing lto-bootstrap: > > http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00750.html > > I will try to start lto-bootstrap with FDO. Great, thanks! The FDO bootstrap always suffered from lack of testing, so this should help. Honza

Re: [Bug bootstrap/46037] --enable-stage1-languages=c,lto --enable-languages=c,lto --with-build-config=bootstrap-lto fails on darwin

> Target attributes must be implying optimisation attributes. Bug depends also > on --with-{arch,tune,fpmath} settings. I'll try and reproduce it on > x86_64-linux, it should be possible if I choose the right settings - will > reply > again later. Well, we probably should just go ahead and impl

Re: [Bug bootstrap/46037] --enable-stage1-languages=c,lto --enable-languages=c,lto --with-build-config=bootstrap-lto fails on darwin

> The patch will also be problematic for powerpc-apple-darwin9 and darwin8 since > it relies on dwarf2 and those OS releases still use stabs. It should not be problem. For stabs we don't do var tracking. The original test tested if target debug info supports var tracking and dwarf2 is the only on

Re: [Bug driver/47244] [4.6 Regression] plugin linker is used unconditionally

> Is pr39968 related (a duplicate) of this pr? No, it is older than the problem and it is about plugins, not lto-plugin. Perhaps plugins Make also needs to play the games with --enable-shared I added into lto-plugin configury. Honza

Re: [Bug bootstrap/46037] --enable-stage1-languages=c,lto --enable-languages=c,lto --with-build-config=bootstrap-lto fails on darwin

> Why not retain the original code behavior unless generating lto? The patch Because the original code bahviour is wrong. It assumes that debug_hooks is initialized while it is not at the point. Honza > below works with both a standard and lto-bootstrap on x86_64-apple-darwin10. > > Index: gcc/

Re: [Bug libstdc++/47368] New: CFLAGS_FOR_TARGET, profiledbootstrap and lto-bootstrap flags unused in libstdc++-v3

>The libstdc++-v3 build also doesn't utilize the profiling flags produced > in > a profiledbootstrap or the lto flags produced from an lto-bootstrap. profiledbootstrap/lto-bootstrap is about FDO/LTO while building compiler, not runtime. It would probably make sense for libstdc++-v3 to eventu

Re: [Bug c++/47367] internal compiler error: verify_cgraph_node failed

> It works for me with current trunk which suggests this is a duplicate bug > that was fixed in the meantime. Please re-check with a more recent version. Yes, I am pretty sure it is dup of the inliner bug I was fixing earlier this year. Honza

Re: [Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306

> lto1: internal compiler error: in lto_varpool_replace_node, at > lto-symtab.c:305 Merging should happen after unmerged files are dumped. Perhaps they go to some funny place, like /tmp? Honza

Re: [Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

> 39339456 libxul1.so > 34436696 libxul2.so Yep, it seems similar to what I was getting. Quite important difference and all the stuff gets loaded into memory at startup by dynamic linker. > For a 5 MB reduction I might end up writing a wrapper that runs ld twice :-) You might try GNU-ld's plug

Re: [Bug lto/47916] Using -flto leads to halved performance of unrar unarchiver

> That should work. The error is a sanity check that profile information > is sane. Obviously given that sanity of profile can break for valid reasons, we should not ICE when this happen. I will try to look how it becomes insane here however. Honza

Re: [Bug c/47980] Inefficient code for local const char arrays

> I believe f could do: > assert (arg != "aoeuaoeuaeouaeouaoeuaoeaoxbxod"); > which would then fail with the proposed optimization. It is unspecified if > two string literals with the same content are distinct objects, but foo must > be > a distinct object (ok, with static const char foo[] = >

Re: [Bug target/50135] Loop optimization.

> I bet we have a duplicate report for not using the x86 loop instruction. Well, we used to generate it until we concluded it is pointless... Honza

Re: [Bug lto/50338] ICE Linking with -flto

> Honza, does the ICE ring any bell? I don't recall seeing it previously. The check tests that partition contains only analyzed nodes, so it should not be that hard to track down who adds the unanalyzed one. I will try to do bit of proofreading today in bus. Honza

Re: [Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

> > is altogether more hairy - we create at run-time C++ vtables packed with > > trampolines so we can intercept / model native C++ objects and interact with > > them via python etc. that would need some more intense debugging love I > > guess. > > and this one is the only remaining issue. That

Re: [Bug tree-optimization/10980] vararg functions are not inlined

I bet it just ignores the attribute that is not how the attribute is supposed to work. We output error in this case intentionally (and warning in at the same spot if function is declared inline and -Winline is given). Functions marked always_inlined really ought to be always inlined and attribute

Re: [Bug other/50636] New: GC in large LTO builds cause excessive fragmentation in memory map

> When doing a very large LTO build I fail with "out of virtual memory" > > Some investigation showed the problem was not actually running out of > memory, but gcc excessively fragmenting its memory map. The Linux kernel > has a default limit of 64k mappings per process and the fragmentation > e

Re: [Bug middle-end/41969] [LTO] 23% slow-down with -flto -fwhole-program

It doesn't help to attach this into a closed bugreport. LTO allows GCC to do a lot more transformations and sometime the transformations hurts the final performance. This is a bug and we will try to fix it. >From information you gave it is however impossible to guess what may possibly >go wrong

Re: [Bug fortran/51267] loop optimization error using LOC function

I am surprised that this does not happen already at PRE :) Without volatile attribute there is really nothing that prevents GCC from doing this optimization and unfortunately I don't think we provide way to prevent it without this big hammer. We have fpcr register defined for the control word th

Re: [Bug middle-end/32911] Function __attribute__ ((idempotent))

Note that I was thinking of similar attribute for C++ iostream initialization code. Currently every unit including iostream gets a call to the iostream constructor. With LTO we merge the constructors together and get _alot_ of redundant calls to the construction code. Declaring that only first

Re: [Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64

> > This isn't necessary. If __int128 is put on stack by caller, > > the stack must be aligned at 16 bytes. > > Not when you call function with -fpreferred-stack-boundary=3 > and it is itself compiled with -fpreferred-stack-boudnary=4 > and calls another functions passing __int128. > Thus the ABI

Re: [Bug tree-optimization/53726] [4.8 Regression] aes test performance drop for eembc_2_0_peak_32

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53726 > > --- Comment #22 from Jan Hubicka 2012-06-22 22:45:35 > UTC --- > > Yes. The question is what is "very small" and how can we possibly > > As what is very small is defined in the i386.c in the cost tables

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

> 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

Re: [Bug middle-end/23181] [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20%

> > > --- Comment #11 from law at redhat dot com 2005-10-31 23:18 --- > Subject: Re: [4.1 Regression] Slowdown of the > bresenham line drawing by roughly 20% > > On Mon, 2005-10-31 at 20:55 +, hubicka at gcc dot gnu dot org wrote: > > > > --- Comment #10 from hubicka a

Re: [Bug middle-end/23181] [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20%

> > > --- Comment #13 from law at redhat dot com 2005-10-31 23:36 --- > Subject: Re: [4.1 Regression] Slowdown of the > bresenham line drawing by roughly 20% > > On Mon, 2005-10-31 at 23:25 +, hubicka at ucw dot cz wrote: > > > See comment #5. The fact that we ended up wi

Re: [Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test "rnflow" degraded

> So for the loop that starting at bb 28 you can see the xxtrt_46 access was not > put into pretemp. Possible reason is exactly as it was mentioned by Richard - > there were extra candidates collected and this one become less anticipatable > > Skipping partial partial redundancy for expression

Re: [Bug fortran/48636] Enable more inlining with -O2 and higher

mgrid do not seem to be sensitive to --param min-inline-speedup, so it seems independent regression of this change. No idea what goes wrong. Honza

Re: [Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

> Oh got it - it is this one, right?: > > profiling:/home/tejohnson/extra/gcc_trunk_3_obj/libcpp/files.gcda:Invocation > mismatch - some data files may have been removed Yes, it is this one. > > I think this one was there before, but I had to modify it after my > histogram change. I will take a

  1   2   >