On 06/30/2016 10:23 PM, Mikael Morin wrote:
> Le 30/06/2016 21:09, FX a écrit :
>> Here are my thoughts on the general approach and the patch:
>>
>>    1. It seems there is unanimous agreement (both here, in previous PRs and on comp.lang.fortran) that loops that reach HUGE(i) are invalid code. If one of the Fortran maintainers is against it, now is the time to speak :)
> 
> Well, in the case the value of the loop variable is not used after the loop, I would rather support it if possible and not too costly.
> In that case the overflow is completely hidden, and it is possible to produce code behaving as expected without overflowing.

Hello.

I agree with the approach that we should not introduce a new flag and rather convert current code emission to generate a better GENERIC code.

> 
>>
>>    2. If so, do we really need yet another option? I don’t disagree with it, but others might :)  Anyone in favor of simply using the faster loops all the time?
> 
> I'm on the same page here. No option please. Just let the compiler do its best.
> 
>>
>>    2b. Another warning? I would simply make it -W or -Wall.
> 
> I'm in favor of the warning flag. It makes it possible to enable/disable individually.

Agree with you that having a warning option would be beneficial.

> 
>>
>>    3. The warning is nice, but the text isn’t. First, because MAX_INT and MIN_INT will mean nothing to a Fortran coder. Can we use overflow/underflow instead? And second, because there is no reason for the loop to be infinite. Let’s just say it is invalid.

Sure, I've tried to change the warning to be more precise.

I'm attaching a second version:

467d46d Add PRED_FORTRAN_LOOP_PREHEADER to DO loops with step bigger than +-1.

1) I converted predict-[12].f90 tests to use a different step than 1
2) I noticed that a generic DO loop code emission misses expect PRED_FORTRAN_LOOP_PREHEADER, thus I added that.

221061a Optimize fortran loops with +-1 step.

1) -ffast-do-loops option is removed.
2) We generate just the c-style loop.
3) Warning messages are changes to: 'DO loop at %L is undefined as it overflows' and 'DO loop at %L is undefined as it underflows'
4) I removed couple of tests that hit the undefined behavior.
5) A few tests are amended as GENERIC code is a bit different.


>>
>>    4. Finally: profile, don’t speculate. Does this really make code generation easier? (and running code faster?)

I see a noticeable speed-up for exchange_2 benchmark which is going to be part of SPEC CPUv6. With the patch applied,
it runs by 6% faster.

Thank you for your feedback, I'm triggering proper testing and if there aren't any big problem, I'll send it to gcc-patches mailing list.

Martin

> 
> Agreed on both.
> 
> Mikael
> 
>