Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On 10.09.21 17:39, Andreas Schwab wrote: This misses the m68k extended real format. * ISO_Fortran_binding.h (CFI_type_long_double) (CFI_type_long_double_Complex) [LDBL_MANT_DIG == 64 && LDBL_MIN_EXP == -16382 && LDBL_MAX_EXP == 16384]: Define. LGTM – thanks! Tobias --- libgfortran/ISO_Fortran_binding.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libgfortran/ISO_Fortran_binding.h b/libgfortran/ISO_Fortran_binding.h index 5335ea471c7..9c42464affa 100644 --- a/libgfortran/ISO_Fortran_binding.h +++ b/libgfortran/ISO_Fortran_binding.h @@ -233,6 +233,13 @@ extern int CFI_setpointer (CFI_cdesc_t *, CFI_cdesc_t *, const CFI_index_t []); #define CFI_type_long_double (CFI_type_Real + (10 << CFI_type_kind_shift)) #define CFI_type_long_double_Complex (CFI_type_Complex + (10 << CFI_type_kind_shift)) +/* This is the 96-bit encoding on m68k; Fortran assigns it kind 10. */ +#elif (LDBL_MANT_DIG == 64 \ + && LDBL_MIN_EXP == -16382 \ + && LDBL_MAX_EXP == 16384) +#define CFI_type_long_double (CFI_type_Real + (10 << CFI_type_kind_shift)) +#define CFI_type_long_double_Complex (CFI_type_Complex + (10 << CFI_type_kind_shift)) + /* This is the IEEE 128-bit encoding, same as float128. */ #elif (LDBL_MANT_DIG == 113 \ && LDBL_MIN_EXP == -16381 \ - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: [PATCH] PR fortran/85130 - Handling of substring range
Dear Harald, hi all, On 12.09.21 20:40, Harald Anlauf via Fortran wrote: in find_substring_ref we erroneously handled given substring start and end indices as unsigned integers. However, gives indices could be negative, which is legal as long as end < start, leading to a string of length zero. The current behavior could lead to a wrong length as well as an invalid read from (compiler) memory. The fix allows to reintroduce code in testcase substr_6.f90 that was erroneously considered as illegal. Regtested on x86_64-pc-linux-gnu. OK for mainline? As this is invalid code, I'd like to backport this fix. OK to both – thanks for patch and all your recent patch work! Tobias Fortran - fix handling of substring start and end indices gcc/fortran/ChangeLog: PR fortran/85130 * expr.c (find_substring_ref): Handle given substring start and end indices as signed integers, not unsigned. gcc/testsuite/ChangeLog: PR fortran/85130 * gfortran.dg/substr_6.f90: Revert commit r8-7574, adding again test that was erroneously considered as illegal. - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: [PATCH] PR fortran/82314 - ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
On 07.09.21 23:44, Harald Anlauf via Fortran wrote: When adding the initializer for an array, we need to make sure that array bounds are properly simplified if that array is a PARAMETER. Otherwise the generated initializer could be wrong and screw up subsequent simplifications, see PR. The minimal solution is to attempt simplification of array bounds before adding the initializer as in the attached patch. (We could place that part in a helper function if this functionality is considered useful elsewhere). Regtested on x86_64-pc-linux-gnu. OK for mainline? OK. Thanks for the patch, Tobias Fortran - ensure simplification of bounds of array-valued named constants gcc/fortran/ChangeLog: PR fortran/82314 * decl.c (add_init_expr_to_sym): For proper initialization of array-valued named constants the array bounds need to be simplified before adding the initializer. gcc/testsuite/ChangeLog: PR fortran/82314 * gfortran.dg/pr82314.f90: New test. - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Wed, 18 Aug 2021, Sandra Loosemore wrote: > I realized last week that having multilib-specific versions of > ISO_Fortran_binding.h (generated by running the compiler to ask what kinds it > supports) was still broken outside of the test support; the directory where > it's being installed isn't on GCC's normal search path. It seemed to me that > it was better to try to find some other solution for this problem than to > venture down what appears to be a rat hole. > > I've come up with this patch to return to a single ISO_Fortran_binding.h file > that uses preprocessor magic to identify the Fortran kind corresponding to the > standard C long double type and the GCC extension types __float128 and > int128_t. : > 2021-08-18 Sandra Loosemore > > libgfortran/ > * ISO_Fortran_binding-1-tmpl.h: Deleted. > * ISO_Fortran_binding-2-tmpl.h: Deleted. > * ISO_Fortran_binding-3-tmpl.h: Deleted. > * ISO_Fortran_binding.h: New file to replace the above. > * Makefile.am (gfor_cdir): Remove MULTISUBDIR. > (ISO_Fortran_binding.h): Simplify to just copy the file. > * Makefile.in: Regenerated. > * mk-kinds-h.sh: Revert pieces no longer needed for > ISO_Fortran_binding.h. This broke bootstrap on i586-unknown-freebsd11: In file included from .../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30: .../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2: error: #error "Can't determine kind of long double" 255 | #error "Can't determine kind of long double" | ^ Does this work on i586-*-linux? % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/ /usr/include/x86/float.h:#define LDBL_MANT_DIG 64 /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381) /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384 This looks like it matches existing Linux case already in place? Hmm, I wonder whether this may be related to the bootstrap compiler, which is clang 10.0.1 on FreeBSD 11 and 12. Apparently not, since even setting CC and CXX to recent GCC builds the same issue occurs. (Note this happens after stage 3, so in hindsight not too surprising that it's independent of the bootstrap compiler.) Gerald
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
Hi Gerald,
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
In file included from
.../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
.../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2:
error: #error "Can't determine kind of long double"
255 | #error "Can't determine kind of long double"
| ^
Does this work on i586-*-linux?
% egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/
/usr/include/x86/float.h:#define LDBL_MANT_DIG 64
/usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381)
/usr/include/x86/float.h:#define LDBL_MAX_EXP 16384
This looks like it matches existing Linux case already in place?
Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo |
./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output?
It might be that /usr/include/x86/float.h is not used; e.g. there is
$(gcc-src)/ginclude/float.h which undef's the LDBL_MAX_EXP to replace it
by a #define using __LDBL_MAX_EXP. Thus, if those are different from the
values under /usr/include, it might be the reason for the fail?
I think it works under Linux, at least the "x86-64 -m32"
libgfortran.{so,a} build and the -m32 testsuite runs do work.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
> On 13.09.21 17:56, Gerald Pfeifer wrote:
> > This broke bootstrap on i586-unknown-freebsd11:
> >
> >In file included from
> > .../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
> >.../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2:
> >error: #error "Can't determine kind of long double"
> >255 | #error "Can't determine kind of long double"
> >| ^
> >
> > Does this work on i586-*-linux?
> >
> >
> > % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/
> > /usr/include/x86/float.h:#define LDBL_MANT_DIG 64
> > /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381)
> > /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384
> >
> > This looks like it matches existing Linux case already in place?
>
> Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo |
> ./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output?
>
> It might be that /usr/include/x86/float.h is not used; e.g. there is
> $(gcc-src)/ginclude/float.h which undef's the LDBL_MAX_EXP to replace it
> by a #define using __LDBL_MAX_EXP. Thus, if those are different from the
> values under /usr/include, it might be the reason for the fail?
>
> I think it works under Linux, at least the "x86-64 -m32"
> libgfortran.{so,a} build and the -m32 testsuite runs do work.
Wouldn't it be better to use the __LDBL_* macros anyway and not rely on
float.h? The header doesn't want to test what float.h tells about the
long double type, but what the compiler knows about it.
Jakub
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On 9/13/21 10:51 AM, Jakub Jelinek wrote:
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
In file included from
.../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
.../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2:
error: #error "Can't determine kind of long double"
255 | #error "Can't determine kind of long double"
| ^
Does this work on i586-*-linux?
% egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/
/usr/include/x86/float.h:#define LDBL_MANT_DIG 64
/usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381)
/usr/include/x86/float.h:#define LDBL_MAX_EXP 16384
This looks like it matches existing Linux case already in place?
Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo |
./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output?
It might be that /usr/include/x86/float.h is not used; e.g. there is
$(gcc-src)/ginclude/float.h which undef's the LDBL_MAX_EXP to replace it
by a #define using __LDBL_MAX_EXP. Thus, if those are different from the
values under /usr/include, it might be the reason for the fail?
I think it works under Linux, at least the "x86-64 -m32"
libgfortran.{so,a} build and the -m32 testsuite runs do work.
Wouldn't it be better to use the __LDBL_* macros anyway and not rely on
float.h? The header doesn't want to test what float.h tells about the
long double type, but what the compiler knows about it.
I originally wrote the code to use the internal GCC __LDBL_* macros as
you suggest, but Tobias complained that then the gfortran-provided .h
file could not be used to compile the C parts of the program with some
other C compiler. (I guess there are people out in the real world who
want to mash up clang-compiled C code with gfortran programs). Maybe it
needs to first check the internal macros and then look for the float.h
versions if it can't find them?
-Sandra
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On 13.09.21 18:59, Sandra Loosemore wrote: On 9/13/21 10:51 AM, Jakub Jelinek wrote: On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote: On 13.09.21 17:56, Gerald Pfeifer wrote: This broke bootstrap on i586-unknown-freebsd11: % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/ /usr/include/x86/float.h:#define LDBL_MANT_DIG 64 /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381) /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384 This looks like it matches existing Linux case already in place? Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo | ./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output? Regarding FreeBSD: Does this output different values? – If yes, we know what to do, otherwise – hmm. [...] Wouldn't it be better to use the __LDBL_* macros anyway and not rely on float.h? The header doesn't want to test what float.h tells about the long double type, but what the compiler knows about it. I originally wrote the code to use the internal GCC __LDBL_* macros as you suggest, but Tobias complained that then the gfortran-provided .h file could not be used to compile the C parts of the program with some other C compiler. For instance, clang does not seem to provide those - and in some cases, it can be useful to mix gfortran code with code complied by other compilers (icc, clang, ...). Maybe it needs to first check the internal macros and then look for the float.h versions if it can't find them? I think that makes sense. (Adding a comment that #include is for non-GCC compilers, only.) Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Mon, Sep 13, 2021 at 07:07:01PM +0200, Tobias Burnus wrote: > Regarding FreeBSD: Does this output different values? – If yes, we know > what to do, otherwise – hmm. > > [...] > > > > Wouldn't it be better to use the __LDBL_* macros anyway and not rely on > > > float.h? The header doesn't want to test what float.h tells about the > > > long double type, but what the compiler knows about it. > > I originally wrote the code to use the internal GCC __LDBL_* macros as > > you suggest, but Tobias complained that then the gfortran-provided .h > > file could not be used to compile the C parts of the program with some > > other C compiler. > For instance, clang does not seem to provide those - and in some cases, > it can be useful to mix gfortran code with code complied by other > compilers (icc, clang, ...). > > Maybe it needs to first check the internal macros and then look for > > the float.h versions if it can't find them? > > I think that makes sense. (Adding a comment that #include is > for non-GCC compilers, only.) At least according to godbolt and my tests, both clang and icc predefine those macros too. But there are other C compilers, sure. So we'd need #if defined (__LDBL_MAX__) && defined (__LDBL_*_) // whatever we need #else #include ... #endif or so. Jakub
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Sep 13 2021, Gerald Pfeifer wrote: > % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/ > /usr/include/x86/float.h:#define LDBL_MANT_DIG 64 > /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381) > /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384 > > This looks like it matches existing Linux case already in place? gcc has its own , see gcc/include/float.h in the build directory. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Mon, Sep 13, 2021 at 05:56:53PM +0200, Gerald Pfeifer wrote: > % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/ > /usr/include/x86/float.h:#define LDBL_MANT_DIG 64 > /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381) > /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384 > > This looks like it matches existing Linux case already in place? Those are indeed the same. But perhaps the FreeBSD float.h header guards those defines with some preprocessor condition? Jakub
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On 9/13/21 11:07 AM, Tobias Burnus wrote:
On 13.09.21 18:59, Sandra Loosemore wrote:
On 9/13/21 10:51 AM, Jakub Jelinek wrote: >>> Wouldn't it be better to use the
__LDBL_* macros anyway and not rely on
float.h? The header doesn't want to test what float.h tells about the
long double type, but what the compiler knows about it.
I originally wrote the code to use the internal GCC __LDBL_* macros as
you suggest, but Tobias complained that then the gfortran-provided .h
file could not be used to compile the C parts of the program with some
other C compiler.
For instance, clang does not seem to provide those - and in some cases,
it can be useful to mix gfortran code with code complied by other
compilers (icc, clang, ...).
Maybe it needs to first check the internal macros and then look for
the float.h versions if it can't find them?
I think that makes sense. (Adding a comment that #include is
for non-GCC compilers, only.)
Here's a patch. Gerald, can you check that this fixes your bootstrap
problem on i586-unknown-freebsd11?
-Sandra
commit b8b19bca743ed678ef1b59f1a363c7fa7d155c43
Author: Sandra Loosemore
Date: Mon Sep 13 19:48:16 2021 -0700
Fortran: Prefer GCC internal macros to float.h in ISO_Fortran_binding.h.
2021-09-13 Sandra Loosemore
libgfortran/
* ISO_Fortran_binding.h: Only include float.h if the C compiler
doesn't have predefined __LDBL_* and __DBL_* macros.
diff --git a/libgfortran/ISO_Fortran_binding.h b/libgfortran/ISO_Fortran_binding.h
index 9c42464..a3c6f80 100644
--- a/libgfortran/ISO_Fortran_binding.h
+++ b/libgfortran/ISO_Fortran_binding.h
@@ -32,7 +32,6 @@ extern "C" {
#include /* Standard ptrdiff_t tand size_t. */
#include /* Integer types. */
-#include /* Macros for floating-point type characteristics. */
/* Constants, defined as macros. */
#define CFI_VERSION 1
@@ -217,40 +216,82 @@ extern int CFI_setpointer (CFI_cdesc_t *, CFI_cdesc_t *, const CFI_index_t []);
#endif
/* The situation with long double support is more complicated; we need to
- examine the type in more detail to figure out its kind. */
+ examine the type in more detail to figure out its kind.
+ GCC and some other compilers predefine the __LDBL* macros; otherwise
+ get the parameters we need from float.h. */
+
+#if (defined (__LDBL_MANT_DIG__) \
+ && defined (__LDBL_MIN_EXP__) \
+ && defined (__LDBL_MAX_EXP__) \
+ && defined (__DBL_MANT_DIG__) \
+ && defined (__DBL_MIN_EXP__) \
+ && defined (__DBL_MAX_EXP__))
+#define __CFI_LDBL_MANT_DIG__ __LDBL_MANT_DIG__
+#define __CFI_LDBL_MIN_EXP__ __LDBL_MIN_EXP__
+#define __CFI_LDBL_MAX_EXP__ __LDBL_MAX_EXP__
+#define __CFI_DBL_MANT_DIG__ __DBL_MANT_DIG__
+#define __CFI_DBL_MIN_EXP__ __DBL_MIN_EXP__
+#define __CFI_DBL_MAX_EXP__ __DBL_MAX_EXP__
+
+#else
+#include
+
+#if (defined (LDBL_MANT_DIG) \
+ && defined (LDBL_MIN_EXP) \
+ && defined (LDBL_MAX_EXP) \
+ && defined (DBL_MANT_DIG) \
+ && defined (DBL_MIN_EXP) \
+ && defined (DBL_MAX_EXP))
+#define __CFI_LDBL_MANT_DIG__ LDBL_MANT_DIG
+#define __CFI_LDBL_MIN_EXP__ LDBL_MIN_EXP
+#define __CFI_LDBL_MAX_EXP__ LDBL_MAX_EXP
+#define __CFI_DBL_MANT_DIG__ DBL_MANT_DIG
+#define __CFI_DBL_MIN_EXP__ DBL_MIN_EXP
+#define __CFI_DBL_MAX_EXP__ DBL_MAX_EXP
+
+#else
+#define CFI_no_long_double 1
+
+#endif /* Definitions from float.h. */
+#endif /* Definitions from compiler builtins. */
+
+/* Can't determine anything about long double support? */
+#if (defined (CFI_no_long_double))
+#define CFI_type_long_double -2
+#define CFI_type_long_double_Complex -2
/* Long double is the same kind as double. */
-#if (LDBL_MANT_DIG == DBL_MANT_DIG \
- && LDBL_MIN_EXP == DBL_MIN_EXP \
- && LDBL_MAX_EXP == DBL_MAX_EXP)
+#elif (__CFI_LDBL_MANT_DIG__ == __CFI_DBL_MANT_DIG__ \
+ && __CFI_LDBL_MIN_EXP__ == __CFI_DBL_MIN_EXP__ \
+ && __CFI_LDBL_MAX_EXP__ == __CFI_DBL_MAX_EXP__)
#define CFI_type_long_double CFI_type_double
#define CFI_type_long_double_Complex CFI_type_double_Complex
/* This is the 80-bit encoding on x86; Fortran assigns it kind 10. */
-#elif (LDBL_MANT_DIG == 64 \
- && LDBL_MIN_EXP == -16381 \
- && LDBL_MAX_EXP == 16384)
+#elif (__CFI_LDBL_MANT_DIG__ == 64 \
+ && __CFI_LDBL_MIN_EXP__ == -16381 \
+ && __CFI_LDBL_MAX_EXP__ == 16384)
#define CFI_type_long_double (CFI_type_Real + (10 << CFI_type_kind_shift))
#define CFI_type_long_double_Complex (CFI_type_Complex + (10 << CFI_type_kind_shift))
/* This is the 96-bit encoding on m68k; Fortran assigns it kind 10. */
-#elif (LDBL_MANT_DIG == 64 \
- && LDBL_MIN_EXP == -16382 \
- && LDBL_MAX_EXP == 16384)
+#elif (__CFI_LDBL_MANT_DIG__ == 64 \
+ && __CFI_LDBL_MIN_EXP__ == -16382 \
+ && __CFI_LDBL_MAX_EXP__ == 16384)
#define CFI_type_long_double (CFI_type_Real + (10 << CFI_type_kind_shift))
#define CFI_type_long_double_Complex (CFI_type_Complex + (10 << CFI_type_kind_shift))
/* This is the IEEE 128-bit e
