Hello,
I've attempted to kick out the rebuilds for new icu in rawhide which was announced last week via https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... (that is on hold for now).
I however encountered lots of compiler fails on both s390x and i686 (eg. boost scratch build at https://koji.fedoraproject.org/koji/taskinfo?taskID=145945327 , but this is plaguing many more packages):
/usr/include/c++/16/cmath: In instantiation of ‘_Tp std::__detail::__ellint_rf(_Tp, _Tp, _Tp) [with _Tp = float]’: /usr/include/c++/16/tr1/ell_integral.tcc:201:27: required from ‘_Tp std::__detail::__comp_ellint_1(_Tp) [with _Tp = float]’ 201 | return __ellint_rf(_Tp(0), _Tp(1) - __k * __k, _Tp(1)); | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/16/bits/specfun.h:358:44: required from here 358 | { return __detail::__comp_ellint_1<float>(__k); } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~ /usr/include/c++/16/tr1/ell_integral.tcc:102:40: in ‘constexpr’ expansion of ‘std::pow(1.1920929e-7f, 1.66666672e-1f)’ 102 | const _Tp __errtol = std::pow(__eps, _Tp(1) / _Tp(6)); | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
*/usr/include/c++/16/cmath:384:26: internal compiler error: Segmentation fault 384 | { return __builtin_powf(__x, __y); } | ~~~~~~~~~~~~~~^~~~~~~~~~*
These are present even in attempted scratch builds outside the icu side-tag, so that isn't the culprit. Does anyone have any more context/can look into it?
Thanks!
Hello,
I believe I have encountered a similar/the same issue but for me it triggers on all the architectures:
/builddir/build/BUILD/mariadb10.11-10.11.17-build/mariadb-10.11.17/mysys/waiting_threads.c: In function ‘wt_init’: /builddir/build/BUILD/mariadb10.11-10.11.17-build/mariadb-10.11.17/mysys/waiting_threads.c:460:5: internal compiler error: Segmentation fault 460 | double to= log(60e6); /* 1 min */ | ^~~~~~
The builds are here: https://koji.fedoraproject.org/koji/taskinfo?taskID=145945213 The package still builds ok on a local mockbuild and has built ok yesterday in koji as well.
Best regards,
Pavol Sloboda
On Wed, May 27, 2026 at 10:13 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
Hello,
I've attempted to kick out the rebuilds for new icu in rawhide which was announced last week via https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... (that is on hold for now).
I however encountered lots of compiler fails on both s390x and i686 (eg. boost scratch build at https://koji.fedoraproject.org/koji/taskinfo?taskID=145945327 , but this is plaguing many more packages):
/usr/include/c++/16/cmath: In instantiation of ‘_Tp std::__detail::__ellint_rf(_Tp, _Tp, _Tp) [with _Tp = float]’: /usr/include/c++/16/tr1/ell_integral.tcc:201:27: required from ‘_Tp std::__detail::__comp_ellint_1(_Tp) [with _Tp = float]’ 201 | return __ellint_rf(_Tp(0), _Tp(1) - __k * __k, _Tp(1)); | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/16/bits/specfun.h:358:44: required from here 358 | { return __detail::__comp_ellint_1<float>(__k); } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~ /usr/include/c++/16/tr1/ell_integral.tcc:102:40: in ‘constexpr’ expansion of ‘std::pow(1.1920929e-7f, 1.66666672e-1f)’ 102 | const _Tp __errtol = std::pow(__eps, _Tp(1) / _Tp(6)); | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
*/usr/include/c++/16/cmath:384:26: internal compiler error: Segmentation fault 384 | { return __builtin_powf(__x, __y); } |
These are present even in attempted scratch builds outside the icu side-tag, so that isn't the culprit. Does anyone have any more context/can look into it? Thanks! -- Best regards / S pozdravem, František Zatloukal Principal Software Engineer Red Hat -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
On Wed, 27 May 2026 10:21:13 +0200 Pavol Sloboda psloboda@redhat.com wrote:
Hello,
I believe I have encountered a similar/the same issue but for me it triggers on all the architectures:
the icu rebuild is run with "fail_fast = True", so not all build tasks are allowed to really finish, they are cancelled after a first fail instead.
Dan
/builddir/build/BUILD/mariadb10.11-10.11.17-build/mariadb-10.11.17/mysys/waiting_threads.c: In function ‘wt_init’: /builddir/build/BUILD/mariadb10.11-10.11.17-build/mariadb-10.11.17/mysys/waiting_threads.c:460:5: internal compiler error: Segmentation fault 460 | double to= log(60e6); /* 1 min */ | ^~~~~~
The builds are here: https://koji.fedoraproject.org/koji/taskinfo?taskID=145945213 The package still builds ok on a local mockbuild and has built ok yesterday in koji as well.
Best regards,
Pavol Sloboda
On Wed, May 27, 2026 at 10:13 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
Hello,
I've attempted to kick out the rebuilds for new icu in rawhide which was announced last week via https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... (that is on hold for now).
I however encountered lots of compiler fails on both s390x and i686 (eg. boost scratch build at https://koji.fedoraproject.org/koji/taskinfo?taskID=145945327 , but this is plaguing many more packages):
/usr/include/c++/16/cmath: In instantiation of ‘_Tp std::__detail::__ellint_rf(_Tp, _Tp, _Tp) [with _Tp = float]’: /usr/include/c++/16/tr1/ell_integral.tcc:201:27: required from ‘_Tp std::__detail::__comp_ellint_1(_Tp) [with _Tp = float]’ 201 | return __ellint_rf(_Tp(0), _Tp(1) - __k * __k, _Tp(1)); | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/16/bits/specfun.h:358:44: required from here 358 | { return __detail::__comp_ellint_1<float>(__k); } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~ /usr/include/c++/16/tr1/ell_integral.tcc:102:40: in ‘constexpr’ expansion of ‘std::pow(1.1920929e-7f, 1.66666672e-1f)’ 102 | const _Tp __errtol = std::pow(__eps, _Tp(1) / _Tp(6)); | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
*/usr/include/c++/16/cmath:384:26: internal compiler error: Segmentation fault 384 | { return __builtin_powf(__x, __y); } |
These are present even in attempted scratch builds outside the icu side-tag, so that isn't the culprit. Does anyone have any more context/can look into it? Thanks! -- Best regards / S pozdravem, František Zatloukal Principal Software Engineer Red Hat -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
On Wed, May 27, 2026 at 10:32:08AM +0200, Dan Horák wrote:
On Wed, 27 May 2026 10:21:13 +0200 Pavol Sloboda psloboda@redhat.com wrote:
Hello,
I believe I have encountered a similar/the same issue but for me it triggers on all the architectures:
the icu rebuild is run with "fail_fast = True", so not all build tasks are allowed to really finish, they are cancelled after a first fail instead.
I've managed to reproduce the boost ICE on i686, but it is really weird. The ICE is within mpfr: #0 0x00000000 in ?? () #1 0xf7ee9537 in mpfr_cache (dest=0xffffaeec, cache=0xf79effd4, rnd=MPFR_RNDU) at /usr/src/debug/mpfr-4.2.2-3.fc44.i386/src/cache.c:102 #2 0xf7ec20b3 in mpfr_exp2 (y=0xffffaff0, x=0xffffaf78, rnd_mode=MPFR_RNDN) at /usr/src/debug/mpfr-4.2.2-3.fc44.i386/src/exp2.c:141 #3 0xf7ed343a in mpfr_pow (z=0xffffaff0, x=0xffffaff0, y=0xffffafe0, rnd_mode=MPFR_RNDN) at /usr/src/debug/mpfr-4.2.2-3.fc44.i386/src/pow.c:665 #4 0x09797f41 in do_mpfr_arg2(real_value*, int (*)(__mpfr_struct*, __mpfr_struct const*, __mpfr_struct const*, mpfr_rnd_t), real_value const*, real_value const*, real_format const*) [clone .lto_priv.0] () #5 0x09797a66 in fold_const_call_sss(real_value*, combined_fn, real_value const*, real_value const*, real_format const*) [clone .lto_priv.0] () #6 0x0909e6a1 in fold_const_call_1(combined_fn, tree_node*, tree_node*, tree_node*) [clone .lto_priv.0] [clone .cold] () #7 0x0a089231 in fold_builtin_n(unsigned long long, tree_node*, tree_node*, tree_node**, int, bool) [clone .isra.0] () but reproduces only in f45 and not in f44, gcc is the same source (gcc-16.1.1-2.fc{45,44}), mpfr is even exactly the same (mpfr-4.2.2-3.fc44), gmp is also exactly the same. Reproducer can be even e.g. just echo 'double a = __builtin_log (60e6);' > test.c gcc test.c
Wonder if something hasn't changed on the glibc side...
Jakub
* Jakub Jelinek:
On Wed, May 27, 2026 at 10:32:08AM +0200, Dan Horák wrote:
On Wed, 27 May 2026 10:21:13 +0200 Pavol Sloboda psloboda@redhat.com wrote:
Hello,
I believe I have encountered a similar/the same issue but for me it triggers on all the architectures:
the icu rebuild is run with "fail_fast = True", so not all build tasks are allowed to really finish, they are cancelled after a first fail instead.
I've managed to reproduce the boost ICE on i686, but it is really weird. The ICE is within mpfr: #0 0x00000000 in ?? () #1 0xf7ee9537 in mpfr_cache (dest=0xffffaeec, cache=0xf79effd4, rnd=MPFR_RNDU) at /usr/src/debug/mpfr-4.2.2-3.fc44.i386/src/cache.c:102 #2 0xf7ec20b3 in mpfr_exp2 (y=0xffffaff0, x=0xffffaf78, rnd_mode=MPFR_RNDN) at /usr/src/debug/mpfr-4.2.2-3.fc44.i386/src/exp2.c:141 #3 0xf7ed343a in mpfr_pow (z=0xffffaff0, x=0xffffaff0, y=0xffffafe0, rnd_mode=MPFR_RNDN) at /usr/src/debug/mpfr-4.2.2-3.fc44.i386/src/pow.c:665 #4 0x09797f41 in do_mpfr_arg2(real_value*, int (*)(__mpfr_struct*, __mpfr_struct const*, __mpfr_struct const*, mpfr_rnd_t), real_value const*, real_value const*, real_format const*) [clone .lto_priv.0] () #5 0x09797a66 in fold_const_call_sss(real_value*, combined_fn, real_value const*, real_value const*, real_format const*) [clone .lto_priv.0] () #6 0x0909e6a1 in fold_const_call_1(combined_fn, tree_node*, tree_node*, tree_node*) [clone .lto_priv.0] [clone .cold] () #7 0x0a089231 in fold_builtin_n(unsigned long long, tree_node*, tree_node*, tree_node**, int, bool) [clone .isra.0] () but reproduces only in f45 and not in f44, gcc is the same source (gcc-16.1.1-2.fc{45,44}), mpfr is even exactly the same (mpfr-4.2.2-3.fc44), gmp is also exactly the same. Reproducer can be even e.g. just echo 'double a = __builtin_log (60e6);' > test.c gcc test.c
Wonder if something hasn't changed on the glibc side...
In rawhide, glibc copies the TLS initialization image before relocation, so pointer initializations are lost. Adhemerval has already posted a fix:
[PATCH] elf: Re-initialise static TLS after .tdata relocation (BZ 34164) https://inbox.sourceware.org/libc-alpha/20260526185235.4093779-1-adhemerval.zanella@linaro.org
The v2 version merely adds a bug reference.
Pavol Sloboda wrote on 2026/05/27 17:21:
Hello,
I believe I have encountered a similar/the same issue but for me it triggers on all the architectures:
/builddir/build/BUILD/mariadb10.11-10.11.17-build/mariadb-10.11.17/mysys/waiting_threads.c: In function ‘wt_init’: /builddir/build/BUILD/mariadb10.11-10.11.17-build/mariadb-10.11.17/mysys/waiting_threads.c:460:5: internal compiler error: Segmentation fault 460 | double to= log(60e6); /* 1 min */ | ^~~~~~
The builds are here: https://koji.fedoraproject.org/koji/taskinfo?taskID=145945213 The package still builds ok on a local mockbuild and has built ok yesterday in koji as well.
Best regards,
Pavol Sloboda
I also see similar ICE on all arches for magic build: https://koji.fedoraproject.org/koji/buildinfo?buildID=3002670
Looks like glibc-2.43.9000-17.fc45 which was pushed into F45 buildroot 2 hours ago is the culprit. https://bodhi.fedoraproject.org/updates/FEDORA-2026-f9c515532f
Downloading glibc to -16.fc45 cures the ICE. https://koji.fedoraproject.org/koji/taskinfo?taskID=145946402
Untagging needed?
Regards, Mamoru
On Wed, May 27, 2026 at 10:13 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
Hello,
I've attempted to kick out the rebuilds for new icu in rawhide which was announced last week via https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... (that is on hold for now).
I however encountered lots of compiler fails on both s390x and i686 (eg. boost scratch build at https://koji.fedoraproject.org/koji/taskinfo?taskID=145945327 , but this is plaguing many more packages):
/usr/include/c++/16/cmath: In instantiation of ‘_Tp std::__detail::__ellint_rf(_Tp, _Tp, _Tp) [with _Tp = float]’: /usr/include/c++/16/tr1/ell_integral.tcc:201:27: required from ‘_Tp std::__detail::__comp_ellint_1(_Tp) [with _Tp = float]’ 201 | return __ellint_rf(_Tp(0), _Tp(1) - __k * __k, _Tp(1)); | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/16/bits/specfun.h:358:44: required from here 358 | { return __detail::__comp_ellint_1<float>(__k); } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~ /usr/include/c++/16/tr1/ell_integral.tcc:102:40: in ‘constexpr’ expansion of ‘std::pow(1.1920929e-7f, 1.66666672e-1f)’ 102 | const _Tp __errtol = std::pow(__eps, _Tp(1) / _Tp(6)); | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
*/usr/include/c++/16/cmath:384:26: internal compiler error: Segmentation fault 384 | { return __builtin_powf(__x, __y); } |
These are present even in attempted scratch builds outside the icu side-tag, so that isn't the culprit. Does anyone have any more context/can look into it? Thanks! -- Best regards / S pozdravem, František Zatloukal Principal Software Engineer Red Hat -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
Mamoru TASAKA wrote:
I also see similar ICE on all arches for magic build: https://koji.fedoraproject.org/koji/buildinfo?buildID=3002670
Looks like glibc-2.43.9000-17.fc45 which was pushed into F45 buildroot 2 hours ago is the culprit. https://bodhi.fedoraproject.org/updates/FEDORA-2026-f9c515532f
Downloading glibc to -16.fc45 cures the ICE. https://koji.fedoraproject.org/koji/taskinfo?taskID=145946402
glibc-2.43.9000-17.fc45 also looks like the most relevant of the differences in this report from Koschei:
https://koschei.fedoraproject.org/build/23116745
Björn Persson
Mamoru TASAKA wrote on 2026/05/27 17:45:
Pavol Sloboda wrote on 2026/05/27 17:21:
Hello,
I believe I have encountered a similar/the same issue but for me it triggers on all the architectures:
/builddir/build/BUILD/mariadb10.11-10.11.17-build/mariadb-10.11.17/mysys/waiting_threads.c: In function ‘wt_init’: /builddir/build/BUILD/mariadb10.11-10.11.17-build/mariadb-10.11.17/mysys/waiting_threads.c:460:5: internal compiler error: Segmentation fault 460 | double to= log(60e6); /* 1 min */ | ^~~~~~
The builds are here: https://koji.fedoraproject.org/koji/taskinfo?taskID=145945213 The package still builds ok on a local mockbuild and has built ok yesterday in koji as well.
Best regards,
Pavol Sloboda
I also see similar ICE on all arches for magic build: https://koji.fedoraproject.org/koji/buildinfo?buildID=3002670
Looks like glibc-2.43.9000-17.fc45 which was pushed into F45 buildroot 2 hours ago is the culprit. https://bodhi.fedoraproject.org/updates/FEDORA-2026-f9c515532f
Downloading glibc to -16.fc45 cures the ICE. https://koji.fedoraproject.org/koji/taskinfo?taskID=145946402
Untagging needed?
Regards, Mamoru
glibc-2.43.9000-17.fc45 is now untagged. https://forge.fedoraproject.org/releng/tickets/issues/13366
Mamoru
On Wed, May 27, 2026 at 10:13 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
Hello,
I've attempted to kick out the rebuilds for new icu in rawhide which was announced last week via https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... (that is on hold for now).
I however encountered lots of compiler fails on both s390x and i686 (eg. boost scratch build at https://koji.fedoraproject.org/koji/taskinfo?taskID=145945327 , but this is plaguing many more packages):
/usr/include/c++/16/cmath: In instantiation of ‘_Tp std::__detail::__ellint_rf(_Tp, _Tp, _Tp) [with _Tp = float]’: /usr/include/c++/16/tr1/ell_integral.tcc:201:27: required from ‘_Tp std::__detail::__comp_ellint_1(_Tp) [with _Tp = float]’ 201 | return __ellint_rf(_Tp(0), _Tp(1) - __k * __k, _Tp(1)); | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/16/bits/specfun.h:358:44: required from here 358 | { return __detail::__comp_ellint_1<float>(__k); } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~ /usr/include/c++/16/tr1/ell_integral.tcc:102:40: in ‘constexpr’ expansion of ‘std::pow(1.1920929e-7f, 1.66666672e-1f)’ 102 | const _Tp __errtol = std::pow(__eps, _Tp(1) / _Tp(6)); | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
*/usr/include/c++/16/cmath:384:26: internal compiler error: Segmentation fault 384 | { return __builtin_powf(__x, __y); } | ~~~~~~~~~~~~~~^~~~~~~~~~*
These are present even in attempted scratch builds outside the icu side-tag, so that isn't the culprit. Does anyone have any more context/can look into it?
Thanks!
--
Best regards / S pozdravem,
František Zatloukal Principal Software Engineer Red Hat -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
I didn't see a bug mentioned, but I filed this one this morning:
https://bugzilla.redhat.com/show_bug.cgi?id=2481846
Rich.