[Bug fortran/55501] [F03] ICE using MERGE in constant expr

["janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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 ?