[solved] Profile upgrade from 17.1 to 23: error rebuild gcc

[e8root]

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: Select all

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.

[sam_]

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.

[hujuice]

Very clear, and easy workaround.

[sam_]

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

[hujuice]

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.

[e8root]

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: Select all

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: Select all

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: Select all

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.

[hujuice]

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.

[pietinger]

[...] I see that a new stage file is downloadable, now (2024-03-24 [...] I hope it's already in the new profile.

Yes. See: viewtopic-p-8821210.html#8821210