(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.

Those tests pass for me with a native powerpc64le-unknown-linux-gnu compiler on gcc112.

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.

Could the testsuite be finding an older libstdc++.so somewhere in the LD_LIBRARY_PATH?

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.

GCC 14.1 is being released, retargeting bugs to GCC 14.2.

GCC 14.2 is being released, retargeting bugs to GCC 14.3.

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?

(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?

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.

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.

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]

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.