Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote: > On 07.10.21 05:35, Michael Meissner via Fortran wrote: > > I tried this at one point. There are a lot of hidden assumptions that the > > kind > > number is the number of bytes. I'm sure it can be tracked down, but the > > problem is with these assumptions is you can't prove a negative (i.e. you > > never > > know that you've missed some). > > So, summing up from the Fortran side, I'd say the best course of action > is to > > - make KIND=16 into IEEE QP > > - bump the SONAME on on affected systems on POWER and nowhere else > > - have a preprocessor flag so we can #ifdef out code which is relevant > only there If for libgfortran purposes, we already have one. > - provide a CONVERT option (have to think of a suitable syntax) to > do unformatted I/O either in IEEE QP or double double, but only > on affected systems, so people can set this either via a CONVERT > option on open or an environment variable. For OPEN, we should > extend the existing one, for an environment variable, I'd say > we should use a new one and reuse the existing parsing routines. So no extra KIND=15 support for double double? The above essentially means unlike the C/C++ world where the decision on what is long double we defer to distributions "when they are ready" (at gcc configure time for the default, or to users through -mabi=ieeelongdouble or -mabi=ibmlongdouble) for the Fortran we'd make the decision on the GCC side (in GCC 11 and earlier real(kind=16) is double double, in GCC 12+ on ppc64le real(kind=16) is IEEE QP), regardless of the -mabi=*longdouble flags etc. As Joseph mentioned, on the Fortran side doing that is easier than on the C/C++ side, where there is e.g. the requirement for GLIBC 2.32 or later for IEEE QP, for Fortran we'll need to decide at gcc configure time and either build libquadmath for ppc64le too (if glibc is older than 2.32) or use the libm stuff instead. Oh, and I guess some small difficulties will there be in the C compatibility, e.g. what to do iso_c_binding c_long_double and c_long_double_complex, if C and Fortran agree (depending on gcc configure time decision and -mabi=*longdouble) then it would be 16, but it is unclear what can be done for the case where the C long double doesn't have a corresponding Fortran kind... So maybe KIND=15 support would be useful at least for that. Jakub
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On 06/10/2021 07:59, Thomas Koenig via Fortran wrote: On 05.10.21 23:54, Segher Boessenkool wrote: Hi! On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote: On 04.10.21 16:14, Jakub Jelinek via Fortran wrote: Based on some IRC discussion, yet another option would be bump libgfortran SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean always IEEE quad (starting with GCC 12) and if wanted add support for real(kind=15) meaning double double. Bumping the SONAME for everybody even on architectures which are not affected (like x86 or ARM) does not really feel right. We will probably have to do it sooner or later, at least to get PDTs right (and for array descriptor reform), but we will then have to do another SONAME change when we do that (it is certainly not ready now). You do not have to change soname more than once per release. You could leave it at the old value for archs not affected. It is good for everyone's sanity to keep the same numbers for all archs though, so, just skip some for some archs. That's the best way, I think - no disruption on all other systems. I strongly advise against this -- identical SONAMEs for the libraries on all architectures is a key assumption on all Debian-based distributions and designs - I don't see it being possible on Fedora or SuSE etc either ; all presume a library package and updates based on SONAME (ie each source only generates a single SONAME). Updating SONAMEs is a key tool for distributions. Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Okt 07 2021, Alastair McKinstry wrote: > I strongly advise against this -- identical SONAMEs for the libraries on > all architectures is a key assumption on all Debian-based distributions > and designs Even glibc has differing sonames on some architectures. And libgcc_s, too. 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: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote: > On Okt 07 2021, Alastair McKinstry wrote: > > > I strongly advise against this -- identical SONAMEs for the libraries on > > all architectures is a key assumption on all Debian-based distributions > > and designs > > Even glibc has differing sonames on some architectures. And libgcc_s, > too. Yeah, lib[cm].so.6 on most arches and lib[cm].so.6.1 on ia64 or alpha. At least on Fedora I don't see a problem having libgfortran.so.5 on most arches and libgfortran.so.6 on ppc64le. And then next year or two/3 switch to libgfortran.so.7 everywhere. Jakub
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On 07/10/2021 11:01, Jakub Jelinek wrote: On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote: On Okt 07 2021, Alastair McKinstry wrote: I strongly advise against this -- identical SONAMEs for the libraries on all architectures is a key assumption on all Debian-based distributions and designs Even glibc has differing sonames on some architectures. And libgcc_s, too. Yeah, lib[cm].so.6 on most arches and lib[cm].so.6.1 on ia64 or alpha. At least on Fedora I don't see a problem having libgfortran.so.5 on most arches and libgfortran.so.6 on ppc64le. And then next year or two/3 switch to libgfortran.so.7 everywhere. SOVERSION (Major release) (and hence SONAME) change tracking are key to tracking the task of rebuilds/porting when incompatible changes happen in libraries (see https://release.debian.org/transitions/ and https://wiki.debian.org/Teams/ReleaseTeam/Transitions for examples of the process). lib[cm] on ia64 and alpha work in that libc has not changed major version in many years, and neither ia64 or alpha are currently "release candidates" in Debian, which we need to keep rebuilds in sync. Even so, the exception handling needed for them is a wart seen across the distro dependency trees. To make upgrades work, we have policy that it's possible that two versions of a library with different SONAME can co-exist on a users' system (package libgfortran5 "just" ships the libgfortran.so.5 file, libgfortran6 can co-exist with it), but a given source package only provides one of these library packages, and there is only one -dev package (eg libgfortran-dev pointing libgfortran.so -> libgfortan.so.6). A transition (eg gcc-11 to gcc-12 moving into the 'testing' staging distro) updates libgfortran-dev to point to 6, drops libgfortran5 from the Debian archive (but doesn't delete the package libgfortran5 from the users' computer) and we rebuild and transition simultaneously all packages that depend on libgfortran5. So if we introduce libgfortran6 for ppc64le (with potential ABI changes such as KIND) we rely on libgfortran5 disappearing for our transition scripts to work, and testing the transition process. We can special-case it just for one arch/package but its significant work and really painful. A simple soname/soversion transition across all archs is much preferred. Jakub Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
[PATCH, OpenMP 5.1, Fortran] Strictly-structured block support for OpenMP directives
Hi all,
this patch add support for "strictly-structured blocks" introduced in OpenMP
5.1,
basically allowing BLOCK constructs to serve as the body for directives:
!$omp target
block
...
end block
[!$omp end target] !! end directive is optional
!$omp parallel
block
...
end block
...
!$omp end parallel !! error, considered as not match to above parallel
directive
The parsing loop in parse_omp_structured_block() has been modified to allow
a BLOCK construct after the first statement has been detected to be ST_BLOCK.
This is done by a hard modification of the state into (the new)
COMP_OMP_STRICTLY_STRUCTURED_BLOCK
after the statement is known (I'm not sure if there's a way to 'peek' the next
statement/token in the Fortran FE, open to suggestions on how to better write
this)
Tested with no regressions on trunk, is this okay to commit?
Thanks,
Chung-Lin
2021-10-07 Chung-Lin Tang
gcc/fortran/ChangeLog:
* decl.c (gfc_match_end): Add COMP_OMP_STRICTLY_STRUCTURED_BLOCK case
together with COMP_BLOCK.
* parse.c (parse_omp_structured_block): Adjust declaration, add
'bool strictly_structured_block' default true parameter, add handling
for strictly-structured block case, adjust recursive calls to
parse_omp_structured_block.
(parse_executable): Adjust calls to parse_omp_structured_block.
* parse.h (enum gfc_compile_state): Add
COMP_OMP_STRICTLY_STRUCTURED_BLOCK.
* trans-openmp.c (gfc_trans_omp_workshare): Add EXEC_BLOCK case
handling.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/strictly-structured-block-1.f90: New test.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index b3c65b7175b..ff66d1f9475 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -8445,6 +8445,7 @@ gfc_match_end (gfc_statement *st)
break;
case COMP_BLOCK:
+case COMP_OMP_STRICTLY_STRUCTURED_BLOCK:
*st = ST_END_BLOCK;
target = " block";
eos_ok = 0;
diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index 7d765a0866d..d78bf9b8fa5 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -5451,8 +5451,9 @@ parse_oacc_loop (gfc_statement acc_st)
/* Parse the statements of an OpenMP structured block. */
-static void
-parse_omp_structured_block (gfc_statement omp_st, bool workshare_stmts_only)
+static gfc_statement
+parse_omp_structured_block (gfc_statement omp_st, bool workshare_stmts_only,
+ bool strictly_structured_block = true)
{
gfc_statement st, omp_end_st;
gfc_code *cp, *np;
@@ -5538,6 +5539,32 @@ parse_omp_structured_block (gfc_statement omp_st, bool
workshare_stmts_only)
gcc_unreachable ();
}
+ bool block_construct = false;
+ gfc_namespace* my_ns = NULL;
+ gfc_namespace* my_parent = NULL;
+
+ st = next_statement ();
+
+ if (strictly_structured_block && st == ST_BLOCK)
+{
+ /* Adjust state to a strictly-structured block, now that we found that
+the body starts with a BLOCK construct. */
+ s.state = COMP_OMP_STRICTLY_STRUCTURED_BLOCK;
+
+ block_construct = true;
+ gfc_notify_std (GFC_STD_F2008, "BLOCK construct at %C");
+
+ my_ns = gfc_build_block_ns (gfc_current_ns);
+ gfc_current_ns = my_ns;
+ my_parent = my_ns->parent;
+
+ new_st.op = EXEC_BLOCK;
+ new_st.ext.block.ns = my_ns;
+ new_st.ext.block.assoc = NULL;
+ accept_statement (ST_BLOCK);
+ st = parse_spec (ST_NONE);
+}
+
do
{
if (workshare_stmts_only)
@@ -5554,7 +5581,6 @@ parse_omp_structured_block (gfc_statement omp_st, bool
workshare_stmts_only)
restrictions apply recursively. */
bool cycle = true;
- st = next_statement ();
for (;;)
{
switch (st)
@@ -5576,17 +5602,20 @@ parse_omp_structured_block (gfc_statement omp_st, bool
workshare_stmts_only)
parse_forall_block ();
break;
+ case ST_OMP_PARALLEL_SECTIONS:
+ st = parse_omp_structured_block (st, false, false);
+ continue;
+
case ST_OMP_PARALLEL:
case ST_OMP_PARALLEL_MASKED:
case ST_OMP_PARALLEL_MASTER:
- case ST_OMP_PARALLEL_SECTIONS:
- parse_omp_structured_block (st, false);
- break;
+ st = parse_omp_structured_block (st, false);
+ continue;
case ST_OMP_PARALLEL_WORKSHARE:
case ST_OMP_CRITICAL:
- parse_omp_structured_block (st, true);
- break;
+ st = parse_omp_structured_block (st, true);
+ continue;
case ST_OMP_PARALLEL_DO:
case ST_OMP_PARALLEL_DO_SIMD:
@@ -5609,7 +5638,7 @@ parse_omp_structured_block (gfc_statement omp_st, bool
workshare_stmts_only)
}
}
else
- st = parse_executab
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote: > On 07.10.21 05:35, Michael Meissner via Fortran wrote: > > I tried this at one point. There are a lot of hidden assumptions that the > > kind > > number is the number of bytes. I'm sure it can be tracked down, but the > > problem is with these assumptions is you can't prove a negative (i.e. you > > never > > know that you've missed some). > > So, summing up from the Fortran side, I'd say the best course of action > is to > > - make KIND=16 into IEEE QP This is probably the right thing to do. Note, it will effectively mean that any fortran users on BE systems will no longer be able to use KIND=16. It will also be a compatibility issue if users have code compiled on a LE system with GCC 11 and earlier with KIND=16, it will not link with GCC 12. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
Re: [PATCH, Fortran] Add diagnostic for F2018:C839 (TS29113:C535c)
Hi Sandra,
On 06.10.21 23:37, Sandra Loosemore wrote:
This patch is for PR fortran/54753, to add a diagnostic for violations
of this constraint in the 2018 standard:
C839 If an assumed-size or nonallocatable nonpointer assumed-rank
array is an actual argument that corresponds to a dummy argument that
is an INTENT (OUT) assumed-rank array, it shall not be polymorphic,
finalizable, of a type with an allocatable ultimate component, or of a
type for which default initialization is specified.
(It now uses an interface instead of an actual subroutine definition,
since Tobias recently committed a patch to fix interfaces in order to
unblock my work on this one.) That bug is independent of enforcing
this constraint so I'm planning to open a new issue for it with its
own test case, if there isn't already one in Bugzilla.
I concur that that should be in a separate PR.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
...
+ gfc_array_spec *fas, *aas;
+ bool pointer_arg, allocatable_arg;;
Remove either ";" or ";".
@@ -3329,13 +3331,48 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap,
gfc_formal_arglist *formal,
+ if (a->expr->expr_type != EXPR_VARIABLE)
+ {
+ aas = NULL;
+ pointer_arg = false;
+ allocatable_arg = false;
This code is not generic but rather specific.
But it is fine as used in the code.
The question is how to prevent "?" or wrong code for future
code readers and writers.
The issue is that:
* "alloc_array(:)" is not allocatable but allocatable_arg
would be true.
* For var(5)%comp%comp2 - the aas and
allocatable_arg/pointer_arg is based on 'var' and not on
'comp2'.
As those vars are only used with expr->ref == NULL
(or expr->ref == whole-array ref) – and only with
assumed-rank or assumed-size dummys as actual argument,
it works fine as the not-handled code cannot occur.
* * *
Solution: I think the simplest would be to add a comment.
Alternatively:
* For 'aas', one way might be to move to 'enum array_type'
as that makes it clearer that 'aas' is for a special purpose,
only. I mean something like:
enum array_type a_array_type = AS_UNKNOWN;
if (a->expr->expr_type == EXPR_VARIABLE && a->expr->symtree->n.sym
&& a->expr->symtree->n.sym->as && )
a_array_type = a->expr->symtree->n.sym->as->type;
else if (... BT_CLASS ...)
...
For the attribute, either of the following would work:
* symbol_attribute arg_attr = gfc_expr_attr (e);
This uses the big hammer when a small one would be sufficient,
but it works in general.
or
* bool nonpointer_nonalloc_arg = ...
This uses a more specific name. The attributes might not be
correct, but the chance that it gets misused are reduced.
I think all variants work – and I am not sure what's the best.
There might be also other solutions, which are better/equally
good.
+ if (fas
+ && (fas->type == AS_ASSUMED_SHAPE
+ || fas->type == AS_DEFERRED
+ || (fas->type == AS_ASSUMED_RANK && f->sym->attr.pointer))
+ && aas
+ && aas->type == AS_ASSUMED_SIZE
&& (a->expr->ref == NULL
|| (a->expr->ref->type == REF_ARRAY
&& a->expr->ref->u.ar.type == AR_FULL)))
That's old code – but can you adapt it to handle BT_CLASS? I think
only 'f->sym->attr.pointer' causes the issue as it does not check for
CLASS_DATA()->attr.class_pointer – and the rest is fine, also because
of now using 'aas->type' which already encapsulates the classness.
Testcase:
--
type t
end type t
interface
subroutine fc2 (x)
import :: t
class(t), pointer, intent(in) :: x(..)
end
end interface
contains
subroutine sub1(y)
type(t), target :: y(*)
call fc2 (y) ! silently accepted
end
end
--
+ subroutine test_assumed_size_polymorphic (a1, a2)
+class(t1) :: a1(*), a2(*)
+call poly (a1, a2) ! { dg-error "(A|a)ssumed.rank" }
+call upoly (a1, a2) ! { dg-error "(A|a)ssumed.rank" }
+ end subroutine
Can you also add a call like involving something like:
a1(5), a2(4:7), a1(:10) or a2(:-5) ? (Here, '(:-5)' is a
rank-1, size-zero array.)
Calls with those are valid as those pass the array size alongside.
From the patch it looks as if they should just work, but it is
still good to test this.
+ subroutine test_assumed_size_unlimited_polymorphic (a1, a2)
+class(*) :: a1(*), a2(*)
+call upoly (a1, a2) ! { dg-error "(A|a)ssumed.rank" }
+ end subroutine
Likewise.
Otherwise, it looks good to me.
Thanks,
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: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Thu, Oct 07, 2021 at 11:24:35AM -0400, Michael Meissner wrote: > On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote: > > On 07.10.21 05:35, Michael Meissner via Fortran wrote: > > > I tried this at one point. There are a lot of hidden assumptions that > > > the kind > > > number is the number of bytes. I'm sure it can be tracked down, but the > > > problem is with these assumptions is you can't prove a negative (i.e. you > > > never > > > know that you've missed some). > > > > So, summing up from the Fortran side, I'd say the best course of action > > is to > > > > - make KIND=16 into IEEE QP > > This is probably the right thing to do. Note, it will effectively mean that > any fortran users on BE systems will no longer be able to use KIND=16. Changing it on powerpc64le-linux doesn't imply we also have to change it for powerpc64-linux, or perhaps can change it later than in GCC 12. > It will also be a compatibility issue if users have code compiled on a LE > system with GCC 11 and earlier with KIND=16, it will not link with GCC 12. libgfortran ABI changed multiple times in the past already, e.g. the so.1 -> so.2 transition in 4.2 so.2 -> so.3 transition in 4.3 so.3 -> so.4 transition in 7 so.4 -> so.5 transition in 8 and users have coped. Jakub
Re: [PATCH, OpenMP 5.1, Fortran] Strictly-structured block support for OpenMP directives
Hi Chung-Lin, On 07.10.21 15:59, Chung-Lin Tang wrote: this patch add support for "strictly-structured blocks" introduced in OpenMP 5.1, basically allowing BLOCK constructs to serve as the body for directives: !$omp target block ... end block [!$omp end target] !! end directive is optional Pre-remark: That OpenMP feature causes ambiguities. I have filled an OpenMP spec issue to discuss this, Issue 3154. Namely the following is unclear: !$omp parallel !$omp parallel block x= x+ 1 end block !$omp end parallel Does the 'end parallel' end the inner strictly structured block or the outer loosely structured block? In principle, a compiler could defer this until later during parsing, but this requires a tremendous state tracking and it is surely not simple to do in gfortran (and probably all other compilers). — Thus, I think the spec will change and probably in the way which this patch has implemented. NOTE: It takes the kind of directive into account, i.e. 'omp end target' vs. 'omp end parallel' aren't ambiguous. The parsing loop in parse_omp_structured_block() has been modified to allow a BLOCK construct after the first statement has been detected to be ST_BLOCK. This is done by a hard modification of the state into (the new) COMP_OMP_STRICTLY_STRUCTURED_BLOCK after the statement is known (I'm not sure if there's a way to 'peek' the next statement/token in the Fortran FE, open to suggestions on how to better write this) Tested with no regressions on trunk, is this okay to commit? LGTM – unless Jakub has further comments. However, I have two requests: First, can you include an update of the implementation status in libgomp/libgomp.texi (+ fix the ...ppp... typo): "@item Suppport of strictly structured blocks in Fortran @tab N @tab" Secondly, can you extend the testcase a bit to include nesting a BLOCK inside the other BLOCK – and nesting the directive with a strictly structured block inside another (different) directive to ensure that the 'omp end ...' is correctly matched. I mean something like: integer :: x !$omp target map(i) !$omp parallel block block x = x + 1 end block end block !$omp end target !$omp target map(i) !$omp parallel block block x = x + 1 end block end block !$omp end parallel !$omp end target end Thanks, Tobias 2021-10-07 Chung-Lin Tang gcc/fortran/ChangeLog: * decl.c (gfc_match_end): Add COMP_OMP_STRICTLY_STRUCTURED_BLOCK case together with COMP_BLOCK. * parse.c (parse_omp_structured_block): Adjust declaration, add 'bool strictly_structured_block' default true parameter, add handling for strictly-structured block case, adjust recursive calls to parse_omp_structured_block. (parse_executable): Adjust calls to parse_omp_structured_block. * parse.h (enum gfc_compile_state): Add COMP_OMP_STRICTLY_STRUCTURED_BLOCK. * trans-openmp.c (gfc_trans_omp_workshare): Add EXEC_BLOCK case handling. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/strictly-structured-block-1.f90: New test. - 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, OpenMP 5.1, Fortran] Strictly-structured block support for OpenMP directives
On Thu, Oct 07, 2021 at 09:59:00PM +0800, Chung-Lin Tang wrote:
> this patch add support for "strictly-structured blocks" introduced in OpenMP
> 5.1,
> basically allowing BLOCK constructs to serve as the body for directives:
>
> !$omp target
> block
> ...
> end block
> [!$omp end target] !! end directive is optional
>
> !$omp parallel
> block
> ...
> end block
> ...
> !$omp end parallel !! error, considered as not match to above parallel
> directive
>
> The parsing loop in parse_omp_structured_block() has been modified to allow
> a BLOCK construct after the first statement has been detected to be ST_BLOCK.
> This is done by a hard modification of the state into (the new)
> COMP_OMP_STRICTLY_STRUCTURED_BLOCK
> after the statement is known (I'm not sure if there's a way to 'peek' the next
> statement/token in the Fortran FE, open to suggestions on how to better write
> this)
Thanks for working on this.
The workshare/parallel workshare case is unclear, I've filed
https://github.com/OpenMP/spec/issues/3153
for it. Either don't allow block if workshare_stmts_only for now
until that is clarified, or if we do, we need to make sure that it does the
expected thing, does that gfc_trans_block_construct call ensure it?
Then we have the
https://github.com/OpenMP/spec/issues/3154
issue Tobias discovered, if that issue is resolved to end always applying to
the directive before the block statement, I think your patch handles it that
way but we want testsuite coverage for some of those cases.
For the testcases, I think best would be to split it into two, one that
contains only what we want to accept and another one with dg-errors in it.
I don't think the patch does the right thing for sections/parallel sections.
That is (at least in 5.1) defined as:
!$omp sections clauses...
[!$omp section]
structured-block-sequence
[!$omp section
structured-block-sequence]
...
!$omp end sections
(and similarly for parallel sections).
I believe your patch properly disallows:
!$omp sections
block
...
!$omp section
...
end block
!$omp end sections
- block itself is allowed, e.g.
!$omp sections
block
a=1
b=2
end block
!$omp end sections
with the meaning that the block is after the first implied !$omp section
and there is nothing else. But does the patch actually check that
!$omp sections
block
...
end block
c=1
!$omp end sections
or
!$omp sections
!$omp section
block
...
end block
c=1
!$omp section
d=1
!$omp end sections
is invalid? Though, not sure if that was the intended effect, in
OpenMP 5.0 that used to be fine. But then the other changes are backwards
incompatible too,
!$omp parallel
block
...
end block
c=1
!$omp end parallel
used to be valid but no longer is. structured-block-sequence is fortran
defined as structured-block and structured-block is defined as either
loosely-structured-block or strictly-structured-block, so for sections
in between each !$omp section should be either anything not starting with
block, or, if it starts with block, after end block there should be
immediately !$omp section or !$omp end {,parallel }sections.
Another thing is scan, the wording is similar and newly
!$omp do reduction(+,inscan:a)
do i=1,10
block
...
end block
x=1
!$omp scan
block
...
end block
x=2
end do
is invalid.
> @@ -5538,6 +5539,32 @@ parse_omp_structured_block (gfc_statement omp_st, bool
> workshare_stmts_only)
>gcc_unreachable ();
> }
>
> + bool block_construct = false;
> + gfc_namespace* my_ns = NULL;
> + gfc_namespace* my_parent = NULL;
The usual coding conventions put * before variable name instead of after it
(except for libstdc++).
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/gomp/strictly-structured-block-1.f90
> @@ -0,0 +1,295 @@
> +! { dg-do compile }
> +! { dg-options "-fopenmp" }
> +
> +program main
> + integer :: x
> +
> + !$omp parallel
> + block
> +x = x + 1
> + end block
> +
> + !$omp parallel
> + block
> +x = x + 1
> + end block
> + !$omp end parallel
> +
> + !$omp parallel
> + block
> +x = x + 1
> + end block
> + x = x + 1
> + !$omp end parallel ! { dg-error "Unexpected !.OMP END PARALLEL statement" }
Other than the splitting into non-dg-error stuff in one testcase and
dg-error in another one, I think we want (probably in yet another pair of
testcases) test what we are not required to do but with your patch we
actually implement, in particular that !$omp master behaves the same way.
> + !$omp ordered
> + block
> +x = x + 1
> + end block
> +
> + !$omp ordered
> + block
> +x = x + 1
> + end block
> + !$omp end ordered
> +
> + !$omp ordered
> + block
> +x = x + 1
> + end block
> + x = x + 1
> + !$omp end ordered ! { dg-error "Unexpected !.OMP END ORDERED statement" }
I believe these 3 can't be done in the program, would either need to be
wrapped in some !$omp do with ordered clause or should go each ordered into
its own orphaned subroutine, because ordered region must bind to a
worksharing-loop with ordered clause. I th
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On 07.10.21 17:33, Jakub Jelinek wrote:
It will also be a compatibility issue if users have code compiled on a LE
system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
libgfortran ABI changed multiple times in the past already, e.g. the
so.1 -> so.2 transition in 4.2
so.2 -> so.3 transition in 4.3
so.3 -> so.4 transition in 7
so.4 -> so.5 transition in 8
and users have coped.
Yes, and it has always been a hassle for users, and we've been
criticized for it.
This is currently a change which brings users on non-POWER-systems
(the vast majority) all pain and no gain. If this cannot be
avoided, I would at least try to fit in as much of other improvements
as there are possible.
There's a PR for it somewhere, but I can think of three areas, none
of the small, and all require an ABI change:
a) Get PDTs right (Paul?)
b) Make file descriptors conform to the C interop version
c) Remove the run-time parsing of I/O arguments and
replace them with a bit field.
What I mean by the last one is that
WRITE (unit,'(A)',ADVANCE="NO")
we currently parse the "NO" at runtime, for every statement
execution. What we could be doing instead is to have
dt_parm.0.advance = __gfortran_evaluate_yesno ("NO")
where the latter function can be simplified at compile-time.
We should strive to break the ABI as few times as possible.
Best regards
Thomas
