[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 Tomasz Kłoczko changed: What|Removed |Added CC||kloczko.tomasz at gmail dot com --- Comment #34 from Tomasz Kłoczko --- Any progress on that issue? Just hit that issue trying to build NetworkManager https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/278
[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #36 from Tomasz Kłoczko --- Thanks for update. Please let me know when you will have working version of your patch. I have ready to use gcc build in which after about two hours (my gcc compile time) I would be able to to try to help you test that patch :) Just point to exact patch in git or attach the patch here.
[Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394 Tomasz Kłoczko changed: What|Removed |Added CC||kloczko.tomasz at gmail dot com --- Comment #8 from Tomasz Kłoczko --- Any progress on that issue? Looks like I've hit this issu in protobuf https://github.com/protocolbuffers/protobuf/issues/7092
[Bug c/93764] New: lzo 2.10 test suite fails with -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93764 Bug ID: 93764 Summary: lzo 2.10 test suite fails with -O2 and -O3 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kloczko.tomasz at gmail dot com Target Milestone: --- Gcc 9.2 was OK. With gcc 10.0.1 from rawhide test suite fails like below + /usr/bin/make -O -j48 V=1 VERBOSE=1 check test /usr/bin/make check-local /usr/bin/make all-am make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/lzo-2.10' ./lzotest/lzotest -mlzo -n2 -q './COPYING' LZO real-time data compression library (v2.10, Mar 01 2017). Copyright (C) 1996-2017 Markus Franz Xaver Johannes Oberhumer All Rights Reserved. internal error - lzo_init() failed !!! (this usually indicates a compiler bug - try recompiling without optimizations, and enable `-DLZO_DEBUG' for diagnostics) make[1]: *** [Makefile:1701: check-local] Error 1 make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/lzo-2.10' make: *** [Makefile:1373: check-am] Error 2 make: *** Waiting for unfinished jobs ./lzotest/lzotest -mavail -n10 -q './COPYING' LZO real-time data compression library (v2.10, Mar 01 2017). Copyright (C) 1996-2017 Markus Franz Xaver Johannes Oberhumer All Rights Reserved. internal error - lzo_init() failed !!! (this usually indicates a compiler bug - try recompiling without optimizations, and enable `-DLZO_DEBUG' for diagnostics)
[Bug middle-end/93764] [10 Regression] lzo 2.10 test suite fails with -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93764 --- Comment #2 from Tomasz Kłoczko --- If gcc produces correctly working code I think that it would be better to just disable that single test if code with aliasing is faster.
[Bug c/93911] New: Need expertise about how to solve some LTO related warnings in glib API code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93911 Bug ID: 93911 Summary: Need expertise about how to solve some LTO related warnings in glib API code Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kloczko.tomasz at gmail dot com Target Milestone: --- The problem is described on: https://gitlab.gnome.org/GNOME/glib/issues/2042 In general using LTO is causing sometimes flooding about some inline warnings. This is about gcc 10 from rawhide.
[Bug c/93911] Need expertise about how to solve some LTO related warnings in glib API code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93911 --- Comment #2 from Tomasz Kłoczko --- Because I don't want to be listen by all people who needs help and I want to talk with those who knows how LTO woorks? And as well I don't subscribe to yet-amnother-list to ask one question some exact people .. I'm politely asking .. only thi snd nothing more. This is an issue reported by gcc LTO and even I have some doubts how to approach to that issue .. is it bug or feacture?
[Bug lto/93911] Need expertise about how to solve some LTO related warnings in glib API code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93911 --- Comment #4 from Tomasz Kłoczko --- In this actual case it is flood of such warnings when LTO is used. Looks like glib developers are trying to tell that this those warnings should be calmed down. I know that LTO is pushing a lot of inlining so question is this correct code or not or maybe it is something which is only trying to inline such code when in reality LTO in such cases should be no trying to do that? Because that macro is part of the API it will affect more projects so if gcc is perfectly fine and it is kind of exertion which is acceptable maybe that code in glib header file should have altered that warning? I'm just looking for any hints which could improve situation here and/or encircle something which potentially can/could be corrected.
[Bug lto/101146] New: mesa build with LTO is crashing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101146 Bug ID: 101146 Summary: mesa build with LTO is crashing Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: kloczko.tomasz at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- All details are in https://gitlab.freedesktop.org/mesa/mesa/-/issues/4399
[Bug lto/101146] mesa build with LTO is crashing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101146 --- Comment #1 from Tomasz Kłoczko --- I forgot about on crucial detail. To reproduce that you need env with NVidia card. In my case I'm using :18:00.1 Audio device: NVIDIA Corporation GP104 High Definition Audio Controller (rev a1) However my friends who are using my packages had the same effect with other NVidia cards.
[Bug lto/101146] mesa build with LTO is crashing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101146 --- Comment #5 from Tomasz Kłoczko --- About strict aliasing: I need to check that (will back with results shortly) Here is short sctipt to produce binaries: CFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none' CXXFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none' FFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -I/usr/lib64/gfortran/modules' FCFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -I/usr/lib64/gfortran/modules' LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,--gc-sections -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin' CC=/usr/bin/gcc CXX=/usr/bin/g++ FC=/usr/bin/gfortran AR=/usr/bin/gcc-ar NM=/usr/bin/gcc-nm RANLIB=/usr/bin/gcc-ranlib export CFLAGS CXXFLAGS FFLAGS FCFLAGS LDFLAGS CC CXX FC AR NM RANLIB meson --buildtype=plain --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/libexec --bindir=/usr/bin --sbindir=/usr/sbin --includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man --infodir=/usr/share/info --localedir=/usr/share/locale --sysconfdir=/etc --localstatedir=/var --sharedstatedir=/var/lib --wrap-mode=nodownload --auto-features=enabled . x86_64-redhat-linux-gnu -D build-tests=true -D cpp_std=gnu++14 -D dri3=enabled -D dri-drivers=nouveau,r100,r200,i915,i965 -D egl=enabled -D gallium-drivers=swrast,virgl,r300,nouveau,iris,svga,radeonsi,r600 -D gallium-nine=true -D gallium-omx=bellagio -D gallium-opencl=icd -D gallium-va=enabled -D gallium-vdpau=enabled -D gallium-xa=enabled -D gallium-xvmc=disabled -D gbm=enabled -D gles1=disabled -D gles2=enabled -D glvnd=true -D glx=dri -D llvm=enabled -D microsoft-clc=disabled -D opengl=true -D osmesa=true -D platforms=x11,wayland -D selinux=true -D shared-glapi=enabled -D shared-llvm=enabled -D valgrind=enabled -D vulkan-drivers=intel,amd meson compile -C x86_64-redhat-linux-gnu --verbose Compiler versiom: Any gcc produced in last yeear. Currently I was able to reporoduce that using last ninaries from fedora rawhide [tkloczko@barrel SPECS]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-11.1.1-20210617/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.1 20210617 (Red Hat 11.1.1-5) (GCC) I just found that current mesa from fedora rawhide has didsabled LTO so to reporduce that issue you can use as well build env out of fedora rawhide packages and mesa package with commented line disabling LTO.
[Bug lto/101146] mesa build with LTO is crashing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101146 --- Comment #6 from Tomasz Kłoczko --- Hmm .. why status has been changed to RESOLVED?
[Bug lto/101146] mesa build with LTO is crashing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101146 --- Comment #7 from Tomasz Kłoczko --- (In reply to Andrew Pinski from comment #4) > https://gitlab.freedesktop.org/mesa/mesa/-/issues/2977 > > So not a GCC bug. This not the same stack trace and that ticket is more than year old.
[Bug lto/101146] mesa build with LTO is crashing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101146 --- Comment #9 from Tomasz Kłoczko --- (In reply to Andrew Pinski from comment #3) > Does adding -fno-strict-aliasing help? > What is exactly command lines being used to compile the object files and the > final link? Just tested binaries builkd with -fno-strict-aliasing. Everything crashes the same way. Will back shortly with secod test with -flifetime-dse=1
[Bug lto/101146] mesa build with LTO is crashing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101146 --- Comment #10 from Tomasz Kłoczko --- Just restarted gdm on system with mesa compiled with -flifetime-dse=1 abd it works. Looks like it wi still sometbing to do with medsa code to add probably necessary #pragma around the code which relies on -flifetime-dse=1 Thank you.
[Bug lto/106499] New: LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 Bug ID: 106499 Summary: LTO runs forever in libfabric 1.15.1 linking Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: kloczko.tomasz at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- gcc-12.1.1-3.fc37.1.x86_64 from fedora rawhide. >From top PID USER VIRTRESSHR S %CPU %MEM TIME+ COMMAND nTH P SWAP CODE DATA nMaj nMin 2736489 tkloczko 114.2g 105.8g 6.6m R 99.3 84.3 155:42.14 /usr/libexec/gcc/x86_64-redhat-linux/12/lto1 -quiet -dumpdir src/.l+ 1 12 7.5g 17.0m 114.2g 2.3m 79m 2 So it already runs +2h and ate +100GB RAM. Exact comman which is running tkloczko 2736413 0.0 0.0 9208 140 pts/9S+ 13:27 0:00 | \_ /bin/sh ./libtool --tag=CC --mode=link /usr/bin/gcc -Wall -O2 -DNDEBUG -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -Os -version-info 19:1:18 -export-dynamic -Wl,--version-script=./libfabric.map -Wl,-z,relro -Wl,--as-needed -Wl,--gc-sections -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin -Wl,--build-id=sha1 -o src/libfabric.la -rpath /usr/lib64 src/libfabric_la-fabric.lo src/libfabric_la-fi_tostr.lo src/libfabric_la-perf.lo src/libfabric_la-log.lo src/libfabric_la-var.lo src/libfabric_la-abi_1_0.lo prov/hook/src/src_libfabric_la-hook.lo prov/hook/src/src_libfabric_la-hook_av.lo prov/hook/src/src_libfabric_la-hook_cm.lo prov/hook/src/src_libfabric_la-hook_cntr.lo prov/hook/src/src_libfabric_la-hook_cq.lo prov/hook/src/src_libfabric_la-hook_domain.lo prov/hook/src/src_libfabric_la-hook_ep.lo prov/hook/src/src_libfabric_la-hook_eq.lo prov/hook/src/src_libfabric_la-hook_wait.lo prov/hook/src/src_libfabric_la-hook_xfer.lo src/libfabric_la-hmem.lo src/libfabric_la-hmem_rocr.lo src/libfabric_la-hmem_cuda.lo src/libfabric_la-hmem_cuda_gdrcopy.lo src/libfabric_la-hmem_ze.lo src/libfabric_la-hmem_neuron.lo src/libfabric_la-common.lo src/libfabric_la-enosys.lo src/libfabric_la-rbtree.lo src/libfabric_la-tree.lo src/libfabric_la-fasthash.lo src/libfabric_la-indexer.lo src/libfabric_la-mem.lo src/libfabric_la-iov.lo src/shared/libfabric_la-ofi_str.lo prov/util/src/src_libfabric_la-util_atomic.lo prov/util/src/src_libfabric_la-util_attr.lo prov/util/src/src_libfabric_la-util_av.lo prov/util/src/src_libfabric_la-util_cq.lo prov/util/src/src_libfabric_la-util_cntr.lo prov/util/src/src_libfabric_la-util_domain.lo prov/util/src/src_libfabric_la-util_ep.lo prov/util/src/src_libfabric_la-util_pep.lo prov/util/src/src_libfabric_la-util_eq.lo prov/util/src/src_libfabric_la-util_fabric.lo prov/util/src/src_libfabric_la-util_main.lo prov/util/src/src_libfabric_la-util_poll.lo prov/util/src/src_libfabric_la-util_wait.lo prov/util/src/src_libfabric_la-util_buf.lo prov/util/src/src_libfabric_la-util_mr_map.lo prov/util/src/src_libfabric_la-util_ns.lo prov/util/src/src_libfabric_la-util_shm.lo prov/util/src/src_libfabric_la-util_mem_monitor.lo prov/util/src/src_libfabric_la-util_mem_hooks.lo prov/util/src/src_libfabric_la-util_mr_cache.lo prov/util/src/src_libfabric_la-cuda_mem_monitor.lo prov/util/src/src_libfabric_la-rocr_mem_monitor.lo prov/util/src/src_libfabric_la-ze_mem_monitor.lo prov/util/src/src_libfabric_la-util_coll.lo src/unix/libfabric_la-osd.lo src/linux/libfabric_la-osd.lo src/linux/libfabric_la-rdpmc.lo prov/sockets/src/src_libfabric_la-sock_attr.lo prov/sockets/src/src_libfabric_la-sock_av.lo prov/sockets/src/src_libfabric_la-sock_dom.lo prov/sockets/src/src_libfabric_la-sock_mr.lo prov/sockets/src/src_libfabric_la-sock_eq.lo prov/sockets/src/src_libfabric_la-sock_cq.lo prov/sockets/src/src_libfabric_la-sock_cntr.lo prov/sockets/src/src_libfabric_la-sock_poll.lo prov/sockets/src/src_libfabric_la-sock_wait.lo prov/sockets/src/src_libfabric_la-sock_ep_rdm.lo prov/sockets/src/src_libfabric_la-sock_ep_dgram.lo prov/sockets/src/src_libfabric_la-sock_ep_msg.lo prov/sockets/src/src_libfabric_la-sock_fabric.lo prov/sockets/src/src_libfabric_la-sock_ep.lo prov/sockets/src/src_libfabric_la-sock_ctx.lo prov/sockets/src/src_libfabric_la-sock_rx_entry.lo prov/sockets/src/src_libfabric_la-sock_progress.lo prov/sockets/src/src_libfabric_la-sock_comm.lo prov/sockets/src/src_libfabric_la-sock_conn.lo prov/sockets/src/src_libfabric_la-sock_msg.lo prov/sockets/src/src_libfabric_la-sock_rma.lo p
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #1 from Tomasz Kłoczko --- Last detail. I'm adding -Os to %build_cflags
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #3 from Tomasz Kłoczko --- This box has 256GB of RAM and ZERO swap.
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #4 from Tomasz Kłoczko --- Other detail is that produces DSO libfabric.so.1.18.1 without LTO has only 1340096 bytest so question is why lto needs in this case +10GB of RAM?🤔
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #5 from Tomasz Kłoczko --- +100GB
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #7 from Tomasz Kłoczko --- Hmm .. Martin even if that can be fixed in libfabric code does it still mean that it something wrong with LO optimisation? Sorry for asking maybe dumb question but this situation is not clear for me :)
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #9 from Tomasz Kłoczko --- (In reply to Andrew Pinski from comment #8) [..] > Basically with the flatten attribute and lto, every function needs to there > and cloned and inlined causing a lot of memory and time really. > Functions become huge and all. Gcc memory usage for some things can be > improved but it won't be enough. Knowing size of the non-LTO optimised DSO I suppose that sill it maybe some design issue (higher level) which is causing that inline operations are causing such gigantic memory usage increase. And/or maybe it would be good to organise some internal metric with such operation counter to display at least some warning that some threshold of such operations has been reached? Maybe I'm mumbling but I'm trying to find at least sone generic solution to have some at least linker fart that thing are going in wrong direction because what is implemented in the code ..
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #11 from Tomasz Kłoczko --- (In reply to Andrew Pinski from comment #10) > The flatten attribute is designed to override all heuristics in the compiler > that is designed to not cause the gignatic memory usage and compile time. > Basically you told the compiler to ignore those. Now I'm a bit confused because in this case looks like use flatten attribute caused high memory usage. Does it mean that (generally) flatten should not be used at the same time with inline?
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #13 from Tomasz Kłoczko --- Thank you for the explanation.
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #15 from Tomasz Kłoczko --- (In reply to Richard Biener from comment #14) > In addition to that, -flto-partition=none is almost never a good idea either. > > Note I think that we should honor flatten only during early inlining to > avoid all kinds of funny behavior when applying cross TU. Issue is that in few cases AFAIK it is only solution to some still unresolved LTO issues :/
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #17 from Tomasz Kłoczko --- (In reply to Martin Liška from comment #16) [..] > Well, in most cases it's used for symbol versioning which is implemented by > assembly directives. However, we offer symver function attribute that > survives LTO partitioning. One more reason can be usage of top-level asm, > which can be mitigated by -fno-lto for units that use it. Yes I know however many project still is not usig that macro. BTW I just realised that as long as low level versioning symbols is handled it turns ouit that this bug seems is only arount he code which is handling versioned symbols taken from sym file. It should not be so hard to fix that. Am I right? This bug is in the queue for et least two years. What is the difficultu with fixing that?
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #19 from Tomasz Kłoczko --- (In reply to Martin Liška from comment #18) > > It should not be so hard to fix that. Am I right? > > Do you mean the usage of symver attribute? No, it's quite a straightforward > transformation many projects have already done. No, no .. I mean IIRC therea are few cases when versioned sym file is incorrectly handled if -flto-partition=none is not used.
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #21 from Tomasz Kłoczko --- FYI I've opened libfabric ticket https://github.com/ofiwg/libfabric/issues/7916 Thank you one more time for all your explanations :)
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #22 from Tomasz Kłoczko --- (In reply to Martin Liška from comment #6) > Doctor it hurts! Then don't do it. Sorry, seriously, it's caused by the > flatten attribute and I can reproduce it for our openSUSE package. If may I ask yet another question 😋 Martin can you tell how did you manage to diagnose that it was exactly that cause in this case?🤔 Thank you in advance.
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #24 from Tomasz Kłoczko --- Thank you :)
[Bug lto/107078] New: LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 Bug ID: 107078 Summary: LTO is causing that firebird build is core dumping Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: kloczko.tomasz at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- firebird 4.0.2 and gcc-c++ 12.2.1-2 from fedora rawhide. Build is crashing with sigsegv on execution of the linked binary Quote from firebird maintainer comment: "That's almost for sure (99%) pure virtual function call. Usual bug for dtor/ctor - but I doubt half-constructed node was passed into node copier. I try to lower compiler optimization level first of all in such cases (taking into an account that this stuff builds and works OK for some years)." More details is in https://github.com/FirebirdSQL/firebird/issues/7308 I found that fedora spec file has disabled LTO as well with comment # firebird is mis-compiled when LTO is enabled. A root # cause analysis has not yet been completed. Reported upstream. # Disable LTO for now
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #5 from Tomasz Kłoczko --- FWD of the firebird developer from https://github.com/FirebirdSQL/firebird/issues/7308#issuecomment-1262043660 "Firebird (that code left from interbase times) traditionally zeroes memory when allocating a lot of internal data structures using function like calloc(). When moving from C to C++ it was wrapped into operator new of some base class in order to avoid type casts, be able to use ctors and a lot of other c++ features. 20 years ago it was fine. Some years ago an optimization removing any data initalization in new (data returned by it is not initialized according to standard). By itself it did not affect the code - our calloc() is placed into separate file, it's not inline. But together with cross-file optimization... we get what you've seen. Certainly correct fix is to move memory initialization into ctor - but that was not done yet. May be there some more issues with LTO, I did not learn it deeper."
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #8 from Tomasz Kłoczko --- (In reply to Andrew Pinski from comment #6) [..] > Then almost certainly -fno-lifetime-dse will help. Tested -O2 + LTO + -fno-lifetime-dse and it crashes.
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #9 from Tomasz Kłoczko --- (In reply to Jakub Jelinek from comment #7) > Then as documented, -fno-lifetime-dse or -flifetime-dse=1 can be a temporary > workaround, but as has been said, such code is undefined behavior and should > be fixed in the application. > See > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flifetime-dse I just realised that +year ago working on my packages I've started removing all hardcodes in source tree warnig and optimisation flags to be able to controll that on rpm build layer and when I've removed in mesa -flifetime-dse=1 it started crashing as well.
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #10 from Tomasz Kłoczko --- Tested -O2 + LTO + -flifetime-dse=1 and it crashes.
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #11 from Tomasz Kłoczko --- Tested -O2 + LTO + -flifetime-dse=1 and it crashes.
[Bug lto/104245] New: abseil-cpp 20211102.0 fails with "internal compiler error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104245 Bug ID: 104245 Summary: abseil-cpp 20211102.0 fails with "internal compiler error" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: kloczko.tomasz at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- https://github.com/abseil/abseil-cpp//archive/20211102.0/abseil-cpp-20211102.0.tar.gz %build %cmake \ -D ABSL_USE_EXTERNAL_GOOGLETEST=ON \ -D BUILD_TESTING=ON \ Build fails on linking [ 52%] Building CXX object absl/flags/CMakeFiles/absl_flags_flag_test.dir/flag_test.cc.o cd /home/tkloczko/rpmbuild/BUILD/abseil-cpp-20211102.0/x86_64-redhat-linux-gnu/absl/flags && /usr/bin/g++ -DGTEST_LINKED_AS_SHARED_LIBRARY=1 -I/home/tkloczko/rpmbuild/BUILD/abseil-cpp-20211102.0 -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -DNDEBUG -Wall -Wextra -Wcast-qual -Wconversion-null -Wformat-security -Wmissing-declarations -Woverlength-strings -Wpointer-arith -Wundef -Wunused-local-typedefs -Wunused-result -Wvarargs -Wvla -Wwrite-strings -DNOMINMAX -Wno-conversion-null -Wno-deprecated-declarations -Wno-missing-declarations -Wno-sign-compare -Wno-unused-function -Wno-unused-parameter -Wno-unused-private-field -MD -MT absl/flags/CMakeFiles/absl_flags_flag_test.dir/flag_test.cc.o -MF CMakeFiles/absl_flags_flag_test.dir/flag_test.cc.o.d -o CMakeFiles/absl_flags_flag_test.dir/flag_test.cc.o -c /home/tkloczko/rpmbuild/BUILD/abseil-cpp-20211102.0/absl/flags/flag_test.cc *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event| Plugins PLUGIN_FINISH_UNIT | annobin: Generate final annotations PLUGIN_START_UNIT| annobin: Generate global annotations PLUGIN_ALL_PASSES_START | annobin: Generate per-function annotations PLUGIN_ALL_PASSES_END| annobin: Register per-function end symbols during IPA pass: modref /home/tkloczko/rpmbuild/BUILD/abseil-cpp-20211102.0/absl/flags/flag_test.cc:979:1: internal compiler error: tree code ‘template_type_parm’ is not supported in LTO streams 979 | } | ^ Please submit a full bug report, with preprocessed source if appropriate. I'm not sure where I can find that preporocessed source.
[Bug lto/104245] abseil-cpp 20211102.0 fails with "internal compiler error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104245 --- Comment #1 from Tomasz Kłoczko --- gcc from rawhide [tkloczko@ss-desktop SRPMS]$ rpm -q gcc-c++ gcc-c++-12.0.1-0.2.fc36.x86_64
[Bug c++/104245] [12 Regression] abseil-cpp 20211102.0 fails with "internal compiler error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104245 --- Comment #7 from Tomasz Kłoczko --- Created attachment 52303 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52303&action=edit flag_test.cc.o.gz gzipped file generated by /usr/bin/g++ -save-temps -DGTEST_LINKED_AS_SHARED_LIBRARY=1 -I/home/tkloczko/rpmbuild/BUILD/abseil-cpp-20211102.0 -O2 -g -grecord-gcc-switches -E -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -DNDEBUG -Wall -Wextra -Wcast-qual -Wconversion-null -Wformat-security -Wmissing-declarations -Woverlength-strings -Wpointer-arith -Wundef -Wunused-local-typedefs -Wunused-result -Wvarargs -Wvla -Wwrite-strings -DNOMINMAX -Wno-conversion-null -Wno-deprecated-declarations -Wno-missing-declarations -Wno-sign-compare -Wno-unused-function -Wno-unused-parameter -Wno-unused-private-field -MD -MT absl/flags/CMakeFiles/absl_flags_flag_test.dir/flag_test.cc.o -MF CMakeFiles/absl_flags_flag_test.dir/flag_test.cc.o.d -o CMakeFiles/absl_flags_flag_test.dir/flag_test.cc.o -c /home/tkloczko/rpmbuild/BUILD/abseil-cpp-20211102.0/absl/flags/flag_test.cc
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #12 from Tomasz Kłoczko --- Any update?🤔
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #15 from Tomasz Kłoczko --- (In reply to Martin Liška from comment #14) > Can you please provide the exact steps on how to configure the project with > the corresponding options and run the crashing command? I would like to > attach a gdb to it. - take fedora firebird src.rpm and unpack it - undomment ins spec file disable LTO - build package
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #17 from Tomasz Kłoczko --- > /tmp/firebird-4.0.2/gen/Release/firebird/bin/isql -q -i > /tmp/firebird-4.0.2/src/dbs/metadata.sql > can't format message 17:0 -- message file /usr/local/firebird/firebird.msg > not found > Unable to complete network request to host "localhost". > -Failed to establish a connection. > can't format message 17:120 -- message file /usr/local/firebird/firebird.msg > not found This issue has nothing to do with running firebird. This issue is about compiler issue on linking firebird binary linked with LTO.
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #21 from Tomasz Kłoczko --- On emore time. You are commenting under GNU C Compilet issue during linking firebird binaries linking. *COMPILER* (not firebird) is core dumping. Please discuss firebird issue opening ticket on https://github.com/FirebirdSQL/firebird/issues/
[Bug other/109600] New: 13.0.1-0.15.fc39: missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109600 Bug ID: 109600 Summary: 13.0.1-0.15.fc39: missing #include Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: kloczko.tomasz at gmail dot com Target Milestone: --- Just noticed that with latest gcc version many packages builds re failing with /usr/lib/gcc/x86_64-redhat-linux/13/include/immintrin.h:135:10: fatal error: amxcomplexintrin.h: No such file or directory 135 | #include | ^~~~
[Bug other/109600] 13.0.1-0.15.fc39: missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109600 --- Comment #3 from Tomasz Kłoczko --- Broken binary packages are still in repo.
[Bug c++/111964] New: 13.2.1: potential GIMPLE bug in inline assempler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111964 Bug ID: 111964 Summary: 13.2.1: potential GIMPLE bug in inline assempler Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kloczko.tomasz at gmail dot com Target Milestone: --- According to node developers it is bug in GIMPLE and inline assembler causing that node build with enabled LTO fails with missing PushAllRegistersAndIterateStack symbol. More details about how to build nodejs 21.0.0 to reproduce this issue is on https://github.com/nodejs/node/issues/50347
[Bug middle-end/111964] 13.2.1: potential GIMPLE bug in inline assempler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111964 --- Comment #2 from Tomasz Kłoczko --- (In reply to Andrew Pinski from comment #1) > There are some known issues with top-level inline-asm and lto. > > It would be better if folks moved away from toplevel inline-asm really. May I ask to drop some comment about that with some instruction what needs to be done instead under https://github.com/nodejs/node/issues/50347 ?
