| View previous topic :: View next topic |
| Author |
Message |
e8root
n00b
Joined: 09 Feb 2024
Posts: 71
|
 Posted: Mon Mar 25, 2024 3:14 pm Post subject: |
 |
|
| sam_ wrote: | | We've reported the issue to GCC upstream. |
And GCC upstream had a thought: omg, we don't have -march=native test case in our automated test system! 
One small note for everyone now changing -march=native to their CPU architecture by name:
There can be differences between just setting arch to native or specific CPU architecture. When testing it by
| Code: | | gcc -march=native -E -v - </dev/null 2>&1 | grep cc1 |
Versus broadwell on my Broadwell Xeon there were few instructions missing and some cache switches.
On Raptor Lake I get almost no switches on raptorlake or alderlake and a lot of them with native.
With Broadwell my understanding is that broadwell has to be as generic as possible and need to work on all CPUs from given family while some CPUs can have instructions which other models from given family don't have hence few instructions were missing. I didn't go and verify instructions which all Broadwell CPUs have to confirm that though.
All in all these things probably won't affect the performance in any significant measurable way but it is just a tidbit which I found interesting to know and therefore worth sharing.
_________________
Unix Wars - Episode V: AT&T Strikes Back |
|
| Back to top |
|
 |
sam_
Developer
Joined: 14 Aug 2020
Posts: 1678
|
| Posted: Mon Mar 25, 2024 3:20 pm Post subject: |
|
|
Genuinely, it's kind of fun how many bugs we end up hitting. If you think about it, in the wild, most people are not building applications with -march=x (or if they are, it's maybe one of the x86-64-v* baselines).
I would recommend using app-misc/resolve-march-native, btw. |
|
| Back to top |
|
|
hujuice
Guru
Joined: 16 Oct 2007
Posts: 336
Location: Rome, Italy
|
| Posted: Mon Mar 25, 2024 4:55 pm Post subject: |
|
|
Very clear, and easy workaround.
_________________
Who hasn't a spine, should have a method.
Chi non ha carattere, deve pur avere un metodo. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1678
|
| Posted: Mon Mar 25, 2024 5:06 pm Post subject: |
|
|
Sorry about the hassle, though. I really did try to make it handle it automatically. It just turned out there's some interesting interaction between -march=native and subsequent --param ... so it can't work  |
|
| Back to top |
|
|
hujuice
Guru
Joined: 16 Oct 2007
Posts: 336
Location: Rome, Italy
|
| Posted: Mon Mar 25, 2024 6:09 pm Post subject: |
|
|
| sam_ wrote: | | Sorry about the hassle, though. I really did try to make it handle it automatically. It just turned out there's some interesting interaction between -march=native and subsequent --param ... so it can't work |
No, don't worry. Thank you for your work.
_________________
Who hasn't a spine, should have a method.
Chi non ha carattere, deve pur avere un metodo. |
|
| Back to top |
|
|
e8root
n00b
Joined: 09 Feb 2024
Posts: 71
|
| Posted: Mon Mar 25, 2024 7:19 pm Post subject: |
|
|
| sam_ wrote: | Genuinely, it's kind of fun how many bugs we end up hitting. If you think about it, in the wild, most people are not building applications with -march=x (or if they are, it's maybe one of the x86-64-v* baselines).
I would recommend using app-misc/resolve-march-native, btw. |
Yeah, when building world with --emptytree few packages failed rebuild and out of these all were not added by --emptytree.
I managed to build packages failing on my default gcc by using different compilers:
sys-fs/f2fs-tools o2 compiler-clang-lto-full
sys-libs/slang o2 compiler-clang
dev-python/numpy o2 compiler-intel
app-emulation/virtualbox o2 compiler-clang-lto-full
I didn't investigate what is the cause of these build issues yet because for that I will need to first narrow issues to profile change. Maybe it is some other change I made in the meantime... though nothing comes to mind really.
I have another Gentoo install used for testing so I can check it there first making sure to collect some information on these packages beforehand.
Anyways, there was one more package which failed which didn't build on any other compiler and it is www-client/seamonkey
It failed because it didn't like the line /usr/include/math.h:170 and more specifically:
| Code: | | typedef long double double_t; |
conflicting with its own definition of double_t in /var/tmp/portage/www-client/seamonkey-2.53.18.1/work/seamonkey-2.53.18.1/modules/fdlibm/src/math_private.h:34
| Code: | typedef double __double_t;
typedef __double_t double_t; |
I updated seamonkey very recently and it did build so I am pretty sure it has to do with profile change.
Owner of the file /usr/include/math.h is sys-libs/glibc-2.38-r10
So apparently the definition of double_t changed in my system. Another thing to confirm in chrooted Gentoo and collect more data...
Of course the fix was very simple and I only had to create patch file /etc/portage/patches/www-client/seamonkey/double-fun.diff
| Code: | diff -Naru to/modules/fdlibm/src/e_rem_pio2.cpp seamonkey-2.53.18.1/modules/fdlibm/src/e_rem_pio2.cpp
--- seamonkey-2.53.18.1/modules/fdlibm/src/e_rem_pio2.cpp 2024-03-25 18:48:53.690475190 +0100
+++ to2/modules/fdlibm/src/e_rem_pio2.cpp 2024-03-25 19:17:14.238418104 +0100
@@ -126,7 +126,7 @@
}
if(ix<0x413921fb) { /* |x| ~< 2^20*(pi/2), medium size */
medium:
- fn = rnint((double_t)x*invpio2);
+ fn = rnint((double)x*invpio2);
n = irint(fn);
r = x-fn*pio2_1;
w = fn*pio2_1t; /* 1st round good to 85 bit */
diff -Naru to/modules/fdlibm/src/math_private.h to2/modules/fdlibm/src/math_private.h
--- to/modules/fdlibm/src/math_private.h 2024-03-25 19:29:19.833393746 +0100
+++ seamonkey-2.53.18.1/modules/fdlibm/src/math_private.h 2024-03-25 19:15:33.461421487 +0100
@@ -31,7 +31,7 @@
*/
typedef double __double_t;
-typedef __double_t double_t;
+//typedef __double_t double_t;
typedef float __float_t;
/*
diff -Naru to/modules/fdlibm/src/s_scalbn.cpp to2/modules/fdlibm/src/s_scalbn.cpp
--- to/modules/fdlibm/src/s_scalbn.cpp 2024-03-25 18:48:53.690475190 +0100
+++ seamonkey-2.53.18.1/modules/fdlibm/src/s_scalbn.cpp 2024-03-25 19:17:19.833417916 +0100
@@ -14,7 +14,7 @@
double scalbn(double x, int n)
{
union {double f; uint64_t i;} u;
- double_t y = x;
+ double y = x;
if (n > 1023) {
y *= 0x1p1023; |
And this is why I love Gentoo - very useful set of features that enable users to automatically patch source code with whatever changes they want. Including fixing bs build issues only caused by the fact we don't install binary packages like pretty much everyone else
(I guess now with binpkg's you can skip building from sources for some packages... and hopefully users won't abuse this feature to get out of the build issues...)
EDIT://
Update, Seamonkey fails on 17.1 too. Verified in chrooted environment.
Now I am completely lost as to why it compiled before and now doesn't.
_________________
Unix Wars - Episode V: AT&T Strikes Back |
|
| Back to top |
|
|
hujuice
Guru
Joined: 16 Oct 2007
Posts: 336
Location: Rome, Italy
|
| Posted: Mon Mar 25, 2024 8:13 pm Post subject: |
|
|
Nothing failed for me (once -march=my_march).
There is another minor consideration, though.
I'm installing Gentoo on a new laptop, and I've found myself with a stage file tied to a an old profile.
I see that a new stage file is downloadable, now (2024-03-24, mine was 2024-03-17). I hope it's already in the new profile.
_________________
Who hasn't a spine, should have a method.
Chi non ha carattere, deve pur avere un metodo. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4160
Location: Bavaria
|
|
| Back to top |
|
|
|
Portage & Programming
