Re: [power-iee128] How to specify linker flags
On 02.01.22 23:58, Thomas Koenig wrote: Hi Michael, If you are building libraries that contain modules with multiple long double types, you must use the '-mno-gnu-attribute'. We also use the '-Wno-psabi' option, which silences the warning that you are switching long double types (if glibc is not 2.34 or newer). We may need to tweak -Wno-psabi for use with Fortran. I am now at the point where the object files are also compiled correctly for the gfortran specifics: <_gfortran_specific__abs_r17>: 0: 09 00 43 f4 lxv vs34,0(r3) 4: 48 16 40 fc xsabsqp v2,v2 8: 20 00 80 4e blr However, the linker complains, as you said it would, about the different formats: /opt/at15.0/bin/ld: .libs/maxloc0_4_r16.o uses IBM long double, .libs/_abs_r17.o uses IEEE long double /opt/at15.0/bin/ld: failed to merge target specific data of file .libs/_abs_r17.o I know next to nothing about libtool, so I do not know how to add the flags so the linker can find them. Any pointers? One additional point. The linker does not understand -mno-gnu-attribute: $ /opt/at15.0/bin/ld -mno-gnu-attribute /opt/at15.0/bin/ld: unrecognised emulation mode: no-gnu-attribute Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim elf64ppc elf32ppc elf32ppclinux elf32ppcsim So, waiting for info to proceed. Best regards Thomas
Re: [power-iee128] How to specify linker flags
On Mon, Jan 03, 2022 at 11:19:21AM +0100, Thomas Koenig wrote: > > > If you are building libraries that contain modules with multiple > > > long double > > > types, you must use the '-mno-gnu-attribute'. We also use the > > > '-Wno-psabi' > > > option, which silences the warning that you are switching long > > > double types (if > > > glibc is not 2.34 or newer). We may need to tweak -Wno-psabi for > > > use with > > > Fortran. > > > > I am now at the point where the object files are also compiled correctly > > for the gfortran specifics: > > > > <_gfortran_specific__abs_r17>: > > 0: 09 00 43 f4 lxv vs34,0(r3) > > 4: 48 16 40 fc xsabsqp v2,v2 > > 8: 20 00 80 4e blr > > > > However, the linker complains, as you said it would, about the different > > formats: > > > > /opt/at15.0/bin/ld: .libs/maxloc0_4_r16.o uses IBM long double, > > .libs/_abs_r17.o uses IEEE long double > > /opt/at15.0/bin/ld: failed to merge target specific data of file > > .libs/_abs_r17.o > > > > I know next to nothing about libtool, so I do not know how to > > add the flags so the linker can find them. > > > > Any pointers? > > One additional point. The linker does not understand > -mno-gnu-attribute: > > $ /opt/at15.0/bin/ld -mno-gnu-attribute > /opt/at15.0/bin/ld: unrecognised emulation mode: no-gnu-attribute > Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim > elf64ppc elf32ppc elf32ppclinux elf32ppcsim > > So, waiting for info to proceed. -mno-gnu-attribute isn't a linker flag, but a compiler flag. And e.g. libstdc++ configure uses it while compiling itself on powerpc*linux: LONG_DOUBLE_COMPAT_FLAGS="$LONG_DOUBLE_COMPAT_FLAGS -mno-gnu-attribute" # Check for IEEE128 support in libm: AC_CHECK_LIB(m, __frexpieee128, [ac_ldbl_ieee128_in_libc=yes], [ac_ldbl_ieee128_in_libc=no]) if test $ac_ldbl_ieee128_in_libc = yes; then # Determine which long double format is the compiler's default: AC_TRY_COMPILE(, [ #ifndef __LONG_DOUBLE_IEEE128__ #error compiler defaults to ibm128 #endif ], [ac_ldbl_ieee128_default=yes], [ac_ldbl_ieee128_default=no]) # Library objects should use default long double format. if test "$ac_ldbl_ieee128_default" = yes; then LONG_DOUBLE_128_FLAGS="-mno-gnu-attribute" # Except for the ones that explicitly use these flags: LONG_DOUBLE_ALT128_COMPAT_FLAGS="-mabi=ibmlongdouble -mno-gnu-attribute -Wno-psabi" else LONG_DOUBLE_128_FLAGS="-mno-gnu-attribute" LONG_DOUBLE_ALT128_COMPAT_FLAGS="-mabi=ieeelongdouble -mno-gnu-attribute -Wno-psabi" fi AC_DEFINE([_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT],1, [Define if compatibility should be provided for alternative 128-bit long double formats.]) port_specific_symbol_files="$port_specific_symbol_files \$(top_srcdir)/config/os/gnu-linux/ldbl-ieee128-extra.ver" ac_ldbl_alt128_compat=yes else ac_ldbl_alt128_compat=no fi ;; The idea behind this is that libstdc++ is written such that it can handle both IBM extended and IEEE quad long double, so its object files are compatible with both. So I think we want: 2022-01-03 Jakub Jelinek * configure.ac (Use -mno-gnu-attribute together with -mabi=ibmlongdouble or -mabi=ieeelongdouble. --- libgfortran/configure.ac2021-12-31 11:08:19.032835533 + +++ libgfortran/configure.ac2022-01-03 10:32:16.927834682 + @@ -163,9 +163,9 @@ if test "x$GCC" = "xyes"; then #error long double is double #endif]], [[(void) 0;]])], -[AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble"; -AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble"; -CFLAGS="$CFLAGS -mabi=ibmlongdouble"; +[AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; +AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; +CFLAGS="$CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; have_real_17=yes]) ;; *) Jakub
Re: [power-iee128] How to specify linker flags
Hi! On Mon, Jan 03, 2022 at 11:19:21AM +0100, Thomas Koenig wrote: > One additional point. The linker does not understand > -mno-gnu-attribute: That is a GCC option, not an ld one. If you use it to compile some file there will be no .gnu.attributes section generated for that translation unit. Segher
[power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran
On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote: > The idea behind this is that libstdc++ is written such that it can handle > both IBM extended and IEEE quad long double, so its object files are > compatible with both. Now tested on powerpc64le-linux (and together with the regenerated file), ok for power-ieee128? 2022-01-03 Jakub Jelinek * configure.ac (Use -mno-gnu-attribute together with -mabi=ibmlongdouble or -mabi=ieeelongdouble. * configure: Regenerated. --- libgfortran/configure.ac.jj 2021-12-31 11:08:19.032835533 + +++ libgfortran/configure.ac2022-01-03 10:32:16.927834682 + @@ -163,9 +163,9 @@ if test "x$GCC" = "xyes"; then #error long double is double #endif]], [[(void) 0;]])], -[AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble"; -AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble"; -CFLAGS="$CFLAGS -mabi=ibmlongdouble"; +[AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; +AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; +CFLAGS="$CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; have_real_17=yes]) ;; *) --- libgfortran/configure.jj2021-12-31 11:08:19.032835533 + +++ libgfortran/configure 2022-01-03 13:55:38.684926082 + @@ -6025,9 +6025,9 @@ main () } _ACEOF if ac_fn_c_try_cpp "$LINENO"; then : - AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble"; -AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble"; -CFLAGS="$CFLAGS -mabi=ibmlongdouble"; + AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; +AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; +CFLAGS="$CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; have_real_17=yes fi rm -f conftest.err conftest.i conftest.$ac_ext Jakub
[patch, power-ieee128, committed] Make the library functions compile correctly
Hello world, the attached patch lets the library compile correctly, as far as I have been able to determine. Committed to the branch. Best regards Thomas Make sure the Fortran specifics have real(kind=16). This brings the library to compile with all specific functions. It also corrects the patsubst patterns so the right files get the flags. It was necessary to manually add -D__powerpc64__ because apparently this is not set for Fortran. libgfortran/ChangeLog: * Makefile.am: Correct files for compilation flags. Add -D__powerpc64__ for Fortran sources. Get kinds.inc from grep of kinds.h and kinds-override.h. * Makefile.in: Regenerate. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Add -mno-gnu-attribute to compile flags. * generated/_abs_c17.F90: Regenerate. * generated/_abs_r17.F90: Regenerate. * generated/_acos_r17.F90: Regenerate. * generated/_acosh_r17.F90: Regenerate. * generated/_aimag_c17.F90: Regenerate. * generated/_aint_r17.F90: Regenerate. * generated/_anint_r17.F90: Regenerate. * generated/_asin_r17.F90: Regenerate. * generated/_asinh_r17.F90: Regenerate. * generated/_atan2_r17.F90: Regenerate. * generated/_atan_r17.F90: Regenerate. * generated/_atanh_r17.F90: Regenerate. * generated/_conjg_c17.F90: Regenerate. * generated/_cos_c17.F90: Regenerate. * generated/_cos_r17.F90: Regenerate. * generated/_cosh_r17.F90: Regenerate. * generated/_dim_r17.F90: Regenerate. * generated/_exp_c17.F90: Regenerate. * generated/_exp_r17.F90: Regenerate. * generated/_log10_r17.F90: Regenerate. * generated/_log_c17.F90: Regenerate. * generated/_log_r17.F90: Regenerate. * generated/_mod_r17.F90: Regenerate. * generated/_sign_r17.F90: Regenerate. * generated/_sin_c17.F90: Regenerate. * generated/_sin_r17.F90: Regenerate. * generated/_sinh_r17.F90: Regenerate. * generated/_sqrt_c17.F90: Regenerate. * generated/_sqrt_r17.F90: Regenerate. * generated/_tan_r17.F90: Regenerate. * generated/_tanh_r17.F90: Regenerate. * kinds-override.h: Adjust to trunk. Change condition to single line so it can be grepped. * m4/specific.m4: Make sure that real=kind16 is used for _r17.F90 and _c17.F90 files. * m4/specific2.m4: Likewise. * mk-kinds-h.sh: Adjust to trunk. diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am index f3e358368cc..efc79d0d0b7 100644 --- a/libgfortran/Makefile.am +++ b/libgfortran/Makefile.am @@ -1075,15 +1075,16 @@ $(patsubst %.F90,%.lo,$(patsubst %.f90,%.lo,$(notdir $(gfor_specific_src: AM selected_real_kind.lo selected_int_kind.lo: AM_FCFLAGS += -fallow-leading-underscore # Build *_r17.F90 and *_c17.F90 with additional -mabi=ieeelongdouble on powerpc64le-linux. + if HAVE_REAL_17 -$(patsubst %_r17.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -$(patsubst %_r17.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -$(patsubst %_c17.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -$(patsubst %_c17.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -$(patsubst %_r16.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble -$(patsubst %_r16.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble -$(patsubst %_c16.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble -$(patsubst %_c16.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble +$(patsubst %_r16.F90,%_r16.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble +$(patsubst %_c16.F90,%_c16.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble +$(patsubst %_r17.F90,%_r17.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -D__powerpc64__ +$(patsubst %_c17.F90,%_c17.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -D__powerpc64__ +$(patsubst %_r16.c,%_r16.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ibmlongdouble +$(patsubst %_c16.c,%_c16.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ibmlongdouble +$(patsubst %_r17.c,%_r17.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ieeelongdouble +$(patsubst %_c17.c,%_c17.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ieeelongdouble endif if IEEE_SUPPORT @@ -1154,8 +1155,8 @@ I_M4_DEPS9=$(I_M4_DEPS) m4/ifindloc2.m4 kinds.h: $(srcdir)/mk-kinds-h.sh $(SHELL) $(srcdir)/mk-kinds-h.sh '@LIBGOMP_CHECKED_INT_KINDS@' '@LIBGOMP_CHECKED_REAL_KINDS@' '$(FCCOMPILE)' > $@ || rm $@ -kinds.inc: kinds.h - grep '^#' < kinds.h > $@ +kinds.inc: kinds.h $(srcdir)/kinds-override.h + cat kinds.h $(srcdir)/kinds-override.h | grep '^#' | grep -v include > $@ c99_
[power-ieee128] libquadmath: Use -mno-gnu-attribute in libquadmath
Hi!
Testing found that we also need libquadmath to be built with
-mno-gnu-attribute, otherwise -mabi=ieeelongdouble programs don't link.
Ok for power-ieee128?
2022-01-03 Jakub Jelinek
* configure.ac: Set XCFLAGS to -mno-gnu-attribute on
powerpc64le*-linux*.
* configure: Regenerated.
--- libquadmath/configure.ac
+++ libquadmath/configure.ac
@@ -352,6 +352,19 @@ fi
# Add CET specific flags if CET is enabled
GCC_CET_FLAGS(CET_FLAGS)
XCFLAGS="$XCFLAGS $CET_FLAGS"
+
+case x$target in
+ xpowerpc64le*-linux*)
+AC_PREPROC_IFELSE(
+ [AC_LANG_PROGRAM([[#if __SIZEOF_LONG_DOUBLE__ != 16
+ #error long double is double
+ #endif]],
+ [[(void) 0;]])],
+ [XCFLAGS="$XCFLAGS -mno-gnu-attribute"])
+;;
+ *)
+;;
+esac
AC_SUBST(XCFLAGS)
AC_CACHE_SAVE
--- libquadmath/configure
+++ libquadmath/configure
@@ -13096,6 +13096,30 @@ fi
XCFLAGS="$XCFLAGS $CET_FLAGS"
+case x$target in
+ xpowerpc64le*-linux*)
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+#if __SIZEOF_LONG_DOUBLE__ != 16
+ #error long double is double
+ #endif
+int
+main ()
+{
+(void) 0;
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_cpp "$LINENO"; then :
+ XCFLAGS="$XCFLAGS -mno-gnu-attribute"
+fi
+rm -f conftest.err conftest.i conftest.$ac_ext
+;;
+ *)
+;;
+esac
+
cat >confcache <<\_ACEOF
# This file is a shell script that caches the results of configure
Jakub
Re: [power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran
Hi Jakub, On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote: The idea behind this is that libstdc++ is written such that it can handle both IBM extended and IEEE quad long double, so its object files are compatible with both. Now tested on powerpc64le-linux (and together with the regenerated file), ok for power-ieee128? Since you posted it, I had already tested this and included it into the patch I pushed a couple of minutes ago. So, OK, and I already pushed it :-) Thanks a lot for your help in this! Best regards Thomas
[power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
Hi!
The following patch adds the library side of -mabi=ieeelongdouble
I/O support.
There is one issue to be resolved though, for the sake of libgfortran.a
built on an older powerpc64le-linux system (glibc older than 2.32) and
then deployed on glibc 2.32 or later, I believe we want to use
_gfortran_transfer_real128_write etc. APIs so that we force in libquadmath
in that case. The following patch does that, but unfortunately it means
that right now those
512: 001a31d056 FUNCGLOBAL DEFAULT 11
_gfortran_transfer_real128@@GFORTRAN_8 [: 8]
920: 001a321056 FUNCGLOBAL DEFAULT 11
_gfortran_transfer_real128_write@@GFORTRAN_8 [: 8]
487: 001a329056 FUNCGLOBAL DEFAULT 11
_gfortran_transfer_complex128_write@@GFORTRAN_8 [: 8]
574: 001a325056 FUNCGLOBAL DEFAULT 11
_gfortran_transfer_complex128@@GFORTRAN_8[: 8]
symbols. But those symbols weren't exported on powerpc64le-linux in
GCC 8, 9, 10 or 11, so they shouldn't be exported @@GFORTRAN_8, but
@@GFORTRAN_12.
So, either we'd need to add e.g. preprocessing support for gfortran.map
or some other way how to make certain symbols appear conditionally at
different symbol versions, or another option would be to choose different
symbol names for those for the powerpc64le-linux cases
(e.g. _gfortran_transfer_{real,complex}ieee128{,_write}).
Any preferences?
2022-01-03 Jakub Jelinek
* libgfortran.h (__acoshieee128, __acosieee128, __asinhieee128,
__asinieee128, __atan2ieee128, __atanhieee128, __atanieee128,
__coshieee128, __cosieee128, __erfieee128, __expieee128,
__fabsieee128, __jnieee128, __log10ieee128, __logieee128,
__powieee128, __sinhieee128, __sinieee128, __sqrtieee128,
__tanhieee128, __tanieee128, __ynieee128): Formatting fixes.
(__strtoieee128, __snprintfieee128): Declare.
* io/io.h (default_width_for_float, default_precision_for_float):
Handle kind == 17.
* io/size_from_kind.c (size_from_real_kind, size_from_complex_kind):
Likewise.
* io/read.c (set_integer, si_max, convert_real, convert_infnan,
read_f): Likewise.
* io/write.c (extract_uint, size_from_kind, set_fnode_default):
Likewise.
* io/write_float.def (DTOA2Q, FDTOA2Q): Define for HAVE_GFC_REAL_17.
(determine_en_precision, get_float_string): Handle kind == 17.
* io/transfer128.c: Use also for HAVE_GFC_REAL_17, but don't drag in
libquadmath if POWER_IEEE128.
--- libgfortran/libgfortran.h.jj2021-12-31 11:45:06.121158716 +
+++ libgfortran/libgfortran.h 2022-01-03 14:32:45.063730903 +
@@ -1936,28 +1936,54 @@ internal_proto(cshift1_16_c17);
/* Prototypes for the POWER __ieee128 functions. */
#ifdef POWER_IEEE128
-extern __float128 __acoshieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __acosieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __asinhieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __asinieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __atan2ieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __atanhieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __atanieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __coshieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __cosieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __erfieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __expieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __fabsieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __jnieee128 (int, __float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __log10ieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __logieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __powieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __sinhieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __sinieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __sqrtieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __tanhieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __tanieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __ynieee128 (int , __float128) __attribute__ ((__nothrow__,
__leaf__));
+extern __float128 __acoshieee128 (__float128)
+ __attribute__ ((__nothrow__, __leaf__));
+extern __float128 __acosieee128 (__float128)
+ __attribute__ ((__nothrow__, __leaf__));
+extern __float128 __asinhieee128 (__
[power-ieee128] fortran: trans-io.c side of -mabi=ieeelongdouble I/O support
Hi!
Here is the compiler side of those changes, but depends of course
on the decision what to do with those *real128* and *complex128* symbols.
With all the 4 patches e.g. print *, var for real(kind=16) var; var = 1.0;
works both with -mabi=ibmlongdouble and -mabi=ieeelongdouble.
2022-01-03 Jakub Jelinek
* trans-io.c (transfer_namelist_element): Use gfc_type_abi_kind,
formatting fixes.
(transfer_expr): Use gfc_type_abi_kind, use *REAL128* APIs even
for abi_kind == 17.
--- gcc/fortran/trans-io.c.jj 2021-12-31 11:00:15.052190585 +
+++ gcc/fortran/trans-io.c 2022-01-03 14:20:55.238159269 +
@@ -1765,18 +1765,17 @@ transfer_namelist_element (stmtblock_t *
else
tmp = build_int_cst (gfc_charlen_type_node, 0);
+ int abi_kind = gfc_type_abi_kind (ts);
if (dtio_proc == null_pointer_node)
-tmp = build_call_expr_loc (input_location,
- iocall[IOCALL_SET_NML_VAL], 6,
- dt_parm_addr, addr_expr, string,
- build_int_cst (gfc_int4_type_node, ts->kind),
- tmp, dtype);
+tmp = build_call_expr_loc (input_location, iocall[IOCALL_SET_NML_VAL], 6,
+ dt_parm_addr, addr_expr, string,
+ build_int_cst (gfc_int4_type_node, abi_kind),
+ tmp, dtype);
else
-tmp = build_call_expr_loc (input_location,
- iocall[IOCALL_SET_NML_DTIO_VAL], 8,
- dt_parm_addr, addr_expr, string,
- build_int_cst (gfc_int4_type_node, ts->kind),
- tmp, dtype, dtio_proc, vtable);
+tmp = build_call_expr_loc (input_location, iocall[IOCALL_SET_NML_DTIO_VAL],
+ 8, dt_parm_addr, addr_expr, string,
+ build_int_cst (gfc_int4_type_node, abi_kind),
+ tmp, dtype, dtio_proc, vtable);
gfc_add_expr_to_block (block, tmp);
/* If the object is an array, transfer rank times:
@@ -2298,7 +2297,7 @@ transfer_expr (gfc_se * se, gfc_typespec
ts->kind = gfc_index_integer_kind;
}
- kind = ts->kind;
+ kind = gfc_type_abi_kind (ts);
function = NULL;
arg2 = NULL;
arg3 = NULL;
@@ -2318,14 +2317,14 @@ transfer_expr (gfc_se * se, gfc_typespec
arg2 = build_int_cst (integer_type_node, kind);
if (last_dt == READ)
{
- if (gfc_real16_is_float128 && ts->kind == 16)
+ if ((gfc_real16_is_float128 && kind == 16) || kind == 17)
function = iocall[IOCALL_X_REAL128];
else
function = iocall[IOCALL_X_REAL];
}
else
{
- if (gfc_real16_is_float128 && ts->kind == 16)
+ if ((gfc_real16_is_float128 && kind == 16) || kind == 17)
function = iocall[IOCALL_X_REAL128_WRITE];
else
function = iocall[IOCALL_X_REAL_WRITE];
@@ -2337,14 +2336,14 @@ transfer_expr (gfc_se * se, gfc_typespec
arg2 = build_int_cst (integer_type_node, kind);
if (last_dt == READ)
{
- if (gfc_real16_is_float128 && ts->kind == 16)
+ if ((gfc_real16_is_float128 && kind == 16) || kind == 17)
function = iocall[IOCALL_X_COMPLEX128];
else
function = iocall[IOCALL_X_COMPLEX];
}
else
{
- if (gfc_real16_is_float128 && ts->kind == 16)
+ if ((gfc_real16_is_float128 && kind == 16) || kind == 17)
function = iocall[IOCALL_X_COMPLEX128_WRITE];
else
function = iocall[IOCALL_X_COMPLEX_WRITE];
Jakub
Re: [power-ieee128] libquadmath: Use -mno-gnu-attribute in libquadmath
On 03.01.22 16:24, Jakub Jelinek via Fortran wrote: Ok for power-ieee128? OK. Thanks! Best regards Thomas
Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
On Mon, Jan 03, 2022 at 04:36:21PM +0100, Jakub Jelinek via Gcc-patches wrote: > The following patch adds the library side of -mabi=ieeelongdouble > I/O support. > > There is one issue to be resolved though, for the sake of libgfortran.a > built on an older powerpc64le-linux system (glibc older than 2.32) and > then deployed on glibc 2.32 or later, I believe we want to use > _gfortran_transfer_real128_write etc. APIs so that we force in libquadmath > in that case. The following patch does that, but unfortunately it means > that right now those >512: 001a31d056 FUNCGLOBAL DEFAULT 11 > _gfortran_transfer_real128@@GFORTRAN_8 [: 8] >920: 001a321056 FUNCGLOBAL DEFAULT 11 > _gfortran_transfer_real128_write@@GFORTRAN_8 [: 8] >487: 001a329056 FUNCGLOBAL DEFAULT 11 > _gfortran_transfer_complex128_write@@GFORTRAN_8[: 8] >574: 001a325056 FUNCGLOBAL DEFAULT 11 > _gfortran_transfer_complex128@@GFORTRAN_8 [: 8] > symbols. But those symbols weren't exported on powerpc64le-linux in > GCC 8, 9, 10 or 11, so they shouldn't be exported @@GFORTRAN_8, but > @@GFORTRAN_12. > > So, either we'd need to add e.g. preprocessing support for gfortran.map Note, an example of preprocessed version file is e.g. libgomp, in the Makefile it does: # -Wc is only a libtool option. comma = , PREPROCESS = $(subst -Wc$(comma), , $(COMPILE)) -E libgomp.ver: $(top_srcdir)/libgomp.map $(EGREP) -v '#(#| |$$)' $< | \ $(PREPROCESS) -P -include config.h - > $@ || (rm -f $@ ; exit 1) and in libgomp.map it has both: #ifdef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT # If the assembler used lacks the .symver directive or the linker # doesn't support GNU symbol versioning, we have the same symbol in # two versions, which Sun ld chokes on. omp_init_lock; ... #endif so we could similarly have something like: #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; #endif ... #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif ... #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16 _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif or make that dependent on HAVE_GFC_REAL_17 or whatever else (with suitable includes that only define macros and not actual C code). Jakub
Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
Hi Jakub,
So, either we'd need to add e.g. preprocessing support for gfortran.map
or some other way how to make certain symbols appear conditionally at
different symbol versions, or another option would be to choose different
symbol names for those for the powerpc64le-linux cases
(e.g._gfortran_transfer_{real,complex}ieee128{,_write}).
Any preferences?
My personal preference would be the ieee128 variant, it would be cleaner
that way, but I have no strong opinion either way.
So, that variant is OK from my side, but maybe you could wait for
a day or so for anybody else to chime in.
Best regards
Thomas
Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
On 03.01.22 17:26, Jakub Jelinek wrote: so we could similarly have something like: #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; #endif ... #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif ... #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16 _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif That would also work for me. or make that dependent on HAVE_GFC_REAL_17 or whatever else (with suitable includes that only define macros and not actual C code). With my most recent commit, HAVE_GFC_REAL_17 can now be found in kinds.inc if all of the macros above are defined, that should be suitable. I found that __powerpc64__ is not defined when compiling *.F90 files (which is why I added them by hand). Not sure how the preprocessor is invoked on gfortran.map, but if things don't work, this could be related :-) So, it's OK either way with me. What do others think? Best regards Thomas
[PATCH] PR fortran/101762 - ICE on non-constant pointer initialization targets
Dear all,
the initial-data-target for a pointer initialization can be either
NULL() or a non-constant target. In the latter case subscripts of
the target specification (or substring starting and ending points)
must be constant expressions. The patch adds corresponding checks.
I have verified that current Intel and Cray compilers generate similar
errors for the testcase.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From db7562ef764564560fcc59c192df5c00269382ac Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 3 Jan 2022 20:31:10 +0100
Subject: [PATCH] Fortran: reject invalid non-constant pointer initialization
targets
gcc/fortran/ChangeLog:
PR fortran/101762
* decl.c (match_pointer_init): Check that subscripts and substring
indices in specifications of pointer initialization targets are
constant expressions.
gcc/testsuite/ChangeLog:
PR fortran/101762
* gfortran.dg/pr101762.f90: New test.
---
gcc/fortran/decl.c | 34 ++
gcc/testsuite/gfortran.dg/pr101762.f90 | 23 +
2 files changed, 57 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/pr101762.f90
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 4e510cc72ef..4a52a908ac8 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2525,6 +2525,40 @@ match_pointer_init (gfc_expr **init, int procptr)
"initialization at %C"))
return MATCH_ERROR;
+ gfc_ref *ref = (*init)->ref;
+ for (; ref; ref = ref->next)
+{
+ switch (ref->type)
+ {
+ case REF_ARRAY:
+ for (int n = 0; n < ref->u.ar.dimen; n++)
+ if (!gfc_is_constant_expr (ref->u.ar.start[n])
+ || !gfc_is_constant_expr (ref->u.ar.end[n])
+ || !gfc_is_constant_expr (ref->u.ar.stride[n]))
+ {
+ gfc_error ("Every subscript of target specification "
+ "at %L must be a constant expression",
+ &ref->u.ar.where);
+ return MATCH_ERROR;
+ }
+ break;
+
+ case REF_SUBSTRING:
+ if (!gfc_is_constant_expr (ref->u.ss.start)
+ || !gfc_is_constant_expr (ref->u.ss.end))
+ {
+ gfc_error ("Substring starting and ending points of target "
+ "specification at %L must be constant expressions",
+ &ref->u.ss.start->where);
+ return MATCH_ERROR;
+ }
+ break;
+
+ default:
+ break;
+ }
+}
+
return MATCH_YES;
}
diff --git a/gcc/testsuite/gfortran.dg/pr101762.f90 b/gcc/testsuite/gfortran.dg/pr101762.f90
new file mode 100644
index 000..14bcee9ec00
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr101762.f90
@@ -0,0 +1,23 @@
+! { dg-do compile }
+! PR fortran/101762 - ICE on non-constant pointer initialization targets
+! Contributed by G.Steinmetz
+
+program p
+ integer, target :: a(3) = [7, 8, 9]
+ integer, pointer :: x=> a(3)
+ integer, pointer :: y=> a(n()) ! { dg-error "constant expression" }
+ integer, pointer :: z=> a(:n()) ! { dg-error "constant expression" }
+ character(7), target :: c= "abcdefg"
+ character(3), pointer :: c0 => c(2:4)
+ character(3), pointer :: c1 => c(m():) ! { dg-error "constant expression" }
+ character(3), pointer :: c2 => c(:m()) ! { dg-error "constant expression" }
+ print *, x
+contains
+ pure integer function k ()
+k = 2
+ end function k
+ subroutine s ()
+integer, pointer :: yy => a(k()) ! { dg-error "constant expression" }
+print *, yy
+ end subroutine s
+end
--
2.31.1
[power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O
On Mon, Jan 03, 2022 at 06:03:41PM +0100, Thomas Koenig wrote:
> On 03.01.22 17:26, Jakub Jelinek wrote:
>
> > so we could similarly have something like:
> > #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> > && __SIZEOF_LONG_DOUBLE__ == 16)
> > _gfortran_transfer_complex128;
> > _gfortran_transfer_complex128_write;
> > #endif
> > ...
> > #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> > && __SIZEOF_LONG_DOUBLE__ == 16)
> > _gfortran_transfer_real128;
> > _gfortran_transfer_real128_write;
> > #endif
> > ...
> > #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ &&
> > __SIZEOF_LONG_DOUBLE__ == 16
> >_gfortran_transfer_complex128;
> >_gfortran_transfer_complex128_write;
> >_gfortran_transfer_real128;
> >_gfortran_transfer_real128_write;
> > #endif
>
> That would also work for me.
>
> > or make that dependent on HAVE_GFC_REAL_17 or whatever else (with suitable
> > includes that only define macros and not actual C code).
>
> With my most recent commit, HAVE_GFC_REAL_17 can now be found in
> kinds.inc if all of the macros above are defined, that should
> be suitable.
>
> I found that __powerpc64__ is not defined when compiling *.F90 files
> (which is why I added them by hand). Not sure how the preprocessor is
> invoked on gfortran.map, but if things don't work, this could be
> related :-)
>
> So, it's OK either way with me. What do others think?
Here is an updated patch that does that (and now includes also the
gcc/fortran part, since it makes no sense to split the two).
I've run make check-fortran both normally and with
RUNTESTFLAGS='--target_board=unix\{-mabi=ieeelongdouble\}'
The former has:
FAIL: gfortran.dg/reshape_shape_2.f90 -O (internal compiler error)
FAIL: gfortran.dg/reshape_shape_2.f90 -O (test for errors, line 6)
FAIL: gfortran.dg/reshape_shape_2.f90 -O (test for excess errors)
FAIL: gfortran.dg/vector_subscript_1.f90 -O1 execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O2 execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -g execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -Os execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O0 execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O1 execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O2 execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O3 -g execution test
FAIL: gfortran.dg/ieee/large_2.f90 -Os execution test
and the latter has:
FAIL: gfortran.dg/dec_math.f90 -O0 execution test
FAIL: gfortran.dg/dec_math.f90 -O1 execution test
FAIL: gfortran.dg/dec_math.f90 -O2 execution test
FAIL: gfortran.dg/dec_math.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/dec_math.f90 -O3 -g execution test
FAIL: gfortran.dg/dec_math.f90 -Os execution test
FAIL: gfortran.dg/fmt_en.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_en.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_en.f90 -O2 output pattern test
FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions output pattern test
FAIL: gfortran.dg/fmt_en.f90 -O3 -g output pattern test
FAIL: gfortran.dg/fmt_en.f90 -Os output pattern test
FAIL: gfortran.dg/fmt_en_rd.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_en_rd.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_en_rd.f90 -O2 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_en_rd.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O2 output pattern test
FAIL: gfortran.dg/fmt_g0_7.f08 -O0 execution test
FAIL: gfortran.dg/fmt_g0_7.f08 -O1 execution test
FAIL: gfortran.dg/fmt_g0_7.f08 -O2 execution test
FAIL: gfortran.dg/fmt_en_rd.f90 -O3 -g output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions output pattern test
FAIL: gfortran.dg/fmt_g0_7.f08 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/fmt_g0_7.f08 -O3 -g execution test
FAIL: gfortran.dg/fmt_en_rd.f90 -Os output pattern test
FAIL: gfortran.dg/fmt_g0_7.f08 -Os execution test
FAIL: gfortran.dg/fmt_en_rn.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O3 -g output pattern test
FAIL: gfortran.dg/fmt_en_rn.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -Os output pattern test
FAIL: gfortran.dg/fmt_e
Re: [power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O
Hi Jakub, clearly there is still work to fix (but seems e.g. most of the lto tests are related to the gnu attributes stuff:( ). This is looking better than what I expected. Apart from LTO, I expect that a couple of files still do not have the correct flags set when compiling, or maybe some types are wrong. This is now something that can be debugged in detail. Ok? OK. And thanks! Best regards Thomas
