Re: Bison 3.0 updates

On 2013-07-29 08:44:56 -0400, Tom Lane wrote:
> Andres Freund <andres@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.

If I understand the optimization correctly what it does is building a
flow control model of a loop and concluding which its iterations can be
reached assuming standard conforming code. In this case, since it knows
(from looking at the underlying data structures) that the upper bound of
the iteration has to be 1 it decides to stop there. If oidvector had
values[2] it would make two iterations.

> 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.

Well, it seems to me like we don't have particularly good experience
with fixing compiler optimization issues by disabling some specific
optimization. They tend to crop up again under the umbrella of another
feature a compiler version or two later.

FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and
e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me
(After fixing trivial conflicts in the latter).
32 files changed, 98 insertions(+), 50 deletions(-)

> 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.

No, don't really want to spend more time on this. We'll see whether it
crops up again or not.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services