> I am. I just now looked and found another example. > gcc-4.3-20061223/gcc/fold-const.c's neg_double function > contains this line: > > *hv = - h1;
OK, granted. But it is followed by code testing for overflow. That means that (1) we can find these by looking for cases where we are setting an overflow indication and (2) that the heuristic of preserving tests for overflow will be sufficient to deal with these kinds of cases. > This may be the policy of the GCC developers for the code they > maintain, but it's not a realistic policy for everybody, and GCC > shouldn't insist on it, or even recommend it, for everybody. I > certainly can't assume it for the code I help maintain, as the > minimal GCC standard is far too restrictive. I continue to feel that it is reasonable for a compiler for a programming language to require that its input be a valid program in that language. > Sure, but right now the position of many GCC developers seems to be > that code like this is "broken" and that its authors should find and > rewrite it. I don't think this is realistic. Even GCC itself seems > to have trouble implementing this policy well. I can't speak for any other GCC developer, but I personally am quite comfortable viewing any code that assumes wrapping semantics as broken and needing fixing with the exception of these cases of checking for overflow: there simply is no good way in C to do these checks in a portable manner and, as I said, I think we should make sure they continue to work and maybe even document that. But also note that my position also is that we, as much as possible, should allow these "broken" legacy codes to continue to work properly despite that feeling, unless we have a specific case (such as the loop cases) where the benefits of losing the optimization are quite high and the likelihood that we'll break code is very low.
