--- Comment #10 from janus at gcc dot gnu dot org 2009-12-28 21:41 ---
*** This bug has been marked as a duplicate of 41344 ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from janus at gcc dot gnu dot org 2009-12-27 11:38 ---
One more observation: The Fortran test case works, with return as well as goto,
giving the correct error message, if one removes the 'if' statement:
subroutine sub
!$omp critical
return
!$omp end
--- Comment #7 from janus at gcc dot gnu dot org 2009-12-27 12:53 ---
Interestingly, the test case also works when using an 'if ... then ... end if'
instead of a simple 'if':
subroutine sub
integer :: nRead
!$omp critical
if (nRead3) then
goto 100
end if
--- Comment #8 from janus at gcc dot gnu dot org 2009-12-27 13:05 ---
The reason for the failure of comment #0 and #4 is that these cases run into
the following optimization in gimplify_cond_expr (gimplify.c):
if (TREE_OPERAND (expr, 1) != NULL
TREE_CODE (TREE_OPERAND (expr,
--- Comment #9 from janus at gcc dot gnu dot org 2009-12-27 15:57 ---
Here is a patch which fixes the ICE, and gives the correct error messages:
Index: gcc/fortran/trans.c
===
--- gcc/fortran/trans.c (revision 155304)
+++
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-26 20:11 ---
There is a pass 'diagnose_omp_blocks', which generates the error message for
the C code. Its execution function is 'diagnose_omp_structured_block_errors' in
omp-low.x, which is correctly called also for Fortran code.
--- Comment #4 from janus at gcc dot gnu dot org 2009-12-26 22:31 ---
Here are test cases in Fortran and C, which both use GOTOs. Again, the Fortran
code ICEs, while the C code gives an error message:
subroutine sub
integer :: nRead
!$omp critical
if (nRead3) goto 100
--- Comment #5 from janus at gcc dot gnu dot org 2009-12-26 22:46 ---
For the Fortran test case in comment #4, diagnose_sb_2 (omp-low.c) is called
six times, with the following statements:
* GIMPLE_BIND
* GIMPLE_OMP_CRITICAL
* GIMPLE_COND
* GIMPLE_LABEL
* GIMPLE_LABEL
* GIMPLE_ASSIGN
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-25 20:36 ---
Sorry. Of course the code is *not* valid. Section 1.2.2 of the OpenMP 3.0
specification says: The point of exit cannot be a branch out of the structured
block.
Also, an analogous example in C is correctly rejected:
