Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On 14.09.21 05:39, Sandra Loosemore wrote: Here's a patch. Gerald, can you check that this fixes your bootstrap problem on i586-unknown-freebsd11? LGTM – thanks! Tobias Fortran: Prefer GCC internal macros to float.h in ISO_Fortran_binding.h. 2021-09-13 Sandra Loosemore libgfortran/ * ISO_Fortran_binding.h: Only include float.h if the C compiler doesn't have predefined __LDBL_* and __DBL_* macros. - 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
[committed] Fortran: Add missing ST_OMP_END_SCOPE handling [PR102313]
Committed as obvious as r12-3524.
I have also re-checked openmp.c omp_code_to_statement (seems to be
complete, 'omp declare...' + 'omp requires' missing but it is
probably fine that those are absent).
And I checked gfc_ascii_statement – missing are some internally
used ones (like ST_SIMPLE_IF), which are probably never reachable.
Thus, it seems as if G. Steinmetz managed to find the only missing one.
I have created a testcase with all missing ST_OMP_END_* and ST_OACC_END_*;
I am not quite sure why a different code path is triggered for some, but
at least here is now a parse check for all.
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
commit 33fdbbe4ce6055eb858096d01720ccf94aa854ec
Author: Tobias Burnus
Date: Tue Sep 14 14:17:35 2021 +0200
Fortran: Add missing ST_OMP_END_SCOPE handling [PR102313]
PR fortran/102313
gcc/fortran/ChangeLog:
* parse.c (gfc_ascii_statement): Add missing ST_OMP_END_SCOPE.
gcc/testsuite/ChangeLog:
* gfortran.dg/goacc/unexpected-end.f90: New test.
* gfortran.dg/gomp/unexpected-end.f90: New test.
---
gcc/fortran/parse.c| 3 +
gcc/testsuite/gfortran.dg/goacc/unexpected-end.f90 | 23
gcc/testsuite/gfortran.dg/gomp/unexpected-end.f90 | 123 +
3 files changed, 149 insertions(+)
diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index d37a0b5a697..7d765a0866d 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -2406,6 +2406,9 @@ gfc_ascii_statement (gfc_statement st)
case ST_OMP_END_DO_SIMD:
p = "!$OMP END DO SIMD";
break;
+case ST_OMP_END_SCOPE:
+ p = "!$OMP END SCOPE";
+ break;
case ST_OMP_END_SIMD:
p = "!$OMP END SIMD";
break;
diff --git a/gcc/testsuite/gfortran.dg/goacc/unexpected-end.f90 b/gcc/testsuite/gfortran.dg/goacc/unexpected-end.f90
new file mode 100644
index 000..442724fea83
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/unexpected-end.f90
@@ -0,0 +1,23 @@
+! PR fortran/102313
+
+!$acc end ATOMIC ! { dg-error "Unexpected !.ACC END ATOMIC" }
+
+!$acc end DATA ! { dg-error "Unexpected !.ACC END DATA" }
+
+!$acc end HOST DATA ! { dg-error "Unclassifiable OpenACC directive" }
+
+!$acc end KERNELS ! { dg-error "Unexpected !.ACC END KERNELS" }
+
+!$acc end KERNELS LOOP ! { dg-error "Unexpected !.ACC END KERNELS LOOP" }
+
+!$acc end LOOP ! { dg-error "Unexpected !.ACC END LOOP" }
+
+!$acc end PARALLEL ! { dg-error "Unexpected !.ACC END PARALLEL" }
+
+!$acc end PARALLEL LOOP ! { dg-error "Unexpected !.ACC END PARALLEL LOOP" }
+
+!$acc end SERIAL ! { dg-error "Unexpected !.ACC END SERIAL" }
+
+!$acc end SERIAL LOOP ! { dg-error "Unexpected !.ACC END SERIAL LOOP" }
+
+end
diff --git a/gcc/testsuite/gfortran.dg/gomp/unexpected-end.f90 b/gcc/testsuite/gfortran.dg/gomp/unexpected-end.f90
new file mode 100644
index 000..d2e8daa3fde
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/unexpected-end.f90
@@ -0,0 +1,123 @@
+! PR fortran/102313
+
+!$omp end ATOMIC ! { dg-error "Unexpected !.OMP END ATOMIC" }
+
+!$omp end CRITICAL ! { dg-error "Unexpected !.OMP END CRITICAL" }
+
+!$omp end DISTRIBUTE ! { dg-error "Unexpected !.OMP END DISTRIBUTE" }
+
+!$omp end DISTRIBUTE PARALLEL DO ! { dg-error "Unexpected !.OMP END DISTRIBUTE PARALLEL DO" }
+
+!$omp end DISTRIBUTE PARALLEL DO SIMD ! { dg-error "Unexpected !.OMP END DISTRIBUTE PARALLEL DO SIMD" }
+
+!$omp end DISTRIBUTE SIMD ! { dg-error "Unexpected !.OMP END DISTRIBUTE SIMD" }
+
+!$omp end DO ! { dg-error "Unexpected !.OMP END DO" }
+
+!$omp end DO SIMD ! { dg-error "Unexpected !.OMP END DO SIMD" }
+
+!$omp end LOOP ! { dg-error "Unclassifiable OpenMP directive" }
+
+!$omp parallel loop
+do i = 1, 5
+end do
+!$omp end LOOP ! { dg-error "Unclassifiable OpenMP directive" }
+
+!$omp end MASKED ! { dg-error "Unexpected !.OMP END MASKED" }
+
+!$omp end MASKED TASKLOOP ! { dg-error "Unexpected !.OMP END MASKED TASKLOOP" }
+
+!$omp end MASKED TASKLOOP SIMD ! { dg-error "Unexpected !.OMP END MASKED TASKLOOP SIMD" }
+
+!$omp end MASTER ! { dg-error "Unexpected !.OMP END MASTER" }
+
+!$omp end MASTER TASKLOOP ! { dg-error "Unexpected !.OMP END MASTER TASKLOOP" }
+
+!$omp end MASTER TASKLOOP SIMD ! { dg-error "Unexpected !.OMP END MASTER TASKLOOP SIMD" }
+
+!$omp end ORDERED ! { dg-error "Unexpected !.OMP END ORDERED" }
+
+!$omp end PARALLEL ! { dg-error "Unexpected !.OMP END PARALLEL" }
+
+!$omp end PARALLEL DO ! { dg-error "Unexpected !.OMP END PARALLEL DO" }
+
+!$omp end PARALLEL DO SIMD ! { dg-error "Unexpected !.OMP END PARALLEL DO SIMD" }
+
+!$omp loop
+!$omp end PARALLEL LOOP ! { dg-error "Unexpected junk" }
+
+!$omp end PARALLEL MASKED ! { dg-error "Unex
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Mon, 13 Sep 2021, Tobias Burnus wrote: > Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo | > ./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output? Thank you, Tobias, and I'm just testing the proposed patch, but still wanted to follow up on your question: % echo | ./gcc/cc1 -E -g3 -dD | grep DBL #define __DBL_MANT_DIG__ 53 #define __DBL_DIG__ 15 #define __DBL_MIN_EXP__ (-1021) #define __DBL_MIN_10_EXP__ (-307) #define __DBL_MAX_EXP__ 1024 #define __DBL_MAX_10_EXP__ 308 #define __DBL_DECIMAL_DIG__ 17 #define __DBL_MAX__ ((double)1.79769313486231570814527423731704357e+308L) #define __DBL_NORM_MAX__ ((double)1.79769313486231570814527423731704357e+308L) #define __DBL_MIN__ ((double)2.22507385850720138309023271733240406e-308L) #define __DBL_EPSILON__ ((double)2.22044604925031308084726333618164062e-16L) #define __DBL_DENORM_MIN__ ((double)4.94065645841246544176568792868221372e-324L) #define __DBL_HAS_DENORM__ 1 #define __DBL_HAS_INFINITY__ 1 #define __DBL_HAS_QUIET_NAN__ 1 #define __DBL_IS_IEC_60559__ 2 #define __LDBL_MANT_DIG__ 53 #define __LDBL_DIG__ 15 #define __LDBL_MIN_EXP__ (-16381) #define __LDBL_MIN_10_EXP__ (-4931) #define __LDBL_MAX_EXP__ 16384 #define __LDBL_MAX_10_EXP__ 4932 #define __LDBL_DECIMAL_DIG__ 17 #define __LDBL_MAX__ 1.18973149535723163299902939989638351e+4932L #define __LDBL_NORM_MAX__ 1.18973149535723163299902939989638351e+4932L #define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L #define __LDBL_EPSILON__ 2.22044604925031308084726333618164062e-16L #define __LDBL_DENORM_MIN__ 7.46536864129530798597817535205257178e-4948L #define __LDBL_HAS_DENORM__ 1 #define __LDBL_HAS_INFINITY__ 1 #define __LDBL_HAS_QUIET_NAN__ 1 #define __LDBL_IS_IEC_60559__ 2 Gerald
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
Hi Gerald, I note: On 13.09.21 17:56, Gerald Pfeifer wrote: % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)'/usr/include/ /usr/include/x86/float.h:#define LDBL_MANT_DIG 64 /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381) /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384 This looks like it matches existing Linux case already in place? On 14.09.21 16:50, Gerald Pfeifer wrote: On Mon, 13 Sep 2021, Tobias Burnus wrote: Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo | ./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output? Thank you, Tobias, and I'm just testing the proposed patch, but still wanted to follow up on your question: % echo | ./gcc/cc1 -E -g3 -dD | grep DBL #define __DBL_MANT_DIG__ 53 #define __DBL_MIN_EXP__ (-1021) #define __DBL_MAX_EXP__ 1024 #define __LDBL_MANT_DIG__ 53 #define __LDBL_MIN_EXP__ (-16381) #define __LDBL_MAX_EXP__ 16384 I note that LDBL_MANT_DIG is 53 as for "double" – while Linux and your header file has 64. On the other hand, MIN/MAX_EXP for "long double" are larger than "double" – and match the values from Linux and the size in your header file. Thus, the first question is: why does DBL_MANT_DIG differ (64 vs. 53)? And, related, does the following make sense and fixes the issue? --- a/libgfortran/ISO_Fortran_binding.h +++ b/libgfortran/ISO_Fortran_binding.h @@ -228,5 +228,5 @@ extern int CFI_setpointer (CFI_cdesc_t *, CFI_cdesc_t *, const CFI_index_t []); /* This is the 80-bit encoding on x86; Fortran assigns it kind 10. */ -#elif (LDBL_MANT_DIG == 64 \ +#elif ((LDBL_MANT_DIG == 64 || LDBL_MANT_DIG == 53) \ && LDBL_MIN_EXP == -16381 \ && LDBL_MAX_EXP == 16384) 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: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Sep 14 2021, Gerald Pfeifer wrote: > #define __LDBL_MANT_DIG__ 53 > #define __LDBL_DIG__ 15 > #define __LDBL_MIN_EXP__ (-16381) > #define __LDBL_MIN_10_EXP__ (-4931) > #define __LDBL_MAX_EXP__ 16384 > #define __LDBL_MAX_10_EXP__ 4932 > #define __LDBL_DECIMAL_DIG__ 17 > #define __LDBL_MAX__ 1.18973149535723163299902939989638351e+4932L > #define __LDBL_NORM_MAX__ 1.18973149535723163299902939989638351e+4932L > #define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L > #define __LDBL_EPSILON__ 2.22044604925031308084726333618164062e-16L > #define __LDBL_DENORM_MIN__ 7.46536864129530798597817535205257178e-4948L > #define __LDBL_HAS_DENORM__ 1 > #define __LDBL_HAS_INFINITY__ 1 > #define __LDBL_HAS_QUIET_NAN__ 1 > #define __LDBL_IS_IEC_60559__ 2 That looks like range of extended float, but rounded to double float precision. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Tue, Sep 14, 2021 at 05:17:04PM +0200, Andreas Schwab wrote: > On Sep 14 2021, Gerald Pfeifer wrote: > > > #define __LDBL_MANT_DIG__ 53 > > #define __LDBL_DIG__ 15 > > #define __LDBL_MIN_EXP__ (-16381) > > #define __LDBL_MIN_10_EXP__ (-4931) > > #define __LDBL_MAX_EXP__ 16384 > > #define __LDBL_MAX_10_EXP__ 4932 > > #define __LDBL_DECIMAL_DIG__ 17 > > #define __LDBL_MAX__ 1.18973149535723163299902939989638351e+4932L > > #define __LDBL_NORM_MAX__ 1.18973149535723163299902939989638351e+4932L > > #define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L > > #define __LDBL_EPSILON__ 2.22044604925031308084726333618164062e-16L > > #define __LDBL_DENORM_MIN__ 7.46536864129530798597817535205257178e-4948L > > #define __LDBL_HAS_DENORM__ 1 > > #define __LDBL_HAS_INFINITY__ 1 > > #define __LDBL_HAS_QUIET_NAN__ 1 > > #define __LDBL_IS_IEC_60559__ 2 > > That looks like range of extended float, but rounded to double float > precision. Yeah. real.c has: /* The following caters to i386 systems that set the rounding precision to 53 bits instead of 64, e.g. FreeBSD. */ const struct real_format ieee_extended_intel_96_round_53_format = But, wonder why it didn't work with the float.h include then, because https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381) and LDBL_MAX_EXP to 16384 and that case was handled in ISO_Fortran_binding.h. Jakub
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Sep 14 2021, Jakub Jelinek wrote: > But, wonder why it didn't work with the float.h include then, because > https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h > seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381) and > LDBL_MAX_EXP to 16384 and that case was handled in ISO_Fortran_binding.h. Doesn't gcc always use its own float.h? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Mon, 13 Sep 2021, Sandra Loosemore wrote: > Here's a patch. Gerald, can you check that this fixes your bootstrap > problem on i586-unknown-freebsd11? I does not change the bootstrap failure on i586-unknown-freebsd11 - though looking at the discussion here still looks like a good change to make? And I just kicked off testing Tobias' suggestion on top of an unpatched tree and will let you know: /* This is the 80-bit encoding on x86; Fortran assigns it kind 10. */ -#elif (LDBL_MANT_DIG == 64 \ +#elif ((LDBL_MANT_DIG == 64 || LDBL_MANT_DIG == 53) \ && LDBL_MIN_EXP == -16381 \ && LDBL_MAX_EXP == 16384) Gerald
[PATCH, committed] PR fortran/102311 - fix ICE during error recovery checking entry characteristics
Committed as obvious as r12-3533.
The fix to PR87737 did work for the given testcase, but could lead
to a bad internal compiler state for a variation of the testcase.
(Found by Gerhard...)
The solution was to not return too early after emitting the error
message but going through a 'cleanup' instead.
Regtested on x86_64-pc-linux-gnu, and checked the testcase also
with valgrind (to be on the safer side).
Thanks,
Harald
Fortran - fix ICE during error recovery checking entry characteristics
gcc/fortran/ChangeLog:
PR fortran/102311
* resolve.c (resolve_entries): Attempt to recover cleanly after
rejecting mismatched function entries.
gcc/testsuite/ChangeLog:
PR fortran/102311
* gfortran.dg/entry_25.f90: New test.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 8e5ed1c032c..30b96b2f597 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -811,7 +811,7 @@ resolve_entries (gfc_namespace *ns)
gfc_error ("Function %s at %L has entry %s with mismatched "
"characteristics", ns->entries->sym->name,
&ns->entries->sym->declared_at, el->sym->name);
- return;
+ goto cleanup;
}
else if (ts->type == BT_CHARACTER && ts->u.cl && fts->u.cl
&& (((ts->u.cl->length && !fts->u.cl->length)
@@ -917,6 +917,8 @@ resolve_entries (gfc_namespace *ns)
}
}
}
+
+cleanup:
proc->attr.access = ACCESS_PRIVATE;
proc->attr.entry_master = 1;
diff --git a/gcc/testsuite/gfortran.dg/entry_25.f90 b/gcc/testsuite/gfortran.dg/entry_25.f90
new file mode 100644
index 000..518560aa198
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/entry_25.f90
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! PR fortran/102311 - ICE during error recovery checking entry characteristics
+
+module m
+contains
+ function f() ! { dg-error "mismatched characteristics" }
+character(:), allocatable :: f
+character(1) :: g
+f = 'f'
+ entry g()
+g = 'g'
+ end
+end
[PATCH] PR fortran/102287 - optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines
As nicely described in the PR, we mishandled the case of passing
optional allocatable DT arguments with allocatable components
when the INTENT was declared as INTENT(OUT), as we unconditionally
tried to deallocate these components even when the argument was not
present. The obvious solution is to wrap the code for deallocation
by a check for presence.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As this is a potentially nasty wrong-code bug, I'd like to backport
to at least 11-branch.
Thanks,
Harald
Fortran - fix handling of optional allocatable DT arguments with INTENT(OUT)
gcc/fortran/ChangeLog:
PR fortran/102287
* trans-expr.c (gfc_conv_procedure_call): Wrap deallocation of
allocatable components of optional allocatable derived type
procedure arguments with INTENT(OUT) into a presence check.
gcc/testsuite/ChangeLog:
PR fortran/102287
* gfortran.dg/intent_out_14.f90: New test.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 18d665192f0..4a81f4695d9 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6548,6 +6548,17 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
// deallocate the components first
tmp = gfc_deallocate_alloc_comp (fsym->ts.u.derived,
parmse.expr, e->rank);
+ /* But check whether dummy argument is optional. */
+ if (tmp != NULL_TREE
+ && fsym->attr.optional
+ && e->expr_type == EXPR_VARIABLE
+ && e->symtree->n.sym->attr.optional)
+ {
+ tree present;
+ present = gfc_conv_expr_present (e->symtree->n.sym);
+ tmp = build3_v (COND_EXPR, present, tmp,
+ build_empty_stmt (input_location));
+ }
if (tmp != NULL_TREE)
gfc_add_expr_to_block (&se->pre, tmp);
}
diff --git a/gcc/testsuite/gfortran.dg/intent_out_14.f90 b/gcc/testsuite/gfortran.dg/intent_out_14.f90
new file mode 100644
index 000..e5994635008
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intent_out_14.f90
@@ -0,0 +1,24 @@
+! { dg-do run }
+! PR fortran/102287 - optional allocatable DT array arguments (intent out)
+
+module m
+ type t
+ integer, allocatable :: a
+ end type t
+contains
+ subroutine a (x, v)
+type(t), optional, allocatable, intent(out) :: x(:)
+type(t), optional, intent(out) :: v(:)
+call b (x, v)
+ end subroutine a
+
+ subroutine b (y, w)
+type(t), optional, allocatable, intent(out) :: y(:)
+type(t), optional, intent(out) :: w(:)
+ end subroutine b
+end module m
+
+program p
+ use m
+ call a ()
+end
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Tue, 14 Sep 2021, Tobias Burnus wrote: > And, related, does the following make sense and fixes the issue? > > --- a/libgfortran/ISO_Fortran_binding.h > +++ b/libgfortran/ISO_Fortran_binding.h > @@ -228,5 +228,5 @@ extern int CFI_setpointer (CFI_cdesc_t *, CFI_cdesc_t *, > const CFI_index_t []); > > /* This is the 80-bit encoding on x86; Fortran assigns it kind 10. */ > -#elif (LDBL_MANT_DIG == 64 \ > +#elif ((LDBL_MANT_DIG == 64 || LDBL_MANT_DIG == 53) \ > && LDBL_MIN_EXP == -16381 \ > && LDBL_MAX_EXP == 16384) Yes, with this patch (on top of current trunk) i586-freebsd-* is back in bootstrap land. :) On Tue, 14 Sep 2021, Jakub Jelinek wrote: >> That looks like range of extended float, but rounded to double float >> precision. > Yeah. > real.c has: > /* The following caters to i386 systems that set the rounding precision >to 53 bits instead of 64, e.g. FreeBSD. */ > const struct real_format ieee_extended_intel_96_round_53_format = > But, wonder why it didn't work with the float.h include then, because > https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h > seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381) and > LDBL_MAX_EXP to 16384 and that case was handled in ISO_Fortran_binding.h. A friendly soul reminded me off-list "that on i585-*-freebsd, the FPU is put into a mode where long double has only 53 bits of precision instead of 64 bits. [ /usr/include/x86/fpu.h has ] /* * The hardware default control word for i387's and later coprocessors is * 0x37F, giving: * * round to nearest * 64-bit precision * all exceptions masked. * * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc * because of the difference between memory and fpu register stack arguments. * If its using an intermediate fpu register, it has 80/64 bits to work * with. If it uses memory, it has 64/53 bits to work with. However, * gcc is aware of this and goes to a fair bit of trouble to make the * best use of it. * * This is mostly academic for AMD64, because the ABI prefers the use * SSE2 based math. For FreeBSD/amd64, we go with the default settings. */ #define __INITIAL_FPUCW__ 0x037F #define __INITIAL_FPUCW_I386__ 0x127F #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ #define __INITIAL_MXCSR__ 0x1F80 #define __INITIAL_MXCSR_MASK__ 0xFFBF " (end quote) Thanks for looking into this together! Gerald
Missing finalizations
I will (hopefully) have some time in the next few months to work on gfortran. I could pick up a few easy PRs to fix, but a more ambitious (and more useful) task would be to work on some of the missing finalizations. For my own work finalization of function results and stay constructors would be most useful. But, I don't have any real idea of how difficult this would be to do. Does any one here have any guidance on how to do this, or how challenging it might be? Thanks, Andrew
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Tue, 14 Sep 2021, Andreas Schwab wrote: > On Sep 14 2021, Jakub Jelinek wrote: > > > But, wonder why it didn't work with the float.h include then, because > > https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h > > seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381) and > > LDBL_MAX_EXP to 16384 and that case was handled in ISO_Fortran_binding.h. > > Doesn't gcc always use its own float.h? Subject to USER_H (i.e., except on OpenBSD, where GCC tests for newer float.h features would probably fail unless OpenBSD's version exactly matches the GCC testsuite expectations for those features). -- Joseph S. Myers jos...@codesourcery.com
Re: Missing finalizations
Hi Andrew, Not long before I had to step aside (temporarily, I hope) from gfortran maintenance, I made quite a lot of progress on missing finalizations. I'll dig out the in-progress patch for you and remind myself of the remaining issues. One of these was a standards problem, where the patched gfortran differed from a leading brand and I thought that the leading brand was wrong. Give me a day or two and prod me if I do not come up with the goods by the end of the week. Paul On Wed, 15 Sept 2021 at 01:31, Andrew Benson via Fortran < fortran@gcc.gnu.org> wrote: > I will (hopefully) have some time in the next few months to work on > gfortran. > I could pick up a few easy PRs to fix, but a more ambitious (and more > useful) > task would be to work on some of the missing finalizations. For my own > work > finalization of function results and stay constructors would be most > useful. > But, I don't have any real idea of how difficult this would be to do. Does > any > one here have any guidance on how to do this, or how challenging it might > be? > > Thanks, > Andrew > > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
