This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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] PR28201 and PR20844 - two more one liners.


:ADDPATCH fortran:

The enclosed consists of two patches, which I admit have nothing to do with one another, other than that they are tiny and very simple:

PR28201: Here resolve_generic_s would go charging off to try to find a generic interface in the parent namespace, if it existed. This is fine normally but, in the case of a use associated symbol, the parent namespace exists but there is no guarantee that an appropriately named symbol will be found there! In the case of the testcase, this is not so and the ICE ensues. The patch simply prevents the search in the parent namespace, if the initial symbol is use asscoaited.

PR20844: This has had my name next to it in Bugzilla for an embarrassing amount of time. The standard(9.4.1) constrains ADVANCE specifiers to appear with an explicit FORMAT specification. The condition includes dt->namelist == NULL to prevent the corresponding NAMELIST error from being overwritten. The error is tested by an additional line in io_constraints_2.f90

Regtested on FC5/Athlon1700.

OK for trunk and 4.1?

Paul

2006-07-08 Paul Thomas <pault@gcc.gnu.org>

   PR fortran/20844
   * io.c (check_io_constraints): It is an error if an ADVANCE
   specifier appears without an explicit format.

   PR fortran/28201
   * resolve.c (resolve_generic_s): For a use_associated function,
   do not search for an alternative symbol in the parent name
   space.

2006-07-08 Paul Thomas <pault@gcc.gnu.org>

   PR fortran/20844
   * gfortran.dg/io_constaints_2.f90: Add the test for ADVANCE
   specifiers requiring an explicit format tag..

   PR fortran/28201
   * gfortran.dg/generic_5: New test.


Index: gcc/fortran/io.c
===================================================================
*** gcc/fortran/io.c	(revision 115246)
--- gcc/fortran/io.c	(working copy)
*************** if (condition) \
*** 2340,2345 ****
--- 2340,2351 ----
  		     "List directed format(*) is not allowed with a "
  		     "ADVANCE=specifier at %L.", &expr->where);
  
+       io_constraint (dt->format_expr == NULL
+ 		       && dt->format_label == NULL
+ 		       && dt->namelist == NULL,
+ 		     "the ADVANCE=specifier at %L must appear with an "
+ 		     "explicit format expression", &expr->where);
+ 
        if (expr->expr_type == EXPR_CONSTANT && expr->ts.type == BT_CHARACTER)
  	{
  	  const char * advance = expr->value.character.string;
Index: gcc/fortran/resolve.c
===================================================================
*** gcc/fortran/resolve.c	(revision 115245)
--- gcc/fortran/resolve.c	(working copy)
*************** resolve_generic_s (gfc_code * c)
*** 1500,1506 ****
    if (m == MATCH_ERROR)
      return FAILURE;
  
!   if (sym->ns->parent != NULL)
      {
        gfc_find_symbol (sym->name, sym->ns->parent, 1, &sym);
        if (sym != NULL)
--- 1500,1506 ----
    if (m == MATCH_ERROR)
      return FAILURE;
  
!   if (sym->ns->parent != NULL && !sym->attr.use_assoc)
      {
        gfc_find_symbol (sym->name, sym->ns->parent, 1, &sym);
        if (sym != NULL)
Index: gcc/testsuite/gfortran.dg/io_constraints_2.f90
===================================================================
*** gcc/testsuite/gfortran.dg/io_constraints_2.f90	(revision 115245)
--- gcc/testsuite/gfortran.dg/io_constraints_2.f90	(working copy)
***************
*** 1,6 ****
--- 1,7 ----
  ! { dg-do compile }
  ! Part II of the test  of the IO constraints patch, which fixes PRs:
  ! PRs 25053, 25063, 25064, 25066, 25067, 25068, 25069, 25307 and 20862.
+ ! Modified2006-07-08 to check the patch for PR20844.
  !
  ! Contributed by Paul Thomas  <pault@gcc.gnu.org>
  !
*************** end module global
*** 52,57 ****
--- 53,60 ----
   READ(buffer, fmt='(i6)', advance='YES') a      ! { dg-error "internal file" }
   READ(1, NML=NL, advance='YES')                 ! { dg-error "NAMELIST IO is not allowed" }
  
+  READ(1, advance='YES')                         ! { dg-error "must appear with an explicit format" }
+ 
   write(1, fmt='(i6)', advance='YES', size = c(1)) a ! { dg-error "output" }
   write(1, fmt='(i6)', advance='YES', eor = 100) a   ! { dg-error "output" }
  
Index: gcc/testsuite/gfortran.dg/generic_5.f90
===================================================================
*** gcc/testsuite/gfortran.dg/generic_5.f90	(revision 0)
--- gcc/testsuite/gfortran.dg/generic_5.f90	(revision 0)
***************
*** 0 ****
--- 1,29 ----
+ ! { dg-do compile }
+ ! Tests the patch for PR28201, in which the call to ice would cause an ICE
+ ! because resolve.c(resolve_generic_s) would try to look in the parent
+ ! namespace to see if the subroutine was part of a legal generic interface.
+ ! In this case, there is nothing to test, hence the ICE.
+ !
+ ! Contributed by Daniel Franke  <franke.daniel@gmail.com>
+ !
+ !
+ MODULE ice_gfortran
+   INTERFACE ice
+     MODULE PROCEDURE ice_i
+   END INTERFACE
+ 
+ CONTAINS
+   SUBROUTINE ice_i(i)
+     INTEGER, INTENT(IN) :: i
+     ! do nothing
+   END SUBROUTINE
+ END MODULE
+ 
+ MODULE provoke_ice
+ CONTAINS
+   SUBROUTINE provoke
+     USE ice_gfortran
+     CALL ice(23.0)   ! { dg-error "is not an intrinsic subroutine" }
+   END SUBROUTINE
+ END MODULE
+ 
2006-07-08  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/20844
	* io.c (check_io_constraints): It is an error if an ADVANCE
	specifier appears without an explicit format.

	PR fortran/28201
	* resolve.c (resolve_generic_s): For a use_associated function,
	do not search for an alternative symbol in the parent name
	space.

2006-07-08  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/20844
	* gfortran.dg/io_constaints_2.f90: Add the test for ADVANCE
	specifiers requiring an explicit format tag..

	PR fortran/28201
	* gfortran.dg/generic_5: New test.


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