[Bug fortran/84778] Issue with character arguments of specified length (does not compile)

2018-03-12 Thread david.applegate at woodplc dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84778

david.applegate at woodplc dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from david.applegate at woodplc dot com ---
Actually forget I mentioned that second bug - fixing it would cause us much
more pain than the first fix did!

Thanks for your time.

[Bug fortran/84778] Issue with character arguments of specified length (does not compile)

2018-03-12 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84778

--- Comment #4 from Steve Kargl  ---
On Mon, Mar 12, 2018 at 10:16:19AM +, david.applegate at woodplc dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84778
> 
> --- Comment #3 from david.applegate at woodplc dot com ---
> Thanks for the reply and the clarification.  
> 
> I have two comments to make regarding this if I may...
> 
> 1) Previous gfortran compilers were happy with the code.
>I also tested g95 and Ifort (admittedly aged versions
>of both).  Ifort also refused to compile the code while
>g95 did compile the code (you may not care I guess).  It
>is slightly irritating that gfortran is essentially not
>backwards compatible with previous versions.  Maybe
>gfortran should compile this code unless the users
>specify one of the -std=f95/f2003/f2008 switches?

If we wrapped every bug fix in a -std option, the gfortran
source code would become unreadable.  

> 2) What about array declaration? Gfortran 7.3 is happy to
>compile the following code, which presumably does not
>conform to the standard you mention, while Ifort refuses
>to compile this code:

It seems that you have found another bug.  It may one day
be fixed.

[Bug fortran/84778] Issue with character arguments of specified length (does not compile)

2018-03-12 Thread david.applegate at woodplc dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84778

--- Comment #3 from david.applegate at woodplc dot com ---
Thanks for the reply and the clarification.  

I have two comments to make regarding this if I may...

1) Previous gfortran compilers were happy with the code.  I also tested g95 and
Ifort (admittedly aged versions of both).  Ifort also refused to compile the
code while g95 did compile the code (you may not care I guess).  It is slightly
irritating that gfortran is essentially not backwards compatible with previous
versions.  Maybe gfortran should compile this code unless the users specify one
of the -std=f95/f2003/f2008 switches?

2) What about array declaration? Gfortran 7.3 is happy to compile the following
code, which presumably does not conform to the standard you mention, while
Ifort refuses to compile this code:

program test2

  implicit none
  integer, parameter :: b = 5
  integer :: a(b)

  a = 4

  write(*,*)a

  call testsub(a,b)

contains

  subroutine testsub(a,b)

! integer, intent(in) :: b   ! if we put declaration of b here instead it
compiles ok

integer :: a(b)
integer, intent(in) :: b  

write(*,*)a

  end subroutine testsub
end program test2

[Bug fortran/84778] Issue with character arguments of specified length (does not compile)

2018-03-09 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84778

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-03-09
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to david.applegate from comment #0)
> Pass a character "a"  into a subroutine with an additional argument integer
> "b" which specifies its length.  This does not compile if integer "b" is
> declared after character "a" in the subroutine. See below
> 
> program test
> 
>   implicit none
>   integer, parameter :: b = 5
>   character(len=b) :: a
> 
>   a = "hello"
> 
>   write(*,*)a//" from main program"
>   
>   call testsub(a,b)
> 
> contains
> 
>   subroutine testsub(a,b)
> 
> ! integer, intent(in) :: b   ! if we put declaration of b here instead
> it compiles ok
> character(len=b), intent(in) :: a
> integer, intent(in) :: b 
> 
> write(*,*)a//" from testsub"
> 
>   end subroutine testsub
> end program test

The gfortran gives

% gfcx -o z m.f90
m.f90:16:18:

 character(len=b), intent(in) :: a
  1
Error: Scalar INTEGER expression expected at (1)

plus a few run on errors.  The above error message 
is correct.  The dummy argument 'b' in testsub
prevents host associate, so when 'b' is used
in the above statement it has no type and the
implicit none prevents determining what type 
to use in the specification statement.

F2003 explicitly states 

A variable in a specification expression shall have
its type and type parameters, if any, specified by a
previous declaration in the same scoping unit, by the
implicit typing rules in effect for the scoping unit,
or by host or use association. If a variable in a
specification expression is typed by the implicit typing
rules, its appearance in any subsequent type declaration
statement shall confirm the implied type and type parameters.

[Bug fortran/84778] Issue with character arguments of specified length (does not compile)

2018-03-09 Thread david.applegate at woodplc dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84778

--- Comment #1 from david.applegate at woodplc dot com ---
This bug does not occur in GCC 4.8.2