public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb] gdb/testsuite: fix testsuite regressions for unix/-m32 board
@ 2022-05-10 12:55 Nils-Christian Kempke
  0 siblings, 0 replies; only message in thread
From: Nils-Christian Kempke @ 2022-05-10 12:55 UTC (permalink / raw)
  To: gdb-cvs

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6dc7160b2d598201653f74d65d4c4d34a0284f6c

commit 6dc7160b2d598201653f74d65d4c4d34a0284f6c
Author: Nils-Christian Kempke <nils-christian.kempke@intel.com>
Date:   Wed Apr 20 12:30:48 2022 +0200

    gdb/testsuite: fix testsuite regressions for unix/-m32 board
    
    This commit fixes two regressions introduced by
    891e4190ba705373eec7b374209478215fff5401.
    
    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.
    
    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.
    
    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_BINDING
    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 skip
    the 4 byte overflow tests if the procedure is_64_target evaluates to false.
    
    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.
    
    With this patch both test run fine with the unix/-m32 board and
    gcc/gfortran (9.4) as well as the standard board file.
    
    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.
    
    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
    
      integer*8, parameter :: var = 2147483647 + 5.
    
    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
    
      integer*8 :: var
      var = 2147483647 + 5
    
    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 deduces
    the type the additon is done in as Integer*4.  So var will actually
    contain the value -2147483644 after this.  The lines
    
      integer*8 :: var
      var = 2147483652
    
    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
    
      integer*8, parameter :: helper = 2147483647
      integer*8 :: var
      var = helper + 5.
    
    This works on all 3 compilers as expected.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29053
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29054

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/gdb.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 = 127 + 2
   integer, parameter :: b2 = 32767 - 10
   integer, parameter :: b2_o = 32767 + 3
-  integer*8, parameter :: b4 = 2147483647 - 10
-  integer*8, parameter :: b4_o = 2147483647 + 5
+
+  ! This 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 range.
+  ! We take the byte size of a C pointer as indication as to whether or not we
+  ! are on a 32 bit machine an skip the 4 byte overflow tests in that case.
+  integer, parameter :: bytes_c_ptr = C_SIZEOF(C_NULL_PTR)
+
+  integer*8, parameter :: max_signed_4byte_int = 2147483647
+  integer*8, parameter :: b4 = max_signed_4byte_int - 10
+  integer*8 :: b4_o
+  logical :: is_64_bit
 
   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 (:,:,:)
 
+  ! Set the 4 byte overflow only on 64 bit machines.
+  if (bytes_c_ptr < 8) then
+    b4_o = 0
+    is_64_bit = .FALSE.
+  else
+    b4_o = max_signed_4byte_int + 5
+    is_64_bit = .TRUE.
+  end if
+
   ! Allocate or associate any variables as needed.
   allocate (other (-5:4, -2:7))
   pointer2d => tarray
@@ -91,8 +113,9 @@ program test
 
   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))
 
@@ -116,7 +139,9 @@ program test
   DO_TEST (array_1d_1bytes_overflow)
   DO_TEST (array_1d_2bytes_overflow)
 
-  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)
 
-  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)
 
diff --git a/gdb/testsuite/gdb.fortran/lbound-ubound.exp b/gdb/testsuite/gdb.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)" "= 32757"
 gdb_test "p ubound(array_1d_2bytes_overflow, 1, 2)" "= -32766"
 gdb_test "p ubound(array_1d_2bytes_overflow, 1, 4)" "= 32770"
 
-gdb_test "p lbound(array_1d_4bytes_overflow, 1, 4)" "= 2147483644"
-gdb_test "p lbound(array_1d_4bytes_overflow, 1, 8)" "= -2147483652"
-gdb_test "p ubound(array_1d_4bytes_overflow, 1, 4)" "= -2147483637"
-gdb_test "p lbound(array_1d_4bytes_overflow)" "= \\(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 targets.
+if {[is_64_target]} {
+    gdb_test "p lbound(array_1d_4bytes_overflow, 1, 4)" "= 2147483644"
+    gdb_test "p lbound(array_1d_4bytes_overflow, 1, 8)" "= -2147483652"
+    gdb_test "p ubound(array_1d_4bytes_overflow, 1, 4)" "= -2147483637"
+    gdb_test "p lbound(array_1d_4bytes_overflow)" "= \\(2147483644\\)"
+}
 
 # 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
 
   ! Things to perform tests on.
   integer, target :: array_1d (1:10) = 0
@@ -30,7 +31,17 @@ program test
 
   integer, parameter :: b1_o = 127 + 1
   integer, parameter :: b2_o = 32767 + 3
-  integer*8, parameter :: b4_o = 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 range.
+  ! We take the byte size of a C pointer as indication as to whether or not we
+  ! are on a 32 bit machine an skip the 4 byte overflow tests in that case.
+  integer, parameter :: bytes_c_ptr = C_SIZEOF(C_NULL_PTR)
+  integer*8, parameter :: max_signed_4byte_int = 2147483647
+  integer*8 :: b4_o
+  logical :: is_64_bit
 
   integer, allocatable :: array_1d_1byte_overflow (:)
   integer, allocatable :: array_1d_2bytes_overflow (:)
@@ -42,12 +53,22 @@ program test
   ! Loop counters.
   integer :: s1, s2
 
+  ! Set the 4 byte overflow only on 64 bit machines.
+  if (bytes_c_ptr < 8) then
+    b4_o = 0
+    is_64_bit = .FALSE.
+  else
+    b4_o = max_signed_4byte_int + 5
+    is_64_bit = .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))
 
   allocate (array_3d_1byte_overflow (1:b1_o, 1:b1_o, 1:b1_o))
 
@@ -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))
 
-  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
 
   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
 
   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
 
   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
 
   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
 
   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
 
   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)
 
-  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)


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2022-05-10 12:55 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-10 12:55 [binutils-gdb] gdb/testsuite: fix testsuite regressions for unix/-m32 board Nils-Christian Kempke

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).