[Bug 106731] ICE on automatic array of derived type with DTIO: need help

[Federico Perini via Fortran]

Hello,

I’m stil trying to fix this
 ICE bug for an
automatic array of a derived type with DTIO:

   63 | type(t) :: automatic(n)

  |   1

internal compiler error: in gfc_trans_auto_array_allocation, at
fortran/trans-array.cc:6617


Still digging for the first time in the gfortran code, I need help to move
further.

So far I’ve found:



   1. ICE is triggered in trans-array line 6617 by  gcc_assert
   (!TREE_STATIC (decl)); Makes sense, an automatic array is not SAVEd.
   2. Elsewhere, in trans-decl.cc, I found this chunk and commented it out.
   This fixed the ICE issue, but crashes some test cases i.e. dtio_4.f90 and
   dtio_14.f90, when built with full optimization (-O3)


  /* If derived-type variables with DTIO procedures are not made static
 some bits of code referencing them get optimized away.
 TODO Understand why this is so and fix it.  */
//  if (!sym->attr.use_assoc
//  && ((sym->ts.type == BT_DERIVED
//   && sym->ts.u.derived->attr.has_dtio_procs)
//|| (sym->ts.type == BT_CLASS
//&& CLASS_DATA (sym)->ts.u.derived->attr.has_dtio_procs)))
//TREE_STATIC (decl) = 1;3.

3. Of the optimization flags "-fpeel-loops" is the one that triggers the
failing tests

3. in dtio_4.f90, the first test fails for 1) non-extended class; 2)
derived-type READ. Write works; extended type (BT_CLASS) works. It appears
that the optimizer thinks the derived type is not modified by the read
statement.

4. If i replace the READ statement with a direct call to the udt routine
(`call user_defined_read`) the test succeeds, so I've looked how the tree
dumps compare:

federico@Federicos-MacBook-Pro dtio % diff callsub withdtio

498c498,500

<   CALL user_defined_read ((test1:udt1) (10) ('dt') ((/ 1 /)) (iostat =
test1:ios) (iomsg = test1:iomsg))

---

>   READ UNIT=10 FMT='(dt)' IOMSG=test1:iomsg IOSTAT=test1:ios ADVANCE='no'

>   TRANSFER test1:udt1

>   DT_END

federico@Federicos-MacBook-Pro dtio %

while -fdump-tree-original returns exactly identical dumps:

federico@Federicos-MacBook-Pro dtio % diff callsub withdtio

federico@Federicos-MacBook-Pro dtio %

Now I'm a bit stuck because I have no experience in gfortran coding, more
so with the gcc optimizer.
I hope some of you can help! But at least, I'm starting to understand how
the code structure works.

Best,
Federico


dtio_4.f90
Description: Binary data

Re: [PATCH v5 3/4] OpenMP: Pointers and member mappings

[Julian Brown]

On Wed, 7 Dec 2022 17:31:20 +0100
Tobias Burnus  wrote:

> Hi Julian,
> 
> I think this patch is OK; however, at least for gimplify.cc Jakub
> needs to have a second look.

Thanks for the review!  Here's a new version that hopefully addresses
your comments.  (The gimplify bits change a bit more in this version!)

> As remarked for the 2/4 patch, I believe mapping 'map(tofrom:
> var%f(2:3))' should work without explicitly mapping 'map(tofrom:
> var%f)' (→ [TR11 157:21-26] (approx. [5.2 154:22-27], [5.1
> 352:17-22], [5.0 320:22-27]). →
> https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608100.html
> (+ previously in the thread).
> 
> Testing the patch, that seems to work fine (i.e. contrary to C/C++,
> cf. 2/4), which matches the dump and, if I understood correctly, also
> your (Julian's) expectation. Thus, no need to modify the code part.

That change is undone.

> Regarding the testcases:
> * I would prefer if you don't modify the existing
> libgomp.fortran/struct-elem-map-1.f90 testcase; However, you could
> add your version as another variant ('subroutine nine()',
> 'four_var()' or what's the next free name, possibly with a comment
> telling that it is 'four()' but with an added explicit basepointer
> mapping.).

I've added new functions "nine" through "twelve" with the added base
pointer.

> * As the new version should map *less*, I wonder whether some
> -fdump-tree-{original,gimple,omplower} scan-dump-tree checks would be
> useful besides testing whether it works at run time. (Your decision
> regarding which tree, which testcases and whether at all.)

A couple added...

> * Likewise, maybe a 'target enter/exit data' check? However, you
> might very well run into my 'omp target data exit' issue, cf.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604887.html
> (needs to be revised based on Jakub's comments; I think those were on
> IRC only – the problem is that not only 'alloc' is affected but also
> 'from' etc.)

Hmm -- this wasn't quite as straightforward as it probably should have
been!  This version of the patch fixes a couple of bugs with "enter
data" and "exit data" directives I found when adding a new test
(map-subarray-8.f90).

(I'm not sure if this patch fixes all the problems you saw previously
with "alloc", etc. for enter/exit data -- there might still be work to
do there.)

Re-tested with offloading to NVPTX.  Does this look OK now?

Thanks,

Julian
commit 377dba3ca7dc6fdf86bdb82936e80100ef2dbf4f
Author: Julian Brown 
Date:   Mon Oct 17 16:44:31 2022 +

OpenMP: Pointers and member mappings

This patch changes the mapping node arrangement used for array components
of derived types, e.g.:

  type T
  integer, pointer, dimension(:) :: arrptr
  end type T

  type(T) :: tvar
  [...]
  !$omp target map(tofrom: tvar%arrptr)

This will currently be mapped using three mapping nodes:

  GOMP_MAP_TO tvar%arrptr   (the descriptor)
  GOMP_MAP_TOFROM *tvar%arrptr%data (the actual array data)
  GOMP_MAP_ALWAYS_POINTER tvar%arrptr%data  (a pointer to the array data)

This follows OMP 5.0, 2.19.7.1 (or OpenMP 5.2, 5.8.3) "map Clause":

  "If a list item in a map clause is an associated pointer and the
   pointer is not the base pointer of another list item in a map clause
   on the same construct, then it is treated as if its pointer target
   is implicitly mapped in the same clause. For the purposes of the map
   clause, the mapped pointer target is treated as if its base pointer
   is the associated pointer."

However, we can also write this:

  map(to: tvar%arrptr) map(tofrom: tvar%arrptr(3:8))

and then instead we should follow (OpenMP 5.2, 5.8.3 "map Clause"):

  "For map clauses on map-entering constructs, if any list item has a base
   pointer for which a corresponding pointer exists in the data environment
   upon entry to the region and either a new list item or the corresponding
   pointer is created in the device data environment on entry to the region,
   then:
   1. [Fortran] The corresponding pointer variable is associated with
  a pointer target that has the same rank and bounds as the pointer
  target of the original pointer, such that the corresponding list item
  can be accessed through the pointer in a target region.
   2. The corresponding pointer variable becomes an attached pointer
  for the corresponding list item."

With this patch you can write the above mappings, and the mapping nodes
used to map pointers to array sections (with descriptors) now look
like this:

  1) map(to: tvar%arrptr)   -->
  GOMP_MAP_TO [implicit]  *tvar%arrptr%data  (the array data)
  GOMP_MAP_TO_PSETtvar%arrptr(the descriptor)
  GOMP_MAP_ATTACH_DETACH  tvar%arrptr%data

  2) map(tofrom: tvar%arrptr(3:8)   -->

Re: [PATCH v5 3/4] OpenMP: Pointers and member mappings

[Julian Brown]

On Thu, 15 Dec 2022 14:54:58 +
Julian Brown  wrote:

> On Wed, 7 Dec 2022 17:31:20 +0100
> Tobias Burnus  wrote:
> 
> > Hi Julian,
> > 
> > I think this patch is OK; however, at least for gimplify.cc Jakub
> > needs to have a second look.  
> 
> Thanks for the review!  Here's a new version that hopefully addresses
> your comments.  (The gimplify bits change a bit more in this version!)

FYI, this is the current dependency list for this patch:

(1) "OpenMP/OpenACC: Reindent TO/FROM/_CACHE_ stanza in
{c_}finish_omp_clause"
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603791.html
Approved.

(2) "OpenMP/OpenACC: Rework clause expansion and nested struct handling"
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603792.html
Approved, but waiting for *this* patch to avoid regressing Fortran
pointer-mapping behaviour, and which Tobias noticed an issue with prior
to committing, addressed by (4).

(3) "OpenMP/OpenACC: Refine condition for when map clause expansion
happens"
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607543.html
Not reviewed (partly OpenACC).

(4) "OpenMP: implicitly map base pointer for array-section pointer
components"
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608318.html
Not reviewed.

The following patches also depend on this one and the above:

(5) "OpenMP: lvalue parsing for map clauses (C++)"
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605367.html
Mostly approved.

(6) "OpenMP: C++ "declare mapper" support"
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607544.html
Revised version unreviewed.

...and the to-be-revised "lvalue parsing for C", and C/Fortran "declare
mapper" patches.

HTH,

Julian

testsuite under wine

[NightStrike via Fortran]

When I run the testsuite under wine, I'm getting a lot of ANSI escape
sequences.  We had fixed this long ago, but it seems to be back.  Any
idea what I should change in my configuration to have this not happen?
 This is for build=host=x86_64-pc-linux-gnu and
target=x86_64-w64-mingw32, with the testsuite running under wine64
v7.20.  Example output, where you can see the output in between the
escape sequences is correct:

FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -Os  output pattern test
Output was:
^[[?25lC^[[?25h^[[?25lF^[[?25h^[[?25lI^[[?25h^[[?25l_^[[?25h^[[?25ls^[[?25h^[[?25le^[[?25h^[[?25lt^[[?25h^[[?25lp^[[?25h^[[?25lo^[[?25h^[[?25li^[[?25h^[[?25ln^[[?25h
^[[?25lt^[[?25h^[[?25le^[[?25h^[[?25lr^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lR^[[?25h^[[?25le^[[?25h^[[?25ls^[[?25h^[[?25lu^[[?25h^[[?25ll^[[?25h^[[?25l
t^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25ls^[[?25h^[[?25lh^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25ll^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lb^[[?25h^[[?25le^[[?25h^[[?25
l^[[K^[[1C^[[?25h^[[?25lt^[[?25h^[[?25lh^[[?25h^[[?25le^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25la^[[?25h^[[?25ld^[[?25h^[[?25ld^[[?25h^[[?25lr^[[?25h^[[?25le^[[?25h^[[?2
5ls^[[?25h^[[?25ls^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lo^[[?25h^[[?25lf^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25la^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lC^[[?25h^[[?25l^[[K
^[[1C^[[?25h^[[?25ld^[[?25h^[[?25le^[[?25h^[[?25ls^[[?25h^[[?25lc^[[?25h^[[?25lr^[[?25h^[[?25li^[[?25h^[[?25lp^[[?25h^[[?25lt^[[?25h^[[?25lo^[[?25h^[[?25lr^[[?25h^[[
?25l^[[K^[[1C^[[?25h^[[?25lf^[[?25h^[[?25lo^[[?25h^[[?25lr^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25la^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lF^[[?25h^[[?25lo^[[?25h^[[?25lr^
[[?25h^[[?25lt^[[?25h^[[?25lr^[[?25h^[[?25la^[[?25h^[[?25ln^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lp^[[?25h^[[?25lo^[[?25h^[[?25li^[[?25h^[[?25ln^[[?25h^[[?25lt^[[?25h^
[[?25le^[[?25h^[[?25lr^[[?25h^[[?25l.^[[?25h^M^M

Should match:
CFI_setpointer: Result shall be the address of a C descriptor for a
Fortran pointer.

Re: testsuite under wine

[Thomas Koenig via Fortran]

On 16.12.22 03:20, NightStrike via Fortran wrote:


When I run the testsuite under wine, I'm getting a lot of ANSI escape
sequences.  We had fixed this long ago, but it seems to be back.  Any
idea what I should change in my configuration to have this not happen?


This should probably be fixed properly in some *.exp file, but you can
try setting the GCC_COLORS environment variable to an empty string
before running the test.

Regards

Thomas