------- 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
