* [Bug middle-end/42484] ICE with -fopenmp
2009-12-23 22:00 [Bug middle-end/42484] New: ICE with -fopenmp janus at gcc dot gnu dot org
@ 2009-12-24 13:54 ` janus at gcc dot gnu dot org
2009-12-25 20:37 ` [Bug fortran/42484] " janus at gcc dot gnu dot org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu dot org @ 2009-12-24 13:54 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from janus at gcc dot gnu dot org 2009-12-24 13:54 -------
I think the example is valid. ifort and sunf95 accept it.
--
janus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|ice-on-invalid-code |ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/42484] ICE with -fopenmp
2009-12-23 22:00 [Bug middle-end/42484] New: ICE with -fopenmp janus at gcc dot gnu dot org
2009-12-24 13:54 ` [Bug middle-end/42484] " janus at gcc dot gnu dot org
@ 2009-12-25 20:37 ` janus at gcc dot gnu dot org
2009-12-26 20:11 ` janus at gcc dot gnu dot org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu dot org @ 2009-12-25 20:37 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
------- 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:
void sub ()
{
int nRead;
#pragma omp critical
if (nRead<3) return;
}
In function sub:
error: invalid branch to/from an OpenMP structured block
So, I guess it is a problem of the Fortran front-end, which should detect this
situation and reject the code.
--
janus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|middle-end |fortran
Keywords|ice-on-valid-code |ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/42484] ICE with -fopenmp
2009-12-23 22:00 [Bug middle-end/42484] New: ICE with -fopenmp janus at gcc dot gnu dot org
2009-12-24 13:54 ` [Bug middle-end/42484] " janus at gcc dot gnu dot org
2009-12-25 20:37 ` [Bug fortran/42484] " janus at gcc dot gnu dot org
@ 2009-12-26 20:11 ` janus at gcc dot gnu dot org
2009-12-26 22:31 ` janus at gcc dot gnu dot org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu dot org @ 2009-12-26 20:11 UTC (permalink / raw)
To: gcc-bugs
------- 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. However, the checks
in 'diagnose_sb_0' and 'diagnose_sb_2' don't seem to work for the Fortran test
case.
For the C code in comment #2, the GIMPLE_RETURN branch in diagnose_sb_2 is in
effect and calls diagnose_sb_0, which throws the errror. For the Fortran case
this does not work, since the RETURN is translated to a GOTO. However, GOTOs
jumping out of an OMP CRITICAL section should also be rejected. (I still don't
see where things go wrong.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/42484] ICE with -fopenmp
2009-12-23 22:00 [Bug middle-end/42484] New: ICE with -fopenmp janus at gcc dot gnu dot org
` (2 preceding siblings ...)
2009-12-26 20:11 ` janus at gcc dot gnu dot org
@ 2009-12-26 22:31 ` janus at gcc dot gnu dot org
2009-12-26 22:47 ` janus at gcc dot gnu dot org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu dot org @ 2009-12-26 22:31 UTC (permalink / raw)
To: gcc-bugs
------- 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 (nRead<3) goto 100
!$omp end critical
100 nRead=4
end subroutine
void sub ()
{
int nRead;
#pragma omp critical
if (nRead<3) goto out;
out: nRead=4;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/42484] ICE with -fopenmp
2009-12-23 22:00 [Bug middle-end/42484] New: ICE with -fopenmp janus at gcc dot gnu dot org
` (3 preceding siblings ...)
2009-12-26 22:31 ` janus at gcc dot gnu dot org
@ 2009-12-26 22:47 ` janus at gcc dot gnu dot org
2009-12-27 11:38 ` janus at gcc dot gnu dot org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu dot org @ 2009-12-26 22:47 UTC (permalink / raw)
To: gcc-bugs
------- 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
For the C case, it is called eight times:
* GIMPLE_BIND
* GIMPLE_OMP_CRITICAL
* GIMPLE_COND
* GIMPLE_LABEL
* GIMPLE_GOTO
* GIMPLE_LABEL
* GIMPLE_LABEL
* GIMPLE_ASSIGN
The question is why GIMPLE_GOTO is missing for the Fortran case?!?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/42484] ICE with -fopenmp
2009-12-23 22:00 [Bug middle-end/42484] New: ICE with -fopenmp janus at gcc dot gnu dot org
` (4 preceding siblings ...)
2009-12-26 22:47 ` janus at gcc dot gnu dot org
@ 2009-12-27 11:38 ` janus at gcc dot gnu dot org
2009-12-27 12:54 ` janus at gcc dot gnu dot org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu dot org @ 2009-12-27 11:38 UTC (permalink / raw)
To: gcc-bugs
------- 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 critical
end subroutine
"error: invalid branch to/from an OpenMP structured block"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/42484] ICE with -fopenmp
2009-12-23 22:00 [Bug middle-end/42484] New: ICE with -fopenmp janus at gcc dot gnu dot org
` (5 preceding siblings ...)
2009-12-27 11:38 ` janus at gcc dot gnu dot org
@ 2009-12-27 12:54 ` janus at gcc dot gnu dot org
2009-12-27 13:05 ` janus at gcc dot gnu dot org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu dot org @ 2009-12-27 12:54 UTC (permalink / raw)
To: gcc-bugs
------- 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 (nRead<3) then
goto 100
end if
!$omp end critical
100 nRead=4
end subroutine
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/42484] ICE with -fopenmp
2009-12-23 22:00 [Bug middle-end/42484] New: ICE with -fopenmp janus at gcc dot gnu dot org
` (6 preceding siblings ...)
2009-12-27 12:54 ` janus at gcc dot gnu dot org
@ 2009-12-27 13:05 ` janus at gcc dot gnu dot org
2009-12-27 15:57 ` janus at gcc dot gnu dot org
2009-12-28 21:41 ` janus at gcc dot gnu dot org
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu dot org @ 2009-12-27 13:05 UTC (permalink / raw)
To: gcc-bugs
------- 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, 1)) == GOTO_EXPR
&& TREE_CODE (GOTO_DESTINATION (TREE_OPERAND (expr, 1))) == LABEL_DECL
&& (DECL_CONTEXT (GOTO_DESTINATION (TREE_OPERAND (expr, 1)))
== current_function_decl)
/* For -O0 avoid this optimization if the COND_EXPR and GOTO_EXPR
have different locations, otherwise we end up with incorrect
location information on the branches. */
&& (optimize
|| !EXPR_HAS_LOCATION (expr)
|| !EXPR_HAS_LOCATION (TREE_OPERAND (expr, 1))
|| EXPR_LOCATION (expr) == EXPR_LOCATION (TREE_OPERAND (expr, 1))))
{
label_true = GOTO_DESTINATION (TREE_OPERAND (expr, 1));
have_then_clause_p = true;
}
Note that one only runs into this, if the locations of the IF condition and the
THEN clause are the same, which is the case for the simple IF in Fortran, but
not for IF...THEN...END IF statements. In C, the locations always seem to be
different, also for the simple one-lined case.
So, I guess the solution is to apply different locations to the simple IF
statement in Fortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/42484] ICE with -fopenmp
2009-12-23 22:00 [Bug middle-end/42484] New: ICE with -fopenmp janus at gcc dot gnu dot org
` (7 preceding siblings ...)
2009-12-27 13:05 ` janus at gcc dot gnu dot org
@ 2009-12-27 15:57 ` janus at gcc dot gnu dot org
2009-12-28 21:41 ` janus at gcc dot gnu dot org
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu dot org @ 2009-12-27 15:57 UTC (permalink / raw)
To: gcc-bugs
------- 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)
+++ gcc/fortran/trans.c (working copy)
@@ -1043,7 +1043,9 @@ void
gfc_set_backend_locus (locus * loc)
{
gfc_current_backend_file = loc->lb->file;
- input_location = loc->lb->location;
+ /* 'loc->lb->location' only gives the location of the start of the line,
+ so we add the column number here. */
+ input_location = loc->lb->location + loc->nextc - loc->lb->line;
}
Index: gcc/fortran/match.c
===================================================================
--- gcc/fortran/match.c (revision 155304)
+++ gcc/fortran/match.c (working copy)
@@ -1602,7 +1602,7 @@ got_match:
p = gfc_get_code ();
p->next = gfc_get_code ();
*p->next = new_st;
- p->next->loc = gfc_current_locus;
+ p->next->loc = old_loc2;
p->expr1 = expr;
p->op = EXEC_IF;
--
janus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-12-27 15:57:18
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/42484] ICE with -fopenmp
2009-12-23 22:00 [Bug middle-end/42484] New: ICE with -fopenmp janus at gcc dot gnu dot org
` (8 preceding siblings ...)
2009-12-27 15:57 ` janus at gcc dot gnu dot org
@ 2009-12-28 21:41 ` janus at gcc dot gnu dot org
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu dot org @ 2009-12-28 21:41 UTC (permalink / raw)
To: gcc-bugs
------- 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
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
^ permalink raw reply [flat|nested] 11+ messages in thread