[Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL

[Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL

[burnus at gcc dot gnu.org]

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

             Bug #: 50564
           Summary: [4.7 Regression] Front-end optimization - ICE with
                    FORALL
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: abenson@caltech.edu, tkoenig@gcc.gnu.org


Reported by Andrew Benson at
http://gcc.gnu.org/ml/fortran/2011-09/msg00154.html

With -ffrontend-optimize, gfortran ICEs with
  internal compiler error: in gfc_trans_forall_1, at fortran/trans-stmt.c:3796

Workaround: -fno-frontend-optimize
Said to be a 4.7 regression.

Test case:

program test
  implicit none
  double precision, allocatable, dimension(:) :: timeSteps
  integer                                     :: iTime
  double precision                            :: ratio
  forall(iTime=1:2)
     timeSteps(iTime)=ratio**(dble(iTime)-0.5d0)-ratio**(dble(iTime)-1.5d0)
  end forall
end program test

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.0

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-09-29 12:44:16 UTC ---
The problem is that with front-end optimization, the forall body is changed
from:
     timeSteps(iTime)=ratio**(dble(iTime)-0.5d0)-ratio**(dble(iTime)-1.5d0)
which is a simple assignment (EXEC_ASSIGN) to a block of the form
  block
    tmp = dble(iTime)
    timeSteps(iTime)=ratio**(tmp-0.5) - ratio**(tmp-1.5)
  end block
or something similar (in any case it is an EXEC_BLOCK); however,
gfc_trans_forall_1 only handles: EXEC_ASSIGN, EXEC_WHERE, EXEC_POINTER_ASSIGN,
EXEC_FORALL and EXEC_ASSIGN_CALL.

That matches F2008 (cf. below), though one could allow BLOCK internally.
  R756 forall-body-construct   is  forall-assignment-stmt
                               or  where-stmt
                               or  where-construct
                               or  forall-construct
                               or  forall-stmt
  R757 forall-assignment-stmt  is  assignment-stmt
                               or  pointer-assignment-stmt

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-09-30
     Ever Confirmed|0                           |1

--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-09-30 05:58:53 UTC ---
I'll have a look in the next few days.

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-09-30 09:11:38 UTC ---
(In reply to comment #2)
> I'll have a look in the next few days.

One way could be to move the "EXPR_ASSIGN:" part of trans-stmt.c's
gfc_trans_forall_1 into a separate function and add a "EXPR_BLOCK:" which loops
over all c->block->next, calling that new function (with an gcc_assert that it
only contains EXPR_ASSIGN); it probably deserves also a comment that the BLOCK
is generated by the FE optimization.

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |tkoenig at gcc dot gnu.org
                   |gnu.org                     |

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-10-08 21:41:11 UTC ---
FORALL sucks rocks through a straw.

We cannot use the usual front-end optimization within forall, because

  forall(iTime=1:2)
     tmp = dble(iTime)
     timeSteps(iTime)=ratio**(tmp-0.5d0)-ratio**(tmp-1.5d0)
  end forall

doesn't work (gfortran correctly warns about multiple assignments to tmp).

So, the best method is to disable front-end optimization within
a forall loop.

I assume the same holds for DO CONCURRENT.

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-10-09 16:00:41 UTC ---
(In reply to comment #4)
> So, the best method is to disable front-end optimization within
> a forall loop.
> 
> I assume the same holds for DO CONCURRENT.

I think do concurrent is OK - here, the same as with a DO loop applies -- only
the user has to guarantee that the loop will yield the same result independent
of the execution order of the bounds.

However, I think the current FE optimization might have problems with
threadsafety. Assume:

!$OMP parallel do default(share)
do i = 1, 5
  A(i) = 5*cos(B(i))+8*cos(B(i))
end do

If one now transforms this into:

!$OMP parallel do default(share)
do i = 1, 5
  tmp = cos(B(i))
  A(i) = 5*tmp+8*tmp
end do

one has a problem as "tmp" is shared. Thus, one needs to make sure that all
inserted temporary variables are thread private (DECL_THREAD_LOCAL_P).

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-10-09 16:14:43 UTC ---
(In reply to comment #5)
> one has a problem as "tmp" is shared. Thus, one needs to make sure that all
> inserted temporary variables are thread private (DECL_THREAD_LOCAL_P).

Actually, it probably works as one declares "tmp" as BLOCK in the DO loop,
which presumably generates a thread-private variable.

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[tkoenig at netcologne dot de]

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

--- Comment #7 from tkoenig at netcologne dot de <tkoenig at netcologne dot de> 2011-10-09 18:10:37 UTC ---
Am 09.10.2011 18:14, schrieb burnus at gcc dot gnu.org:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564
>
> --- Comment #6 from Tobias Burnus<burnus at gcc dot gnu.org>  2011-10-09 16:14:43 UTC ---
> (In reply to comment #5)
>> one has a problem as "tmp" is shared. Thus, one needs to make sure that all
>> inserted temporary variables are thread private (DECL_THREAD_LOCAL_P).
>
> Actually, it probably works as one declares "tmp" as BLOCK in the DO loop,
> which presumably generates a thread-private variable.

Could you supply a complete test case?  I'd like to check this out, but#
I don't use OpenMP myself.

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-10-10 09:23:19 UTC ---
(In reply to comment #7)
> Could you supply a complete test case?  I'd like to check this out, but#
> I don't use OpenMP myself.

Well, something along the following lines. Except for some declaration lines
[and "default(share)"->"default(shared)], the example is really the one of
comment 5. You can tune the number of threads using the OMP_NUM_THREADS
environment variable. However, as said before (comment 6): As the "tmp"
variable is generated in the parallel block, it should be created on the
thread-private stack and there should be no issue.

implicit none
integer :: i
real :: A(5), B(5)
B = [real :: 1, 2, 3, 4, 5 ]
!$omp parallel do default(shared)
do i = 1, 5
  A(i) = 5*cos(B(i))+8*cos(B(i))
end do
print *, A
end

 * * *

Actually, I wonder in that case, how WORKSHARE will be handled, e.g.

implicit none
integer :: i
real :: A(5), B(5)
B(1) = 3.344
A = [real :: 1, 2, 3, 4, 5 ]
!$omp parallel default(shared)
!$omp workshare
A(:) = A(:)*cos(B(1))+A(:)*cos(B(1))
!$omp end workshare nowait
!$omp end parallel ! sync is implied here
print *, A
end


Answer: With -O, one gets an ICE:

omp.f90:7:0: internal compiler error: gfc_trans_omp_workshare(): Bad statement
code

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[tkoenig at netcologne dot de]

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

--- Comment #9 from tkoenig at netcologne dot de <tkoenig at netcologne dot de> 2011-10-10 18:57:09 UTC ---
> implicit none
> integer :: i
> real :: A(5), B(5)
> B(1) = 3.344
> A = [real :: 1, 2, 3, 4, 5 ]
> !$omp parallel default(shared)
> !$omp workshare
> A(:) = A(:)*cos(B(1))+A(:)*cos(B(1))
> !$omp end workshare nowait
> !$omp end parallel ! sync is implied here
> print *, A
> end
>
>
> Answer: With -O, one gets an ICE:

The equivalent test case (inserting the BLOCK by hand)
gets a very strange error, PR 50688 .

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-10-10 19:07:38 UTC ---
Author: tkoenig
Date: Mon Oct 10 19:07:35 2011
New Revision: 179770

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179770
Log:
2011-10-10  Thomas Koenig  <tkoenig@gcc.gnu.org>

    PR fortran/50564
    * frontend-passes (forall_level):  New variable.
    (cfe_register_funcs):  Don't register functions if we
    are within a forall loop.
    (optimize_namespace):  Set forall_level to 0 before entry.
    (gfc_code_walker):  Increase/decrease forall_level.

2011-10-10  Thomas Koenig  <tkoenig@gcc.gnu.org>

    PR fortran/50564
    * gfortran.dg/forall_15.f90:  New test case.


Added:
    trunk/gcc/testsuite/gfortran.dg/forall_15.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/frontend-passes.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #11 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-10-10 19:14:36 UTC ---
Closing; I have opened PR 50690 for tracking the issue
in comment #8.