Re: [PATCH] PR fortran/102685 - ICE in output_constructor_regular_field, at varasm.c:5514
Hi Harald, dear all,
On 14.10.21 23:27, Harald Anlauf via Fortran wrote:
the attached patch adds a check for the shape of arrays in derived type
constructors. This brings it in line with other major brands.
...
In developing the patch I encountered a difficulty with testcase
dec_structure_6.f90, which uses a DEC extension, namelist "old-style
CLIST initializers in STRUCTURE". I could not figure out how to
determine the shape of the initializer; it seemed to be always zero.
I've added code to accept this, but only under -fdec-structure, and
added a TODO in a comment. If somebody reading this could give me
a hint to solve end, I would adjust the patch accordingly.
See attached patch – it does initialize the variables similarly to other
shapes in that file, except that it has to take the shape from the LHS
as seemingly (same testfile) having a 1-dim array can be used to
initialize a 2-dim array.
You can approve that patch and integrate it then in your own patch :-)
Regtested on x86_64-pc-linux-gnu. OK? Or further comments?
LGTM – with the DECL exception removed from resolve.c.
Thanks,
Tobias
PS: Without the auto-reshape part, a simple 'gfc_array_size (expr,
&expr->shape[0]))" would have been sufficient.
-
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
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index d6a22d13451..86adb81da32 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -892,29 +892,32 @@ match_clist_expr (gfc_expr **result, gfc_typespec *ts, gfc_array_spec *as)
/* Set up expr as an array constructor. */
if (!scalar)
{
expr = gfc_get_array_expr (ts->type, ts->kind, &where);
expr->ts = *ts;
expr->value.constructor = array_head;
- expr->rank = as->rank;
- expr->shape = gfc_get_shape (expr->rank);
-
/* Validate sizes. We built expr ourselves, so cons_size will be
constant (we fail above for non-constant expressions).
We still need to verify that the sizes match. */
gcc_assert (gfc_array_size (expr, &cons_size));
cmp = mpz_cmp (cons_size, as_size);
if (cmp < 0)
gfc_error ("Not enough elements in array initializer at %C");
else if (cmp > 0)
gfc_error ("Too many elements in array initializer at %C");
mpz_clear (cons_size);
if (cmp)
goto cleanup;
+
+ /* Set the rank/shape to match the LHS as auto-reshape is implied. */
+ expr->rank = as->rank;
+ expr->shape = gfc_get_shape (as->rank);
+ for (int i = 0; i < as->rank; ++i)
+ spec_dimen_size (as, i, &expr->shape[i]);
}
/* Make sure scalar types match. */
else if (!gfc_compare_types (&expr->ts, ts)
&& !gfc_convert_type (expr, ts, 1))
goto cleanup;
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
Thanks, Jakub, for starting this discussion, and to everyone who weighed in. The conversation went in a number of different directions, so I'd like to summarize my understanding of points where I think there was agreement. I'd also like to separate out short-term considerations for powerpc64le and GCC 12 from other topics like supporting more targets. === First, for the short-term. For powerpc64le only (little-endian, ELFv2 ABI) Thomas suggested that Fortran's best course of action is: - Change KIND=16 in GCC 12 from double-double to IEEE QP just for affected targets - Bump the SONAME just for affected targets - Have a preprocessor flag to help #ifdef out irrelevant code (which Jakub asserted exists) - Deal with binary (unformatted) I/O with a CONVERT option for OPEN, and/or an envvar, to allow selection between the two formats There was some discussion of dual-mangling names for Fortran, but this didn't seem practical because of a number of complicating factors. There is an open question about possibly using KIND=15 or KIND=17 to represent double-double going forward. It's not clear whether or not this is necessary, but some C compatibility scenarios were cited as possible motivations. There was some concern about SONAME numbers differing across architectures, but consensus seems to be that this can be handled. Summary: I didn't see any serious pushback to Thomas's suggested course of action, and the only major open question is about maintaining a KIND to represent double-double. === Longer term, we have the question of supporting more Power targets. AIX will continue to use only double-double. It is agreed that it would be useful for 32- and 64-bit BE Linux to support IEEE QP as well, on some future timeline. The first step towards this is to develop and document ABI for IEEE QP on those targets. The simplest approach that everyone seemed to like is for these ABIs to require AltiVec support in order for IEEE QP to be supported. This allows parameters and return values to always be passed in vector registers, whether implemented with hardware instructions or a soft-float library. libquadmath can be built for these targets. [Sidebar: The ELFv1 document needs a new home, as the last version was published by the now-defunct POWER.org. But we can deal with that.] Beyond ABI and compiler support, glibc would also need to support IEEE QP for these other targets. Currently we only have support for powerpc64le. === Is this a fair summary of the results of the discussion? Thanks again! Bill
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Fri, Oct 15, 2021 at 08:50:08AM -0500, Bill Schmidt wrote: > Thanks, Jakub, for starting this discussion, and to everyone who weighed in. > The conversation > went in a number of different directions, so I'd like to summarize my > understanding of points > where I think there was agreement. I'd also like to separate out short-term > considerations > for powerpc64le and GCC 12 from other topics like supporting more targets. > > === > > First, for the short-term. For powerpc64le only (little-endian, ELFv2 ABI) > Thomas suggested > that Fortran's best course of action is: > - Change KIND=16 in GCC 12 from double-double to IEEE QP just for affected > targets > - Bump the SONAME just for affected targets > - Have a preprocessor flag to help #ifdef out irrelevant code (which Jakub > asserted exists) > - Deal with binary (unformatted) I/O with a CONVERT option for OPEN, and/or > an envvar, to >allow selection between the two formats > > There was some discussion of dual-mangling names for Fortran, but this didn't > seem practical > because of a number of complicating factors. > > There is an open question about possibly using KIND=15 or KIND=17 to > represent double-double > going forward. It's not clear whether or not this is necessary, but some C > compatibility > scenarios were cited as possible motivations. > > There was some concern about SONAME numbers differing across architectures, > but consensus > seems to be that this can be handled. > > Summary: I didn't see any serious pushback to Thomas's suggested course of > action, and the > only major open question is about maintaining a KIND to represent > double-double. > > === ... > > Is this a fair summary of the results of the discussion? For me yes. As for a separate KIND!=16 for double-double, I've looked up Fortran 2018 standard wording and it seems that the ISO C Bindings actually don't require such kind to exist, I believe C_LONG_DOUBLE should be -3 if -mabi=ibmlongdouble and we only support real KIND 4, 8 and 16 (last one IEEE quad), because it says that -3 stands for "has neither the precision nor range" and when one compiles integer function foo () foo = precision (0.0_16) end function foo integer function bar () bar = range (0.0_16) end function bar with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble 33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither precision of C long double if it is double-double nor range matches anything. If we do implement double-double support, I think KIND=15 would be better than KIND=17, it is true that double-double has for certain numbers much higher precision than IEEE quad, but the precision depends on the numbers and most of the time is smaller, the range is always smaller. And the PRECISION/RANGE intrinsic numbers are also both smaller. Jakub
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On 15.10.21 16:20, Jakub Jelinek wrote: [...] when one compiles integer function foo () foo = precision (0.0_16) end function foo integer function bar () bar = range (0.0_16) end function bar with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble 33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither precision of C long double if it is double-double nor range matches anything. If we do implement double-double support, I think KIND=15 would be better than KIND=17, it is true that double-double has for certain numbers much higher precision than IEEE quad, but the precision depends on the numbers and most of the time is smaller, the range is always smaller. And the PRECISION/RANGE intrinsic numbers are also both smaller. There is one potential problem: selected_real_kind. The standard says about that... # If more than one kind type parameter value meets the criteria, the # value returned is the one with the smallest decimal precision, unless # there are several such values, in which case the smallest of these # kind values is returned So, selected_real_kind(25) would yield double double, and we would have to violate the standard there if we wanted people to have IEEE QP in that case. Best regards Thomas
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote: > > with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble > > 33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither > > precision of C long double if it is double-double nor range matches > > anything. > > If we do implement double-double support, I think KIND=15 would be better > > than KIND=17, it is true that double-double has for certain numbers much > > higher precision than IEEE quad, but the precision depends on the numbers > > and most of the time is smaller, the range is always smaller. And > > the PRECISION/RANGE intrinsic numbers are also both smaller. > > There is one potential problem: selected_real_kind. > > The standard says about that... > > # If more than one kind type parameter value meets the criteria, the > # value returned is the one with the smallest decimal precision, unless > # there are several such values, in which case the smallest of these > # kind values is returned > > So, selected_real_kind(25) would yield double double, and we would > have to violate the standard there if we wanted people to have > IEEE QP in that case. That would be true if some kind exist for double double, whether it is kind == 15 or kind == 17, no? Because precision (0.0_double_double_kind) < precision (0.0_ieee_quad_kind) so the "smallest of the kind values" doesn't trigger. Jakub
Re: [PATCH, OpenMP 5.1, Fortran] Strictly-structured block support for OpenMP directives
On 2021/10/14 7:19 PM, Jakub Jelinek wrote: On Thu, Oct 14, 2021 at 12:20:51PM +0200, Jakub Jelinek via Gcc-patches wrote: Thinking more about the Fortran case for !$omp sections, there is an ambiguity. !$omp sections block !$omp section end block is clear and !$omp end sections is optional, but !$omp sections block end block is ambiguous during parsing, it could be either followed by !$omp section and then the BLOCK would be first section, or by !$omp end sections and then it would be clearly the whole sections, with first section being empty inside of the block, or if it is followed by something else, it is ambiguous whether the block ... end block is part of the first section, followed by something and then we should be looking later for either !$omp section or !$omp end section to prove that, or if !$omp sections block end block was the whole sections construct and we shouldn't await anything further. I'm afraid back to the drawing board. And I have to correct myself, there is no ambiguity in 5.2 here, the important fact is hidden in sections/parallel sections being block-associated constructs. That means the body of the whole construct has to be a structured-block, and by the 5.1+ definition of Fortran structured block, it is either block ... end block or something that doesn't start with block. So, !$omp sections block end block a = 1 is only ambiguous in whether it is actually !$omp sections block !$omp section end block a = 1 or !$omp sections !$omp section block end block !$omp end sections a = 1 but both actually do the same thing, work roughly as !$omp single. If one wants block statement as first in structured-block-sequence of the first section, followed by either some further statements or by other sections, then one needs to write !$omp sections !$omp section block end block a = 1 ... !$omp end sections or !$omp sections block block end block a = 1 ... end block Your patch probably already handles it that way, but we again need testsuite coverage to prove it is handled the way it should in all these cases (and that we diagnose what is invalid). The patch currently does not allow strictly-structured BLOCK for sections/parallel sections, since I was referencing the 5.1 spec while writing it, although that is trivially fixable. (was sensing a bit odd why those two constructs had to be specially treated in 5.1 anyways) The bigger issue is that under the current way the patch is written, the statements inside a [parallel] sections construct are parsed automatically by parse_executable(), so to enforce the specified meaning of "structured-block-sequence" (i.e. BLOCK or non-BLOCK starting sequence of stmts) will probably be more a bit harder to implement: !$omp sections block !$omp section block x=0 end block x=1 !! This is allowed now, though should be wrong spec-wise !$omp section x=2 end block Currently "$!omp section" acts essentially as a top-level separator within a sections-construct, rather than a structured directive. Though I would kind of argue this is actually better to use for the user (why prohibit what looks like very apparent meaning of the program?) So Jakub, my question for this is, is this current state okay? Or must we implement the spec pedantically? As for the other issues: (1) BLOCK/END BLOCK is not generally handled in parse_omp_structured_block, so for workshare, it is only handled for the top-level construct, not within workshare. I think this is what you meant in the last mail. (2) As for the dangling-!$omp_end issue Tobias raised, because we are basically using 1-statement lookahead, any "!$omp end <*>" is naturally bound with the adjacent BLOCK/END BLOCK, so we should be okay there. Thanks, Chung-Lin
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On 15.10.21 20:11, Jakub Jelinek wrote: On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote: with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble 33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither precision of C long double if it is double-double nor range matches anything. If we do implement double-double support, I think KIND=15 would be better than KIND=17, it is true that double-double has for certain numbers much higher precision than IEEE quad, but the precision depends on the numbers and most of the time is smaller, the range is always smaller. And the PRECISION/RANGE intrinsic numbers are also both smaller. There is one potential problem: selected_real_kind. The standard says about that... # If more than one kind type parameter value meets the criteria, the # value returned is the one with the smallest decimal precision, unless # there are several such values, in which case the smallest of these # kind values is returned So, selected_real_kind(25) would yield double double, and we would have to violate the standard there if we wanted people to have IEEE QP in that case. That would be true if some kind exist for double double, whether it is kind == 15 or kind == 17, no? Correct. The authors probably did not think of this particular case when they wrote the standard. We can ask the J3 standards committee to change the wording. I think I will just do that, to see what they have to say. Best regards Thomas
Re: [PATCH, OpenMP 5.1, Fortran] Strictly-structured block support for OpenMP directives
On Sat, Oct 16, 2021 at 02:44:12AM +0800, Chung-Lin Tang wrote:
> The patch currently does not allow strictly-structured BLOCK for
> sections/parallel sections,
> since I was referencing the 5.1 spec while writing it, although that is
> trivially fixable.
> (was sensing a bit odd why those two constructs had to be specially treated
> in 5.1 anyways)
>
> The bigger issue is that under the current way the patch is written, the
> statements inside
> a [parallel] sections construct are parsed automatically by
> parse_executable(), so to enforce
> the specified meaning of "structured-block-sequence" (i.e. BLOCK or non-BLOCK
> starting sequence of stmts)
> will probably be more a bit harder to implement:
>
> !$omp sections
> block
>!$omp section
>block
> x=0
>end block
>x=1 !! This is allowed now, though should be wrong spec-wise
>!$omp section
>x=2
> end block
>
> Currently "$!omp section" acts essentially as a top-level separator within a
> sections-construct,
> rather than a structured directive. Though I would kind of argue this is
> actually better to use for the
> user (why prohibit what looks like very apparent meaning of the program?)
>
> So Jakub, my question for this is, is this current state okay? Or must we
> implement the spec pedantically?
I'd certainly not implement 5.1 pedantically when we know we'd change one
way for 5.0 -> 5.1 and change it back again for 5.1 -> 5.2.
An example of that is
!$omp sections
!$omp section
block
end block
x = 1
!$end omp sections
This is valid in 5.0 and will be valid again in 5.2 with the same meaning,
so let's just use the 5.0/5.2 wording here. Ditto the !$omp end ambiguity
Tobias raised etc.
Whether to add support for the 5.2 behavior when one sees
!$omp {,parallel }sections
block
or not is more tough question, I bet the answer should be what is easier to
implement right now (i.e. don't spend too much effort on hard 5.1
implementation if 5.2 would be easier, as eventually we'd need to do the 5.2
implementation afterwards anyway).
So, for block right after sections either we implement the 5.2 wording right
away and therefore look for !$omp section only within that block and not
outside of it, or we for the 1st section with omitted !$omp section before
it only implement the 5.1 pedantic behavior, i.e. if it starts with a block,
don't look for !$omp section in the block, but require either !$omp section
or !$omp end sections right after the corresponding end block.
Does this answer all questions?
Jakub
Re: [PATCH] PR fortran/102685 - ICE in output_constructor_regular_field, at varasm.c:5514
Hi Tobias, all, > > In developing the patch I encountered a difficulty with testcase > > dec_structure_6.f90, which uses a DEC extension, namelist "old-style > > CLIST initializers in STRUCTURE". I could not figure out how to > > determine the shape of the initializer; it seemed to be always zero. > > I've added code to accept this, but only under -fdec-structure, and > > added a TODO in a comment. If somebody reading this could give me > > a hint to solve end, I would adjust the patch accordingly. > > See attached patch – it does initialize the variables similarly to other > shapes in that file, except that it has to take the shape from the LHS > as seemingly (same testfile) having a 1-dim array can be used to > initialize a 2-dim array. > > You can approve that patch and integrate it then in your own patch :-) your fix to match_clist_expr LGTM. I can really use it. > LGTM – with the DECL exception removed from resolve.c. I've removed the DEC exception, cleaned up, regtested again. Committed and pushed: https://gcc.gnu.org/g:1e819bd95ebeefc1dc469daa1855ce005cb77822 Thanks, Harald > Thanks, > > Tobias > > PS: Without the auto-reshape part, a simple 'gfc_array_size (expr, > &expr->shape[0]))" would have been sufficient. > - > 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: Fix CLASS conversion check [PR102745]
This patch fixes two issues:
First, to print 'CLASS(t2)' instead of:
Error: Type mismatch in argument ‘x’ at (1); passed CLASS(__class_MAIN___T2_a)
to TYPE(t)
Additionally,
class(t2) = class(t) ! 't2' extends 't'
class(t2) = class(any)
was wrongly accepted.
OK?
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
Fortran: Fix CLASS conversion check [PR102745]
PR fortran/102745
gcc/fortran/ChangeLog
* intrinsic.c (gfc_convert_type_warn): Fix checks by checking CLASS
and do typcheck in correct order for type extension.
* misc.c (gfc_typename): Print proper not internal CLASS type name.
gcc/testsuite/ChangeLog
* gfortran.dg/class_72.f90: New.
gcc/fortran/intrinsic.c| 7 +--
gcc/fortran/misc.c | 10 ++--
gcc/testsuite/gfortran.dg/class_72.f90 | 83 ++
3 files changed, 92 insertions(+), 8 deletions(-)
diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index 219f04f2317..f5c88d98cc9 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -5237,12 +5237,13 @@ gfc_convert_type_warn (gfc_expr *expr, gfc_typespec *ts, int eflag, int wflag,
/* In building an array constructor, gfortran can end up here when no
conversion is required for an intrinsic type. We need to let derived
types drop through. */
- if (from_ts.type != BT_DERIVED
+ if (from_ts.type != BT_DERIVED && from_ts.type != BT_CLASS
&& (from_ts.type == ts->type && from_ts.kind == ts->kind))
return true;
- if (expr->ts.type == BT_DERIVED && ts->type == BT_DERIVED
- && gfc_compare_types (&expr->ts, ts))
+ if ((expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
+ && (ts->type == BT_DERIVED || ts->type == BT_CLASS)
+ && gfc_compare_types (ts, &expr->ts))
return true;
/* If array is true then conversion is in an array constructor where
diff --git a/gcc/fortran/misc.c b/gcc/fortran/misc.c
index 3d449ae17fe..e6402e881e3 100644
--- a/gcc/fortran/misc.c
+++ b/gcc/fortran/misc.c
@@ -130,7 +130,6 @@ gfc_typename (gfc_typespec *ts, bool for_hash)
static char buffer2[GFC_MAX_SYMBOL_LEN + 8];
static int flag = 0;
char *buffer;
- gfc_typespec *ts1;
gfc_charlen_t length = 0;
buffer = flag ? buffer1 : buffer2;
@@ -180,16 +179,17 @@ gfc_typename (gfc_typespec *ts, bool for_hash)
sprintf (buffer, "TYPE(%s)", ts->u.derived->name);
break;
case BT_CLASS:
- if (ts->u.derived == NULL)
+ if (!ts->u.derived || !ts->u.derived->components
+ || !ts->u.derived->components->ts.u.derived)
{
sprintf (buffer, "invalid class");
break;
}
- ts1 = ts->u.derived->components ? &ts->u.derived->components->ts : NULL;
- if (ts1 && ts1->u.derived && ts1->u.derived->attr.unlimited_polymorphic)
+ if (ts->u.derived->components->ts.u.derived->attr.unlimited_polymorphic)
sprintf (buffer, "CLASS(*)");
else
- sprintf (buffer, "CLASS(%s)", ts->u.derived->name);
+ sprintf (buffer, "CLASS(%s)",
+ ts->u.derived->components->ts.u.derived->name);
break;
case BT_ASSUMED:
sprintf (buffer, "TYPE(*)");
diff --git a/gcc/testsuite/gfortran.dg/class_72.f90 b/gcc/testsuite/gfortran.dg/class_72.f90
new file mode 100644
index 000..0fd6ec010f5
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_72.f90
@@ -0,0 +1,83 @@
+! PR fortran/102745
+
+implicit none
+
+type t
+end type t
+
+type, extends(t) :: t2
+end type t2
+
+type t3
+end type t3
+
+type(t), allocatable :: var
+type(t2), allocatable :: v2ar
+type(t3), allocatable :: v3ar
+class(t), allocatable :: cvar
+class(t2), allocatable :: c2var
+class(t3), allocatable :: c3var
+
+call f(var)
+call f(v2ar) ! { dg-error "passed TYPE.t2. to TYPE.t." }
+call f(v2ar%t)
+call f(cvar)
+call f(c2var) ! { dg-error "passed CLASS.t2. to TYPE.t." }
+call f(c2var%t)
+
+call f2(var) ! { dg-error "passed TYPE.t. to TYPE.t2." }
+call f2(v2ar)
+call f2(cvar) ! { dg-error "passed CLASS.t. to TYPE.t2." }
+call f2(c2var)
+
+
+var = var
+var = v2ar ! { dg-error "TYPE.t2. to TYPE.t." }
+var = cvar
+var = c2var ! { dg-error "TYPE.t2. to TYPE.t." }
+
+v2ar = var ! { dg-error "Cannot convert TYPE.t. to TYPE.t2." }
+v2ar = v2ar
+v2ar = cvar ! { dg-error "Cannot convert TYPE.t. to TYPE.t2." }
+v2ar = c2var
+
+cvar = var
+cvar = v2ar
+cvar = cvar
+cvar = c2var
+
+c2var = var ! { dg-error "Cannot convert TYPE.t. to CLASS.t2." }
+c2var = v3ar ! { dg-error "Cannot convert TYPE.t3. to CLASS.t2." }
+c2var = v2ar
+c2var = cvar ! { dg-error "Cannot convert CLASS.t. to CLASS.t2." }
+c2var = c3var ! { dg-error "Cannot convert CLASS.t3. to CLASS.t2." }
+c2var = c2var
+
+allocate (var, source=var)
+allocate (var, source=v2ar) ! { dg-error "incompatible with source-expr" }
+allocate (var, source=
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Fri, Oct 15, 2021 at 04:20:49PM +0200, Jakub Jelinek wrote: > If we do implement double-double support, I think KIND=15 would be better > than KIND=17, it is true that double-double has for certain numbers much > higher precision than IEEE quad, but the precision depends on the numbers > and most of the time is smaller, the range is always smaller. And > the PRECISION/RANGE intrinsic numbers are also both smaller. Yes. We want KIND=16 to mean the IEEE QP format whenever we can, right? And another 16-byte format would more logically be kind=17 then, considering we want to have two 2-byte kinds at least, one of them IEEE as well. Other practical considerations might well supersede elegance of course. Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
Thank you for writing this out Bill! On Fri, Oct 15, 2021 at 08:50:08AM -0500, Bill Schmidt wrote: > Longer term, we have the question of supporting more Power targets. AIX will > continue to > use only double-double. Yes. So it will be virtually no cost to continue supporting double-double on all targets (implementation cost that is -- maintenance cost will actually be negative for keeping it for a while, old data sticks around for a very long time.) > It is agreed that it would be useful for 32- and 64-bit BE Linux > to support IEEE QP as well, on some future timeline. The first step towards > this is to > develop and document ABI for IEEE QP on those targets. The simplest approach > that everyone > seemed to like is for these ABIs to require AltiVec support in order for IEEE > QP to be > supported. This allows parameters and return values to always be passed in > vector registers, > whether implemented with hardware instructions or a soft-float library. > libquadmath can > be built for these targets. This is a great choice for the ABIs that have AltiVec enabled, yes. It requires almost no modification to the parameter passing for them (ignoring the obvious fact that it changes where long double is passed, if long double now is IEEE QP; similarly, KIND=16), it can be just the same as anything else passed in VRs. At a later date we can consider having QP for ABIs without AltiVec as well, if there is any interest in that. Since there exists no such thing yet, having QP passed in VRs will be easy to do everywhere :-) Segher
