Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Toon Moene]

[ cc'd to the fortran mailing list to hopely get some more knowledgeable 
input ... ]

On 11/20/20 4:38 AM, Maciej W. Rozycki wrote:

> 2. libgfortran -- oddly enough for Fortran a piece requires IEEE 754
>     floating-point arithmetic (possibly a porting problem too).

gcc/libgfortran/config.h.in does have:

/* Define to 1 if you have the <ieeefp.h> header file. */
#undef HAVE_IEEEFP_H

So perhaps it does do the "right thing" if you do not have this header 
file on your VAX operating system.

The Fortran Standard allows an implementation *not* to have IEEE 
floating point support ...

Kind regards,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Sat, 21 Nov 2020, Toon Moene wrote:

> > 2. libgfortran -- oddly enough for Fortran a piece requires IEEE 754
> >     floating-point arithmetic (possibly a porting problem too).
> 
> gcc/libgfortran/config.h.in does have:
> 
> /* Define to 1 if you have the <ieeefp.h> header file. */
> #undef HAVE_IEEEFP_H
> 
> So perhaps it does do the "right thing" if you do not have this header file on
> your VAX operating system.

 Well it does not:

In file included from .../libgfortran/generated/maxval_r4.c:26:
.../libgfortran/generated/maxval_r4.c: In function 'maxval_r4':
.../libgfortran/libgfortran.h:292:30: warning: target format does not support infinity
  292 | # define GFC_REAL_4_INFINITY __builtin_inff ()
      |                              ^~~~~~~~~~~~~~
.../libgfortran/generated/maxval_r4.c:149:19:
note: in expansion of macro 'GFC_REAL_4_INFINITY'
  149 |         result = -GFC_REAL_4_INFINITY;
      |                   ^~~~~~~~~~~~~~~~~~~
.../libgfortran/generated/maxval_r4.c: In function 'mmaxval_r4':
.../libgfortran/libgfortran.h:292:30: warning: target format does not support infinity
  292 | # define GFC_REAL_4_INFINITY __builtin_inff ()
      |                              ^~~~~~~~~~~~~~
.../libgfortran/generated/maxval_r4.c:363:19:
note: in expansion of macro 'GFC_REAL_4_INFINITY'
  363 |         result = -GFC_REAL_4_INFINITY;
      |                   ^~~~~~~~~~~~~~~~~~~
{standard input}: Assembler messages:
{standard input}:204: Fatal error: Can't relocate expression
make[3]: *** [Makefile:3358: maxval_r4.lo] Error 1

with the offending assembly instruction at 204 being:

	movf $0f+QNaN,%r2

and the `QNaN' part of the operand being what GAS complains about (of 
course it is a problem too that GCC lets the infinity intrinsics through 
with a mere warning and rubbish emitted rather than bailing out right 
away, but they are not supposed to be requested in the first place as the 
notion of infinity is specific to IEEE 754 FP and the VAX FP format used 
here does not support such an FP datum).

 The absence of IEEE 754 FP is correctly recognised by the configuration 
script:

checking for ieeefp.h... no
[...]
configure: FPU dependent file will be fpu-generic.h
configure: Support for IEEE modules: no

> The Fortran Standard allows an implementation *not* to have IEEE floating
> point support ...

 Given how long before IEEE 754 Fortran was invented I would be rather 
surprised if it was the other way round, which is why I have suspected, as 
I have noted in the piece quoted above, a problem with the VAX/NetBSD port 
of libgfortran.

  Maciej

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Thomas Koenig]

Am 23.11.20 um 22:51 schrieb Maciej W. Rozycki:
>> /* Define to 1 if you have the <ieeefp.h> header file. */
>> #undef HAVE_IEEEFP_H
>>
>> So perhaps it does do the "right thing" if you do not have this header file on
>> your VAX operating system.
>   Well it does not:
> 
> In file included from .../libgfortran/generated/maxval_r4.c:26:
> .../libgfortran/generated/maxval_r4.c: In function 'maxval_r4':
> .../libgfortran/libgfortran.h:292:30: warning: target format does not support infinity
>    292 | # define GFC_REAL_4_INFINITY __builtin_inff ()
>        |                              ^~~~~~~~~~~~~~

This is guarded with

#ifdef __FLT_HAS_INFINITY__
# define GFC_REAL_4_INFINITY __builtin_inff ()
#endif

I don't know how or why __FLT_HAS_INFINITY is set for a target which
does not support it, but if you get rid of that macro, that particular
problem should be solved.

Best regards

	Thomas

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Mon, 23 Nov 2020, Thomas Koenig wrote:

> >   Well it does not:
> > 
> > In file included from .../libgfortran/generated/maxval_r4.c:26:
> > .../libgfortran/generated/maxval_r4.c: In function 'maxval_r4':
> > .../libgfortran/libgfortran.h:292:30: warning: target format does not
> > support infinity
> >    292 | # define GFC_REAL_4_INFINITY __builtin_inff ()
> >        |                              ^~~~~~~~~~~~~~
> 
> This is guarded with
> 
> #ifdef __FLT_HAS_INFINITY__
> # define GFC_REAL_4_INFINITY __builtin_inff ()
> #endif
> 
> I don't know how or why __FLT_HAS_INFINITY is set for a target which
> does not support it, but if you get rid of that macro, that particular
> problem should be solved.

 Thanks for the hint; I didn't look into it any further not to distract 
myself from the scope of the project.  I have now, and the check you have 
quoted is obviously broken (as are all the remaining similar ones), given:

$ vax-netbsdelf-gcc -E -dM - < /dev/null | sort | grep _HAS_
#define __DBL_HAS_DENORM__ 0
#define __DBL_HAS_INFINITY__ 0
#define __DBL_HAS_QUIET_NAN__ 0
#define __FLT_HAS_DENORM__ 0
#define __FLT_HAS_INFINITY__ 0
#define __FLT_HAS_QUIET_NAN__ 0
#define __LDBL_HAS_DENORM__ 0
#define __LDBL_HAS_INFINITY__ 0
#define __LDBL_HAS_QUIET_NAN__ 0
$ 

which looks reasonable to me.  This seems straightforward to fix to me, so 
I'll include it along with verification I am about to schedule (assuming 
that this will be enough for libgfortran to actually build; obviously it 
hasn't been tried by anyone with such a setup for a while now, as these 
libgfortran checks date back to 2009).

  Maciej

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:

> > I don't know how or why __FLT_HAS_INFINITY is set for a target which
> > does not support it, but if you get rid of that macro, that particular
> > problem should be solved.
> 
>  Thanks for the hint; I didn't look into it any further not to distract 
> myself from the scope of the project.  I have now, and the check you have 
> quoted is obviously broken (as are all the remaining similar ones), given:
> 
> $ vax-netbsdelf-gcc -E -dM - < /dev/null | sort | grep _HAS_
> #define __DBL_HAS_DENORM__ 0
> #define __DBL_HAS_INFINITY__ 0
> #define __DBL_HAS_QUIET_NAN__ 0
> #define __FLT_HAS_DENORM__ 0
> #define __FLT_HAS_INFINITY__ 0
> #define __FLT_HAS_QUIET_NAN__ 0
> #define __LDBL_HAS_DENORM__ 0
> #define __LDBL_HAS_INFINITY__ 0
> #define __LDBL_HAS_QUIET_NAN__ 0
> $ 
> 
> which looks reasonable to me.  This seems straightforward to fix to me, so 
> I'll include it along with verification I am about to schedule (assuming 
> that this will be enough for libgfortran to actually build; obviously it 
> hasn't been tried by anyone with such a setup for a while now, as these 
> libgfortran checks date back to 2009).

 Well, it is still broken, owing to NetBSD failing to implement POSIX 2008 
locale handling correctly, apparently deliberately[1], and missing 
uselocale(3)[2] while still providing newlocale(3).  This confuses our 
conditionals and consequently:

.../libgfortran/io/transfer.c: In function 'data_transfer_init_worker':
.../libgfortran/io/transfer.c:3416:30: error:
'old_locale_lock' undeclared (first use in this function)
 3416 |       __gthread_mutex_lock (&old_locale_lock);
      |                              ^~~~~~~~~~~~~~~

etc.

 We can probably work it around by downgrading to setlocale(3) for NetBSD 
(i.e. whenever either function is missing) unless someone from the NetBSD 
community contributes a better implementation (they seem to prefer their 
own non-standard printf_l(3) library API).

References:

[1] Martin Husemann, "Re: uselocale() function", 
    <https://mail-index.netbsd.org/netbsd-users/2017/02/14/msg019351.html>

[2] "The Open Group Base Specifications Issue 7, 2018 edition", IEEE Std 
    1003.1-2017 (Revision of IEEE Std 1003.1-2008),
    <https://pubs.opengroup.org/onlinepubs/9699919799/functions/uselocale.html>

  Maciej

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:

> > > I don't know how or why __FLT_HAS_INFINITY is set for a target which
> > > does not support it, but if you get rid of that macro, that particular
> > > problem should be solved.
> > 
> >  Thanks for the hint; I didn't look into it any further not to distract 
> > myself from the scope of the project.  I have now, and the check you have 
> > quoted is obviously broken (as are all the remaining similar ones), given:
> > 
> > $ vax-netbsdelf-gcc -E -dM - < /dev/null | sort | grep _HAS_
> > #define __DBL_HAS_DENORM__ 0
> > #define __DBL_HAS_INFINITY__ 0
> > #define __DBL_HAS_QUIET_NAN__ 0
> > #define __FLT_HAS_DENORM__ 0
> > #define __FLT_HAS_INFINITY__ 0
> > #define __FLT_HAS_QUIET_NAN__ 0
> > #define __LDBL_HAS_DENORM__ 0
> > #define __LDBL_HAS_INFINITY__ 0
> > #define __LDBL_HAS_QUIET_NAN__ 0
> > $ 
> > 
> > which looks reasonable to me.  This seems straightforward to fix to me, so 
> > I'll include it along with verification I am about to schedule (assuming 
> > that this will be enough for libgfortran to actually build; obviously it 
> > hasn't been tried by anyone with such a setup for a while now, as these 
> > libgfortran checks date back to 2009).
> 
>  Well, it is still broken, owing to NetBSD failing to implement POSIX 2008 
> locale handling correctly, apparently deliberately[1], and missing 
> uselocale(3)[2] while still providing newlocale(3).  This confuses our 
> conditionals and consequently:
> 
> .../libgfortran/io/transfer.c: In function 'data_transfer_init_worker':
> .../libgfortran/io/transfer.c:3416:30: error:
> 'old_locale_lock' undeclared (first use in this function)
>  3416 |       __gthread_mutex_lock (&old_locale_lock);
>       |                              ^~~~~~~~~~~~~~~
> 
> etc.
> 
>  We can probably work it around by downgrading to setlocale(3) for NetBSD 
> (i.e. whenever either function is missing) unless someone from the NetBSD 
> community contributes a better implementation (they seem to prefer their 
> own non-standard printf_l(3) library API).

 And now:

In file included from .../libgfortran/intrinsics/erfc_scaled.c:33:
.../libgfortran/intrinsics/erfc_scaled_inc.c:
In function 'erfc_scaled_r4':
.../libgfortran/intrinsics/erfc_scaled_inc.c:169:15: warning: target format does not support infinity
  169 |         res = __builtin_inf ();
      |               ^~~~~~~~~~~~~
In file included from .../libgfortran/intrinsics/erfc_scaled.c:39:
.../libgfortran/intrinsics/erfc_scaled_inc.c:
In function 'erfc_scaled_r8':
.../libgfortran/intrinsics/erfc_scaled_inc.c:82:15: warning: floating constant exceeds range of 'double'
   82 |               xbig = 26.543, xhuge = 6.71e+7, xmax = 2.53e+307;
      |               ^~~~
.../libgfortran/intrinsics/erfc_scaled_inc.c:169:15: warning: target format does not support infinity
  169 |         res = __builtin_inf ();
      |               ^~~~~~~~~~~~~

and:

.../libgfortran/intrinsics/c99_functions.c: In function 'tgamma':
.../libgfortran/intrinsics/c99_functions.c:1866:3: warning: floating constant truncated to zero [-Woverflow]
 1866 |   static const double xminin = 2.23e-308;
      |   ^~~~~~
.../libgfortran/intrinsics/c99_functions.c:1868:60: warning: target format does not support infinity
 1868 |   static const double xnan = __builtin_nan ("0x0"), xinf = __builtin_inf ();
      |                                                            ^~~~~~~~~~~~~{standard input}: Assembler messages:
{standard input}:487: Fatal error: Junk at end of expression "QNaN"
make[3]: *** [Makefile:6466: c99_functions.lo] Error 1

I am going to give up at this point, as porting libgfortran to non-IEEE FP 
is surely well beyond what I can afford to do right now.

  Maciej

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Thomas Koenig]

Am 24.11.20 um 07:04 schrieb Maciej W. Rozycki:
> I am going to give up at this point, as porting libgfortran to non-IEEE FP
> is surely well beyond what I can afford to do right now.

Can you file a PR about this? Eliminating __builtin_inf and friends
sounds doable.

And does anybody know what we should return in cases where the result
exceeds the maximum representable number?

Best regards

	Thomas

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:

> I am going to give up at this point, as porting libgfortran to non-IEEE FP 
> is surely well beyond what I can afford to do right now.

 I have now posted fixes for the issues handled so far.

 For the other pieces that are missing perhaps my work I did many years 
ago to port glibc 2.4 (the last one I was able to cook up without NPTL), 
and specifically libm within, to the never-upstreamed VAX/Linux target 
might be useful to complete the effort, as there seems to be an overlap 
here.  That port hasn't been fully verified though and I do not promise 
doing any work related to it anytime either.  The glibc patches continue 
being available online to download and use under the terms of the GNU GPL 
for anyone though.

  Maciej

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Tue, 24 Nov 2020, Thomas Koenig wrote:

> > I am going to give up at this point, as porting libgfortran to non-IEEE FP
> > is surely well beyond what I can afford to do right now.
> 
> Can you file a PR about this? Eliminating __builtin_inf and friends
> sounds doable.

 There's more to that unfortunately.  I would have done it right away if 
it was so easy.

> And does anybody know what we should return in cases where the result
> exceeds the maximum representable number?

 Presumably the standard has it (implementation-specific for non-IEEE-754 
I suppose; in the VAX FP ISA an underflow optionally traps, and otherwise 
produces a zero result, while an overflow traps unconditionally and keeps 
the destination operand unchanged).

  Maciej

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Joseph Myers]

On Wed, 25 Nov 2020, Maciej W. Rozycki wrote:

>  For the other pieces that are missing perhaps my work I did many years 
> ago to port glibc 2.4 (the last one I was able to cook up without NPTL), 
> and specifically libm within, to the never-upstreamed VAX/Linux target 
> might be useful to complete the effort, as there seems to be an overlap 
> here.  That port hasn't been fully verified though and I do not promise 
> doing any work related to it anytime either.  The glibc patches continue 
> being available online to download and use under the terms of the GNU GPL 
> for anyone though.

I think I mentioned before: if you wish to bring a VAX port back to 
current glibc, I think it would make more sense to use software IEEE 
floating point rather than adding new support to glibc for a non-IEEE 
floating-point format.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Wed, 25 Nov 2020, Joseph Myers wrote:

> >  For the other pieces that are missing perhaps my work I did many years 
> > ago to port glibc 2.4 (the last one I was able to cook up without NPTL), 
> > and specifically libm within, to the never-upstreamed VAX/Linux target 
> > might be useful to complete the effort, as there seems to be an overlap 
> > here.  That port hasn't been fully verified though and I do not promise 
> > doing any work related to it anytime either.  The glibc patches continue 
> > being available online to download and use under the terms of the GNU GPL 
> > for anyone though.
> 
> I think I mentioned before: if you wish to bring a VAX port back to 
> current glibc, I think it would make more sense to use software IEEE 
> floating point rather than adding new support to glibc for a non-IEEE 
> floating-point format.

 Right, that would be the path of least resistance (non-FP VAX bits are 
obviously limited and boil down to the OS interface and some handwritten 
assembly such as for optimised string ops), and surely the least involving 
one maintenance-wise, so perhaps the only acceptable compromise these days 
given that VAX is a niche of a niche now.

 The kernel part would have to happen first though, and the old effort 
became stuck in 2.6 days, so clearly not suitable for upstreaming.  Back 
in the day I did enough kernel updates to get interrupt handling right, 
i.e. the IPL stuff, based on what the Alpha port does, which is really the 
same, and then on top of it ptrace(2) support along with a native GDB and 
a `gdbserver' port so that I could actually debug the outstanding userland 
issues.

 But that was surely not enough even back then and is even less so now.  
FWIW I was able to run single-user `bash' (with `ncurses', etc.) and some 
other programs; native GCC crashed as did GDB, due to a bug leading to 
stack exhaustion, but `gdbserver' worked along with single-stepping, etc., 
so that was a good starting point.

 The VAX/NetBSD port however does use hardware FP in their libm as far as 
I can tell, so I guess it would be reasonable for libgfortran to do so as 
well.  I haven't checked how correct their implementation actually is, but 
barring evidence otherwise I would assume they did the right thing.  

 Without all the NaN/denormal stuff the handling should be much simpler I 
believe, though I gather some numeric algorithms do rely on the presence 
of denormals to produce reasonable results in some boundary cases.  These 
would be lost or a different algorithm would have to be chosen for the 
respective computations I suppose.

  Maciej

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Martin Husemann]

On Thu, Nov 26, 2020 at 06:01:31PM +0000, Maciej W. Rozycki wrote:
>  The VAX/NetBSD port however does use hardware FP in their libm as far as 
> I can tell, so I guess it would be reasonable for libgfortran to do so as 
> well.  I haven't checked how correct their implementation actually is, but 
> barring evidence otherwise I would assume they did the right thing.  

It does, but it is not totally correct in all places (due to gcc issues
some parts have not received good testing, and others clearly are broken,
eg. when tables are used that have not been adjusted for the different
limits in VAX float/double formats).

Should be a lot easier to fix with newer gcc soonish (I hope).

Martin

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

On Thu, 26 Nov 2020, Martin Husemann wrote:

> >  The VAX/NetBSD port however does use hardware FP in their libm as far as 
> > I can tell, so I guess it would be reasonable for libgfortran to do so as 
> > well.  I haven't checked how correct their implementation actually is, but 
> > barring evidence otherwise I would assume they did the right thing.  
> 
> It does, but it is not totally correct in all places (due to gcc issues
> some parts have not received good testing, and others clearly are broken,
> eg. when tables are used that have not been adjusted for the different
> limits in VAX float/double formats).

 I have realised that with my VAX/Linux effort, more than 10 years ago, I 
did not encounter such issues, and I did port all the GCC components the 
compiler provided at the time (although the port of libjava could have 
been only partially functional as I didn't properly verify the IEEE<->VAX 
FP conversion stubs I have necessarily implemented), though what chose was 
4.1.2 rather than the most recent version (to avoid the need to port NPTL 
right away).  I should have tripped over this issue then, but I did not.

 So with the objective of this effort out of the way I have now looked 
into what happened with libgfortran here and realised that the cause of 
the compilation error was an attempt to provide a standard ISO C function 
missing from NetBSD's libc or libm (even though it's declared).  Indeed:

$ grep tgamma usr/include/math.h
double	tgamma(double);
float	tgammaf(float);
long double	tgammal(long double);
$ readelf -s usr/lib/libc.so usr/lib/libm.so usr/lib/libc.a usr/lib/libm.a | grep tgamma
$ 

So clearly something went wrong there and I think it's that that has to be 
fixed rather than the fallback implementations in libgfortran (which I 
gather have been only provided for legacy systems that do not implement a 
full ISO C environment and are no longer maintained).  I suspect that once 
this function (and any other ones that may be missing) has been supplied 
by the system libraries libgfortran will just work out of the box.

 Here's the full list of math functions that the `configure' script in 
libgfortran reports as missing:

checking for acosl... no
checking for acoshf... no
checking for acoshl... no
checking for asinl... no
checking for asinhf... no
checking for asinhl... no
checking for atan2l... no
checking for atanl... no
checking for atanhl... no
checking for cosl... no
checking for coshl... no
checking for expl... no
checking for fmaf... no
checking for fma... no
checking for fmal... no
checking for frexpf... no
checking for frexpl... no
checking for logl... no
checking for log10l... no
checking for clog10f... no
checking for clog10... no
checking for clog10l... no
checking for nextafterf... no
checking for nextafter... no
checking for nextafterl... no
checking for lroundl... no
checking for llroundf... no
checking for llround... no
checking for llroundl... no
checking for sinl... no
checking for sinhl... no
checking for tanl... no
checking for tanhl... no
checking for erfcl... no
checking for j0f... no
checking for j1f... no
checking for jnf... no
checking for jnl... no
checking for y0f... no
checking for y1f... no
checking for ynf... no
checking for ynl... no
checking for tgamma... no
checking for tgammaf... no
checking for lgammaf... no

Except for the Bessel functions these are a part of ISO C; `long double' 
versions, some of which appear missing unlike their `float' or `double' 
counterparts, should probably just alias to the corresponding `double' 
versions as I doubt we want to get into the H-floating format, largely 
missing from actual VAX hardware and meant to be emulated by the OS.

 Please note that this is with NetBSD 9 rather than 9.1 (which has only 
been recently released and therefore I decided not to get distracted with 
an upgrade) and I don't know if it has been fixed in the latter release.

  Maciej

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Martin Husemann]

On Tue, Dec 08, 2020 at 02:38:59PM +0000, Maciej W. Rozycki wrote:
>  Here's the full list of math functions that the `configure' script in 
> libgfortran reports as missing:
> 
> checking for acosl... no
> checking for acoshf... no
[..]
> Except for the Bessel functions these are a part of ISO C; `long double' 
> versions, some of which appear missing unlike their `float' or `double' 
> counterparts, should probably just alias to the corresponding `double' 
> versions as I doubt we want to get into the H-floating format, largely 
> missing from actual VAX hardware and meant to be emulated by the OS.

Thanks for the list - I'll add the aliases soonish (they are likely already
there for the IEEE versions but missing from the vax code) and check
what remains missing then.

Martin