This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Update COND_EXPR section of c-tree.texi
- From: Roger Sayle <roger at eyesopen dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Nathan Sidwell <nathan at codesourcery dot com>, Richard Henderson <rth at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 21 Oct 2002 08:26:36 -0600 (MDT)
- Subject: Re: [PATCH] Update COND_EXPR section of c-tree.texi
> >> 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?
>
> I've missed some of this thread, but I'm not really sure why "void" is
> not a reasonable choice for arms of conditionals that are guaranteed to
> throw exceptions and/or not return.
Hi Mark,
Not surprising, this thread is actually the review of the following
patch: http://gcc.gnu.org/ml/gcc-patches/2002-10/msg00873.html
"PR fortran/7388: VOID_TYPE_P in COND_EXPRs"
Shortly after this patch, which fixes constant folding of ?: in
the presence of children with void type and modifies g77 to use
this extension, I noticed the void type semantics of COND_EXPR
weren't documented hence the current thread. The documentation
patch was approved, but whether these semantics are actually
needed is still in doubt.
I'd also appreciate it if someone could approve Nathan's patch in
this area, http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01120.html,
which fixes PR c++/7209. I suspect that there are more bugs here,
but I'm cautious to continue looking for an alternate solution to
PR fortran/7388, until the related fixes are in the tree. We certainly
still need to fix "(abort(), 0)" irrespective of the void types in
COND_EXPR outcome.
Roger
--