[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

[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) Howeve

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

[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

[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

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

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

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

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

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

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

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

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

[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

[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

[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

[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/h

[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

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

[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://gi

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

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

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