On 07/15/2011 12:58 PM, Daniel Carrera wrote:
+ label_errmsg = gfc_build_label_decl (NULL_TREE);
+ label_finish = gfc_build_label_decl (NULL_TREE);
There seems to be a goto missing.
This is strange. The problem is definitely in the following if branch
in gfc_trans_array:
if (code->expr1 || code->expr2)
{
Side remark: One actually only needs to take care whether there is a
STAT=. If there is only an ERRMSG=, the code is unreachable as without
STAT= one gets a run-time error, when an error occurs - and if no error
occurs, ERRMSG= is not modified. Thus, one could reduce the code size by
checking only for code->expr1.
/* The coarray library already sets the errmsg. */
if (gfc_option.coarray == GFC_FCOARRAY_LIB
&& gfc_expr_attr (expr).codimension)
tmp = build1_v (GOTO_EXPR, label_finish);
else
tmp = build1_v (GOTO_EXPR, label_errmsg);
OK, I understand now why. It is a bit convoluted - and it is due to an
existing bug in GCC. All (allocatable) coarrays - including
(allocatable) scalar coarrays are arrays - and arrays are handled in
gfc_array_allocate.
The code to jump over the next items to the final or error label is only
checked in the "!gfc_array_allocate" loop.
Thus:
- The code for jumping to the label needs to be either in an "else"
branch or moved out of "if" branch.
- In the "if" branch, you can remove all coarray additions - and add a
gcc_assert() to make sure that indeed no coarray enters there.
Seemingly, the "if (stat !=0) goto ..." for arrays never worked - not
in GCC 4.1, 4.3, 4.4, 4.6 nor in 4.7.
Tobias
PS: Another bug I found when looking at this patch is PR 49775, it is
related to the code, but an independent issue. I think it will probably
better to place it into a different patch. I was wondering whether you
could/would/want to do it after this patch; it should be straight forward.