This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Patch, Fortran] Check arguments of elemental intrinsic subroutines for conformance


Hi,

while working on PR 35681, I looked at the accepts-invalid mentioned by FX in comment #1. In short, the arguments for a call to MVBITS were not checked for conformance, and thus a call with differently shaped arguments for IN and OUT was accepted.

The problem here is that check_elemental_actual in resolve.c did for subroutine calls not look at c->resolved_sym and thus missed this call was actually to an elemental procedure, as the elemental-flag is only set on resolved_sym during resolution and not on the original symtree. This patch fixes it.

For elemental functions, it seems that the conformance check is (also) done in check.c and nothing has to be done here for them (it already works); it would probably be nicer to do the check for them also only in one place and not a second time (?) in check_elemental_actual, but I think it's also quite fine as it is now. This patch is regression-testing at the moment, but I don't expect any (did one already and fixed the few failures by a simple modification).

Is it ok if no regressions occur? What do you think, should I commit now and work then on the "real" part of PR 35681 or should I try to do both in a single larger patch? I'm fine with both options, although I don't expect that there's a significant "dependance" of both problems, so seperate patches seem totally fine.

Cheers,
Daniel

--
Done:  Arc-Bar-Cav-Rog-Sam-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran-Tou
2008-10-16  Daniel Kraft  <d@domob.eu>

	* resolve.c (resolve_elemental_actual): Handle calls to intrinsic
	subroutines correctly.

2008-10-16  Daniel Kraft  <d@domob.eu>

	* gfortran.dg/elemental_intrinsic_1.f03: New test.
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(revision 141111)
+++ gcc/fortran/resolve.c	(working copy)
@@ -1352,10 +1352,18 @@ resolve_elemental_actual (gfc_expr *expr
       else
 	return SUCCESS;
     }
-  else if (c && c->ext.actual != NULL && c->symtree->n.sym->attr.elemental)
+  else if (c && c->ext.actual != NULL)
     {
       arg0 = c->ext.actual;
-      esym = c->symtree->n.sym;
+      
+      if (c->resolved_sym)
+	esym = c->resolved_sym;
+      else
+	esym = c->symtree->n.sym;
+      gcc_assert (esym);
+
+      if (!esym->attr.elemental)
+	return SUCCESS;
     }
   else
     return SUCCESS;
Index: gcc/testsuite/gfortran.dg/elemental_intrinsic_1.f03
===================================================================
--- gcc/testsuite/gfortran.dg/elemental_intrinsic_1.f03	(revision 0)
+++ gcc/testsuite/gfortran.dg/elemental_intrinsic_1.f03	(revision 0)
@@ -0,0 +1,11 @@
+! { dg-do compile }
+
+! Conformance-checking of arguments was not done for intrinsic elemental
+! subroutines, check this works now.
+
+! This is the test from PR fortran/35681, comment #1 (second program).
+
+  integer, dimension(10) :: ILA1 = (/1,2,3,4,5,6,7,8,9,10/)
+  call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3) ! { dg-error "Different shape" }
+  write (*,'(10(I3))') ila1
+  end 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]