So, if I try to sum up what has been gathered in this thread:
- pr104131.f90 is invalid, as x is not scalar.
Checks are better done in resolve_omp_clauses after a call
to gfc_resolve_expr.
Checking expr->sym->attr.dimension seems to cover more cases than
expr->rank > 0.
-
First, thanks for looking into the standard. I think the information is
too much spread through the standard. I keep searching for restrictions,
find them at 5 places and miss another 5. With OpenMP 5.2, it became
even worse.
On 01.03.22 09:16, Jakub Jelinek wrote:
As there is no explicit
On Tue, Mar 01, 2022 at 08:58:54AM +0100, Tobias Burnus wrote:
> The wording actually also permits array sections. But contrary to coarrays,
> (which are odd but otherwise fine), I think it does not really make sense
> to have arrays and array sections here.
>
> (Do we need/want to get this
On 28.02.22 22:37, Jakub Jelinek via Fortran wrote:
On Mon, Feb 28, 2022 at 09:45:10PM +0100, Mikael Morin wrote:
Lesson learned today: expressions don’t have a corank.
Does pr104131-2.f90 really need to be rejected?
In my reading of the spec, pr104131-2.f90 is _valid_ (in newer OMP). At
Le 28/02/2022 à 22:37, Jakub Jelinek a écrit :
On Mon, Feb 28, 2022 at 09:45:10PM +0100, Mikael Morin wrote:
Le 28/02/2022 à 21:37, Mikael Morin a écrit :
Maybe corank should be checked together with rank?
Lesson learned today: expressions don’t have a corank.
There is gfc_is_coindexed
On Mon, Feb 28, 2022 at 09:45:10PM +0100, Mikael Morin wrote:
> Le 28/02/2022 à 21:37, Mikael Morin a écrit :
> > Maybe corank should be checked together with rank?
>
> Lesson learned today: expressions don’t have a corank.
> Does pr104131-2.f90 really need to be rejected?
OpenMP 5.2 says that
Le 28/02/2022 à 21:37, Mikael Morin a écrit :
Maybe corank should be checked together with rank?
Lesson learned today: expressions don’t have a corank.
Does pr104131-2.f90 really need to be rejected?
Le 28/02/2022 à 19:38, Kwok Cheung Yeung a écrit :
In gfc_expression_rank, e->ref is non-NULL, so e->rank is not set from
the symtree. It then iterates through the ref elements - ref->type ==
REF_ARRAY and ref->u.ar.type == AR_ELEMENT, so e->rank remains at 0.
This is the expected
On 28/02/2022 5:37 pm, Jakub Jelinek wrote:
On Mon, Feb 28, 2022 at 06:33:15PM +0100, Mikael Morin wrote:
It is true that the spots I saw in fortran/openmp.cc that test rank look
like:
if (!gfc_resolve_expr (el->expr)
|| el->expr->ts.type != BT_INTEGER || el->expr->rank
On Mon, Feb 28, 2022 at 06:33:15PM +0100, Mikael Morin wrote:
> > It is true that the spots I saw in fortran/openmp.cc that test rank look
> > like:
> > if (!gfc_resolve_expr (el->expr)
> > || el->expr->ts.type != BT_INTEGER || el->expr->rank != 0)
> > etc., so probably
Le 28/02/2022 à 17:00, Jakub Jelinek a écrit :
On Mon, Feb 28, 2022 at 04:54:24PM +0100, Mikael Morin wrote:
Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit :
On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
(...)
Don't we usually test instead || (*expr)->rank != 0 when testing for
scalars?
On Mon, Feb 28, 2022 at 04:54:24PM +0100, Mikael Morin wrote:
> Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit :
> > On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
> (...)
> > > Don't we usually test instead || (*expr)->rank != 0 when testing for
> > > scalars?
> > >
> (...)
> >
> > So
Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit :
On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
(...)
Don't we usually test instead || (*expr)->rank != 0 when testing for
scalars?
(...)
So (*expr)->rank is 0 here even with an array. I'm not sure why - is
rank updated later, or did we
On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
On Mon, Feb 28, 2022 at 02:01:03PM +, Kwok Cheung Yeung wrote:
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 19142c4d8d0..50a1c476009 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -531,9 +531,10 @@
On Mon, Feb 28, 2022 at 02:01:03PM +, Kwok Cheung Yeung wrote:
> gcc/fortran/
>
> PR fortran/104131
> * openmp.cc (gfc_match_omp_detach): Check that the event handle is not
> an array type.
>
> gcc/testsuite/
>
> PR fortran/104131
> *
Hello
This patch addresses PR fortran/104131 on the GCC bug tracker, where an
ICE would occur if an array or co-array was passed as the event handle
in the detach clause of a task.
Since the event handle is supposed to be a scalar of type
omp_event_handle_kind, we can simply reject the
16 matches
Mail list logo
