Andres Freund <and...@2ndquadrant.com> writes:
> On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
>> I'm not excited about breaking code in order to fix optimization bugs
>> that are purely hypothetical (and for which there's no particular reason
>> to believe that the proposed change would fix them anyway). If we were
>> seeing such things in the field it would be a different story.
> Well, given the problems we're discussing here, it's not all that
> hypothetical. Obviously the compiler *does* have information it believes
> to proof some code to be unreachable.
The known case here has nothing to do with unreachability IMO; it has
to do with concluding that a loop can be unrolled into exactly one
execution. But in any case, there is no point in arguing about what
hypothetical versions of gcc might do in hypothetical cases. We have
experimental evidence that -fno-aggressive-loop-optimizations fixes the
observed problem with gcc 4.8.0. So we can apply a one-line patch that
fixes the observed problem and seems 100% safe, or we can apply a very
large patch that might possibly fix problems that we don't know exist,
and might also break third-party code. Given the available evidence
the choice seems pretty clear to me. If you want to provide concrete
proof that there are additional optimization hazards then that would
change the tradeoff.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
