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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109600
--- Comment #3 from Tomasz Kłoczko ---
Broken binary packages are still in repo.
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
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://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
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
>
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
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
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
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
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
>
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.
>
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
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
: 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 %
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=edit
flag_test.cc.o.gz
gzipped file generated by
/usr/bin/g++ -save-temps -DGTEST_LINKED_AS_SHARED_LIBRARY=1
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
ty: 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-2021110
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
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
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
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)
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
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
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
: 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
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Tomasz Kłoczko changed:
What|Removed |Added
CC||kloczko.tomasz at gmail dot com
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
Tomasz Kłoczko changed:
What|Removed |Added
CC||kloczko.tomasz at gmail dot com
47 matches
Mail list logo
