GCC 12.0.0 Status Report (2022-01-10), Stage 3 ends Jan 16th

2022-01-10 Thread Richard Biener via Fortran
Status
==

The GCC development branch is open for general bugfixing (Stage 3)
and will transition to regression and documentation fixing only
(Stage 4) on the end of Jan 16th.

Take the quality data below with a big grain of salt - most of the
new P3 classified bugs will become P1 or P2 (generally every
regression against GCC 11 is to be considered P1 if it concerns
primary or secondary platforms).


Quality Data


Priority  #   Change from last report
---   ---
P1   30   -  4
P2  307   +  1
P3  279   + 42
P4  220   + 13
P5   25
---   ---
Total P1-P3 616   + 39
Total   861   + 52


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2021-November/237741.html


Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

2022-01-10 Thread FX via Fortran
Thanks Mikael. I haven’t been active with gfortran development in a while, but 
I originally wrote those IEEE routines so I believe my understanding of them is 
fair. I will continue posting my next patches to gather comments (if any), but 
they’re relatively straightforward.

The main limitation (not with this patch, but with the next ones) is some 
targets have really weird floating-point formats, and I cannot test on all 
possible targets. Feel free to poke me on any issue that arises, in ML or in 
bugzilla.

Best,
FX


[PING] [PATCH] C, C++, Fortran, OpenMP: Add 'has_device_addr' clause to 'target' construct

2022-01-10 Thread Marcel Vollweiler

Hi,

I'd like to ping the patch for the OpenMP 'has_device_addr' clause on
the target construct:

https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585361.html


Thanks
Marcel
-
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


[PATCH] Fortran: make IEEE_VALUE produce signaling NaNs

2022-01-10 Thread FX via Fortran
Hi,

Second part of a three-patch series to fix PR 82207 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle 
signaling NaNs. This part fixes the library code implementing IEEE_VALUE. To do 
so, I switched that part of library code from Fortran to C, because in C we 
have access to all GCC built-ins related to NaNs/infinities/etc, which is super 
useful for generating the right bit patterns (instead of using roundabout ways, 
like the previous Fortran implementation, for which I am guilty).

I needed to add to kinds.h the value of TINY for each floating-point (which is 
used to produce denormals, by halving TINY).

The patch comes with a testcase, which is still conditional on issignaling 
support at this stage (and therefore will run on glibc targets only).

I had to amend the gfortran.dg/ieee/ieee_10.f90 testcase, which produces 
signaling NaNs while -ffpe-trap=invalid is set. It passed before, but only by 
accident, because we were not actually generating signaling NaNs. I’m not sure 
what is the expected behaviour, but the patch does not affect the real 
behaviour.

Bootstrapped and regtested on x86_64-pc-gnu-linux. OK to commit?

FX



0001-Fortran-Allow-IEEE_CLASS-to-identify-signaling-NaNs.patch
Description: Binary data




0001-Fortran-allow-IEEE_VALUE-to-correctly-return-signali.patch
Description: Binary data


[power-ieee128, committed] Enable conversion selection via environment variable

2022-01-10 Thread Thomas Koenig via Fortran

Hello world,

I have just pushed the attched patch to the branch.

With this patch, the program

tkoenig@gcc-fortran:~/Tst$ cat write_env.f90
program main
  real(kind=16) :: x
  character (len=30) :: conv
  x = 1/3._16
  open 
(10,file="out.dat",status="replace",access="stream",form="unformatted")

  inquire(10,convert=conv)
  print *,conv
  write (10) 1/3._16
end program main

gives the result:

tkoenig@gcc-fortran:~/Tst$ GFORTRAN_CONVERT_UNIT="r16_ibm:10" ./a.out && 
od -w64 -t x1 out.dat

 LITTLE_ENDIAN,R16_IBM
000 55 55 55 55 55 55 d5 3f 56 55 55 55 55 55 75 3c
020
tkoenig@gcc-fortran:~/Tst$ GFORTRAN_CONVERT_UNIT="r16_ieee:10" ./a.out 
&& od -w64 -t x1 out.dat

 LITTLE_ENDIAN,R16_IEEE
000 80 55 55 55 55 55 55 55 55 55 55 55 55 55 fd 3f
020
tkoenig@gcc-fortran:~/Tst$ 
GFORTRAN_CONVERT_UNIT="big_endian:10;r16_ieee:10" ./a.out && od -w64 -t 
x1 out.dat

 BIG_ENDIAN,R16_IEEE
000 3f fd 55 55 55 55 55 55 55 55 55 55 55 55 55 80
020

so things look OK.  In the next few days, I will do a bit more
testing to see if I have missed any corner cases.

So, the only thing missing is handling of the options, but
I think that is not critical (and could be added later; two
separate possibilities might just be enough for most users :-)

So... time to merge the branch into trunk before stage 4
kicks in?

Best regards

Thomas


Handle R16 conversion for POWER in the environment variables.

This patch handles the environment variables for the REAL(KIND=16)
variables like for the little/big-endian routines, so users without
who have no access to the source or are unwilling to recompile
can use this.

Syntax is, for example

GFORTRAN_CONVERT_UNIT="r16_ieee:10;little_endian:10" ./a.out

libgfortran/ChangeLog:

* runtime/environ.c (R16_IEEE): New macro.
(R16_IBM): New macro.
(next_token): Handle IBM R16 conversion cases.
(push_token): Likewise.
(mark_single): Likewise.
(do_parse): Likewise, initialize endian.
diff --git a/libgfortran/runtime/environ.c b/libgfortran/runtime/environ.c
index fe16c080797..ff10fe53f68 100644
--- a/libgfortran/runtime/environ.c
+++ b/libgfortran/runtime/environ.c
@@ -247,6 +247,11 @@ init_variables (void)
 #define SWAP 258
 #define BIG  259
 #define LITTLE   260
+#ifdef HAVE_GFC_REAL_17
+#define R16_IEEE 261
+#define R16_IBM  262
+#endif
+
 /* Some space for additional tokens later.  */
 #define INTEGER  273
 #define END  (-1)
@@ -392,6 +397,15 @@ next_token (void)
   result = match_word ("swap", SWAP);
   break;
 
+#ifdef HAVE_GFC_REAL_17
+case 'r':
+case 'R':
+  result = match_word ("r16_ieee", R16_IEEE);
+  if (result == ILLEGAL)
+	result = match_word ("r16_ibm", R16_IBM);
+  break;
+
+#endif
 case '1': case '2': case '3': case '4': case '5':
 case '6': case '7': case '8': case '9':
   result = match_integer ();
@@ -414,7 +428,8 @@ push_token (void)
 
 /* This is called when a unit is identified.  If do_count is nonzero,
increment the number of units by one.  If do_count is zero,
-   put the unit into the table.  */
+   put the unit into the table.  For POWER, we have to make sure that
+   we can also put in the conversion btween IBM and IEEE long double.  */
 
 static void
 mark_single (int unit)
@@ -428,7 +443,11 @@ mark_single (int unit)
 }
   if (search_unit (unit, &i))
 {
+#ifdef HAVE_GFC_REAL_17
+  elist[i].conv |= endian;
+#else
   elist[i].conv = endian;
+#endif
 }
   else
 {
@@ -437,7 +456,11 @@ mark_single (int unit)
 
   n_elist += 1;
   elist[i].unit = unit;
+#ifdef HAVE_GFC_REAL_17
+  elist[i].conv |= endian;
+#else
   elist[i].conv = endian;
+#endif
 }
 }
 
@@ -481,6 +504,8 @@ do_parse (void)
 
   /* Parse the string.  First, let's look for a default.  */
   tok = next_token ();
+  endian = 0;
+
   switch (tok)
 {
 case NATIVE:
@@ -499,6 +524,15 @@ do_parse (void)
   endian = GFC_CONVERT_LITTLE;
   break;
 
+#ifdef HAVE_GFC_REAL_17
+case R16_IEEE:
+  endian = GFC_CONVERT_R16_IEEE;
+  break;
+
+case R16_IBM:
+  endian = GFC_CONVERT_R16_IBM;
+  break;
+#endif
 case INTEGER:
   /* A leading digit means that we are looking at an exception.
 	 Reset the position to the beginning, and continue processing
@@ -571,6 +605,19 @@ do_parse (void)
 	goto error;
 	  endian = GFC_CONVERT_BIG;
 	  break;
+#ifdef HAVE_GFC_REAL_17
+	case R16_IEEE:
+	  if (next_token () != ':')
+	goto error;
+	  endian = GFC_CONVERT_R16_IEEE;
+	  break;
+
+	case R16_IBM:
+	  if (next_token () != ':')
+	goto error;
+	  endian = GFC_CONVERT_R16_IBM;
+	  break;
+#endif
 
 	case INTEGER:
 	  push_token ();