Daniel Berlin <[EMAIL PROTECTED]> writes: | On Fri, 2005-07-01 at 03:39 +0200, Gabriel Dos Reis wrote: | > Joe Buck <[EMAIL PROTECTED]> writes: | > | > | On Thu, Jun 30, 2005 at 09:02:48PM -0400, Andrew Pinski wrote: | > | > But the reason question is why make it an undefined behavior instead of | > | > an implementation defined? This would have made it clearer instead of | > | > allowing the compiler not document what happens. Or is C++ | > | > just following C here? In which case it might be better to ask the C | > | > committee why it was done this way and real definition of undefined for | > | > this case? | > | | > | I already showed you the answer: loop optimization works better if you | > | can ignore overflow. | > | > There are various ways to work within "loop optimization" assumptions. | | Gaby, if you have plans to do what nobody else has had any real luck | doing for 10 years in compilers in any practical way, which is proving | the iteration count of loops in the presence of overflow, please share.
As we have briefly discussed in mails, the most critical part of the issue seems to be what can be assumed for loop variables. I countend that for many if not most practical loops, the variable can be assumed not to overflow and apply the transformation. But we need not apply "undefined behaviour" to all other cases; only for those "well-written" loop and loop variables. In summary, if user's loop is well-written then he will benefit from the transformation. That will cover already a good set of common loops. There are of course coner and pathological cases, but I don't think we should worry too much about missing them. Let's first cover the structured loops, and address the contorsed ones later if they become really important. This is why I suggested earlier whether you'd be happy with letting user specify through a switch that his loops behave well. Some counter-examples were produced, but after some thoughts I think that if user specifies through switch that his loops behave well but write such deceiving codes then, well, he looses. -- Gaby
