public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* Testsuite patch for PR fortran/16511
@ 2004-07-14 13:10 Billinghurst, David (CALCRTS)
  2004-07-14 13:30 ` Steve Kargl
  0 siblings, 1 reply; 6+ messages in thread
From: Billinghurst, David (CALCRTS) @ 2004-07-14 13:10 UTC (permalink / raw)
  To: gcc-patches; +Cc: fortran

I now think the current gfortran behaviour is standard conforming.
See the PR for discussion.

OK to commit.

2004-07-14  David Billinghurst (David.Billinghurst@riotinto.com)

	PR fortran/16511
	* gfortran.dg/g77/19990905-0.f:  Add dg-error. Remove xfail
	* gfortran.dg/g77/README: Update

Index: gfortran.dg/g77/README
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gfortran.dg/g77/README,v
retrieving revision 1.1
diff -u -r1.1 README
--- gfortran.dg/g77/README      13 Jul 2004 13:27:52 -0000      1.1
+++ gfortran.dg/g77/README      14 Jul 2004 03:38:56 -0000
@@ -74,7 +74,7 @@
 19990525-0.f                   Y
 19990826-1.f                   Y
 19990826-3.f                   Y
-19990905-0.f                   Y  XFAIL PR 16511
+19990905-0.f                   Y  Correctly gives error with gfortran
 19990905-2.f                   Y
 20000412-1.f                   Y
 20000511-1.f                   Y
Index: gfortran.dg/g77/19990905-0.f
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gfortran.dg/g77/19990905-0.f,v
retrieving revision 1.1
diff -u -r1.1 19990905-0.f
--- gfortran.dg/g77/19990905-0.f        13 Jul 2004 07:08:22 -0000      1.1
+++ gfortran.dg/g77/19990905-0.f        14 Jul 2004 03:38:56 -0000
@@ -1,8 +1,11 @@
 c { dg-do compile }
 * =foo0.f in Burley's g77 test suite.
+c
+c Gives error with gfortran.  This is correct.
+c See Fortran 77 5.5.1 and Fortran 95 5.1.2.4.1 & 7.1.6.2
       subroutine sub(a)
       common /info/ iarray(1000)
       equivalence (m,iarray(100)), (n,iarray(200))
-      real a(m,n) ! { dg-bogus "Variable 'm' cannot appear" "Variable 'm' cannot appear" { xfail *-*-* } } PR 16511 
+      real a(m,n) ! { dg-error "Variable 'm' cannot appear" "Variable 'm' cannot appear" }
       a(1,1) = a(2,2)
       end

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Testsuite patch for PR fortran/16511
  2004-07-14 13:10 Testsuite patch for PR fortran/16511 Billinghurst, David (CALCRTS)
@ 2004-07-14 13:30 ` Steve Kargl
  2004-07-14 13:38   ` Steve Kargl
  0 siblings, 1 reply; 6+ messages in thread
From: Steve Kargl @ 2004-07-14 13:30 UTC (permalink / raw)
  To: Billinghurst, David (CALCRTS); +Cc: gcc-patches, fortran

On Wed, Jul 14, 2004 at 01:52:36PM +1000, Billinghurst, David (CALCRTS) wrote:
> I now think the current gfortran behaviour is standard conforming.

Are you sure?  NAG's Fortran 95 compiles this code
without issuing an error.

kargl[207] f95 -c -C=all 19990905-0.f
Obsolescent: 19990905-0.f, line 2: Fixed source form

I'll post a message to c.l.f.

-- 
Steve

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Testsuite patch for PR fortran/16511
  2004-07-14 13:30 ` Steve Kargl
@ 2004-07-14 13:38   ` Steve Kargl
  0 siblings, 0 replies; 6+ messages in thread
From: Steve Kargl @ 2004-07-14 13:38 UTC (permalink / raw)
  To: Billinghurst, David (CALCRTS); +Cc: gcc-patches, fortran

On Tue, Jul 13, 2004 at 09:24:06PM -0700, Steve Kargl wrote:
> On Wed, Jul 14, 2004 at 01:52:36PM +1000, Billinghurst, David (CALCRTS) wrote:
> > I now think the current gfortran behaviour is standard conforming.
> 
> Are you sure?  NAG's Fortran 95 compiles this code
> without issuing an error.
> 
> kargl[207] f95 -c -C=all 19990905-0.f
> Obsolescent: 19990905-0.f, line 2: Fixed source form
> 
> I'll post a message to c.l.f.
> 

I just check the code with Lahey's on-line diaginostic tool.
The code appears to be conforming.

Lahey/Fujitsu Fortran 95 Source Check Output

Compiling program unit sub at line 1:
  3909-W: "SOURCE.F90", line 1: Fixed form source is an obsolescent feature.
Encountered 0 errors, 1 warning, 0 informations in file SOURCE.F90.
Compiling file SOURCE.F90.
Lahey/Fujitsu Fortran 95 Listing and Cross Reference


Source file       : SOURCE.F90

 External subroutine subprogram "sub"
  (line-no.)(nest)
          1        * =foo0.f in Burley's g77 test suite.
          2              subroutine sub(a)
          3              common /info/ iarray(1000)
          4              equivalence (m,iarray(100)), (n,iarray(200))
          5              real a(m,n)
          6              a(1,1) = a(2,2)
          7              end

 Diagnostic messages: program name(sub)
   3909-W: "SOURCE.F90", line 1: Fixed form source is an obsolescent feature.

 Procedure information
   Lines      : 7
   Statements : 6

 Scoping unit of external sub-program : sub
   Attribute and Cross reference of name
     a
      |(Class and Type) : variable name, REAL(4)
      |(Attributes)     : DIMENSION, dummy-argument
      |(Declaration)    : 2  5
      |(Definition)     : 6
      |(Reference)      : 6
     iarray
      |(Class and Type) : variable name, INTEGER(4)-implicit
      |(Attributes)     : DIMENSION, common-block-object, storage-associated
      |(Declaration)    : 3  4  4
      |(Definition)     : 
      |(Reference)      : 
     info
      |(Class and Type) : common name
      |(Attributes)     : 
      |(Declaration)    : 3
      |(Definition)     : 
      |(Reference)      : 
     m
      |(Class and Type) : variable name, INTEGER(4)-implicit
      |(Attributes)     : storage-associated
      |(Declaration)    : 4
      |(Definition)     : 
      |(Reference)      : 
     n
      |(Class and Type) : variable name, INTEGER(4)-implicit
      |(Attributes)     : storage-associated
      |(Declaration)    : 4
      |(Definition)     : 
      |(Reference)      : 
     sub
      |(Class and Type) : external subroutine name
      |(Attributes)     : 
      |(Declaration)    : 
      |(Definition)     : 2
      |(Reference)      : 

 Total information
   Procedures       : 1
   Total lines      : 7
   Total statements : 6
-- 
Steve

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: Testsuite patch for PR fortran/16511
@ 2004-07-16  8:23 Billinghurst, David (CALCRTS)
  0 siblings, 0 replies; 6+ messages in thread
From: Billinghurst, David (CALCRTS) @ 2004-07-16  8:23 UTC (permalink / raw)
  To: gcc-patches; +Cc: fortran

David Billinghurst wrote:
> I now think the current gfortran behaviour is standard conforming.
> See the PR for discussion.
> 
> OK to commit.
> 
> 2004-07-14  David Billinghurst (David.Billinghurst@riotinto.com)
> 
> 	PR fortran/16511
> 	* gfortran.dg/g77/19990905-0.f:  Add dg-error. Remove xfail
> 	* gfortran.dg/g77/README: Update
> 

After following the discussion on c.l.f (thanks Steve) I withdraw this 
patch, as the code in question "clearly" (?) conforms to F90 standard.

Richard Maine wrote:
Date: 14 Jul 2004 08:16:06 -0700

Klaus Wacker <wacker@physik.uni-dortmund.de> writes: 

> I think it could have already been legal in Fortran 77. As the array 
> is passed in as an argument, no dynamic memory allocation is 
> necessary. However, the standard says: 
> 
> | A variable name that appears in a dimension bound expression of an 
> | array must also appear as a name either in every dummy argument list 
> | that contains the array name or in a common block in that subprogram. 
> 
> The phrase "as a name" seems to exclude the association to a common 
> via equivalence. 

I find that phrase a little strange in general. After all, a name 
isn't in a common block. A name is in a common statement, but not 
a common block. I'd be tempted to interpret that as the variable 
being in the common block. But I guess I don't find it definitive. 

The f90 standard is a little more clear here. The corresponding 
requirement for a specification expression is 

  "A variable that is in a common block or a variable that is the subobject 
   of a variable in a common block." 

No funniness about names being in common blocks. I'd say that the 
equivalenced variable is probably alsso "in" the common block, 
though the precise definition of common blocks is tricky indeed 
(I'm occasionally amazed at the people who mention how simple 
common is - I think they mostly don't understand its real definition, 
but only how simple it can be if you restrict yourself to simple 
use of it...which isn't a bad idea). Hmm... Ah. I'm slighly surprised, 
but I do manage to find the words to cover this pretty much in exactly 
the form needed. F90 5.5.2.1(2) 

  "Data objects associated with an entity in a common block are considered 
   to be in that common block." 

So I think I'll go with "clearly" legal in f90, but subject to debate 
in f77. Since you aren't going to get a formal f77 interp any more, 
that's probably how it will have to stand

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Testsuite patch for PR fortran/16511
  2004-07-14 17:21 Billinghurst, David (CALCRTS)
@ 2004-07-14 18:57 ` Steve Kargl
  0 siblings, 0 replies; 6+ messages in thread
From: Steve Kargl @ 2004-07-14 18:57 UTC (permalink / raw)
  To: Billinghurst, David (CALCRTS); +Cc: gcc-patches, fortran

On Wed, Jul 14, 2004 at 05:25:08PM +1000, Billinghurst, David (CALCRTS) wrote:
> From: Steve Kargl
> >
> > On Wed, Jul 14, 2004 at 01:52:36PM +1000, Billinghurst, David 
> > (CALCRTS) wrote:
> > > I now think the current gfortran behaviour is standard conforming.
> > 
> > Are you sure?  NAG's Fortran 95 compiles this code
> > without issuing an error.
> > 
> > kargl[207] f95 -c -C=all 19990905-0.f
> > Obsolescent: 19990905-0.f, line 2: Fixed source form
> > 
> > I'll post a message to c.l.f.
> 
> I am not sure.  It is a nasty little corner case.
> The Fortran 77 standard seems clear, but ...
> 

I started a c.l.f thread.  From the responses that I have received
so far, the code appears to be conforming to F90 and beyond.  But,
the heavy weight experts have not respondent, yet.

-- 
Steve

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: Testsuite patch for PR fortran/16511
@ 2004-07-14 17:21 Billinghurst, David (CALCRTS)
  2004-07-14 18:57 ` Steve Kargl
  0 siblings, 1 reply; 6+ messages in thread
From: Billinghurst, David (CALCRTS) @ 2004-07-14 17:21 UTC (permalink / raw)
  To: Steve Kargl; +Cc: gcc-patches, fortran

From: Steve Kargl
>
> On Wed, Jul 14, 2004 at 01:52:36PM +1000, Billinghurst, David 
> (CALCRTS) wrote:
> > I now think the current gfortran behaviour is standard conforming.
> 
> Are you sure?  NAG's Fortran 95 compiles this code
> without issuing an error.
> 
> kargl[207] f95 -c -C=all 19990905-0.f
> Obsolescent: 19990905-0.f, line 2: Fixed source form
> 
> I'll post a message to c.l.f.

I am not sure.  It is a nasty little corner case.
The Fortran 77 standard seems clear, but ...


   

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2004-07-15 22:55 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-07-14 13:10 Testsuite patch for PR fortran/16511 Billinghurst, David (CALCRTS)
2004-07-14 13:30 ` Steve Kargl
2004-07-14 13:38   ` Steve Kargl
2004-07-14 17:21 Billinghurst, David (CALCRTS)
2004-07-14 18:57 ` Steve Kargl
2004-07-16  8:23 Billinghurst, David (CALCRTS)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).