See also PR 32703; example found by Paul and compared with other compilers by Dominique and me.

I have a patch for this.  Unfortunately, while playing around with testcases I found a new segfault, so I'll have to look into this before submitting.

Failing testcase:
! { dg-do run }
! { dg-options "-fbounds-check" }
! { dg-shouldfail "Different CHARACTER lengths" }
! PR fortran/33254: No bounds checking for array constructors
program array_char
implicit none
character (len=2) :: x, y
character (len=2) :: z(2)
x = "a "
y = "cd"
z = [y(1:len(trim(y))), x(1:1)]  ! causes segfault
z = [trim(x),trim(y)] ! [ "a", "cd" ] ->INVALID: different string lengths
end program array_char

! { dg-output "Different CHARACTER lengths .2/1. in array constructor" }
! { dg-output "Different CHARACTER lengths .1/2. in array constructor" }

The failure from #2 is now PR 33727.

(In reply to comment #3)
> The failure from #2 is now PR 33727.

Tobi,

Why don't you fix them both at once? :-)

Cheers

Paul

After applying the patch and the one to PR33727 (thanks Paul!-), the first test fails at runtime:

At line 6 of file pr32703_1.f90
Fortran runtime error: Different CHARACTER lengths (1/2) in array constructor

but the following code

program array_char
implicit none
character (len=2) :: x, y
character (len=2) :: z(2)
x = "a "
y = "cd"
z = (/y(1:len(trim(y))), x(1:len(trim(x)))/)  ! causes segfault
print *, "'", z(1), "'  '", z(2), "'"
end program array_char

gives

[karma] f90/bug% gfc -fbounds-check pr33727_bad.f90
[karma] f90/bug% a.out 
 'cd'  'a'

I am expecting this test to fail at runtime and the other one. Am I missing something.

I have also noticed something strange with the following valid(?) code:

program array_char
implicit none
character (len=2) :: x, y
character (len=2) :: z(2)
x = "a "
y = "cd"
z = "  "
z = (/y(1:len(trim(x))), x(1:len(trim(x)))/)
print *, "'", z(1), "'  '", z(2), "'"
end program array_char

which gives

 'c'  'a'

while I am expecting

 'c '  'a '

Looks like another bug, should I fill a new PR?

Subject: Re:  Diagnose different string lengths in array
 constructors at run time

dominiq at lps dot ens dot fr wrote:
> program array_char
> implicit none
> character (len=2) :: x, y
> character (len=2) :: z(2)
> x = "a "
> y = "cd"
> z = (/y(1:len(trim(y))), x(1:len(trim(x)))/)  ! causes segfault
> print *, "'", z(1), "'  '", z(2), "'"
> end program array_char
> 
> gives
> 
> [karma] f90/bug% gfc -fbounds-check pr33727_bad.f90
> [karma] f90/bug% a.out 
>  'cd'  'a'
> 
> I am expecting this test to fail at runtime and the other one. Am I missing
> something.

This is weird, and can't really be (well, in a hypothetical world where 
only the bounds check goes wrong), as the whole array has only a single 
  string length, so I would expect it to either print two length one 
strings or two length two strings, not one lenghth one string and one 
length two string.

> 
> I have also noticed something strange with the following valid(?) code:
> 
> program array_char
> implicit none
> character (len=2) :: x, y
> character (len=2) :: z(2)
> x = "a "
> y = "cd"
> z = "  "
> z = (/y(1:len(trim(x))), x(1:len(trim(x)))/)
> print *, "'", z(1), "'  '", z(2), "'"
> end program array_char
> 
> which gives
> 
>  'c'  'a'
> 
> while I am expecting
> 
>  'c '  'a '
> 
> Looks like another bug, should I fill a new PR?

Yes.  This looks related to the previous one, again the string length 
seems to be taken from the wrong place.

Are these with or without Paul's patch?

> This is weird, and can't really be (well, in a hypothetical world where 
> only the bounds check goes wrong), as the whole array has only a single 
> string length, so I would expect it to either print two length one 
> strings or two length two strings, not one lenghth one string and one 
> length two string.

I am not sure to understand the above. Each element of z is a string of length 2,
y(1:len(trim(y))) is also of length 2, while x(1:len(trim(x))) is of length one,
so the constructor should give an error.

> Are these with or without Paul's patch?

with otherwise I got an ICE.

Subject: Re:  Diagnose different string lengths in array
 constructors at run time

dominiq at lps dot ens dot fr wrote:
> ------- Comment #7 from dominiq at lps dot ens dot fr  2007-10-11 12:34 -------
>> This is weird, and can't really be (well, in a hypothetical world where 
>> only the bounds check goes wrong), as the whole array has only a single 
>> string length, so I would expect it to either print two length one 
>> strings or two length two strings, not one lenghth one string and one 
>> length two string.
> 
> I am not sure to understand the above. Each element of z is a string of length
> 2,
> y(1:len(trim(y))) is also of length 2, while x(1:len(trim(x))) is of length
> one,
> so the constructor should give an error.

Yes, I agree with the latter.  What I menat is the following: after the 
data has been added to the array, the compiler should use the string 
length of the array, so if you do

CHARACTER*10 z
z = (/ something /)
print *, z

all printed strings should be length 10, no the contents of the constructor.

>> Are these with or without Paul's patch?
> 
> with otherwise I got an ICE.

ok, thanks.

Subject: Re:  Diagnose different string lengths in array
 constructors at run time

Tobias dot Schlueter at physik dot uni-muenchen dot de wrote:
> all printed strings should be length 10, no the contents of the constructor.
                                            ^^ read: independent of

> ... What I menat is the following: after the 
> data has been added to the array, the compiler should use the string 
> length of the array, ...

I agree, this is why I posted the second code with y(1:len(trim(x))),
because the result seems wrong to me. My question was "is this related to this PR or a different one?" If the answer is yes to the latter, then we probably need to open a new PR.

I'm adding Paul to the CC list, as perhaps he immediately knows what's happening (Paul, see comment #5).  Otherwise I will investigate tomorrow evening or Saturday.

Subject: Bug 33254

Author: tobi
Date: Sat Oct 13 21:43:49 2007
New Revision: 129286

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129286
Log:
2007-10-13  Tobias Schlueter  <tobi@gcc.gnu.org>
    Paul Thomas  <pault@gcc.gnu.org>

PR fortran/33254
PR fortran/33727
fortran/
* trans-array.c (get_array_ctor_var_strlen): Check upper bound for
constness instead of lower bound.
(get_array_ctor_strlen): Add bounds-checking code.
testsuite/
* bounds_check_10.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/bounds_check_10.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog

Fixed.

Now I understand the strange result I reported in comment #5. What is happening is that there is a second nonprintable character. If I redirect the output to a file I see it (in general ^@).

From what I understand of the code the substring x(1:len(trim(x))) is not computed correctly by:

          if (ref->u.ss.start->expr_type != EXPR_CONSTANT
              || ref->u.ss.end->expr_type != EXPR_CONSTANT)
            break;

probably not computed at all, as noticed by Tobias Schlüter in the patch in

http://gcc.gnu.org/ml/fortran/2007-10/msg00212.html

However get_array_ctor_all_strlen (block, expr, len); leads to ICE's. I assume that there is somewhere a piece of code able to compute the length of x(1:len(trim(x))), but I did not find it.

Subject: Re:  Diagnose different string lengths in array
 constructors at run time

dominiq at lps dot ens dot fr wrote:
> ------- Comment #14 from dominiq at lps dot ens dot fr  2007-10-21 20:05 -------
> Now I understand the strange result I reported in comment #5. What is happening
> is that there is a second nonprintable character. If I redirect the output to a
> file I see it (in general ^@).
> 
> From what I understand of the code the substring x(1:len(trim(x))) is not
> computed correctly by:
> 
>           if (ref->u.ss.start->expr_type != EXPR_CONSTANT
>               || ref->u.ss.end->expr_type != EXPR_CONSTANT)
>             break;
> 
> probably not computed at all, as noticed by Tobias Schlüter in the patch in
> 
> http://gcc.gnu.org/ml/fortran/2007-10/msg00212.html


The next iteration of the testcase will contain code that verifies that 
the string length actually gets calculated :-}

Re this testcase:
(In reply to comment #5)
> program array_char
> implicit none
> character (len=2) :: x, y
> character (len=2) :: z(2)
> x = "a "
> y = "cd"
> z = (/y(1:len(trim(y))), x(1:len(trim(x)))/)  ! causes segfault
> print *, "'", z(1), "'  '", z(2), "'"
> end program array_char

Changing z's length to, say, 5 shows that the strings are correctly padded, i.e. z(1) == "cd   " after the assignment, so there's only an issue with bounds-checking not working on this code, it doesn't expose another bug.  I've yet to figure out how to evaluate the string length, and only evaluate it once.  Dominique has correctly identified one of the crucial parts of the code in #14.  I hope I can look at this tomorrow night or Wednesday night.

(In reply to comment #11)
> I'm adding Paul to the CC list, as perhaps he immediately knows what's
> happening (Paul, see comment #5).  Otherwise I will investigate tomorrow
> evening or Saturday.

I'm pretty permanently on the road, at the moment, so I missed this. I'll try to take a look-see tonight, although I am trying to concentrate on getting the various FORALL bugs sorted.

Cheers

Paul