http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
--- Comment #10 from janus at gcc dot gnu.org 2012-11-28 12:16:59 UTC ---
(In reply to comment #9)
> (In reply to comment #7)
> > - if (tsource->expr_type != EXPR_CONSTANT
> > - || fsource->expr_type != EXPR_CONSTANT
> > - || mask->expr_type != EXPR_CONSTANT)
> > + if (mask->expr_type != EXPR_CONSTANT)
> > return NULL;
>
> That makes sense: If mask is a constant scalar, tsource or fsource can be
> used.
> That patch is pre-approved.
Unfortunately, it triggers a couple of testsuite regressions:
FAIL: gfortran.dg/bound_2.f90 -O0 execution test
FAIL: gfortran.dg/bound_7.f90 -O0 execution test
FAIL: gfortran.dg/char_cast_1.f90 -O scan-tree-dump-times original
"6\\]\\[1\\]" 2
FAIL: gfortran.dg/merge_char_3.f90 -O0 execution test
The last one is understandable: It is supposed to check for different char
lengths beings passed to MERGE at runtime, but the call to MERGE is simplified
away (which is good!).
The third one is a tree-dump failure, where apparently the dump is different
because MERGE is simplified away now.
The first two are runtime checks, which are basically identical. Here is a
reduced test case for these:
implicit none
integer :: i(-1:1) = 0
print *, lbound(merge(i,i,.true.))
print *, ubound(merge(i,i,.true.))
end
Without the patch, this prints:
1
3
And with the patch:
-1
1
The output with the patch does look more reasonable to me. Or is there any
reason why the standard would demand the MERGE expression to have bounds of 1:3
instead of -1:1 ?
