[Bug fortran/90890] New: segfault on LHS memory reallocation

2019-06-15 Thread bharat.mahajan at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90890

Bug ID: 90890
   Summary: segfault on LHS memory reallocation
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bharat.mahajan at hotmail dot com
  Target Milestone: ---

The following program fails with segfault:

program test
implicit  none
real, dimension(:), allocatable :: a
integer :: b

a = [a, 2.0]
b = -100
end program test

Compiled it without any option to gfortran on MingW (Win10). If you comment out
the line "b=-100" then it works! gfortran version:

GNU Fortran (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0

[Bug fortran/90890] segfault on LHS memory reallocation

2019-06-15 Thread bharat.mahajan at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90890

--- Comment #2 from Bharat Mahajan  ---
(In reply to kargl from comment #1)
> (In reply to Bharat Mahajan from comment #0)
> > The following program fails with segfault:
> > 
> > program test
> > implicit  none
> > real, dimension(:), allocatable :: a
> > integer :: b
> > 
> > a = [a, 2.0]
> > b = -100
> > end program test
> > 
> > Compiled it without any option to gfortran on MingW (Win10). If you comment
> > out the line "b=-100" then it works! gfortran version:
> > 
> > GNU Fortran (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0
> 
> The code is invalid.  In the expression 'a = [a, 2.0]'
> you reference 'a' on the RHS when it is undefined.

I forgot to mention that code runs with no issues with ifort. Second, then why
the following code works with gfortran?

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

I am not sure I would say 'a' is not defined. It is not allocated yet, that is
what the code is trying to do. I have not checked the standards so not sure
that the code is trying to do something outside of that, but it works with
ifort without their extensions.

[Bug fortran/90890] segfault on LHS memory reallocation

2019-06-16 Thread bharat.mahajan at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90890

--- Comment #4 from Bharat Mahajan  ---
(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!!

[Bug fortran/90890] segfault on LHS memory reallocation

2019-06-17 Thread bharat.mahajan at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90890

--- Comment #6 from Bharat Mahajan  ---
(In reply to Steve Kargl from comment #5)
> You got lucky.  You gave the compiler invalid code.  It can do
> anything with the code (including giving you a result that you
> may expect).
> 

Ok I see. I checked with ifort team and ifort also gives a warning in this case
if appropriate option is used. And the correct way was to allocate 'a' to 0
size and then use it in order to avoid calls to 'allocated()' inside a loop. I
didn't know that was an option in Fortran. Thanks for the clarifications!