* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) [not found] <alpine.LFD.2.21.2010251020560.866917@eddie.linux-mips.org> @ 2020-11-21 21:02 ` Toon Moene 2020-11-23 21:51 ` Maciej W. Rozycki 0 siblings, 1 reply; 14+ messages in thread From: Toon Moene @ 2020-11-21 21:02 UTC (permalink / raw) To: gcc-patches; +Cc: fortran [ 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-11-21 21:02 ` [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) Toon Moene @ 2020-11-23 21:51 ` Maciej W. Rozycki 2020-11-23 22:12 ` Thomas Koenig 0 siblings, 1 reply; 14+ messages in thread From: Maciej W. Rozycki @ 2020-11-23 21:51 UTC (permalink / raw) To: Toon Moene; +Cc: gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-11-23 21:51 ` Maciej W. Rozycki @ 2020-11-23 22:12 ` Thomas Koenig 2020-11-24 4:28 ` Maciej W. Rozycki 0 siblings, 1 reply; 14+ messages in thread From: Thomas Koenig @ 2020-11-23 22:12 UTC (permalink / raw) To: Maciej W. Rozycki, Toon Moene; +Cc: gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-11-23 22:12 ` Thomas Koenig @ 2020-11-24 4:28 ` Maciej W. Rozycki 2020-11-24 5:27 ` Maciej W. Rozycki 0 siblings, 1 reply; 14+ messages in thread From: Maciej W. Rozycki @ 2020-11-24 4:28 UTC (permalink / raw) To: Thomas Koenig; +Cc: Toon Moene, gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-11-24 4:28 ` Maciej W. Rozycki @ 2020-11-24 5:27 ` Maciej W. Rozycki 2020-11-24 6:04 ` Maciej W. Rozycki 0 siblings, 1 reply; 14+ messages in thread From: Maciej W. Rozycki @ 2020-11-24 5:27 UTC (permalink / raw) To: Thomas Koenig Cc: Martin Husemann, Anders Magnusson, Toon Moene, gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-11-24 5:27 ` Maciej W. Rozycki @ 2020-11-24 6:04 ` Maciej W. Rozycki 2020-11-24 6:16 ` Thomas Koenig 2020-11-25 18:26 ` Maciej W. Rozycki 0 siblings, 2 replies; 14+ messages in thread From: Maciej W. Rozycki @ 2020-11-24 6:04 UTC (permalink / raw) To: Thomas Koenig Cc: Martin Husemann, Anders Magnusson, Toon Moene, gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-11-24 6:04 ` Maciej W. Rozycki @ 2020-11-24 6:16 ` Thomas Koenig 2020-11-25 19:22 ` Maciej W. Rozycki 2020-11-25 18:26 ` Maciej W. Rozycki 1 sibling, 1 reply; 14+ messages in thread From: Thomas Koenig @ 2020-11-24 6:16 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Martin Husemann, Anders Magnusson, Toon Moene, gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-11-24 6:16 ` Thomas Koenig @ 2020-11-25 19:22 ` Maciej W. Rozycki 0 siblings, 0 replies; 14+ messages in thread From: Maciej W. Rozycki @ 2020-11-25 19:22 UTC (permalink / raw) To: Thomas Koenig Cc: Martin Husemann, Anders Magnusson, Toon Moene, gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-11-24 6:04 ` Maciej W. Rozycki 2020-11-24 6:16 ` Thomas Koenig @ 2020-11-25 18:26 ` Maciej W. Rozycki 2020-11-25 22:20 ` Joseph Myers 1 sibling, 1 reply; 14+ messages in thread From: Maciej W. Rozycki @ 2020-11-25 18:26 UTC (permalink / raw) To: Thomas Koenig Cc: Martin Husemann, Anders Magnusson, Toon Moene, gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-11-25 18:26 ` Maciej W. Rozycki @ 2020-11-25 22:20 ` Joseph Myers 2020-11-26 18:01 ` Maciej W. Rozycki 0 siblings, 1 reply; 14+ messages in thread From: Joseph Myers @ 2020-11-25 22:20 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Thomas Koenig, Anders Magnusson, Martin Husemann, gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-11-25 22:20 ` Joseph Myers @ 2020-11-26 18:01 ` Maciej W. Rozycki 2020-11-26 18:08 ` Martin Husemann 0 siblings, 1 reply; 14+ messages in thread From: Maciej W. Rozycki @ 2020-11-26 18:01 UTC (permalink / raw) To: Joseph Myers Cc: Thomas Koenig, Anders Magnusson, Martin Husemann, gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-11-26 18:01 ` Maciej W. Rozycki @ 2020-11-26 18:08 ` Martin Husemann 2020-12-08 14:38 ` Maciej W. Rozycki 0 siblings, 1 reply; 14+ messages in thread From: Martin Husemann @ 2020-11-26 18:08 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Joseph Myers, Thomas Koenig, Anders Magnusson, gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-11-26 18:08 ` Martin Husemann @ 2020-12-08 14:38 ` Maciej W. Rozycki 2020-12-08 15:22 ` Martin Husemann 0 siblings, 1 reply; 14+ messages in thread From: Maciej W. Rozycki @ 2020-12-08 14:38 UTC (permalink / raw) To: Martin Husemann, Tobias Burnus Cc: Joseph Myers, Thomas Koenig, Anders Magnusson, gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) 2020-12-08 14:38 ` Maciej W. Rozycki @ 2020-12-08 15:22 ` Martin Husemann 0 siblings, 0 replies; 14+ messages in thread From: Martin Husemann @ 2020-12-08 15:22 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Tobias Burnus, Joseph Myers, Thomas Koenig, Anders Magnusson, gcc-patches, fortran 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-12-08 15:22 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <alpine.LFD.2.21.2010251020560.866917@eddie.linux-mips.org> 2020-11-21 21:02 ` [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included) Toon Moene 2020-11-23 21:51 ` Maciej W. Rozycki 2020-11-23 22:12 ` Thomas Koenig 2020-11-24 4:28 ` Maciej W. Rozycki 2020-11-24 5:27 ` Maciej W. Rozycki 2020-11-24 6:04 ` Maciej W. Rozycki 2020-11-24 6:16 ` Thomas Koenig 2020-11-25 19:22 ` Maciej W. Rozycki 2020-11-25 18:26 ` Maciej W. Rozycki 2020-11-25 22:20 ` Joseph Myers 2020-11-26 18:01 ` Maciej W. Rozycki 2020-11-26 18:08 ` Martin Husemann 2020-12-08 14:38 ` Maciej W. Rozycki 2020-12-08 15:22 ` Martin Husemann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).