* [Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
@ 2023-04-27 22:51 ` redi at gcc dot gnu.org
2023-04-27 22:52 ` redi at gcc dot gnu.org
` (13 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2023-04-27 22:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed| |2023-04-27
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
2023-04-27 22:51 ` [Bug testsuite/109656] " redi at gcc dot gnu.org
@ 2023-04-27 22:52 ` redi at gcc dot gnu.org
2023-04-27 23:08 ` redi at gcc dot gnu.org
` (12 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2023-04-27 22:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to seurer from comment #0)
> Do these test cases need to be updated?
They shouldn't need to be. The util/testsuite_random.h header was changed to
catch the new exception type that should be thrown from the library. If they're
failing it implies the library wasn't rebuilt so is still throwing the old
exception type. Odd.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
2023-04-27 22:51 ` [Bug testsuite/109656] " redi at gcc dot gnu.org
2023-04-27 22:52 ` redi at gcc dot gnu.org
@ 2023-04-27 23:08 ` redi at gcc dot gnu.org
2023-04-27 23:12 ` redi at gcc dot gnu.org
` (11 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2023-04-27 23:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |14.0
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
` (2 preceding siblings ...)
2023-04-27 23:08 ` redi at gcc dot gnu.org
@ 2023-04-27 23:12 ` redi at gcc dot gnu.org
2023-04-28 12:13 ` seurer at gcc dot gnu.org
` (10 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2023-04-27 23:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Those tests pass for me with a native powerpc64le-unknown-linux-gnu compiler on
gcc112.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
` (3 preceding siblings ...)
2023-04-27 23:12 ` redi at gcc dot gnu.org
@ 2023-04-28 12:13 ` seurer at gcc dot gnu.org
2023-04-28 12:16 ` redi at gcc dot gnu.org
` (9 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: seurer at gcc dot gnu.org @ 2023-04-28 12:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #3 from seurer at gcc dot gnu.org ---
It failed on just the one power 8 system where it fails every time.
configure --enable-languages=c,fortran,c++ --enable-secureplt --with-cpu=power8
--disable-bootstrap --disable-multilib
I will experiment a bit.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
` (4 preceding siblings ...)
2023-04-28 12:13 ` seurer at gcc dot gnu.org
@ 2023-04-28 12:16 ` redi at gcc dot gnu.org
2023-05-04 20:08 ` seurer at gcc dot gnu.org
` (8 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2023-04-28 12:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Could the testsuite be finding an older libstdc++.so somewhere in the
LD_LIBRARY_PATH?
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
` (5 preceding siblings ...)
2023-04-28 12:16 ` redi at gcc dot gnu.org
@ 2023-05-04 20:08 ` seurer at gcc dot gnu.org
2024-05-07 7:40 ` [Bug testsuite/109656] [14/15 " rguenth at gcc dot gnu.org
` (7 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: seurer at gcc dot gnu.org @ 2023-05-04 20:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #5 from seurer at gcc dot gnu.org ---
make -k check
RUNTESTFLAGS="conformance.exp=26_numerics/random/random_device/cons/token.cc"
This is from powerpc64le-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.log
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]^M
terminate called without an active exception
FAIL: 26_numerics/random/random_device/cons/token.cc execution test
I assume the LD_LIBRARY_PATH there is the one used and nothing in it appears
out of order.
BTW, I tried various changes in configure options, build compilers, binutils,
and such in case something there was an issue but it always fails on just this
one power 8 system. It works fine on another similar power 8 and other power X
(X!=8) systems.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
` (6 preceding siblings ...)
2023-05-04 20:08 ` seurer at gcc dot gnu.org
@ 2024-05-07 7:40 ` rguenth at gcc dot gnu.org
2024-08-01 9:32 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-07 7:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|14.0 |14.2
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 14.1 is being released, retargeting bugs to GCC 14.2.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
` (7 preceding siblings ...)
2024-05-07 7:40 ` [Bug testsuite/109656] [14/15 " rguenth at gcc dot gnu.org
@ 2024-08-01 9:32 ` jakub at gcc dot gnu.org
2024-08-01 9:43 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-08-01 9:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|14.2 |14.3
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 14.2 is being released, retargeting bugs to GCC 14.3.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
` (8 preceding siblings ...)
2024-08-01 9:32 ` jakub at gcc dot gnu.org
@ 2024-08-01 9:43 ` redi at gcc dot gnu.org
2024-09-19 22:25 ` bergner at gcc dot gnu.org
` (4 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2024-08-01 9:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I've just noticed that the error is not an uncaught exception, it's:
terminate called without an active exception
That's very odd.
I think you'll need to selectively comment out the calls in main():
int main()
{
test01();
test02();
test03();
test04();
}
Find out where the crash happens. I suspect it's in test01, or I'd expect to
see the printf+puts output coming from test03.
Could it be the call to __builtin_cpu_supports("darn") which happens in the
std::random_device x("default") initialization in test01?!
Could that system not support the DARN insn? Or have a faulty DARN?
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
` (9 preceding siblings ...)
2024-08-01 9:43 ` redi at gcc dot gnu.org
@ 2024-09-19 22:25 ` bergner at gcc dot gnu.org
2024-09-20 16:45 ` seurer at gcc dot gnu.org
` (3 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bergner at gcc dot gnu.org @ 2024-09-19 22:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #9 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #8)
> Could it be the call to __builtin_cpu_supports("darn") which happens in the
> std::random_device x("default") initialization in test01?!
>
> Could that system not support the DARN insn? Or have a faulty DARN?
You can check the AT_HWCAP2 value for whether your system has darn enabled or
not. I'll note darm was added in Power9, so __builtin_cpu_supports("darn")
should be false for Power8.
On my Power10 system, I see:
bergner@ltcden2-lp1:~$ LD_SHOW_AUXV=1 /bin/true | grep HWCAP2
AT_HWCAP2: mma arch_3_1 scv darn ieee128 arch_3_00 vcrypto tar isel
ebb dscr arch_2_07
(In reply to seurer from comment #5)
> BTW, I tried various changes in configure options, build compilers,
> binutils, and such in case something there was an issue but it always fails
> on just this one power 8 system. It works fine on another similar power 8
> and other power X (X!=8) systems.
Bill, which Power8 system is it that we're seeing this on?
Can you determine which test0*() function is the one having the issue?
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
` (10 preceding siblings ...)
2024-09-19 22:25 ` bergner at gcc dot gnu.org
@ 2024-09-20 16:45 ` seurer at gcc dot gnu.org
2024-09-20 17:34 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: seurer at gcc dot gnu.org @ 2024-09-20 16:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #10 from seurer at gcc dot gnu.org ---
Looking through my logs the tests stopped failing sometime between r14-2132 and
r14-2263. I think we can close this unless you want me to find where they
stopped failing.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
` (11 preceding siblings ...)
2024-09-20 16:45 ` seurer at gcc dot gnu.org
@ 2024-09-20 17:34 ` redi at gcc dot gnu.org
2024-09-20 19:18 ` seurer at gcc dot gnu.org
2024-09-20 19:24 ` redi at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2024-09-20 17:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WORKSFORME
Status|ASSIGNED |RESOLVED
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Looking at the commits in that ranges which touched g++, libstdc++, and
config/rs6000, this one looks relevant (r14-2217-gd6a6a4ea086d6a)
libstdc++: Make std::random_device throw more std::system_error [PR105081]
In r14-289-gf9412cedd6c0e7 I made the std::random_device constructor
throw std::system_error for unrecognized tokens. But it still throws
std::runtime_error for a token such as "rdseed" that is recognized but
not supported at runtime by the CPU the program is running on.
With this change we throw std::system_error for those cases too. This
fixes the following failures on Intel CPUs withour rdseed support:
FAIL: 26_numerics/random/random_device/94087.cc execution test
FAIL: 26_numerics/random/random_device/cons/token.cc execution test
FAIL: 26_numerics/random/random_device/entropy.cc execution test
libstdc++-v3/ChangeLog:
PR libstdc++/105081
* src/c++11/random.cc (random_device::_M_init): Throw
std::system_error when the requested device is a valid token but
not available at runtime.
I don't know how this would cause "terminate called without active exception"
but it's certainly in the same code.
I don't see any need to narrow it down further, so I'm happy to close it.
Thanks for checking the logs.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
` (12 preceding siblings ...)
2024-09-20 17:34 ` redi at gcc dot gnu.org
@ 2024-09-20 19:18 ` seurer at gcc dot gnu.org
2024-09-20 19:24 ` redi at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: seurer at gcc dot gnu.org @ 2024-09-20 19:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
seurer at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WORKSFORME |FIXED
--- Comment #12 from seurer at gcc dot gnu.org ---
Just for completeness I started a bisect to find where they began to work and
it led to r14-2217-gd6a6a4ea086d6a
commit d6a6a4ea086d6af97bd7fbd482f51df41c265b79 (HEAD, refs/bisect/bad)
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Fri Jun 30 14:37:59 2023 +0100
libstdc++: Make std::random_device throw more std::system_error [PR105081]
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7
2023-04-27 22:12 [Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7 seurer at gcc dot gnu.org
` (13 preceding siblings ...)
2024-09-20 19:18 ` seurer at gcc dot gnu.org
@ 2024-09-20 19:24 ` redi at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2024-09-20 19:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|14.3 |14.0
--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I see why that fixed it.
// Check whether TOKEN can construct a std::random_device successfully.
inline bool
random_device_available(const std::string& token) noexcept
{
try {
std::random_device dev(token);
return true;
} catch (const std::system_error& /* See PR libstdc++/105081 */) {
return false;
}
}
If the dev(token) constructor throws std::runtime_error instead of
std::system_error then it won't be caught, and will hit the 'noexcept' on the
surrounding function. r14-2217 made it throw std::system_error, so it's caught
now.
But I wouldn't expect "terminate without active exception".
Definitely fixed by that commit anyway.
^ permalink raw reply [flat|nested] 16+ messages in thread