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 event
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
> * gfortran.dg/gomp/pr104131.f
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 @@ gfc_match_o
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 forget
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 (*expr)->ra
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 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 !gfc_r
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 !
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 behavior.
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 16/02/2022 à 22:20, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
while we detect invalid uses of type(*), we may run into other issues
later when the declared variable is used, leading to an ICE due to a
NULL pointer dereference. This is demonstrated by Gerhard's testcase.
Steve an
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 de
Le 28/02/2022 à 22:32, Mikael Morin a écrit :
So please use a condition on expr->ts.type instead.
I said «instead», but «as well» is more appropriate; both expr.ts.type
and expr.ts.u.derived conditions are probably necessary.
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 that
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
least
15 matches
Mail list logo
