[Bug testsuite/109656] New: [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[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]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656

            Bug ID: 109656
           Summary: [14 regression]
                    26_numerics/random/random_device/cons/token.cc fails
                    after r14-289-gf9412cedd6c0e7
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:f9412cedd6c0e7417b30d9a80d3f45c8746223b4, r14-289-gf9412cedd6c0e7

Do these test cases need to be updated?

FAIL: 26_numerics/random/random_device/cons/token.cc execution test
FAIL: 26_numerics/random/random_device/entropy.cc execution test

spawn [open ...]^M
terminate called without an active exception
FAIL: 26_numerics/random/random_device/cons/token.cc execution test
extra_tool_flags are:   -include bits/stdc++.h


commit f9412cedd6c0e7417b30d9a80d3f45c8746223b4 (HEAD, refs/bisect/bad)
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Apr 26 15:23:57 2023 +0100

    libstdc++: Make std::random_device throw std::system_error [PR105081]

[Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[redi at gcc dot gnu.org]

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

[Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[redi at gcc dot gnu.org]

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.

[Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[redi at gcc dot gnu.org]

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

[Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[redi at gcc dot gnu.org]

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.

[Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[seurer at gcc dot gnu.org]

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.

[Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[redi at gcc dot gnu.org]

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?

[Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[seurer at gcc dot gnu.org]

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.

[Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[rguenth at gcc dot gnu.org]

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.

[Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[jakub at gcc dot gnu.org]

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.

[Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[redi at gcc dot gnu.org]

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?

[Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[bergner at gcc dot gnu.org]

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?

[Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[seurer at gcc dot gnu.org]

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.

[Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[redi at gcc dot gnu.org]

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.

[Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[seurer at gcc dot gnu.org]

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]

[Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

[redi at gcc dot gnu.org]

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.