Re: [PATCH] Don't constant fold 1.0/0.0 at compile-time

[Roger Sayle <roger at eyesopen dot com>]

On Wed, 2 Jul 2003, Richard Henderson wrote:
> On Tue, Jul 01, 2003 at 02:12:22AM -0600, Roger Sayle wrote:
> > double dnan = 1.0/0.0 - 1.0/0.0;
> Ug.
>
> > Is there some mechanism that fold can use to determine whether we're
> > folding an initializer?
>
> No, but I think we can add one.  Probably not to fold directly, as
> that would touch too much code, but to a new sister function.

How about just a new lang_hook called static_initializer_p?  The front
ends then just set the required state as they start parsing a static
initializer, and clear it when they're done.  Alternatively, I don't
think its too ugly to use global_bindings_p for this.  At a conceptual
level, a static initializer has "global" scope/lifetime, and all of the
existing "fold" code would just work.  Indeed, it may fix some other
obscure bugs where we might try introducing SAVE_EXPRs into such
initializers.

My recommendation is that we proceed with my patch, which is a definite
improvement and fixes the glibc testsuite regressions and file a new PR
in bugzilla requesting the front-ends use global_bindings_p or a new
static_initializer_p or fold divisions by zero themselves if they want

void foo() { static double bar = 1.0/0.0; ... }

The middle-end can't safely fold this expression unless the front-ends
say that it is safe to do so, and the currrent situation where the
front-ends rely on fold to apply a potentially unsafe transformations in
order to determine which expressions are syntactically valid (without
such support) is completely broken.  For example, the C parser would
need to pass more state to build_binary_op as C99 states that the
interpretation of binary expressions in initializers is different to
that in code...

Certainly, pow is the innocent victim in all of this.

Roger
--