Re: incorrect result with this_image() inside an array constructor

[Tobias Burnus <burnus at net-b dot de>]

Hi Damian, hi all,

(I know that I am badly lagging behind my GCC/gfortran emails do to a 
lack of time due to work and other non-GCC spare time activities.)

Damian Rouson wrote:
> Iâm trying to sort out whether behavior that Arjen Markus reported on the OpenCoarrays mailing list is a front-end bug or a library bug.   A slightly edited version of his code is below.
>
> On the one hand, I think this might be a gfortran front-end problem because simply storing the result of this_image() in an integer variable eliminates the problem.  On the other hand, it might be a library problem because the problem occurs when linking to libcaf_mpi.a, but not when linking to libcaf_single.a.

Looking at your example, you seem to mix up two options:
  -fcoarray=single
simply replaces all calls to this_image() by "1" early in the compilation.

To actually insert calls to libcaf_single, you need to compile with
  -fcoarray=lib
as you would do for libcaf_mpi. And -fcoarray=lib -lcaf_single shows the 
wrong result.

The big question is why the generated code (-fdump-tree-original) contains:
   static real(kind=4) A.2[1] = {0.0}

namely: There is no call to the library's this_image function but it is 
already at compile time 0.

Digging slightly deeper, at some point one has:

6292              if (gfc_is_constant_expr (e) || gfc_is_expandable_expr 
(e))

where at some point the call to "gfc_is_constant_expr(e)" returns true - 
but "this_image() * i" isn't constant. Later at expand_constructor, the 
gfc_constructor_first (base) returns NULL.


The problem seems to be that in gfc_is_constant_expr, the  code to check 
intrinsics triggers:

942           if (e->value.function.isym
943               && (e->value.function.isym->elemental
944                   || e->value.function.isym->pure
945                   || e->value.function.isym->inquiry
946                   || e->value.function.isym->transformational))
947             return 1;

this_image() is transformational - and the arguments are constant. 
Hence, the code triggers. I wonder whether one needs a special case for 
this_image and other coarray procedures of this kind. Or whether the 
check is bogus by itself as we can simplify expressions at compile time. 
If that's done, the expression either does not contain an intrinsic 
function or it does but then we do not have a constant any more.

Maybe the check is also okay - and only the later usage is wrong: For 
the constructor, we expand the expression value by value - including 
replacing the "j" by an actual value. Thus, the gfc_is_const_expr check 
is special for array constructors with do-loop-list (or however they are 
called) as for those the const check has to handle the do-loop variables 
which are replaced later on by real values.

Thus, I can confirm the compiler bug on debugger-step-through level.

Tobias