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

[Roger Sayle <roger at eyesopen dot com>]

My recent patch to fix PR fortran/7388 corrected transformations on
COND_EXPR tree nodes that didn't preserve the noreturn semantics of
operands with void type.  Although this interpretation is described
both in tree.def and some of the routines in fold-const.c, its not
surprising that its not widely known, as it isn't mentioned at all
in the GCC internals documentation on COND_EXPR in c-tree.texi.

The following documentation patch corrects the situation.  It also
reduces the emphasis on GCC's extension to allow "x ? : 3", which
is a front-end feature and described in user documentation, and in
this internals documentation just explains that this syntactic sugar
should be expanded before it reaches GCC's middle-end.

Checked with "make dvi" on i686-pc-cygwin.

Ok for mainline?



2002-10-17  Roger Sayle  <roger@eyesopen.com>

	* doc/c-tree.texi: Update description of COND_EXPR tree nodes.


Index: c-tree.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/c-tree.texi,v
retrieving revision 1.35
diff -c -3 -p -r1.35 c-tree.texi
*** c-tree.texi	4 Sep 2002 17:35:58 -0000	1.35
--- c-tree.texi	16 Oct 2002 02:56:36 -0000
*************** These nodes represent @code{?:} expressi
*** 2127,2151 ****
  is of boolean or integral type.  If it evaluates to a nonzero value,
  the second operand should be evaluated, and returned as the value of the
  expression.  Otherwise, the third operand is evaluated, and returned as
! the value of the expression.  As a GNU extension, the middle operand of
! the @code{?:} operator may be omitted in the source, like this:

! @example
! x ? : 3
! @end example
! @noindent
! which is equivalent to

! @example
! x ? x : 3
! @end example
!
! @noindent
! assuming that @code{x} is an expression without side-effects.  However,
! in the case that the first operation causes side effects, the
! side-effects occur only once.  Consumers of the internal representation
! do not need to worry about this oddity; the second operand will be
! always be present in the internal representation.

  @item CALL_EXPR
  These nodes are used to represent calls to functions, including
--- 2127,2147 ----
  is of boolean or integral type.  If it evaluates to a nonzero value,
  the second operand should be evaluated, and returned as the value of the
  expression.  Otherwise, the third operand is evaluated, and returned as
! the value of the expression.

! The second operand must have the same type as the entire expression,
! unless it unconditionally throws an exception or calls a noreturn
! function, in which case it should have void type.  The same constraints
! apply to the third operand.  This allows array bounds checks to be
! represented conveniently as @code{(i >= 0 && i < 10) ? i : abort()}.

! As a GNU extension, the C language front-ends allow the second
! operand of the @code{?:} operator may be omitted in the source.
! For example, @code{x ? : 3} is equivalent to @code{x ? x : 3},
! assuming that @code{x} is an expression without side-effects.
! In the tree representation, however, the second operand is always
! present, possibly protected by @code{SAVE_EXPR} if the first
! argument does cause side-effects.

  @item CALL_EXPR
  These nodes are used to represent calls to functions, including


Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833