[Bug fortran/44354] New: incorrect output at run time

[Bug fortran/44354] New: incorrect output at run time

[zeccav at gmail dot com]

The following provokes the summary, must be compiled and run:

c gfortran run time only displays "1" 
      I=5
      print *,(/(i,i=1,I)/)
      end

Best regards
Vittorio Zecca


-- 
           Summary: incorrect output at run time
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: zeccav at gmail dot com
  GCC host triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[mikael at gcc dot gnu dot org]

------- Comment #1 from mikael at gcc dot gnu dot org  2010-05-31 17:43 -------
Note that fortran is case insensitive, ie i and I refer to the same variable.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2010-05-31 18:01 -------
> Note that fortran is case insensitive,  ...

Indeed, but I think the implied do loop should still go from 1 to 5. Note that
if I print 'i' after the loop I get 5.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[mikael at gcc dot gnu dot org]

------- Comment #3 from mikael at gcc dot gnu dot org  2010-05-31 18:04 -------
OK, it seems gfortran is wrong here. 

The 4.8 section (Construction of array values) says :
   /If an ac-value is an ac-implied-do, it is expanded
    to form a sequence of elements under the control of the ac-do-variable,
    as in the DO construct (8.1.6.6)./

And in the DO construct the number of iterations shall be evaluated before
execution. 


Confirmed. However, having this in real world codes seems like the best way to
confuse people. 


-- 

mikael at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
      Known to fail|                            |4.4.4 4.6.0
   Last reconfirmed|0000-00-00 00:00:00         |2010-05-31 18:04:29
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[kargl at gcc dot gnu dot org]

------- Comment #4 from kargl at gcc dot gnu dot org  2010-05-31 18:33 -------
(In reply to comment #2)
> > Note that fortran is case insensitive,  ...
> 
> Indeed, but I think the implied do loop should still go from 1 to 5. Note that
> if I print 'i' after the loop I get 5.
> 

Of course it prints 5.  The 'i' in the do-loop has the scope of
the implied-do-loop.  The 'I' in the program has the scope of the
program.

laptop:kargl[247] cat ui.f90
      integer j(4)
      I=5
      j = 42
      j = (/(i,i=1,I-1)/)
      print '(A,I0,A,4(I0,1X))', 'I = ', I, ' j = ', j
      end

laptop:kargl[248] gfc4x -o z -fdump-tree-original ui.f90
laptop:kargl[249] ./z
I = 5 j = 0 134516008 0 0

The question becomes whether the 'I' in the implied-do-loop is
being used uninitialized.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[dominiq at lps dot ens dot fr]

------- Comment #5 from dominiq at lps dot ens dot fr  2010-05-31 19:24 -------
> The question becomes whether the 'I' in the implied-do-loop is
> being used uninitialized.

>From comment #3, I think the 'i' in "i,i=" should not be the same as the 'i' in
"=1,i".

> Confirmed. However, having this in real world codes seems like the best way to
> confuse people. 

Agreed!-) I am always baffled by the users' talent to make their life
miserable.
Nevertheless the compiler should follow the standard, i.e.,  from my
understanding of the construct, print the 1 to 5 sequence.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[kargl at gcc dot gnu dot org]

------- Comment #6 from kargl at gcc dot gnu dot org  2010-05-31 20:02 -------
(In reply to comment #5)
> > The question becomes whether the 'I' in the implied-do-loop is
> > being used uninitialized.
> 
> From comment #3, I think the 'i' in "i,i=" should not be the same as the 'i' in
> "=1,i".

Well, it still comes back to scope.  The implied-do-loop is
different from

      integer j(5)
      I=5
      j = 42
      do i = 1, I
         j(i) = i
      end do
      print '(A,I0,A,5(I0,1X))', 'I = ', I, ' j = ', j
      end

because in the above 'i' and 'I' are in the same scoping unit.
If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in
a different scoping unit.  I agree that the scalar-int-expr
'1' and 'I' need to be evaluated to establish the the loop
start and stop values.  The question again based on scoping
unit is whether 'I' is uninitialized.




> > Confirmed. However, having this in real world codes seems like the best way to
> > confuse people. 
> 
> Agreed!-) I am always baffled by the users' talent to make their life
> miserable.
> Nevertheless the compiler should follow the standard, i.e.,  from my
> understanding of the construct, print the 1 to 5 sequence.
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[mikael at gcc dot gnu dot org]

------- Comment #7 from mikael at gcc dot gnu dot org  2010-05-31 21:31 -------
(In reply to comment #6)
> because in the above 'i' and 'I' are in the same scoping unit.
I couldn't find what mandates in the standard that i and I are in a different
scoping unit/are different variables. Are they ?

> If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in
> a different scoping unit.  I agree that the scalar-int-expr
> '1' and 'I' need to be evaluated to establish the the loop
> start and stop values.  The question again based on scoping
> unit is whether 'I' is uninitialized.
> 
How could it be ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[mikael at gcc dot gnu dot org]

------- Comment #8 from mikael at gcc dot gnu dot org  2010-05-31 21:33 -------
Created an attachment (id=20787)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20787&action=view)
draft patch

This makes loop bounds evaluation before the internal variable substitution.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[zeccav at gmail dot com]

------- Comment #9 from zeccav at gmail dot com  2010-05-31 21:37 -------
Subject: Re:  incorrect output at run time

In my example 'i' is local to the array constructor, while 'I' is
global and is initialized with value 5, so that the statement should
display '1 2 3 4 5'. I agree that this is a pathological example, but
still gfortran should follow the standard and output the correct data.

2010/5/31, mikael at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>:
>
>
> ------- Comment #7 from mikael at gcc dot gnu dot org  2010-05-31 21:31
> -------
> (In reply to comment #6)
>> because in the above 'i' and 'I' are in the same scoping unit.
> I couldn't find what mandates in the standard that i and I are in a
> different
> scoping unit/are different variables. Are they ?
>
>> If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in
>> a different scoping unit.  I agree that the scalar-int-expr
>> '1' and 'I' need to be evaluated to establish the the loop
>> start and stop values.  The question again based on scoping
>> unit is whether 'I' is uninitialized.
>>
> How could it be ?
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[mikael at gcc dot gnu dot org]

------- Comment #10 from mikael at gcc dot gnu dot org  2010-05-31 21:39 -------
(In reply to comment #6)
>       integer j(5)
>       I=5
>       j = 42
>       do i = 1, I
>          j(i) = i
>       end do
>       print '(A,I0,A,5(I0,1X))', 'I = ', I, ' j = ', j
>       end
> 
> because in the above 'i' and 'I' are in the same scoping unit.
> If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in
> a different scoping unit.  I agree that the scalar-int-expr
> '1' and 'I' need to be evaluated to establish the the loop
> start and stop values.  The question again based on scoping
> unit is whether 'I' is uninitialized.

Even if 'i' and 'I' are in different scoping unit, there is nothing unitialized
:
('i' is the external 'I', and 'ii' the internal one)

       integer j(5)
       I=5
       j = 42
       do ii = 1, I
          j(ii) = ii
       end do
       print '(A,I0,A,5(I0,1X))', 'I = ', I, ' j = ', j
       end


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[kargl at gcc dot gnu dot org]

------- Comment #11 from kargl at gcc dot gnu dot org  2010-05-31 21:54 -------
(In reply to comment #7)
> (In reply to comment #6)
> > because in the above 'i' and 'I' are in the same scoping unit.
> I couldn't find what mandates in the standard that i and I are in a different
> scoping unit/are different variables. Are they ?
> 
> > If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in
> > a different scoping unit.  I agree that the scalar-int-expr
> > '1' and 'I' need to be evaluated to establish the the loop
> > start and stop values.  The question again based on scoping
> > unit is whether 'I' is uninitialized.
> > 
> How could it be ?
> 

I don't understand what you are asking.

  integer j(5)
  I = 5
  j = (/ (i,i=1,I) /)  ! (i,i=m1,m2) for discussion below
  end 

'I' in line 2 is in the scope of the main program.
'i' in line 3 is in the scope of the implied-do-loop.
'I' in line 2 is not the same as 'i' in line 3.  The
only thing that 'i' in line 3 gets from 'I' in line 2
is its type and kind type parameter.  When 'i' in 
line 3 comes into scope, does 'I' in the m2 become
undefined?  I can't find anything in the standard
that states that it becomes undefined and I can't
find anywhere that states that it is still defined to
have a value of 5 in the evaluation of m2.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[kargl at gcc dot gnu dot org]

------- Comment #12 from kargl at gcc dot gnu dot org  2010-05-31 22:47 -------
(In reply to comment #8)
> Created an attachment (id=20787)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20787&action=view) [edit]
> draft patch
> 
> This makes loop bounds evaluation before the internal variable substitution.
> 

BTW, I believe your patch is correct.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[kargl at gcc dot gnu dot org]

------- Comment #13 from kargl at gcc dot gnu dot org  2010-05-31 23:44 -------
Due to my confusion over the scope of 'i' and 'I',
I posted to c.l.f.  As usual Richard Maine pieced
through the standard's language.

http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/1f88cd2dec855d73#

Richard's explanation states the code is illegal.

I've removed the wrong-code keyword.  The only point left to
discuss is whether Mikael patch should be applied.  It will
give the results that Vittorio wants.  Personally, I would
rather issue an error.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sgk at troutmask dot apl dot
                   |                            |washington dot edu
           Keywords|wrong-code                  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[jvdelisle at gcc dot gnu dot org]

------- Comment #14 from jvdelisle at gcc dot gnu dot org  2010-06-01 02:09 -------
My take on this as I was reading through this thread before I got to comment
#13 is that the code has to be illegal.  I vote for the error. I think it would
be bad practice too introduce this as an extension or for some other reason.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #15 from sgk at troutmask dot apl dot washington dot edu  2010-06-01 03:07 -------
Subject: Re:  incorrect output at run time

On Tue, Jun 01, 2010 at 02:09:38AM -0000, jvdelisle at gcc dot gnu dot org
wrote:
> 
> My take on this as I was reading through this thread before I got to comment
> #13 is that the code has to be illegal.  I vote for the error. I think it would
> be bad practice too introduce this as an extension or for some other reason.
> 

Note that 

  i = 5
  print *, (i,i=1,i)
  end 

is valid Fortran and gfortran currently gives the expected
result.  The distinction is the above is an io-implied-do.
The original code contains an ac-implied-do.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[jvdelisle at verizon dot net]

------- Comment #16 from jvdelisle at verizon dot net  2010-06-01 03:46 -------
Subject: Re:  incorrect output at run time

On 05/31/2010 08:07 PM, sgk at troutmask dot apl dot washington dot edu wrote:
> ------- Comment #15 from sgk at troutmask dot apl dot washington dot edu  2010-06-01 03:07 -------
> Subject: Re:  incorrect output at run time
>
> On Tue, Jun 01, 2010 at 02:09:38AM -0000, jvdelisle at gcc dot gnu dot org
> wrote:
>>
>> My take on this as I was reading through this thread before I got to comment
>> #13 is that the code has to be illegal.  I vote for the error. I think it would
>> be bad practice too introduce this as an extension or for some other reason.
>>
>
> Note that
>
>    i = 5
>    print *, (i,i=1,i)
>    end
>
> is valid Fortran and gfortran currently gives the expected
> result.  The distinction is the above is an io-implied-do.
> The original code contains an ac-implied-do.
>
>
Understood!

Jerry


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[pault at gcc dot gnu dot org]

------- Comment #17 from pault at gcc dot gnu dot org  2010-06-01 04:31 -------
(In reply to comment #13)
> Due to my confusion over the scope of 'i' and 'I',
> I posted to c.l.f.  As usual Richard Maine pieced
> through the standard's language.
> 
> http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/1f88cd2dec855d73#

As John Harper did on the above thread, I found:

fortcom: Error: pr44354.f90, line 3: It is not permissible to reference the
value of an ac-implied-do variable in one of its limit expressions
      print *,(/(i,i=1,I)/)
-----------------^
compilation aborted for pr44354.f90 (code 1)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[burnus at gcc dot gnu dot org]

------- Comment #18 from burnus at gcc dot gnu dot org  2010-06-01 08:03 -------
Just for fun, I have feed it into NAG's f95 - and it prints:

Extension: gjff.f90, line 2: AC-implied-DO limit references control variable I
$ ./a.out
 1 2 3 4 5

Where extension = vendor extension. (NAG also uses "extension" = F2003, which
can be silenced via -f2003.)

Intel's ifort rejects it (ERROR) - as previously stated - while g95, pathf95,
and openf95 allow it without any warning and print "1 2 3 4 5".

Expected:
a) Allow it as extension (-std=gnu or -std=legacy; especially, for -std=gnu one
could consider a default-enabled warning)
b) Reject it for -std=f(95,2003,2008)


Thus, I am in favour of Mikael's patch, but one should also add some
diagnostics.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[mikael at gcc dot gnu dot org]

------- Comment #19 from mikael at gcc dot gnu dot org  2010-06-01 14:09 -------
Created an attachment (id=20795)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20795&action=view)
Draft patch, version 2

Also pre-evaluate the lower bound.

for a case like this :

      integer j(4)
      I=5
      j = (/(i,i=I-1,8)/)
      end


-- 

mikael at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #20787|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[mikael at gcc dot gnu dot org]

------- Comment #20 from mikael at gcc dot gnu dot org  2010-06-01 14:13 -------
(In reply to comment #19)
> for a case like this :
> 
>       integer j(4)
>       I=5
>       j = (/(i,i=I-1,8)/)
You should read here :
        j = (/(i,i=I,8)/)
>       end
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] incorrect output at run time

[dfranke at gcc dot gnu dot org]

------- Comment #21 from dfranke at gcc dot gnu dot org  2010-06-01 21:02 -------
(In reply to comment #18)
> Expected:
> a) Allow it as extension (-std=gnu or -std=legacy; especially, for -std=gnu one
> could consider a default-enabled warning)
> b) Reject it for -std=f(95,2003,2008)

I'd vote to reject it for any -std=*. This extension just asks for trouble.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org
   GCC host triplet|x86_64-unknown-linux-gnu    |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] implied do loop with its own variable name as upper bound

[tkoenig at gcc dot gnu dot org]

------- Comment #22 from tkoenig at gcc dot gnu dot org  2010-06-07 18:11 -------
Adjusting subject, setting severity to "enhancement" and
adding "diagnostic" keyword.(In reply to comment #21)
> (In reply to comment #18)
> > Expected:
> > a) Allow it as extension (-std=gnu or -std=legacy; especially, for -std=gnu one
> > could consider a default-enabled warning)
> > b) Reject it for -std=f(95,2003,2008)
> 
> I'd vote to reject it for any -std=*. This extension just asks for trouble.

I concur.  I would also favor a warning at least for -Wuninitialized.


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu dot
                   |                            |org
           Severity|normal                      |enhancement
           Keywords|                            |diagnostic
            Summary|incorrect output at run time|implied do loop with its own
                   |                            |variable name as upper bound


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] implied do loop with its own variable name as upper bound

[mikael at gcc dot gnu dot org]

-- 

mikael at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |mikael at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2010-05-31 18:04:29         |2010-07-28 20:53:59
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

[Bug fortran/44354] implied do loop with its own variable name as upper bound

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
      Known to fail|                            |

--- Comment #25 from Mikael Morin <mikael at gcc dot gnu.org> 2012-07-26 09:04:09 UTC ---
The code in comment 0 now gives the expected output:
           1           2           3           4           5

It is accepted by default with a warning.
It is rejected with -std=f{95,2003,2008}.

Thus, (finally) fixed for 4.8.0.

[Bug fortran/44354] implied do loop with its own variable name as upper bound

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

--- Comment #24 from Mikael Morin <mikael at gcc dot gnu.org> 2012-07-26 08:54:02 UTC ---
Author: mikael
Date: Thu Jul 26 08:53:56 2012
New Revision: 189883

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189883
Log:
fortran/
    PR fortran/44354
    * trans-array.c (gfc_trans_array_constructor_value):
    Evaluate the iteration bounds before the inner variable shadows
    the outer.

testsuite/
    PR fortran/44354
    * gfortran.dg/array_constructor_39.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/array_constructor_39.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/44354] implied do loop with its own variable name as upper bound

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354

--- Comment #23 from Mikael Morin <mikael at gcc dot gnu.org> 2012-07-26 08:47:42 UTC ---
Author: mikael
Date: Thu Jul 26 08:47:33 2012
New Revision: 189882

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189882
Log:
fortran/
    PR fortran/44354
    * array.c (sought_symbol): New variable.
    (expr_is_sought_symbol_ref, find_symbol_in_expr): New functions.
    (resolve_array_list): Check for references to the induction
    variable in the iteration bounds and issue a diagnostic if some
    are found.

testsuite/
    PR fortran/44354
    * gfortran.dg/array_constructor_38.f90: New test.



Added:
    trunk/gcc/testsuite/gfortran.dg/array_constructor_38.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/array.c
    trunk/gcc/testsuite/ChangeLog