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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109600
--- Comment #3 from Tomasz Kłoczko ---
Broken binary packages are still in repo.
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078
--- Comment #12 from Tomasz Kłoczko ---
Any update?🤔
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.
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.
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
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.
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499
--- Comment #24 from Tomasz Kłoczko ---
Thank you :)
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
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 :)
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
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
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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499
--- Comment #13 from Tomasz Kłoczko ---
Thank you for the explanation.
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
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
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 :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499
--- Comment #5 from Tomasz Kłoczko ---
+100GB
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?🤔
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.
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
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:
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
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
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
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
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101146
--- Comment #6 from Tomasz Kłoczko ---
Hmm .. why status has been changed to RESOLVED?
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
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
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
39 matches
Mail list logo
