Re: [PATCH] Update COND_EXPR section of c-tree.texi

[Roger Sayle <roger at eyesopen dot com>]

> Richard Henderson wrote:
> > Is this really necessary?  As a front-end thing, maybe, but it
> > would seem that the best way to handle this is to use
> >
> > 	(i >= 0 ? i : (abort(), 0))
> FE's must canonicalize 'cond ?: false' after all ...

The patch that introduced these semantics (without documentation) was:
http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01075.html

2001-02-17  Mark Mitchell  <mark@codesourcery.com>

        * fold-const.c (fold_binary_op_with_conditional_arg): New
        function, split out from ...
        (fold): ... here.
        * tree.def (COND_EXPR): Document the use of VOID_TYPE for
        conditional arms that throw exceptions.

which resolved PR c++/218.  In all fairness to Mark for adding this
functionality, has anyone actually tested whether Richards suggested
idiom "(i>=0 ? i : (abort(), 0))" currently works?

Note that the current situation in the g77 front-end is that s_rng in
libF77 already has the appropriate return type, and the middle-end is
still managing to corrupt uses of "((i>=0) && (i<10)? i : s_rng())",
when s_rng is marked no return.  Obviously the compound expression alone
isn't going to solve the problem.

Perhaps once Nathan's patch is approved (which should improve things)
we can consider alternate solutions for PR c++/218 and PR fortran/7388,
and revert some of the above patch.

It should also be noted that the VOID_EXPR solution allows GCC to
generate less and more efficient RTL, by eliminating dead code
earlier, and avoiding SAVE_EXPRs where no longer required.  I'll
check to see if we have noreturn predicates that'll permit these
savings with compound (and other) expressions.

(i>=0 ? i : (abort(),0)) + c need not become (i>=0 ? i+c : (abort(),c))
for arbitrarily complex c, and s_rng()+c should be folded to s_rng().
Indeed "(noreturn(),x)" could become "(typeof(x))noreturn()", so in
our example above (int)abort().

I'll see what I can come up with.

Roger
--