From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 7876) id 72B683856DD0; Tue, 10 May 2022 12:55:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 72B683856DD0 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Nils-Christian Kempke To: gdb-cvs@sourceware.org Subject: [binutils-gdb] gdb/testsuite: fix testsuite regressions for unix/-m32 board X-Act-Checkin: binutils-gdb X-Git-Author: Nils-Christian Kempke X-Git-Refname: refs/heads/master X-Git-Oldrev: 62b33fde9c7ffd498af0236a50e200210807374a X-Git-Newrev: 6dc7160b2d598201653f74d65d4c4d34a0284f6c Message-Id: <20220510125518.72B683856DD0@sourceware.org> Date: Tue, 10 May 2022 12:55:18 +0000 (GMT) X-BeenThere: gdb-cvs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-cvs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2022 12:55:18 -0000 https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D6dc7160b2d59= 8201653f74d65d4c4d34a0284f6c commit 6dc7160b2d598201653f74d65d4c4d34a0284f6c Author: Nils-Christian Kempke Date: Wed Apr 20 12:30:48 2022 +0200 gdb/testsuite: fix testsuite regressions for unix/-m32 board =20 This commit fixes two regressions introduced by 891e4190ba705373eec7b374209478215fff5401. =20 Reason for the failures was, that on a 32 bit machine the maximum array length as well as the maximum allocatable memory for arrays (in bytes) both seem to be limited by the maximum value of a 4 byte (signed) Fortran integer. This lead to compiler errors/unexpected behavior when compiling/running the test with the -m32 board. This behavior is compiler dependent and can differ for different compiler implementations, but generally, it seemed like a good idea to simply avoid such situations. =20 The affected tests check for GDB's overflow behavior when using KIND parameters with GDB implemented Fortran intrinsic functions. If these KIND parameters are too small to fit the actual intrinsic function's result, an overflow is expected. This was done for 1, 2, and 4 byte overflows. The last one caused problems, as it tried to allocate arrays of length/byte-size bigger than the 4 byte signed integers which would then be used with the LBOUND/UBOUND/SIZE intrinsics. =20 The tests were adapted to only execute the 4 byte overflow tests when running on targets with 64 bit. For this, the compiled tests evaluate = the byte size of a C_NULL_PTR via C_SIZEOF, both defined in the ISO_C_BINDI= NG module. The ISO_C_BINDING constant C_NULL_PTR is a Fortran 2003, the C_SIZEOF a Fortran 2008 extension. Both have been implemented in their respective compilers for while (e.g. C_SIZEOF is available since gfortran 4.6). If this byte size evaluates to less than 8 we skip the 4 byte overflow tests in the compiled tests of size.f90 and lbound-ubound.f90. Similarly, in the lbound-ubound.exp testsfile we sk= ip the 4 byte overflow tests if the procedure is_64_target evaluates to fa= lse. =20 In size.f90, additionally, the to-be-allocated amount of bytes did not fit into 4 byte signed integers for some of the arrays, as it was approximately 4 times the maximum size of a 4 byte signed integer. We adapted the dimensions of the arrays in question as the meaningfulness of the test does not suffer from this. =20 With this patch both test run fine with the unix/-m32 board and gcc/gfortran (9.4) as well as the standard board file. =20 We also thought about completely removing the affected test from the testsuite. We decided against this as the 32 bit identification comes with Fortran 2008 and removing tests would have decreased coverage. =20 A last change that happened with this patch was due to gfortran's and ifx's type resolution when assigning big constants to Fortran Integer*8 variables. Before the above changes this happened in a parameter statement. Here, both compilers happily accepted a line like =20 integer*8, parameter :: var =3D 2147483647 + 5. =20 After this change the assignment is not done as a parameter anymore, as this triggered compile time overflow errors. Instead, the assignment is done dynamically, depending on the kind of machine one is on. Sadly, just changing this line to =20 integer*8 :: var var =3D 2147483647 + 5 =20 does not work with ifx (or flang for that matter, they behave similarly here). It will create an integer overflow in the addition as ifx deduc= es the type the additon is done in as Integer*4. So var will actually contain the value -2147483644 after this. The lines =20 integer*8 :: var var =3D 2147483652 =20 on the other hand fail to compile with gfortran (9.4.0) as the compiler identifies an Integer overflow here. Finally, to make this work with all three compilers an additional parameter has been introduced =20 integer*8, parameter :: helper =3D 2147483647 integer*8 :: var var =3D helper + 5. =20 This works on all 3 compilers as expected. =20 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29053 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29054 Diff: --- gdb/testsuite/gdb.fortran/lbound-ubound.F90 | 39 ++++++++++++++++---- gdb/testsuite/gdb.fortran/lbound-ubound.exp | 13 ++++--- gdb/testsuite/gdb.fortran/size.f90 | 55 +++++++++++++++++++++++--= ---- 3 files changed, 86 insertions(+), 21 deletions(-) diff --git a/gdb/testsuite/gdb.fortran/lbound-ubound.F90 b/gdb/testsuite/gd= b.fortran/lbound-ubound.F90 index aa5be85bb55..4a4474ad85e 100644 --- a/gdb/testsuite/gdb.fortran/lbound-ubound.F90 +++ b/gdb/testsuite/gdb.fortran/lbound-ubound.F90 @@ -49,6 +49,8 @@ end subroutine do_test ! Start of test program. ! program test + use ISO_C_BINDING, only: C_NULL_PTR, C_SIZEOF + interface subroutine do_test (lb, ub) integer*4, dimension (:) :: lb @@ -74,8 +76,19 @@ program test integer, parameter :: b1_o =3D 127 + 2 integer, parameter :: b2 =3D 32767 - 10 integer, parameter :: b2_o =3D 32767 + 3 - integer*8, parameter :: b4 =3D 2147483647 - 10 - integer*8, parameter :: b4_o =3D 2147483647 + 5 + + ! This tests the GDB overflow behavior when using a KIND parameter too s= mall + ! to hold the actual output argument. This is done for 1, 2, and 4 byte + ! overflow. On 32-bit machines most compilers will complain when trying= to + ! allocate an array with ranges outside the 4 byte integer range. + ! We take the byte size of a C pointer as indication as to whether or no= t we + ! are on a 32 bit machine an skip the 4 byte overflow tests in that case. + integer, parameter :: bytes_c_ptr =3D C_SIZEOF(C_NULL_PTR) + + integer*8, parameter :: max_signed_4byte_int =3D 2147483647 + integer*8, parameter :: b4 =3D max_signed_4byte_int - 10 + integer*8 :: b4_o + logical :: is_64_bit =20 integer, allocatable :: array_1d_1bytes_overflow (:) integer, allocatable :: array_1d_2bytes_overflow (:) @@ -84,6 +97,15 @@ program test integer, allocatable :: array_2d_2bytes_overflow (:,:) integer, allocatable :: array_3d_1byte_overflow (:,:,:) =20 + ! Set the 4 byte overflow only on 64 bit machines. + if (bytes_c_ptr < 8) then + b4_o =3D 0 + is_64_bit =3D .FALSE. + else + b4_o =3D max_signed_4byte_int + 5 + is_64_bit =3D .TRUE. + end if + ! Allocate or associate any variables as needed. allocate (other (-5:4, -2:7)) pointer2d =3D> tarray @@ -91,8 +113,9 @@ program test =20 allocate (array_1d_1bytes_overflow (-b1_o:-b1)) allocate (array_1d_2bytes_overflow (b2:b2_o)) - allocate (array_1d_4bytes_overflow (-b4_o:-b4)) - + if (is_64_bit) then + allocate (array_1d_4bytes_overflow (-b4_o:-b4)) + end if allocate (array_2d_1byte_overflow (-b1_o:-b1,b1:b1_o)) allocate (array_2d_2bytes_overflow (b2:b2_o,-b2_o:b2)) =20 @@ -116,7 +139,9 @@ program test DO_TEST (array_1d_1bytes_overflow) DO_TEST (array_1d_2bytes_overflow) =20 - DO_TEST (array_1d_4bytes_overflow) + if (is_64_bit) then + DO_TEST (array_1d_4bytes_overflow) + end if DO_TEST (array_2d_1byte_overflow) DO_TEST (array_2d_2bytes_overflow) DO_TEST (array_3d_1byte_overflow) @@ -130,7 +155,9 @@ program test deallocate (array_2d_2bytes_overflow) deallocate (array_2d_1byte_overflow) =20 - deallocate (array_1d_4bytes_overflow) + if (is_64_bit) then + deallocate (array_1d_4bytes_overflow) + end if deallocate (array_1d_2bytes_overflow) deallocate (array_1d_1bytes_overflow) =20 diff --git a/gdb/testsuite/gdb.fortran/lbound-ubound.exp b/gdb/testsuite/gd= b.fortran/lbound-ubound.exp index 334713666e0..6be9d03af6b 100644 --- a/gdb/testsuite/gdb.fortran/lbound-ubound.exp +++ b/gdb/testsuite/gdb.fortran/lbound-ubound.exp @@ -222,10 +222,15 @@ gdb_test "p lbound(array_1d_2bytes_overflow, 1, 2)" "= =3D 32757" gdb_test "p ubound(array_1d_2bytes_overflow, 1, 2)" "=3D -32766" gdb_test "p ubound(array_1d_2bytes_overflow, 1, 4)" "=3D 32770" =20 -gdb_test "p lbound(array_1d_4bytes_overflow, 1, 4)" "=3D 2147483644" -gdb_test "p lbound(array_1d_4bytes_overflow, 1, 8)" "=3D -2147483652" -gdb_test "p ubound(array_1d_4bytes_overflow, 1, 4)" "=3D -2147483637" -gdb_test "p lbound(array_1d_4bytes_overflow)" "=3D \\(2147483644\\)" +# On 32-bit machines most compilers will complain when trying to allocate = an +# array with ranges outside the 4 byte integer range. As the behavior is +# compiler implementation dependent, we do not run these test on 32 bit ta= rgets. +if {[is_64_target]} { + gdb_test "p lbound(array_1d_4bytes_overflow, 1, 4)" "=3D 2147483644" + gdb_test "p lbound(array_1d_4bytes_overflow, 1, 8)" "=3D -2147483652" + gdb_test "p ubound(array_1d_4bytes_overflow, 1, 4)" "=3D -2147483637" + gdb_test "p lbound(array_1d_4bytes_overflow)" "=3D \\(2147483644\\)" +} =20 # Ensure we reached the final breakpoint. If more tests have been added # to the test script, and this starts failing, then the safety 'while' diff --git a/gdb/testsuite/gdb.fortran/size.f90 b/gdb/testsuite/gdb.fortran= /size.f90 index c924d846736..57e8c5fc84a 100644 --- a/gdb/testsuite/gdb.fortran/size.f90 +++ b/gdb/testsuite/gdb.fortran/size.f90 @@ -17,6 +17,7 @@ ! Start of test program. ! program test + use ISO_C_BINDING, only: C_NULL_PTR, C_SIZEOF =20 ! Things to perform tests on. integer, target :: array_1d (1:10) =3D 0 @@ -30,7 +31,17 @@ program test =20 integer, parameter :: b1_o =3D 127 + 1 integer, parameter :: b2_o =3D 32767 + 3 - integer*8, parameter :: b4_o =3D 2147483647 + 5 + + ! This test tests the GDB overflow behavior when using a KIND parameter + ! too small to hold the actual output argument. This is done for 1, 2, = and + ! 4 byte overflow. On 32-bit machines most compilers will complain when + ! trying to allocate an array with ranges outside the 4 byte integer ran= ge. + ! We take the byte size of a C pointer as indication as to whether or no= t we + ! are on a 32 bit machine an skip the 4 byte overflow tests in that case. + integer, parameter :: bytes_c_ptr =3D C_SIZEOF(C_NULL_PTR) + integer*8, parameter :: max_signed_4byte_int =3D 2147483647 + integer*8 :: b4_o + logical :: is_64_bit =20 integer, allocatable :: array_1d_1byte_overflow (:) integer, allocatable :: array_1d_2bytes_overflow (:) @@ -42,12 +53,22 @@ program test ! Loop counters. integer :: s1, s2 =20 + ! Set the 4 byte overflow only on 64 bit machines. + if (bytes_c_ptr < 8) then + b4_o =3D 0 + is_64_bit =3D .FALSE. + else + b4_o =3D max_signed_4byte_int + 5 + is_64_bit =3D .TRUE. + end if + allocate (array_1d_1byte_overflow (1:b1_o)) allocate (array_1d_2bytes_overflow (1:b2_o)) - allocate (array_1d_4bytes_overflow (1:b4_o)) - + if (is_64_bit) then + allocate (array_1d_4bytes_overflow (b4_o-b2_o:b4_o)) + end if allocate (array_2d_1byte_overflow (1:b1_o, 1:b1_o)) - allocate (array_2d_2bytes_overflow (1:b2_o, 1:b2_o)) + allocate (array_2d_2bytes_overflow (b2_o-b1_o:b2_o, b2_o-b1_o:b2_o)) =20 allocate (array_3d_1byte_overflow (1:b1_o, 1:b1_o, 1:b1_o)) =20 @@ -123,8 +144,10 @@ program test call test_size_4 (size (array_1d_1byte_overflow, 1)) call test_size_4 (size (array_1d_2bytes_overflow, 1)) =20 - call test_size_4 (size (array_1d_4bytes_overflow)) - call test_size_4 (size (array_1d_4bytes_overflow, 1)) + if (is_64_bit) then + call test_size_4 (size (array_1d_4bytes_overflow)) + call test_size_4 (size (array_1d_4bytes_overflow, 1)) + end if =20 call test_size_4 (size (array_2d_1byte_overflow, 1)) call test_size_4 (size (array_2d_1byte_overflow, 2)) @@ -139,7 +162,9 @@ program test =20 call test_size_1 (size (array_1d_1byte_overflow, 1, 1)) call test_size_1 (size (array_1d_2bytes_overflow, 1, 1)) - call test_size_1 (size (array_1d_4bytes_overflow, 1, 1)) + if (is_64_bit) then + call test_size_1 (size (array_1d_4bytes_overflow, 1, 1)) + end if =20 call test_size_1 (size (array_2d_1byte_overflow, 1, 1)) call test_size_1 (size (array_2d_1byte_overflow, 2, 1)) @@ -153,7 +178,9 @@ program test ! Kind 2. call test_size_2 (size (array_1d_1byte_overflow, 1, 2)) call test_size_2 (size (array_1d_2bytes_overflow, 1, 2)) - call test_size_2 (size (array_1d_4bytes_overflow, 1, 2)) + if (is_64_bit) then + call test_size_2 (size (array_1d_4bytes_overflow, 1, 2)) + end if =20 call test_size_2 (size (array_2d_1byte_overflow, 1, 2)) call test_size_2 (size (array_2d_1byte_overflow, 2, 2)) @@ -167,7 +194,9 @@ program test ! Kind 4. call test_size_4 (size (array_1d_1byte_overflow, 1, 4)) call test_size_4 (size (array_1d_2bytes_overflow, 1, 4)) - call test_size_4 (size (array_1d_4bytes_overflow, 1, 4)) + if (is_64_bit) then + call test_size_4 (size (array_1d_4bytes_overflow, 1, 4)) + end if =20 call test_size_4 (size (array_2d_1byte_overflow, 1, 4)) call test_size_4 (size (array_2d_1byte_overflow, 2, 4)) @@ -181,7 +210,9 @@ program test ! Kind 8. call test_size_8 (size (array_1d_1byte_overflow, 1, 8)) call test_size_8 (size (array_1d_2bytes_overflow, 1, 8)) - call test_size_8 (size (array_1d_4bytes_overflow, 1, 8)) + if (is_64_bit) then + call test_size_8 (size (array_1d_4bytes_overflow, 1, 8)) + end if =20 call test_size_8 (size (array_2d_1byte_overflow, 1, 8)) call test_size_8 (size (array_2d_1byte_overflow, 2, 8)) @@ -202,7 +233,9 @@ program test deallocate (array_2d_2bytes_overflow) deallocate (array_2d_1byte_overflow) =20 - deallocate (array_1d_4bytes_overflow) + if (is_64_bit) then + deallocate (array_1d_4bytes_overflow) + end if deallocate (array_1d_2bytes_overflow) deallocate (array_1d_1byte_overflow)