Re: [4.8, Fortran, Patch] PR 48820 - Support TYPE(*) of TS29113

2014-12-02 Thread Tom de Vries
On 03/03/12 08:41, Paul Richard Thomas wrote:
 Dear Tobias,
 
 This is certainly OK for 4.8.
 
 I have a couple of remarks:
 (i) The DTYPE_TYPE_MASK is 0x38 so that we saturated it a long time
 since!  At the moment it does not cause any problems because of the
 extremely limited use of the dtype 'type'.

Hi,

AFAIU, you're saying here that since there are very few uses of the type part of
dtype, it's not a problem.

But at the moment, BT_ASSUMED with value 11 bleeds into the size part of dtype.

In gfc_get_dtype_rank_type, we just set the type directly without applying the 
mask:
...
  i = rank | (n  GFC_DTYPE_TYPE_SHIFT);
...

In fact, the mask seems completely unused.

  Whilst the array
 descriptor revamp will eliminate such worries, we should be mindful of
 this; and

I think that if we have a mask that we're not respecting, we need to clearly
document at the definiton how that's done and why that's not a problem. And
ideally, add some asserts to detect when we break that allowed usage pattern.

Thanks,
- Tom


Re: [4.8, Fortran, Patch] PR 48820 - Support TYPE(*) of TS29113

2012-03-03 Thread Tobias Burnus

Dear Paul,

thanks for the review.

Paul Richard Thomas wrote:

I have a couple of remarks:
(i) The DTYPE_TYPE_MASK is 0x38 so that we saturated it a long time
since!  At the moment it does not cause any problems because of the
extremely limited use of the dtype 'type'.  Whilst the array
descriptor revamp will eliminate such worries, we should be mindful of
this; and


Thanks for the reminder. I kind of expected such an issue - and decided 
not to worry about it.



(ii) By making such substantial use of scan-tree-dump-times in the
dg-run test case, you are potentially building in instability against
future development, I suppose?  Are the runtime tests not sufficient?


In principle, run-time tests are sufficient. But they rely on C tests - 
or at least on a working C_LOC. However, one currently cannot use 
C_LOC() on assumed-shape variables nor BIND(C) for assumed-shape 
dummies. [Which is allowed in TS29113.]  Besides, the C program needs 
then to make use of gfortran's array descriptor to really check.


I tried a bit, but it gets rather complicated so that at some point, I 
gave up, deleted the traces of the C code and surrendered. I checked the 
argument manually and added them to the scan-tree-dump-times. I tried 
carefully to use them such that they should work on all targets. 
However, if the array descriptor will change, they might break. However, 
the work to fix them once or twice might be less than writing a run-time 
test.


Tobias


Re: [4.8, Fortran, Patch] PR 48820 - Support TYPE(*) of TS29113

2012-03-03 Thread Tobias Burnus

Tobias Burnus wrote:

thanks for the review.

Paul Richard Thomas wrote:
[...]


Something is odd. The test case didn't regtest, but I could swear that 
it did so yesterday.


_1.f90: That was correctly failing because one cannot pass an 
assumed-size array to an assumed-shape array.


_4.f90: Somehow, the line has changed.

_3.f90: Besides some more obvious issues, there is:

fourteen is really odd: Depending on the position of that subroutine 
in file, I get an error or not. I think one should try to better 
understand why that happens.


Tobias
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 184855)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,6 +1,13 @@
 2012-03-03  Tobias Burnus  bur...@net-b.de
 
 	PR fortran/48820
+	* gfortran.dg/assumed_type_1.f90: Correct dg-error.
+	* gfortran.dg/assumed_type_3.f90: Correct dg-error.
+	* gfortran.dg/assumed_type_4.f90: Correct dg-error.
+
+2012-03-03  Tobias Burnus  bur...@net-b.de
+
+	PR fortran/48820
 	* gfortran.dg/assumed_type_1.f90: New.
 	* gfortran.dg/assumed_type_2.f90: New.
 	* gfortran.dg/assumed_type_3.f90: New.
Index: gcc/testsuite/gfortran.dg/assumed_type_1.f90
===
--- gcc/testsuite/gfortran.dg/assumed_type_1.f90	(Revision 184855)
+++ gcc/testsuite/gfortran.dg/assumed_type_1.f90	(Arbeitskopie)
@@ -49,7 +49,6 @@ use mpi_interface
 contains
 subroutine foo(x)
 type(*):: x(*)
-call MPI_Send(x, 1, 1,1,1,j,i)
 call MPI_Send2(x, 1, 1,1,1,j,i)
   end
 end
Index: gcc/testsuite/gfortran.dg/assumed_type_4.f90
===
--- gcc/testsuite/gfortran.dg/assumed_type_4.f90	(Revision 184855)
+++ gcc/testsuite/gfortran.dg/assumed_type_4.f90	(Arbeitskopie)
@@ -5,6 +5,6 @@
 !
 ! Test TYPE(*)
 
-subroutine one(a) ! { dg-error TS 29113: Assumed type }
-  type(*)  :: a
+subroutine one(a)
+  type(*)  :: a ! { dg-error TS 29113: Assumed type }
 end subroutine one
Index: gcc/testsuite/gfortran.dg/assumed_type_3.f90
===
--- gcc/testsuite/gfortran.dg/assumed_type_3.f90	(Revision 184855)
+++ gcc/testsuite/gfortran.dg/assumed_type_3.f90	(Arbeitskopie)
@@ -5,6 +5,11 @@
 !
 ! Test TYPE(*)
 
+subroutine fourteen(x)
+  type(*) :: x
+  x = x ! { dg-error Invalid expression with assumed-type variable }
+end subroutine fourteen
+
 subroutine one(a) ! { dg-error may not have the ALLOCATABLE, CODIMENSION, POINTER or VALUE attribute }
   type(*), value :: a
 end subroutine one
@@ -52,10 +57,10 @@ subroutine nine()
 subroutine okay2(x)
   type(*) :: x(*)
 end subroutine okay2
-subroutine okay2(x,y)
+subroutine okay3(x,y)
   integer :: x
   type(*) :: y
-end subroutine okay2
+end subroutine okay3
   end interface
   interface two
 subroutine okok1(x)
@@ -100,10 +105,10 @@ end subroutine eleven
 
 subroutine twelf(x)
   type(*) :: x
-  call bar(x)
+  call bar(x) ! { dg-error Type mismatch in argument }
 contains
   subroutine bar(x)
-integer :: x ! { dg-error Type mismatch in argument }
+integer :: x
   end subroutine bar
 end subroutine twelf
 
@@ -113,7 +118,4 @@ subroutine thirteen(x, y)
   print *, ubound(y, dim=x) ! { dg-error must be INTEGER }
 end subroutine thirteen
 
-subroutine fourteen(x)
-  type(*) :: x
-  x = x ! { dg-error Invalid expression with assumed-type variable }
-end subroutine fourteen
+


Re: [4.8, Fortran, Patch] PR 48820 - Support TYPE(*) of TS29113

2012-03-03 Thread Tobias Burnus

Tobias Burnus wrote:

_3.f90: [...]
fourteen is really odd: Depending on the position of that subroutine 
in file, I get an error or not. I think one should try to better 
understand why that happens.


I found it with the help of Paul. The problem was that I set instead of 
re-set the variable at the end of resolve_actual_arglist. Now, it works.


Committed the attached patch as Rev. 184863 after a fresh rebuild and 
regtesting.


Tobias

PS: Sorry for the glitches.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(Revision 184861)
+++ gcc/fortran/resolve.c	(Arbeitskopie)
@@ -1833,7 +1833,7 @@ resolve_actual_arglist (gfc_actual_arglist *arg, p
   return FAILURE;
 }
 }
-  assumed_type_expr_allowed = true;
+  assumed_type_expr_allowed = false;
 
   return SUCCESS;
 }
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 184861)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,11 @@
 2012-03-03  Tobias Burnus  bur...@net-b.de
 
+	PR fortran/48820
+	* resolve.c (resolve_actual_arglist): Properly reset
+	assumed_type_expr_allowed.
+
+2012-03-03  Tobias Burnus  bur...@net-b.de
+
 	* lang.opt (Wc-binding-type): New flag.
 	* options.c (gfc_init_options, gfc_handle_option): Handle it.
 	* invoke.texi (Wc-binding-type): Document it.
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 184861)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,10 @@
 2012-03-03  Tobias Burnus  bur...@net-b.de
 
+	PR fortran/48820
+	* gfortran.dg/assumed_type_3.f90: Undo previous commit.
+
+2012-03-03  Tobias Burnus  bur...@net-b.de
+
 	* gfortran.dg/bind_c_dts_4.f03: Add dg-options -Wc-binding-type.
 	* gfortran.dg/bind_c_implicit_vars.f03: Ditto.
 	* gfortran.dg/bind_c_usage_8.f03: Ditto.
Index: gcc/testsuite/gfortran.dg/assumed_type_3.f90
===
--- gcc/testsuite/gfortran.dg/assumed_type_3.f90	(Revision 184861)
+++ gcc/testsuite/gfortran.dg/assumed_type_3.f90	(Arbeitskopie)
@@ -5,11 +5,6 @@
 !
 ! Test TYPE(*)
 
-subroutine fourteen(x)
-  type(*) :: x
-  x = x ! { dg-error Invalid expression with assumed-type variable }
-end subroutine fourteen
-
 subroutine one(a) ! { dg-error may not have the ALLOCATABLE, CODIMENSION, POINTER or VALUE attribute }
   type(*), value :: a
 end subroutine one
@@ -118,4 +113,7 @@ subroutine thirteen(x, y)
   print *, ubound(y, dim=x) ! { dg-error must be INTEGER }
 end subroutine thirteen
 
-
+subroutine fourteen(x)
+  type(*) :: x
+  x = x ! { dg-error Invalid expression with assumed-type variable }
+end subroutine fourteen


Re: [4.8, Fortran, Patch] PR 48820 - Support TYPE(*) of TS29113

2012-03-02 Thread Paul Richard Thomas
Dear Tobias,

This is certainly OK for 4.8.

I have a couple of remarks:
(i) The DTYPE_TYPE_MASK is 0x38 so that we saturated it a long time
since!  At the moment it does not cause any problems because of the
extremely limited use of the dtype 'type'.  Whilst the array
descriptor revamp will eliminate such worries, we should be mindful of
this; and
(ii) By making such substantial use of scan-tree-dump-times in the
dg-run test case, you are potentially building in instability against
future development, I suppose?  Are the runtime tests not sufficient?

Thanks for this early upgrade!

Paul

On Fri, Mar 2, 2012 at 12:28 PM, Tobias Burnus bur...@net-b.de wrote:
 TYPE(*) is Fortran's equivalent to C's void *buffer. It may only be used
 for dummy arguments and essentially might only either be passed on, or
 appear in PRESENT, LBOUND/UBOUND/SHAPE/SIZE/IS_CONTIGUOUS - and most useful:
 in C_LOC.


 Note: For scalar TYPE(*) and for assumed-size dummies, only the address is
 passed on. But for dimension(:) and TS29113's new (but unimplemented)
 dimension(..) an array descriptor is passed. In that case, one might recover
 the type from the array descriptor - at least for intrinsic types.


 TYPE(*) is useful for, e.g., MPI (and used in the MPI v3 draft spec): There,
 one simply takes an argument of any type and transfers some bytes from it -
 without needing to know the type. TYPE(*) avoids to create hundreds of
 useless explicit interfaces for all kind of data types (and missing derived
 types that way) - or TS29113 avoids the alternative: Not using explicit
 interfaces (causing argument checking issues and prevents the use of
 BIND(C).)


 See PR (or first test case) for a usage example. For a pure Fortran use, one
 could imagine:

 subroutine send(buf, size)
  use iso_c_binding, only: c_signed_char, c_size_t
  type(*) :: buf(*)
  integer(c_size_t) :: size
  integer(c_signed_char) :: ibuf(size)
  call c_f_pointer (c_loc(buf), ibuf, shape=[size])
  ! ... use ibuf ...
 end

 [This example currently fails as c_loc(buf) is rejected. Several BIND(C)
 restrictions were removed in F2008 and especially in TS29113, but gfortran
 has not yet removed them.]


 For more details, see:

 * TS 29113 draft: ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1904.pdf
 (Status: Went as PDTR through one round of voting by the ISO members, was
 updated at the last J3 meeting and is now the subject of a one-month WG5
 ballot that ends on 19 March 2012. The schedule is that it will then be
 forwarded to SC22, which initiates a DTS ballot such that the final version
 will be published in September by ISO.)

 * MPIv3 draft (of 2011-12-15):
 https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-report-F2008-2011-12-15-changeonlyplustickets_majorpages.pdf

 Build and regtested on x86-64-linux.
 OK for the 4.8 trunk?

 Tobias



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy