Re: [patch, libfortran] [4.7/4.8/4.9 Regression] PR38199 missed optimization: I/O performance

[Jerry DeLisle <jvdelisle at charter dot net>]

On 03/08/2014 02:45 AM, Tobias Burnus wrote:
--- snip ---
> 
> I think that code is okay.
> 
> I wonder whether it can happen that we read one character too far: i.e. stell()
> == end of string; offset++ -> one behind. As one then immediately steps back
> (due to "offset < limit" plus offset--), the code should be handled just fine -
> except for the out of bounds read - which might be detected by, e.g.,
> -fsanitizer=address (if libgfortran and the program use it). However, I am not
> sure whether eat_spaces would be called in that case or whether other conditions
> error out before.
>

The strings are internally NULL terminated, which helps. I will do some tests to
see.

>> I also remove some unneeded error checks.
> 
> I have to admit that I do not really understand why the conditions are
> unreachable. Is it because "dtp->u.p.current_unit->bytes_left == 0" is already
> checked for "is_array_io (dtp)"? If so, can it happen for scalar internal I/O? I
> assume, it is obvious, but I don't quickly see it.

The is_array_io (dtp) is checking for an array descriptor. For scalar internal
I/O the descriptor is a NULL, so the new code is not executed in that case.  I
ran a test using a scalar string and the new code is not needed.

The errors given are not normal error conditions.  If we hit these errors there
is a internal library bug and the program would fail out. Since we have had none
reported ever I don't think we need it.  As Steven suggested I can make them
unlikely.

Also I just realized I did not address the kind=4 case, so I will do that and
resubmit.


Thanks for review.

Jerry