* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
@ 2011-09-29 8:35 ` burnus at gcc dot gnu.org
2011-09-29 13:10 ` burnus at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-09-29 8:35 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
2011-09-29 8:35 ` [Bug fortran/50564] " burnus at gcc dot gnu.org
@ 2011-09-29 13:10 ` burnus at gcc dot gnu.org
2011-09-30 6:01 ` tkoenig at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-09-29 13:10 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
2011-09-29 8:35 ` [Bug fortran/50564] " burnus at gcc dot gnu.org
2011-09-29 13:10 ` burnus at gcc dot gnu.org
@ 2011-09-30 6:01 ` tkoenig at gcc dot gnu.org
2011-09-30 9:30 ` burnus at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2011-09-30 6:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
` (2 preceding siblings ...)
2011-09-30 6:01 ` tkoenig at gcc dot gnu.org
@ 2011-09-30 9:30 ` burnus at gcc dot gnu.org
2011-10-08 9:31 ` tkoenig at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-09-30 9:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
` (3 preceding siblings ...)
2011-09-30 9:30 ` burnus at gcc dot gnu.org
@ 2011-10-08 9:31 ` tkoenig at gcc dot gnu.org
2011-10-08 21:41 ` tkoenig at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2011-10-08 9:31 UTC (permalink / raw)
To: gcc-bugs
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 |
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
` (4 preceding siblings ...)
2011-10-08 9:31 ` tkoenig at gcc dot gnu.org
@ 2011-10-08 21:41 ` tkoenig at gcc dot gnu.org
2011-10-09 16:01 ` burnus at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2011-10-08 21:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
` (5 preceding siblings ...)
2011-10-08 21:41 ` tkoenig at gcc dot gnu.org
@ 2011-10-09 16:01 ` burnus at gcc dot gnu.org
2011-10-09 16:15 ` burnus at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-10-09 16:01 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
` (6 preceding siblings ...)
2011-10-09 16:01 ` burnus at gcc dot gnu.org
@ 2011-10-09 16:15 ` burnus at gcc dot gnu.org
2011-10-09 18:11 ` tkoenig at netcologne dot de
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-10-09 16:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
` (7 preceding siblings ...)
2011-10-09 16:15 ` burnus at gcc dot gnu.org
@ 2011-10-09 18:11 ` tkoenig at netcologne dot de
2011-10-10 9:24 ` burnus at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: tkoenig at netcologne dot de @ 2011-10-09 18:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
` (8 preceding siblings ...)
2011-10-09 18:11 ` tkoenig at netcologne dot de
@ 2011-10-10 9:24 ` burnus at gcc dot gnu.org
2011-10-10 14:28 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-10-10 9:24 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
` (9 preceding siblings ...)
2011-10-10 9:24 ` burnus at gcc dot gnu.org
@ 2011-10-10 14:28 ` rguenth at gcc dot gnu.org
2011-10-10 18:57 ` tkoenig at netcologne dot de
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-10-10 14:28 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
` (10 preceding siblings ...)
2011-10-10 14:28 ` rguenth at gcc dot gnu.org
@ 2011-10-10 18:57 ` tkoenig at netcologne dot de
2011-10-10 19:09 ` tkoenig at gcc dot gnu.org
2011-10-10 19:15 ` tkoenig at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: tkoenig at netcologne dot de @ 2011-10-10 18:57 UTC (permalink / raw)
To: gcc-bugs
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 .
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
` (11 preceding siblings ...)
2011-10-10 18:57 ` tkoenig at netcologne dot de
@ 2011-10-10 19:09 ` tkoenig at gcc dot gnu.org
2011-10-10 19:15 ` tkoenig at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2011-10-10 19:09 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
2011-09-29 8:21 [Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL burnus at gcc dot gnu.org
` (12 preceding siblings ...)
2011-10-10 19:09 ` tkoenig at gcc dot gnu.org
@ 2011-10-10 19:15 ` tkoenig at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2011-10-10 19:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread