Constraint violation

Constraint violation

[Steve Kargl]

It seems that gfortran has been violating a constraint, which has
been in the Fortran standard since at least F95.
!
! F95, 5.1.1.5, p. 51
!
! Constraint: The optional comma in a length-selector is permitted only
!             in a type-spec in a type-declaration-stmt.
!
! Constraint: The optional comma in a length-selector is permitted only if
!             no double colon separator appears in the type-declaration-stmt.
!
! F2003, 4.4.4.1, p. 41
!
! C419 (R425) The optional comma in a length-selector is permitted only in
!      a declaration-type-spec in a type-declaration-stmt.
!
! C420 (R425) The optional comma in a length-selector is permitted only if
!      no double-colon separator appears in the type-declaration-stmt.
!
! F2008, 4.4.3.2, p. 58
!
! C421 (R421) same as F2003:C419
! C422 (R421) same as F2003:C420
!
! F2015, 7.4.4.2, p. 66
!
! C725 (R722) same as F2003:C419
! C726 (R722) same as F2003:C420
!

gfortran accidentally catches the first constraint for each standard,
but it doesn't actually report the error.  Consider,

program foo
   character*2, parameter :: c(2) = [character*2, :: 'ab', 'cd']
   print *, c
end program foo

% gfortran6 -c c.f90
c.f90:2:50:

    character*2, parameter :: c(2) = [character*2, :: 'ab', 'cd']
                                                  1
Error: Syntax error in array constructor at (1)

This seems to be a side effect of r151023 (some 8 years, 3 months ago).

On the otherhand, gfortran seem to have never gotten the second
constraint correct.

program foo
   character*2, parameter :: c(2) = ['ab', 'cd']
   print *, c
end program foo

I have a patch that seems fixes the problem, but it reveals a number
of invalid testcases: arrayio_7.f90, assumed_charlen_function_4.f90,
char_initialiser_actual.f90, char_pointer_assign.f90, ichar_1.f90,
char_pointer_dependency.f90, char_pointer_dummy.f90, char_pointer_func.f90,
initialization_9.f90, pointer_check_6.f90, and read_eor.f90.

-- 
Steve

Re: Constraint violation

[Thomas Koenig]

Hi Steve,

> It seems that gfortran has been violating a constraint, which has
> been in the Fortran standard since at least F95.


> ! Constraint: The optional comma in a length-selector is permitted only if
> !             no double colon separator appears in the type-declaration-stmt.

> On the otherhand, gfortran seem to have never gotten the second
> constraint correct.
> 
> program foo
>     character*2, parameter :: c(2) = ['ab', 'cd']
>     print *, c
> end program foo

I'm afraid you're going to have to help me out on this one.
What is the length-selector here, and what is the optinal
comma?

Regards

	Thomas

Re: Constraint violation

[Steve Kargl]

On Sat, Nov 25, 2017 at 02:51:21PM +0100, Thomas Koenig wrote:
> Hi Steve,
> 
> > It seems that gfortran has been violating a constraint, which has
> > been in the Fortran standard since at least F95.
> 
> 
> > ! Constraint: The optional comma in a length-selector is permitted only if
> > !             no double colon separator appears in the type-declaration-stmt.
> 
> > On the otherhand, gfortran seem to have never gotten the second
> > constraint correct.
> > 
> > program foo
> >     character*2, parameter :: c(2) = ['ab', 'cd']
> >     print *, c
> > end program foo
> 
> I'm afraid you're going to have to help me out on this one.
> What is the length-selector here, and what is the optinal
> comma?
> 

From F2003, 

R425 length-selector  is ( [ LEN = ] type-param-value )
                      or * char-length [ , ]

So the length-selector in the below code is '*2,'. 

program foo
   character*2, parameter :: c(2) = ['ab', 'cd']
   print *, c
end program foo

The comma is optional except that it cannot appear if '::' is present.
This is a constraint and gfortran does not report it.  To fix this,
one dives done a rabbit hole.

% gfortran6 -static -o z c.f90 && ./z
 abcd

If one removes the the attribute, one gets

program foo
   character*2, :: c(2) = ['ab', 'cd']
   print *, c
end program foo

% gfortran6 -static c.f90
c.f90:2:17:

    character*2, :: c(2) = ['ab', 'cd']
                 1
Error: Invalid character in name at (1)

A better error message that reports the constraint (to some extent) would be

% gfc -c c.f90
c.f90:2:18:

    character*2, :: c(2) = ['ab', 'cd']
                  1
Error: Double colon at (1) cannot appear after the comma


The constraint seems to resolves an ambiguity.  Again, from F2003 (where
I have shorten the word declaration to decl),

R501
type-decl-stmt  is decl-type-spec [[ , attr-spec ] ... ::] entity-decl-list

The comma belongs to the attr-spec.  As the comma is optional for
the length-selector one might argument that there isn't a problem.

   character*2   , parameter   :: c(2) = ['ab', 'cd']

except now I should be able to do (note extra comma)

   character*2,   , parameter   :: c(2) = ['ab', 'cd']

% gfortran6 -static -o z c.f90 && ./z
c.f90:2:16:

    character*2,, parameter :: c(2) = ['ab', 'cd']
                1
Error: Invalid character in name at (1)

PS: I check the F90 standard, the constraints as given in F95 are
present in F90.

-- 
Steve

Re: Constraint violation

[Thomas Koenig]

Am 25.11.2017 um 18:11 schrieb Steve Kargl:
>From F2003, 
> 
> R425 length-selector  is ( [ LEN = ] type-param-value )
>                        or * char-length [ , ]
> 
> So the length-selector in the below code is '*2,'.

Hmm... I am not convinces yet. As an indication, I present
the fact that ifort doesn't reject it (but I agree that
this is not evidence in itself).

Let me try to follow the rules here (following F2003).

R501 type-declaration-stmt is  declaration-type-spec [ [ , attr-spec ] 
... :: ] entity-decl-list

R502 declaration-type-spec is intrinsic-type-spec
                            or ...

R503 attr-spec is ...
                or PARAMETER

R401 is  intrinsic-type-spec
      or derived-type-spec

R403 intrinsic-type-spec is ...
                          or CHARACTER [char-selector]

R424 char-selector is length-selector
                    or ...

R525 length-selector is [ , LEN =type-param-value ] )
                      or *char-length[,]

So, what is

character*2, parameter :: c(2) = ['ab', 'cd']

?

character is clearly CHARACTER

*2 is a length-selector. But what about the rest?

One possibility is that ", parameter" is an attr-spec, the
other one is that the "," is part of a length-selector and the
"parameter" is junk.

This looks like a conflict in the grammar, based on that rather strange
optional comma.

I'd say we do not change this (because it can be parsed to something
valid), but this might definitely warrant an interp (or at least a
question on c.l.f., if we are willing to take the risk of being
lectured about PL/I).

Regards

	Thomas

Re: Constraint violation

[Steve Kargl]

On Sat, Nov 25, 2017 at 08:49:42PM +0100, Thomas Koenig wrote:
> Am 25.11.2017 um 18:11 schrieb Steve Kargl:
> >>From F2003, 
> > 
> > R425 length-selector  is ( [ LEN = ] type-param-value )
> >                        or * char-length [ , ]
> > 
> > So the length-selector in the below code is '*2,'.
> 
> Hmm... I am not convinces yet. As an indication, I present
> the fact that ifort doesn't reject it (but I agree that
> this is not evidence in itself).
> 
> So, what is
> 
> character*2, parameter :: c(2) = ['ab', 'cd']
> 
> ?
> 
> character is clearly CHARACTER
> 
> *2 is a length-selector. But what about the rest?
> 
> One possibility is that ", parameter" is an attr-spec, the
> other one is that the "," is part of a length-selector and the
> "parameter" is junk.
> 
> This looks like a conflict in the grammar, based on that rather strange
> optional comma.
> 

That is certainly the way gfortran and others interpret the
line of code.  It's unfortnate that that comma in a length-selector
prevents a more useful error message.

subroutine foo(a)
   real(kind=4), intent(inout), target, volatile, demension(3) :: a
end subroutine foo

% gfortran6 -static -c k.f90
k.f90:2:16:

    real(kind=4), intent(inout), target, volatile, demension(3) :: a
                1
Error: Invalid character in name at (1)

% gfc -c k.f90 
k.f90:2:52:

    real(kind=4), intent(inout), target, volatile, demension(3) :: a
                                                    1
Error: Invalid attribute at (1)

-- 
Steve