Bug 32386 - Pure function not allowed in specification expression
Summary: Pure function not allowed in specification expression
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.1.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-18 00:41 UTC by john.harper
Modified: 2007-06-19 03:50 UTC (History)
1 user (show)

See Also:
Host: ?
Target: i386-redhat-linux
Build: ?
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description john.harper 2007-06-18 00:41:55 UTC
The following program seems to me to be valid Fortran 95, because the f95 standard 5.1.1.5 and 7.1.6.2 say a CHARACTER(n) declaration is OK if n is a scalar integer restricted expression, in which each primary is a constant,
the intrinsic LEN is allowed, and so are pure functions that are not intrinsic, not internal, not statement functions, do not have dummy procedure arguments,
and are not recursive. But gfortran won't compile it. Evidence: 

harper@RHEL5 test system: ~/Jfh/Test 52 >cat testspec.f90
MODULE halvestring ! Can halfit be in a specification expression?
CONTAINS
  PURE FUNCTION halfit(s1) RESULT (s2)
    CHARACTER(*),INTENT(IN):: s1
    CHARACTER(len(s1)/2) :: s2
    s2 = s1
  END FUNCTION halfit
END MODULE halvestring
! -----------
PROGRAM testspec
USE  halvestring
CHARACTER(*),PARAMETER :: stringa = 'abcdeedcba'
CHARACTER(len(halfit(stringa))) :: stringb

stringb = halfit(stringa)
PRINT "(I4,A)", len(stringb),' "'//stringb//'"' !   5 "abcde"
END PROGRAM testspec

harper@RHEL5 test system: ~/Jfh/Test 53 >gfortran -v testspec.f90
Driving: gfortran -v testspec.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)
 /usr/libexec/gcc/i386-redhat-linux/4.1.1/f951 testspec.f90 -quiet -dumpbase testspec.f90 -mtune=generic -auxbase testspec -version -I /usr/lib/gcc/i386-redhat-linux/4.1.1/finclude -o /tmp/ccUf0R9I.s
GNU F95 version 4.1.1 20070105 (Red Hat 4.1.1-52) (i386-redhat-linux)
        compiled by GNU C version 4.1.1 20070105 (Red Hat 4.1.1-52).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 In file testspec.f90:13

CHARACTER(len(halfit(stringa))) :: stringb
                                         1
Error: 'stringb' at (1) must have constant character length in this context
harper@RHEL5 test system: ~/Jfh/Test 54 >
Comment 1 Jerry DeLisle 2007-06-18 01:00:44 UTC
Not saying whether this is valid or not.  However Intel ifort says:

fortcom: Error: john.f90, line 13: An automatic object is invalid in a main program.   [STRINGB]
CHARACTER(len(halfit(stringa))) :: stringb
-----------------------------------^
compilation aborted for john.f90 (code 1)
Comment 2 kargls 2007-06-18 01:46:09 UTC
According to Lahey, the code is invalid.

Lahey/Fujitsu Fortran 95 Source Check Output

Compiling program unit halvestring at line 1:
Compiling program unit testspec at line 9:
  2049-S: "SOURCE.F90", line 13: Automatic object 'stringb' cannot be specified in the main program unit.
Encountered 1 error, 0 warnings, 0 informations in file SOURCE.F90.
Compiling file SOURCE.F90.
Comment 3 John.Harper@mcs.vuw.ac.nz 2007-06-18 02:42:49 UTC
Subject: Re:  Pure function not allowed in specification
 expression

On Mon, 18 Jun 2007, jvdelisle at gcc dot gnu dot org wrote:

> Date: 18 Jun 2007 01:00:47 -0000
> From: jvdelisle at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>
> To: john.harper@vuw.ac.nz
> Subject: [Bug fortran/32386] Pure function not allowed in specification
>     expression
> 
>
>
> ------- Comment #1 from jvdelisle at gcc dot gnu dot org  2007-06-18 01:00 -------
> Not saying whether this is valid or not.  However Intel ifort says:
>
> fortcom: Error: john.f90, line 13: An automatic object is invalid in a main
> program.   [STRINGB]
> CHARACTER(len(halfit(stringa))) :: stringb
> -----------------------------------^
> compilation aborted for john.f90 (code 1)
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32386
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.

I think Intel is wrong because my stringb is not an automatic object.
Its length depends on LEN of a pure module function of a constant.

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
Comment 4 John.Harper@mcs.vuw.ac.nz 2007-06-18 02:44:24 UTC
Subject: Re:  Pure function not allowed in specification
 expression

On Mon, 18 Jun 2007, kargl at gcc dot gnu dot org wrote:

> Date: 18 Jun 2007 01:46:09 -0000
> From: kargl at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>
> To: john.harper@vuw.ac.nz
> Subject: [Bug fortran/32386] Pure function not allowed in specification
>     expression
> 
>
>
> ------- Comment #2 from kargl at gcc dot gnu dot org  2007-06-18 01:46 -------
> According to Lahey, the code is invalid.
>
> Lahey/Fujitsu Fortran 95 Source Check Output
>
> Compiling program unit halvestring at line 1:
> Compiling program unit testspec at line 9:
>  2049-S: "SOURCE.F90", line 13: Automatic object 'stringb' cannot be specified
> in the main program unit.
> Encountered 1 error, 0 warnings, 0 informations in file SOURCE.F90.
> Compiling file SOURCE.F90.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32386
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
So I think Lahey is wrong. My stringb is not an automatic object; it is
a character string whose length is LEN of a pure module function of a 
constant.

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
Comment 5 Jerry DeLisle 2007-06-18 04:12:56 UTC
From Fortran 95/2003 Explained, Metcalf. Reid, and Cohen

Page 101:

"The other way that automatic objects arise is through varying character length. The variable word2 in

      Subroutine example(word1)
        character(len = *), intent(inout) :: word1
        character(len = len(word1))       :: word2

is an example."
Comment 6 kargls 2007-06-18 04:26:26 UTC
In section 7.1.6.2 (which you sight), I find

  A function is a specification function if it is a pure function, is not an
  intrinsic function, is not an internal function, is not a statement function,
  does not have a dummy procedure argument, and is not defined with the
  RECURSIVE keyword.

Isn't s1 a dummy procedure argument in
 PURE FUNCTION halfit(s1) RESULT (s2)
   CHARACTER(*),INTENT(IN):: s1

Yes, I do get the usage of actual and dummy argument confused at times.
I think stringa is your actual argument and s1 the dummy argument.
Comment 7 Paul Thomas 2007-06-18 22:49:36 UTC
John,

5.1
.....many snips.....
....If a specification-expr involves a reference to a specification function (7.1.6.2), the expression is considered to be a nonconstant expression. If the data object being declared depends on the value of such a nonconstant expression and is not a dummy argument, such an object is called an automatic data object.

I can see why you should think that this is OK.  However, this section of the standard says otherwise.  In fact, there is a practical consideration, which probably drives the standard:

This character length cannot be computed at compilation time because the specification function is needed.  Automatic objects in procedures have their variable properties calculated in the interface, which is not available for the main program. Thus, even were this legal code, I would not have the slightest idea how to implement it.

My vote is that this is invalid.

Paul
Comment 8 John.Harper@mcs.vuw.ac.nz 2007-06-19 01:13:50 UTC
Subject: Re:  Pure function not allowed in specification
 expression

On Tue, 18 Jun 2007, pault at gcc dot gnu dot org wrote:

> Date: 18 Jun 2007 22:49:37 -0000
> From: pault at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>
> To: john.harper@vuw.ac.nz
> Subject: [Bug fortran/32386] Pure function not allowed in specification
>     expression
> 
>
>
> ------- Comment #7 from pault at gcc dot gnu dot org  2007-06-18 22:49 -------
> John,
>
> 5.1
> .....many snips.....
> ....If a specification-expr involves a reference to a specification function
> (7.1.6.2), the expression is considered to be a nonconstant expression. If the
> data object being declared depends on the value of such a nonconstant
> expression and is not a dummy argument, such an object is called an automatic
> data object.
>
> I can see why you should think that this is OK.  However, this section of the
> standard says otherwise.  In fact, there is a practical consideration, which
> probably drives the standard:
>
> This character length cannot be computed at compilation time because the
> specification function is needed.  Automatic objects in procedures have their
> variable properties calculated in the interface, which is not available for the
> main program. Thus, even were this legal code, I would not have the slightest
> idea how to implement it.
>
> My vote is that this is invalid.

I now agree the code was invalid - I had found 7.1.6.2 but overlooked 
5.1 before sending the bug report. You may be amused to know that some 
compilers do implement that type of automatic data object: g95 and Sun 
f95. However Compaq f95 and NAG f95 disallow it. I don't think a bug
report to g95 or Sun is warranted though: the part of 5.1 that the
program violates is not in a Constraint.

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
Comment 9 kargls 2007-06-19 03:50:56 UTC
John,

With your acknowledgment of pault's comment, I think this
can be closed.  Thanks for the reports.  These types of
potential corner cases keep us on our toes.