This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] 2 patches for PR tree-optimization/34648
On Jan 17, 2008 1:41 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
>
> > I disagree, unless we also abort if you have it without nothrow.
> > No side-effects means no side-effects. Exceptions are clearly are side-effect
> > I really don't think we should get into the business of trying to
> > figure out what it means to have a no-side-effect functions that can
> > throw.
>
> I'd let the Ada guys sort that out, but apparently it already works
> correctly for them.
Only because they are relying on semantics that we document const as
not having, but have never really enforced.
As Andrew says, it breaks with his change because they assume const
functions can throw.
I have no problem with separating our different side-effects (and in
fact i encourage it). I do have a problem with allowing what i
believe to be conflicting sets of side-effects.
>
> It should be easy to determine which side effects (memory vs.
> control-flow) impede which transformation.
Control flow side-effects always impede a transformation. This is in
fact, the reason we are having this discussion
Can you please give an example transformation where it is safe to
ignore control-flow side-effects?
I'd be fine with DECL_DOESNT_READ_MEMORY && TREE_NOTHROW
but to me, DECL_IS_CONST already implies TREE_NOTHROW, and not having
TREE_NOTHROW should be illegal.