Re: New signaling NaN causes 12 testsuite failures
Hi Steve, > New signaling NaN causes 12 testsuite failures Thanks for alerting me. > Line 42 of signal_1.f90 looks wrong unless the > line is testing conversion on assignment. Should > y be x? Indeed. Fixed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c0a4a658097c56fa03d04b8d15c3ea02961d62a4 > Got the following in testsuite/gfortran/gfortran.log > > NaN 7FFFA000 > NaN 7FFFC000 > NaN 7FFFA000 > > and with "stop 300" commented out everything passes. Now to > chase down hex representations for sNaN and qNaN. Suspect > ieee_class() is broken. How does the long double formation look like on x86_64-unknown-freebsd? That test passes on x86_64 for linux and darwin, so I’m wondering what’s different about freebsd… Can you tell me whether the C front-end defines __LDBL_IS_IEC_60559__? What is the value of __LDBL_DIG__? __DBL_DIG__? __FLOAT_WORD_ORDER == __BIG_ENDIAN or __LITTLE_ENDIAN? FX
Re: New signaling NaN causes 12 testsuite failures
> FAIL: gfortran.dg/ieee/signaling_3.f90 -O0 execution test For that one, can you confirm it’s a 64-bit run, not -m32? I’ve fixed that case: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0336ab4e7e2eb58a64d8ee4e5e8083dd53a4d2d FX
Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).
Hi! On 2022-01-24T12:54:27+, Hafiz Abid Qadeer wrote: > On 24/01/2022 08:45, Tobias Burnus wrote: >> On 21.01.22 18:15, Thomas Schwinge wrote: >>> I'm seeing this test case randomly/non-deterministically FAIL to execute, >>> differently on different systems and runs, for example: [...] >>> I'd assume there's some concurrency issue: the problem disappears if I >>> manually specify a lowerish 'OMP_NUM_THREADS' >> >> If one compiles the program with -fsanitize=thread, it shows tons of errors >> :-( Confirmed. > Did you notice similar behavior with > libgomp/testsuite/libgomp.c-c++-common/allocate-1.c? No, this one I always saw PASS. (... which only means so much, of course...) > It was used as base for fortran testcase and it > shows similar warnings with -fthread=sanitize. Confirmed. > I am trying to figure out if the problem you observed > is a general one or just specific to fortran testcase. So, unless the '-fsanitize=thread' issues are bogus -- unlikely ;-) -- it seems a latent issue generally, now fatal with 'libgomp.fortran/allocate-1.f90'. Grüße Thomas - 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] [gfortran] Add support for allocate clause (OpenMP 5.0).
On 25.01.22 10:19, Thomas Schwinge wrote: I am trying to figure out if the problem you observed is a general one or just specific to fortran testcase. So, unless the '-fsanitize=thread' issues are bogus -- unlikely ;-) -- it seems a latent issue generally, now fatal with 'libgomp.fortran/allocate-1.f90'. There is one known issue with libgomp and TSAN (-fsanitize=thread) that I tend to forget about :-( That's according to Jakub, who wrote a while ago: "TSAN doesn't understand what libgomp is doing, unless built with --disable-linux-futex" However, I now tried to disable futex and still get the following. (First result for libgomp.c-c++-common/allocate-1.c). On the other hand, I have the feeling that the configure option is a no op for libgomp. This can also be seen in the configure.ac script, which only for libstdc++ uses the result and the others have a no-op call to 'true' (alias ':'): libgomp/configure.ac:GCC_LINUX_FUTEX(:) libitm/configure.ac:GCC_LINUX_FUTEX(:) libstdc++-v3/configure.ac:GCC_LINUX_FUTEX([AC_DEFINE(HAVE_LINUX_FUTEX, 1, [Define if futex syscall is available.])]) (The check is not completely pointless as some checks are still done; e.g. 'SYS_gettid and SYS_futex required'.) (TSAN did find issues in libgomp in the past, however. But those habe been fixed.) Thus, there might or might not be an issue when TSAN reports one. * * * Glancing at the Fortran testcase, I noted the following, which probably does not cause the problems. But still, I want to mention it: !$omp parallel private (y, v) firstprivate (x) allocate (x, y, v) if (x /= 42) then stop 1 end if v(1) = 7 if ( (and(fl, 2) /= 0) .and. & ((is_64bit_aligned(x) == 0) .or. & (is_64bit_aligned(y) == 0) .or. & (is_64bit_aligned(v(1)) == 0))) then stop 2 end if If one compares this with the C/C++ testcase, I note that there is a barrier before the alignment check in C/C++ but not in Fortran. Additionally, 'v(1) = 7' is set twice and the alignment check happens earlier than in C/C++. Not that that should really matter, but I just saw it. In C/C++: int v[x], w[x]; ... v[0] = 7; v[41] = 8; In Fortran: integer, dimension(x) :: v ... v(1) = 7 v(41) = 8 where 'x == 42'. The Fortran version is not really wrong, but I think the idea is to set the first and last array element - and that's here v(42) and not v(41). BTW: Fortran permits to specify a different lower bound. When converting C/C++ testcases, it can be useful to use the same lower bound also in Fortran: integer :: v(0:x-1) (or: 'integer, dimension(0:x-1) :: v') uses then 0 ... 41 for the indices instead of 1 ... 42. But one has to be careful as Fortran uses the upper bound and C uses the number of elements. (Same with OpenMP array sections in Fortran vs. C.) Tobias PS: The promised data-race warning: == WARNING: ThreadSanitizer: data race (pid=4135381) Read of size 8 at 0x7ffc0888bdc0 by thread T10: #0 foo._omp_fn.2 libgomp.c-c++-common/allocate-1.c:47 (a.out+0x402c05) #1 gomp_thread_start ../../../repos/gcc/libgomp/team.c:129 (libgomp.so.1+0x1e5ed) Previous write of size 8 at 0x7ffc0888bdc0 by main thread: #0 foo._omp_fn.1 libgomp.c-c++-common/allocate-1.c:47 (a.out+0x402aee) #1 GOMP_teams_reg ../../../repos/gcc/libgomp/teams.c:51 (libgomp.so.1+0x3638c) #2 main libgomp.c-c++-common/allocate-1.c:366 (a.out+0x40273e) Location is stack of main thread. Location is global '' at 0x ([stack]+0x1ddc0) Thread T10 (tid=4135398, running) created by main thread at: #0 pthread_create ../../../../repos/gcc/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001 (libtsan.so.2+0x62c76) #1 gomp_team_start ../../../repos/gcc/libgomp/team.c:858 (libgomp.so.1+0x1ec18) #2 main libgomp.c-c++-common/allocate-1.c:366 (a.out+0x40273e) SUMMARY: ThreadSanitizer: data race libgomp.c-c++-common/allocate-1.c:47 in foo._omp_fn.2 == - 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: detect signaling NaNs on targets without issignaling macro in libc
On Mon, Jan 17, 2022 at 12:11:59AM +0100, FX via Gcc-patches wrote:
> This patch is the third in my “signaling NaN” series. For targets with IEEE
> support but without the issignaling macro in libc (i.e., everywhere except
> glibc), this allows us to provide a fallback implementation. In order to keep
> the code in ieee_helper.c relatively readable, I’ve put that new
> implementation in a separate file, issignaling_fallback.h.
>
> The logic is borrowed from different routines in glibc, but gathered into a
> single file and much simpler than the glibc implementation, because we do not
> need to cover all the cases they have (comments with details are available in
> issignaling_fallback.h).
>
> I can’t test this on all the targets I’d like to, obviously. But it was
> tested on x86_64-pc-linux-gnu (where it doesn’t do anything), on
> x86_64-pc-linux-gnu by mimicking the lack of a issignaling macro, and on
> x86_64-apple-darwin (which does not have issignaling).
This doesn't seem to handle the powerpc* IBM double double long double.
__LDBL_IS_IEC_60559__ isn't defined for this type, because it is far from
an IEEE754 type, but it has signaling NaNs - as can be seen in glibc
libc/sysdeps/ieee754/ldbl-128ibm/s_issignalingl.c
the type is a pair of doubles and whether it is a sNaN or qNaN is determined
by whether the first double is a sNaN or qNaN.
Ok for trunk?
2022-01-25 Jakub Jelinek
* ieee/issignaling_fallback.h (__issignalingl): Define for
IBM extended long double are returning __issignaling on the
first double.
--- libgfortran/ieee/issignaling_fallback.h.jj 2022-01-25 12:14:45.404232320
+0100
+++ libgfortran/ieee/issignaling_fallback.h 2022-01-25 12:14:52.504131720
+0100
@@ -137,6 +137,19 @@ __issignalingl (long double x)
return ret || (((exi & 0x7fff) == 0x7fff) && (hxi > 0xc000));
}
+#elif (__LDBL_DIG__ == 31)
+
+/* Long double is 128-bit IBM extended type. */
+
+static inline int
+__issignalingl (long double x)
+{
+ union { long double value; double parts[2]; } u;
+
+ u.value = x;
+ return __issignaling (u.parts[0]);
+}
+
#elif (__LDBL_DIG__ == 33) && __LDBL_IS_IEC_60559__
/* Long double is 128-bit type. */
Jakub
Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc
Hi Jakub, > This doesn't seem to handle the powerpc* IBM double double long double. Do we support the IEEE Fortran modules on this target, despite having a non-IEEE long double? I remember we talked about it when I first implemented it, but can’t remember what choice we ended up making. > __LDBL_IS_IEC_60559__ isn't defined for this type, because it is far from > an IEEE754 type, but it has signaling NaNs - as can be seen in glibc > libc/sysdeps/ieee754/ldbl-128ibm/s_issignalingl.c > the type is a pair of doubles and whether it is a sNaN or qNaN is determined > by whether the first double is a sNaN or qNaN. > > Ok for trunk? It doesn’t hurt to provide an implementation, in any case. OK to push, and thanks for the patch. FX
powerpc64le real(kind=16) and IEEE_{ARITHMETIC,EXCEPTIONS} modules
Hi!
Apparently something we (at least I) have totally missed, we clearly have a
problem with the IEEE modules for the dual -mabi={ibm,ieee}longdouble.
We have:
__ieee_arithmetic_MOD_ieee_class_16;
__ieee_arithmetic_MOD_ieee_support_datatype_16;
__ieee_arithmetic_MOD_ieee_support_denormal_16;
__ieee_arithmetic_MOD_ieee_support_divide_16;
__ieee_arithmetic_MOD_ieee_support_inf_16;
__ieee_arithmetic_MOD_ieee_support_io_16;
__ieee_arithmetic_MOD_ieee_support_nan_16;
__ieee_arithmetic_MOD_ieee_support_rounding_16;
__ieee_arithmetic_MOD_ieee_support_sqrt_16;
__ieee_arithmetic_MOD_ieee_support_standard_16;
__ieee_arithmetic_MOD_ieee_support_underflow_control_16;
__ieee_arithmetic_MOD_ieee_value_16;
__ieee_exceptions_MOD_ieee_support_flag_16;
__ieee_arithmetic_MOD_ieee_support_subnormal_16;
exported from the library, but no corresponding _17 entrypoints.
1) is there any way how to define them in a different source file
so that they can be compiled with -mabi=ieeelongdouble?
2) I'm afraid interfaces like:
interface IEEE_IS_NEGATIVE
procedure &
#ifdef HAVE_GFC_REAL_16
_gfortran_ieee_is_negative_16, &
#endif
#ifdef HAVE_GFC_REAL_10
_gfortran_ieee_is_negative_10, &
#endif
_gfortran_ieee_is_negative_8, _gfortran_ieee_is_negative_4
end interface
public :: IEEE_IS_NEGATIVE
just aren't going to work for the real(kind=16) case
when it has abi_kind 17, the FE will still resolve it to the
_16 case or error out that we have two real(kind=16) entries.
Can everything these modules do be resolved at compile time inline
such that for the abi_kind 17 nothing is really called, or
any other thoughts on this?
Jakub
Re: powerpc64le real(kind=16) and IEEE_{ARITHMETIC,EXCEPTIONS} modules
Hi,
On 25.01.22 12:44, Jakub Jelinek via Fortran wrote:
Apparently something we (at least I) have totally missed, we clearly have a
problem with the IEEE modules for the dual -mabi={ibm,ieee}longdouble.
We have:
__ieee_arithmetic_MOD_ieee_class_16;
__ieee_arithmetic_MOD_ieee_support_datatype_16;
... exported from the library, but no corresponding _17 entrypoints.
Can everything these modules do be resolved at compile time inline
such that for the abi_kind 17 nothing is really called, or
any other thoughts on this?
We already have in gfc_conv_function_expr:
/* The IEEE_ARITHMETIC functions are caught here. */
if (sym->from_intmod == INTMOD_IEEE_ARITHMETIC)
if (gfc_conv_ieee_arithmetic_function (se, expr))
return;
which handles:
if (startswith (name, "_gfortran_ieee_is_nan"))
else if (startswith (name, "_gfortran_ieee_is_finite"))
else if (startswith (name, "_gfortran_ieee_unordered"))
else if (startswith (name, "_gfortran_ieee_is_normal"))
else if (startswith (name, "_gfortran_ieee_is_negative"))
else if (startswith (name, "_gfortran_ieee_copy_sign"))
else if (startswith (name, "_gfortran_ieee_scalb"))
else if (startswith (name, "_gfortran_ieee_next_after"))
else if (startswith (name, "_gfortran_ieee_rem"))
else if (startswith (name, "_gfortran_ieee_logb"))
else if (startswith (name, "_gfortran_ieee_rint"))
else -> 'return false;' -> library call.
Thus, more functions could be handled in the compiler itself.
(Likewise for INTMOD_IEEE_EXCEPTIONS, not that I know whether
that has any relevant functions.)
Alternatively, kind= tweaking could be done here as well.
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: powerpc64le real(kind=16) and IEEE_{ARITHMETIC,EXCEPTIONS} modules
> Thus, more functions could be handled in the compiler itself. > (Likewise for INTMOD_IEEE_EXCEPTIONS, not that I know whether > that has any relevant functions.) In theory, there is no reason why we need an explicit .mod file in the library for any of the three IEEE modules. They would probably be better treated as compiler intrinsics in the front-end itself, in fact, like all other intrinsics. It would also be easier to adjust for generic forms, and provide better diagnostics for mismatching arguments, etc. This seems to be the way to go, as the next standard versions have added even more intrinsics, some of which really shouldn’t be function calls (comparison, ordering, etc). The reason those modules are not fully implemented in the front-end is simple: I didn’t know how to implement them directly in the front-end, and I am not entirely sure we have the appropriate stuff for that. ISO_FORTRAN_ENV is implemented in the front-end, but its members are simpler, really. In a way, you can see this as a call for help: if someone front-end-savvy has ideas how to do this, we could partner up ;) FX
[PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^
Hi all,
attached patch fixes wrong code generation when broadcasting a derived type
containing allocatable and non-allocatable scalars. Furthermore does it prevent
broadcasting of coarray-tokens, which are always local this_image. Thus having
them on a different image makes no sense.
Bootstrapped and regtested ok on x86_64-linux/F35.
Ok, for trunk and backport to 12 and 11-branch after decent time?
I perceived that 12 is closed for this kind of bugfix, therefore asking ok for
13.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2022-01-24 Andre Vehreschild
PR fortran/103790
* trans-array.cc (structure_alloc_comps): Prevent descriptor
stacking for non-array data; do not broadcast caf-tokens.
* trans-intrinsic.cc (conv_co_collective): Prevent generation
of unused descriptor.
gcc/testsuite/ChangeLog:
2022-01-24 Andre Vehreschild
PR fortran/103790
* gfortran.dg/coarray_collectives_18.f90: New test.
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 2f0c8a4d412..1234932aaff 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -9102,6 +9102,10 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
continue;
}
+ /* Do not broadcast a caf_token. These are local to the image. */
+ if (attr->caf_token)
+ continue;
+
add_when_allocated = NULL_TREE;
if (cmp_has_alloc_comps
&& !c->attr.pointer && !c->attr.proc_pointer)
@@ -9134,10 +9138,13 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
if (attr->dimension)
{
tmp = gfc_get_element_type (TREE_TYPE (comp));
- ubound = gfc_full_array_size (&tmpblock, comp,
- c->ts.type == BT_CLASS
- ? CLASS_DATA (c)->as->rank
- : c->as->rank);
+ if (!GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (comp)))
+ ubound = GFC_TYPE_ARRAY_SIZE (TREE_TYPE (comp));
+ else
+ ubound = gfc_full_array_size (&tmpblock, comp,
+ c->ts.type == BT_CLASS
+ ? CLASS_DATA (c)->as->rank
+ : c->as->rank);
}
else
{
@@ -9145,26 +9152,36 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
ubound = build_int_cst (gfc_array_index_type, 1);
}
- cdesc = gfc_get_array_type_bounds (tmp, 1, 0, &gfc_index_one_node,
-&ubound, 1,
-GFC_ARRAY_ALLOCATABLE, false);
+ /* Treat strings like arrays. Or the other way around, do not
+ * generate an additional array layer for scalar components. */
+ if (attr->dimension || c->ts.type == BT_CHARACTER)
+ {
+ cdesc = gfc_get_array_type_bounds (tmp, 1, 0, &gfc_index_one_node,
+&ubound, 1,
+GFC_ARRAY_ALLOCATABLE, false);
- cdesc = gfc_create_var (cdesc, "cdesc");
- DECL_ARTIFICIAL (cdesc) = 1;
+ cdesc = gfc_create_var (cdesc, "cdesc");
+ DECL_ARTIFICIAL (cdesc) = 1;
- gfc_add_modify (&tmpblock, gfc_conv_descriptor_dtype (cdesc),
- gfc_get_dtype_rank_type (1, tmp));
- gfc_conv_descriptor_lbound_set (&tmpblock, cdesc,
- gfc_index_zero_node,
- gfc_index_one_node);
- gfc_conv_descriptor_stride_set (&tmpblock, cdesc,
- gfc_index_zero_node,
- gfc_index_one_node);
- gfc_conv_descriptor_ubound_set (&tmpblock, cdesc,
- gfc_index_zero_node, ubound);
+ gfc_add_modify (&tmpblock, gfc_conv_descriptor_dtype (cdesc),
+ gfc_get_dtype_rank_type (1, tmp));
+ gfc_conv_descriptor_lbound_set (&tmpblock, cdesc,
+ gfc_index_zero_node,
+ gfc_index_one_node);
+ gfc_conv_descriptor_stride_set (&tmpblock, cdesc,
+ gfc_index_zero_node,
+ gfc_index_one_node);
+ gfc_conv_descriptor_ubound_set (&tmpblock, cdesc,
+ gfc_index_zero_node, ubound);
+ }
if (attr->dimension)
- comp = gfc_conv_descriptor_data_get (comp);
+ {
+ if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (comp)))
+ comp = gfc_conv_descriptor_data_get (comp);
+
Re: New signaling NaN causes 12 testsuite failures
On Tue, Jan 25, 2022 at 09:09:15AM +0100, FX wrote: > > FAIL: gfortran.dg/ieee/signaling_3.f90 -O0 execution test > > For that one, can you confirm it’s a 64-bit run, not -m32? It looks like a multilib build, but the FreeBSD toolchain cannot find its ls-elf32.so.1 dynamic loader (or I need to set appropriate LD_32_* environment during bootstrap). I'll likely need to engage freebsd-toolchain people to get multilib working. I'll disable multilib for now and do a new bootstrap. -- Steve
Re: New signaling NaN causes 12 testsuite failures
On Tue, Jan 25, 2022 at 09:05:55AM +0100, FX wrote:
> Hi Steve,
>
> > New signaling NaN causes 12 testsuite failures
>
> Thanks for alerting me.
>
> > Line 42 of signal_1.f90 looks wrong unless the
> > line is testing conversion on assignment. Should
> > y be x?
>
> Indeed. Fixed:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c0a4a658097c56fa03d04b8d15c3ea02961d62a4
>
Thanks.
> > Got the following in testsuite/gfortran/gfortran.log
> >
> > NaN 7FFFA000
> > NaN 7FFFC000
> > NaN 7FFFA000
> >
> > and with "stop 300" commented out everything passes. Now to
> > chase down hex representations for sNaN and qNaN. Suspect
> > ieee_class() is broken.
>
> How does the long double formation look like on x86_64-unknown-freebsd?
Ugh. I'm afraid that this might be a mess.
> That test passes on x86_64 for linux and darwin, so I’m wondering
> what’s different about freebsd…
>
> Can you tell me whether the C front-end defines __LDBL_IS_IEC_60559__?
> What is the value of __LDBL_DIG__? __DBL_DIG__?
> __FLOAT_WORD_ORDER == __BIG_ENDIAN or __LITTLE_ENDIAN?
>
% cat a.c
#include
int
main(void)
{
#ifdef __LDBL_IS_IEC_60559__
printf("__LDBL_IS_IEC_60559__? yes\n");
#else
printf("__LDBL_IS_IEC_60559__? no\n");
#endif
return 0;
};
% gcc11 -o z a.c && ./z<-- initial bootstrap compiler
__LDBL_IS_IEC_60559__? yes
% cc -o z a.c && ./z <-- clang/llvm FreeBSD system compiler
__LDBL_IS_IEC_60559__? no
% ~/work/x/bin/gcc -o z a.c && ./z <-- gcc build from origin/master
__LDBL_IS_IEC_60559__? yes
There might be some strange interaction between FreeBSD native
toolchain binaries and the binaries I build duringi bootstrap.
The LDBL info from /usr/include/x86/float is
#define LDBL_MANT_DIG 64
#define LDBL_EPSILON1.0842021724855044340E-19L
#define LDBL_DIG18
#define LDBL_MIN_EXP(-16381)
#define LDBL_MIN3.3621031431120935063E-4932L
#define LDBL_MIN_10_EXP (-4931)
#define LDBL_MAX_EXP16384
#define LDBL_MAX1.1897314953572317650E+4932L
#define LDBL_MAX_10_EXP 4932
#if __ISO_C_VISIBLE >= 2011
#define LDBL_TRUE_MIN 3.6451995318824746025E-4951L
#define LDBL_DECIMAL_DIG 21
#define LDBL_HAS_SUBNORM 1
#endif /* __ISO_C_VISIBLE >= 2011 */
which is what I expect. How this maps to the __LDBL_DIG__
info, I do not know.
% grep -R __LDBL_DIG__ /usr/include
/usr/include/c++/v1/limits:static _LIBCPP_CONSTEXPR const int digits10 =
__LDBL_DIG__;
% grep -R __FLOAT_WORD_ORDER /usr/include
Returns no hits, but I see
% grep -R __BIG_ENDIAN /usr/include
/usr/include/c++/v1/__config:#ifdef __BIG_ENDIAN__
/usr/include/c++/v1/__config:# if __BIG_ENDIAN__
/usr/include/c++/v1/__config:# endif // __BIG_ENDIAN__
/usr/include/c++/v1/__config:#endif // __BIG_ENDIAN__
/usr/include/c++/v1/__config:# elif __BYTE_ORDER == __BIG_ENDIAN
/usr/include/c++/v1/__config:# else // __BYTE_ORDER == __BIG_ENDIAN
So, maybe __BYTE_ORDER instead of __FLOAT_WORD_ORDER?
--
Steve
Re: New signaling NaN causes 12 testsuite failures
On Tue, Jan 25, 2022 at 09:09:15AM +0100, FX wrote:
> > FAIL: gfortran.dg/ieee/signaling_3.f90 -O0 execution test
>
> For that one, can you confirm it’s a 64-bit run, not -m32?
> I’ve fixed that case:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0336ab4e7e2eb58a64d8ee4e5e8083dd53a4d2d
>
With --disable-multilib, so no -m32 support, I still
signaling_3.f90 failing. In
! { dg-do run { xfail { { i?86-*-* x86_64-*-* } && ilp32 } } }
! x87 / x86-32 ABI is unsuitable for signaling NaNs
I have no idea what ilp32 is trying to do, but if the
second line of the comment means that i387 fpu should be
used, it isn't on freebsd.
--
Steve
Re: New signaling NaN causes 12 testsuite failures
> With --disable-multilib, so no -m32 support, I still
> signaling_3.f90 failing. In
>
> ! { dg-do run { xfail { { i?86-*-* x86_64-*-* } && ilp32 } } }
> ! x87 / x86-32 ABI is unsuitable for signaling NaNs
This just means the test shouldn’t be run on 32-bit Intel.
Can you run this:
#include
#include
#include "issignaling_fallback.h"
int main (void) {
long double z;
z = __builtin_nansl("");
printf("%d\n", issignaling(z));
z = __builtin_nanl("");
printf("%d\n", issignaling(z));
}
compiled with -fsignaling-nans and the issignaling_fallback.h file from
libgfortran?
FX
Re: New signaling NaN causes 12 testsuite failures
On Tue, Jan 25, 2022 at 09:05:55AM +0100, FX wrote:
>
> > Got the following in testsuite/gfortran/gfortran.log
> >
> > NaN 7FFFA000
> > NaN 7FFFC000
> > NaN 7FFFA000
> >
Could be a problem with __builtin_nansl().
#include
#include
int
main(void)
{
union { float x; uint32_t i; }f;
union { double x; uint64_t i; }d;
union { long double x; uint64_t i[2]; } l;
printf("Quiet NaN\n");
f.x = __builtin_nanf("");
printf("%f %x\n", f.x, f.i);
d.x = __builtin_nan("");
printf("%lf %lx\n", d.x, d.i);
l.x = __builtin_nanl("");
printf("%Lf %lx%lx\n", l.x, l.i[1], l.i[0]);
printf("Signaling NaN\n");
f.x = __builtin_nansf("");
printf("%f %x\n", f.x, f.i);
d.x = __builtin_nans("");
printf("%lf %lx\n", d.x, d.i);
l.x = __builtin_nansl("");
printf("%Lf %lx%lx\n", l.x, l.i[1], l.i[0]);
return 0;
}
% ~/work/x/bin/gcc -o z a.c && ./z
Quiet NaN
nan 7fc0
nan 7ff8
nan 7fffc000
Signaling NaN
nan 7fa0
nan 7ff4
nan 7fffa000
s bit is 0, so the 7 is correct. The width of the
exponet is w = 8, 11, and 15 bits for float, double,
and long double. The first significant bit, d, is
then 9, 12, and 16.
s|w---|d
7fc --> 0111 1100
7fa --> 0111 1010
s|-w-| d
7ff8 --> 0111 1000
7ff4 --> 0111 0100
s|---w| d
7fffc -> 0111 1100 <-- should be 7fff8?
7fffa -> 0111 1010 <-- should be 7fff4?
What does linux/darwin show?
--
Steve
Re: New signaling NaN causes 12 testsuite failures
This is x86_64-linux, with the same source: $ gcc-10 v.c -fsignaling-nans && ./a.out Quiet NaN nan 7fc0 nan 7ff8 nan 564e29277fffc000 Signaling NaN nan 7fa0 nan 7ff4 nan 564e29277fffa000
Re: New signaling NaN causes 12 testsuite failures
On Tue, Jan 25, 2022 at 08:52:34PM +0100, FX wrote:
> > With --disable-multilib, so no -m32 support, I still
> > signaling_3.f90 failing. In
> >
> > ! { dg-do run { xfail { { i?86-*-* x86_64-*-* } && ilp32 } } }
> > ! x87 / x86-32 ABI is unsuitable for signaling NaNs
>
> This just means the test shouldn’t be run on 32-bit Intel.
>
> Can you run this:
>
> #include
> #include
> #include "issignaling_fallback.h"
>
> int main (void) {
> long double z;
>
> z = __builtin_nansl("");
> printf("%d\n", issignaling(z));
>
> z = __builtin_nanl("");
> printf("%d\n", issignaling(z));
> }
>
> compiled with -fsignaling-nans and the issignaling_fallback.h file from
> libgfortran?
>
% ~/work/x/bin/gcc -o -I. -fsignaling-nans -o z b.c && ./z
0
0
Quickly read issignaling_fallback.h. It seems you're looking
for bit that distinguishes snan and qnan. Still need to piece
together exactly what the bit manipulation functions are doing.
--
Steve
Re: New signaling NaN causes 12 testsuite failures
On Tue, Jan 25, 2022 at 09:04:05PM +0100, FX wrote: > This is x86_64-linux, with the same source: > > $ gcc-10 v.c -fsignaling-nans && ./a.out > Quiet NaN > nan 7fc0 > nan 7ff8 > nan 564e29277fffc000 > Signaling NaN > nan 7fa0 > nan 7ff4 > nan 564e29277fffa000 > So the 7fffc and 7fffa signatures are equivalent to what I see on FreeBSD (never seen the 564e2927 string before). Maybe an off-by-one bit in issignaling_fallback.h? -- Steve
Re: New signaling NaN causes 12 testsuite failures
On Tue, Jan 25, 2022 at 08:52:34PM +0100, FX wrote:
> > With --disable-multilib, so no -m32 support, I still
> > signaling_3.f90 failing. In
> >
> > ! { dg-do run { xfail { { i?86-*-* x86_64-*-* } && ilp32 } } }
> > ! x87 / x86-32 ABI is unsuitable for signaling NaNs
>
> This just means the test shouldn’t be run on 32-bit Intel.
>
> Can you run this:
>
> #include
> #include
> #include "issignaling_fallback.h"
>
> int main (void) {
> long double z;
>
> z = __builtin_nansl("");
> printf("%d\n", issignaling(z));
>
> z = __builtin_nanl("");
> printf("%d\n", issignaling(z));
> }
>
> compiled with -fsignaling-nans and the issignaling_fallback.h file from
> libgfortran?
>
If in issignaling_fallback.h, I change
#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
...
#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
...
#endif
to
#if 0
...
#else
...
#endif
to force little endian, I get
% ~/work/x/bin/gcc -o -I. -fsignaling-nans -o z b.c && ./z
1
0
so need an equivalent of __FLOAT_WORD_ORDER for at least
FreeBSD.
Found it. https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
Add trailing undersores to __FLOAT_WORD_ORDER and change
__BIG_ENDIAN to __ORDER_BIG_ENDIAN__. Likewise for LITTLE.
--
Steve
Re: New signaling NaN causes 12 testsuite failures
> Found it. https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
>
> Add trailing undersores to __FLOAT_WORD_ORDER and change
> __BIG_ENDIAN to __ORDER_BIG_ENDIAN__. Likewise for LITTLE.
Thanks Steve!
What I wonder is: if those conditions failed, then the struct they define
should have been empty, and therefore the code shouldn’t compile anyway (that
was the intent).
Does the attached patch fix the remaining failures?
FX
commit 03cfe155f46c05e4dda349be2abe467c16789491
Author: Francois-Xavier Coudert
Date: 2022-01-25 21:54:03 +0100
Fortran: fix issignaling() implementation
libgfortran/ChangeLog:
* ieee/issignaling_fallback.h: Fix GCC-specific preprocessor
macros.
diff --git a/libgfortran/ieee/issignaling_fallback.h
b/libgfortran/ieee/issignaling_fallback.h
index 4632bc510f7..fc59481c43b 100644
--- a/libgfortran/ieee/issignaling_fallback.h
+++ b/libgfortran/ieee/issignaling_fallback.h
@@ -103,12 +103,12 @@ typedef union
long double value;
struct
{
-#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
+#if __FLOAT_WORD_ORDER__ == __ORDER_BIG_ENDIAN__
int sign_exponent:16;
unsigned int empty:16;
uint32_t msw;
uint32_t lsw;
-#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
+#elif __FLOAT_WORD_ORDER__ == __ORDER_LITTLE_ENDIAN__
uint32_t lsw;
uint32_t msw;
int sign_exponent:16;
@@ -146,10 +146,10 @@ typedef union
long double value;
struct
{
-#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
+#if __FLOAT_WORD_ORDER__ == __ORDER_BIG_ENDIAN__
uint64_t msw;
uint64_t lsw;
-#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
+#elif __FLOAT_WORD_ORDER__ == __ORDER_LITTLE_ENDIAN__
uint64_t lsw;
uint64_t msw;
#endif
@@ -191,10 +191,10 @@ typedef union
__float128 value;
struct
{
-#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
+#if __FLOAT_WORD_ORDER__ == __ORDER_BIG_ENDIAN__
uint64_t msw;
uint64_t lsw;
-#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
+#elif __FLOAT_WORD_ORDER__ == __ORDER_LITTLE_ENDIAN__
uint64_t lsw;
uint64_t msw;
#endif
[pushed] PR/fortran 104227 - [9/10/11/12 Regression] ICE virtual memory exhausted: Cannot allocate memory
Dear Fortranners,
committed as obvious after regtesting on x86_64-pc-linux-gnu.
We already had a check for the MOLD argument to the TRANSFER
intrinsic for having storage size 0, which failed if MOLD was
an EXPR_VARIABLE although having rank != 0. Duh.
Adjusting that check fixed the issue.
I intend to backport to the affected branches after some
waiting time.
Thanks,
Harald
From ec543c9833c2d9283c035cd8430849eb4ec04406 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 25 Jan 2022 21:56:39 +0100
Subject: [PATCH] Fortran: MOLD argument to TRANSFER intrinsic having storage
size zero
gcc/fortran/ChangeLog:
PR fortran/104227
* check.cc (gfc_calculate_transfer_sizes): Fix checking of arrays
passed as MOLD argument to the TRANSFER intrinsic for having
storage size zero.
gcc/testsuite/ChangeLog:
PR fortran/104227
* gfortran.dg/transfer_check_6.f90: New test.
---
gcc/fortran/check.cc | 2 +-
gcc/testsuite/gfortran.dg/transfer_check_6.f90 | 11 +++
2 files changed, 12 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/transfer_check_6.f90
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 4fa05ee7e9b..d6c6767ae9e 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6151,7 +6151,7 @@ gfc_calculate_transfer_sizes (gfc_expr *source, gfc_expr *mold, gfc_expr *size,
* If SIZE is present, the result is an array of rank one and size SIZE.
*/
if (result_elt_size == 0 && *source_size > 0 && !size
- && mold->expr_type == EXPR_ARRAY)
+ && (mold->expr_type == EXPR_ARRAY || mold->rank))
{
gfc_error ("% argument of % intrinsic at %L is an "
"array and shall not have storage size 0 when % "
diff --git a/gcc/testsuite/gfortran.dg/transfer_check_6.f90 b/gcc/testsuite/gfortran.dg/transfer_check_6.f90
new file mode 100644
index 000..dffd0913f0d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/transfer_check_6.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR fortran/104227 - ICE virtual memory exhausted
+! Contributed by G.Steinmetz
+
+program p
+ type t
+ end type
+ type(t) :: x(2)
+ print *, transfer(1, x) ! { dg-error "shall not have storage size 0" }
+ x = transfer(1, x) ! { dg-error "shall not have storage size 0" }
+end
--
2.31.1
Re: New signaling NaN causes 12 testsuite failures
On Tue, Jan 25, 2022 at 09:56:05PM +0100, FX wrote: > > Found it. https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html > > > > Add trailing undersores to __FLOAT_WORD_ORDER and change > > __BIG_ENDIAN to __ORDER_BIG_ENDIAN__. Likewise for LITTLE. > > Thanks Steve! > > What I wonder is: if those conditions failed, then the struct they define > should have been empty, and therefore the code shouldn’t compile anyway (that > was the intent). > > Does the attached patch fix the remaining failures? > Yes! % gmake check-fortran RUNTESTFLAGS="ieee.exp=signaling_\*" ... === gfortran Summary === # of expected passes24 # of unsupported tests 6 -- Steve
Re: [PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^
Hi Andre', Am 25.01.22 um 17:32 schrieb Andre Vehreschild via Fortran: Hi all, attached patch fixes wrong code generation when broadcasting a derived type containing allocatable and non-allocatable scalars. Furthermore does it prevent broadcasting of coarray-tokens, which are always local this_image. Thus having them on a different image makes no sense. Bootstrapped and regtested ok on x86_64-linux/F35. Ok, for trunk and backport to 12 and 11-branch after decent time? I perceived that 12 is closed for this kind of bugfix, therefore asking ok for 13. I do not think that 12 is closed for bugfixing, especially not for fortran. And if my cursory reading of the patch is not misleading, the impact of the patch is really limited to coarrays. You may want to wait for another 1-2 days for additional comments. If not, it is OK from my side. Thanks for the patch! Harald Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: New signaling NaN causes 12 testsuite failures
>> Does the attached patch fix the remaining failures? > > Yes! > > % gmake check-fortran RUNTESTFLAGS="ieee.exp=signaling_\*" > ... >=== gfortran Summary === > > # of expected passes24 > # of unsupported tests 6 Thanks Steve, pushed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fa262add75ab6631bf22b7e2884437ba9c62ed2a FX
