https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90890

--- Comment #4 from Bharat Mahajan <bharat.mahajan at hotmail dot com> ---
(In reply to Steve Kargl from comment #3)
> On Sat, Jun 15, 2019 at 11:08:43PM +0000, bharat.mahajan at hotmail dot com
> wrote:
> > 
> > I forgot to mention that code runs with no issues with ifort. Second, then 
> > why
> > the following code works with gfortran?
> 
> The Fortran standard does not require a Fortran processor (i.e., 
> the compiler) to detect and report that you are using an undefined
> entity.
> 
> > program test
> >     implicit  none
> >     real, dimension(:), allocatable :: a    
> >     integer :: b
> >     a = [a, 2.0]
> 
> What value does 'a' have on the right side of the above
> expression?
> 
> The correct way to write the above would have either
> been to assign something to 'a' prior to using on the
> RHS above or writing
> 
>    if (allocated(a)) a = [a, 2.0]
> 
> >     !b = -100
> > end program test
> > ---
> > 
> > I am not sure I would say 'a' is not defined.
> 
> The Fortran standard decides what is defined and undefined.
> 
> From F2018
> 
>    19.6.2 Variables that are always defined
> 
>    Zero-sized arrays and zero-length strings are always defined.
> 
>    19.6.3 Variables that are initially defined
> 
>    The following variables are initially defined:
> 
>      (1) variables specified to have initial values by DATA statements;
>      (2) variables specified to have initial values by type declaration
>          statements;
>      (3) nonpointer default-initialized subcomponents of saved variables
>          that do not have the ALLOCATABLE or POINTER attribute;
>      (4) pointers specified to be initially associated with a variable
>          that is initially defined;
>      (5) variables that are always defined;
>      (6) variables with the BIND attribute that are initialized by means
>         other than Fortran.
> 
>    19.6.4 Variables that are initially undefined
> 
>    Variables that are not initially defined are initially undefined.
> 
> Your 'a' is undefined.

Ok I agree that 'a' is undefined in this case. But that was not my concern in
the original submission. To again clarify what my concern is, 

If the following program fails with segfault because 'a' is undefined:

program test
     implicit  none
     real, dimension(:), allocatable :: a    
     integer :: b
     a = [a, 2.0]
     b = 100
     print *, a
end program test

then why the following program works and prints "2.0" on screen??

program test
     implicit  none
     real, dimension(:), allocatable :: a    
     a = [a, 2.0]
     print *, a
end program test

This is just very unusual to me because 'b' is unrelated to 'a' and 'a' is
undefined in both programs. We should see segfault in both cases to be
consistent but I am seeing that the 2nd programs works and prints "2.0" on
windows machine with MinGW-w64's gfortran-8. I checked it on gfortran-8 on
Ubuntu and it segfaults in both cases, so this behavior is may be specific to
MingW-w64 project only.

If you are saying standard does not say any thing in this regard and if you use
'a' in this manner, the behavior is undefined. So this behavior of sometimes it
works and sometimes not is ok, I hear you.

However, in my personal opinion if a user tries to use an allocatable array in
the following manner:

     real, dimension(:), allocatable :: a    
     a = [a, 2.0]

the compiler (or processor) should see that 'a' is not defined/allocated yet so
just allocate the storage for only 1 real in this case. I think the standard
says that compiler will do automatic reallocation based on RHS expression and
'a' on RHS can be seen as having 0 size. This is what ifort is doing and from a
programmer's perspective we don't have to deal with this ugly piece of code
every time in a loop:

if (.NOT. allocated(a)) then
    a = 2.0
else
    a = [a, 2.0]
end if

I am not sure the gfortran strategy of forcing the programmer to define 'a'
first before using it in 'a=[a,2.0]' helps in catching any bugs. And it defeats
the purpose of having the convenience of automatic reallocation a little.

To be honest, computer science is not my area of expertise and I have been
doing Fortran programming part-time since February 2019, so see for yourself if
I am making any sense here!!

Reply via email to