> > We can also patch in __builtin_unreachable but that will make bugs with > > out overflows/ out of bound accesses hard in loops to debug at -O levels > > (as seen by do-1.f90 testcase and the new PR with integer overflow), so > > perhaps we could do that at -Ofast or only or with > > -funsafe-loop-optimization or so even if it is standard conforming. I > > think friendly trap showing proper line number info is better. > > I'd prefer __builtin_unreachable ().
OK. I feel bit nervous about users being confused. But if you agree with the overall plan, I will realize it with __builtin_unreachable (). We will see what PRs appear and we can fall back into builtin_trap at any time later with an ease. Of course producing traps into -O3 code just for debugging is bit uncool. BTW I wonder why __builtin_trap, __builtin_abort and _exit are not declared CONST. Do we care about memory stores just prior trapping/aborting/forcingly exitting? I also wonder why optimizing of builtin_unreachable can not be part of fixup of noreturn calls in cfgcleanup. That would make it to be handled better in the cfgcleanups run in between cunroll iterations allowing possibly more cascaded urolling. > > > What do you think? > > Well, the issue is really that we exploit undefined behavior to > optimize (unroll in this case) and after that warn about undefined > behavior ... > > That said, the VRP code warning about array bound violations is > already quite weak (it requires the full value-range to be outside > of the array!) - in practice the warning isn't that great for > non-constant indices and for those we should warn during the first > VRP pass already. So one option is to simply disable array-bound > warnings in the late VRP pass. Or my original patch disabling it on all duplicated statements. I am sure with enough of plaing I can make testcase where the loop will be unrolled by cunrolli confusing the early VRP pass, too. It is just matter of introducing enough of IV based calculations that the cost model will consider constant. Honza
