Re: [patch, libgfortran] PR53029 missed optimization in internal read (without implied-do-loop)

2017-05-29 Thread Jerry DeLisle
On 05/29/2017 09:51 AM, Thomas Koenig wrote: Hi Jerry, Regression tested on x86_64. I have added a test case which will check the execution time of the loop. The previous results of the REAd were correct, just took a long time on large arrays. OK for trunk? OK. It might be good if you fol

Re: [patch, libgfortran] PR53029 missed optimization in internal read (without implied-do-loop)

2017-05-29 Thread Thomas Koenig
Hi Jerry, Regression tested on x86_64. I have added a test case which will check the execution time of the loop. The previous results of the REAd were correct, just took a long time on large arrays. OK for trunk? OK. It might be good if you followed Manfred's suggestion and turned down the

Re: [patch, libgfortran] PR53029 missed optimization in internal read (without implied-do-loop)

2017-05-29 Thread Manfred Schwarb
Am 29.05.2017 um 01:16 schrieb Jerry DeLisle: > Hi all, > > The problem here is that we never set the err return to LIBERROR_END in all > cases. For the example case we are detecting the EOF condition inside the > read_integer procedure and it gets acted on correctly at higher levels in the > c

[patch, libgfortran] PR53029 missed optimization in internal read (without implied-do-loop)

2017-05-28 Thread Jerry DeLisle
Hi all, The problem here is that we never set the err return to LIBERROR_END in all cases. For the example case we are detecting the EOF condition inside the read_integer procedure and it gets acted on correctly at higher levels in the code. Consequently in the big loop over the array where we