[Fortran-dev] Implement TS29113 type handling

[Dominique Dhumieres]

Dear Tobias,

First, I have done a clean build of libgfortran without any glitch
(keeping my fingers crossed).

Second all the scan-* tests now pass, but for two with -m32:

gfortran.dg/assumed_rank_12.f90, fixed by the following patch

--- ../for_clean/gcc/testsuite/gfortran.dg/assumed_rank_12.f90	2013-04-25 12:46:06.000000000 +0200
+++ ../for_work/gcc/testsuite/gfortran.dg/assumed_rank_12.f90	2013-04-26 22:51:07.000000000 +0200
@@ -16,6 +16,6 @@ function f() result(res)
 end function f
 end
 
-! { dg-final { scan-tree-dump " = f \\(\\);.*desc.0.base_addr = .void .. D.\[0-9\]+;.*desc.0.elem_len = 48;.*desc.0.version = 1;.*desc.0.rank = 0;.*desc.0.type = 600;.*desc.0.attribute = 1;.*sub \\(&desc.0\\);.*D.\[0-9\]+ = .integer.kind=4. .. desc.0.base_addr;" "original" } }
+! { dg-final { scan-tree-dump " = f \\(\\);.*desc.0.base_addr = .void .. D.\[0-9\]+;.*desc.0.elem_len = (20|32);.*desc.0.version = 1;.*desc.0.rank = 0;.*desc.0.type = 1025;.*desc.0.attribute = 1;.*sub \\(&desc.0\\);.*D.\[0-9\]+ = .integer.kind=4. .. desc.0.base_addr;" "original" } }
 ! { dg-final { cleanup-tree-dump "original" } }

and

FAIL: gfortran.dg/iso-ts-29113_2.f90  -O   scan-tree-dump-times original "x_cptr.type = 2049;" 1
FAIL: gfortran.dg/iso-ts-29113_2.f90  -O   scan-tree-dump-times original "x_funcptr.type = 2049;" 1

If I grep the original dump compiled with -m64 for 2049, I get

      x_cptr.type = 2049;
      x_funcptr.type = 2049;
      x_int8.type = 2049;
      foo (&x_int8, 2049);

and when compiled with -m32 for 1025, I get

      x_cptr.type = 1025;
      x_funcptr.type = 1025;
      x_int4.type = 1025;
      foo (&x_int4, 1025);

Third, I see the failures for gfortran.dg/mvbits_7.f90, but not
for gfortran.dg/mvbits_8.f90, although valgrind complains.

Fourth, I have filled pr57090, pr57094, and pr57095 with reduced
failing tests. It seems that pr57090 may block other tests and
should be fairly easy to fix. Also pr57095 is very annoying since
gfortran.dg/alloc_comp_assign_3.f90 and realloc_on_assign_17.f90
may grab my 4Gb of RAM and are timed out depending on the
revision and 32/64 bit modes (mostly 64) leading to an increase
of the test time between 40 to 80 minutes.

Thanks for your work on this issue.

Dominique