http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47592
--- Comment #1 from paul.richard.thomas at gmail dot com <paul.richard.thomas
at gmail dot com> 2011-02-03 07:43:13 UTC ---
Hi Thomas,
I was aware of the potential for functions with side effects to screw
up ALLOCATE with source. I believe that one can persuade the same
thing to happen with array constructors, although I have not tried it.
> ig25@linux-fd1f:/tmp> gfortran foo.f90
> ig25@linux-fd1f:/tmp> ./a.out
> 12
>
> The output should be 11.
Could you post a PR on this, please?
> Paul, the cleanest way to resolve this would be to replace the call
> to gfc_copy_expr in your recent patch with a new function which
> goes something like this (incomplete and untested...)
>
> void gfc_freeze_expression (gfc_expr *oe, gfc_expr *ne, gfc_code **c)
> {
> if (oe->expr_type == EXPR_CONSTANT || oe->expr_type == EXPR_VARIABLE)
> {
> ne = gfc_copy_expr (oe);
> return;
> }
> /* Create a new variable with the same type as oe,
> create an assignment where oe is assigned to that
> variable and insert it before the current statement,
> then replace oe with that variable. */
> }
>
> This is a function that I've been meaning to write for the
> front end passes for some time...
We have tended to use EXPR_PARENTHESES to achieve the same thing. It
will not work here, however.
This gets dangerously close to something that I have had in mind for a
long time - to do scalarization in the front end. ***sigh*** I feel
like the White Rabbit in the opening scene in Alice in Wonderland!
Cheers
Paul
