mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-22 02:50:08 +08:00
6dc7160b2d
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
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.