This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] Document and correct ABS_EXPR usage (take 2)
- From: Roger Sayle <roger at eyesopen dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Sat, 9 Aug 2003 13:12:22 -0600 (MDT)
- Subject: [PATCH] Document and correct ABS_EXPR usage (take 2)
The following patch is a resubmission of my patch from 2nd June:
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00105.html
It documents the ABS_EXPR tree node. Importantly it also clears
up a misconception that an ABS_EXPR tree node with a complex
type can be used to implement cabs, or modulus of a complex number.
The reason should be obvious; one of the fundamental invariants
of GCC's tree representations is that TREE_TYPE(expr) denotes the
type of the expression expr. The result type of a complex abs
operation isn't a complex value, its a floating point type. Hence
the ABS_EXPR could/should never have a complex type and current
code that checks for this is completely bogus.
To prevent future generations from making the same mistake as I did,
trying to use ABS_EXPR to implement cabs, cabsf and cabsl builtins:
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00103.html
this patch documents the ABS_EXPR tree node for the first time (he
who writes the documentation gets to define the semantics :), and
replaces the particularly misleading code fragment in expand_expr
with an abort.
This change doesn't preclude adding a CABS_EXPR tree node in future,
it just that we can't safely or unambiguously reuse the existing
scalar ABS_EXPR node.
The following patch has been tested on i686-pc-linux-gnu with a full
"make bootstrap", all languages except treelang, and regression tested
with a top-level "make -k check" with no new failures.
2003-08-09 Roger Sayle <roger@eyesopen.com>
* expr.c (expand_expr): If an ABS_EXPR has a complex type, abort.
* c-typeck.c (build_unary_op): COMPLEX_TYPE is not a valid
typecode for an ABS_EXPR.
* doc/c-tree.texi: Document ABS_EXPR.
Index: expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.575
diff -c -3 -p -r1.575 expr.c
*** expr.c 1 Aug 2003 00:37:39 -0000 1.575
--- expr.c 9 Aug 2003 13:04:14 -0000
*************** expand_expr (tree exp, rtx target, enum
*** 8475,8484 ****
if (modifier == EXPAND_STACK_PARM)
target = 0;
! /* Handle complex values specially. */
if (GET_MODE_CLASS (mode) == MODE_COMPLEX_INT
|| GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
! return expand_complex_abs (mode, op0, target, unsignedp);
/* Unsigned abs is simply the operand. Testing here means we don't
risk generating incorrect code below. */
--- 8475,8484 ----
if (modifier == EXPAND_STACK_PARM)
target = 0;
! /* ABS_EXPR is not valid for complex arguments. */
if (GET_MODE_CLASS (mode) == MODE_COMPLEX_INT
|| GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
! abort ();
/* Unsigned abs is simply the operand. Testing here means we don't
risk generating incorrect code below. */
Index: c-typeck.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-typeck.c,v
retrieving revision 1.250
diff -c -3 -p -r1.250 c-typeck.c
*** c-typeck.c 24 Jul 2003 08:58:37 -0000 1.250
--- c-typeck.c 9 Aug 2003 13:04:15 -0000
*************** build_unary_op (enum tree_code code, tre
*** 2152,2159 ****
break;
case ABS_EXPR:
! if (!(typecode == INTEGER_TYPE || typecode == REAL_TYPE
! || typecode == COMPLEX_TYPE))
{
error ("wrong type argument to abs");
return error_mark_node;
--- 2152,2158 ----
break;
case ABS_EXPR:
! if (!(typecode == INTEGER_TYPE || typecode == REAL_TYPE))
{
error ("wrong type argument to abs");
return error_mark_node;
Index: doc/c-tree.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/c-tree.texi,v
retrieving revision 1.44
diff -c -3 -p -r1.44 c-tree.texi
*** doc/c-tree.texi 31 Jul 2003 01:32:24 -0000 1.44
--- doc/c-tree.texi 9 Aug 2003 13:04:15 -0000
*************** This macro returns the attributes on the
*** 1720,1725 ****
--- 1720,1726 ----
@findex PTRMEM_CST_MEMBER
@tindex VAR_DECL
@tindex NEGATE_EXPR
+ @tindex ABS_EXPR
@tindex BIT_NOT_EXPR
@tindex TRUTH_NOT_EXPR
@tindex ADDR_EXPR
*************** determined by looking at the type of the
*** 1914,1919 ****
--- 1915,1934 ----
The behavior of this operation on signed arithmetic overflow is
controlled by the @code{flag_wrapv} and @code{flag_trapv} variables.
+
+ @item ABS_EXPR
+ These nodes represent the absolute value of the single operand, for
+ both integer and floating-point types. This is typically used to
+ implement the @code{abs}, @code{labs} and @code{llabs} builtins for
+ integer types, and the @code{fabs}, @code{fabsf} and @code{fabsl}
+ builtins for floating point types. The type of abs operation can
+ be determined by looking at the type of the expression.
+
+ This node is not used for complex types. To represent the modulus
+ or complex abs of a complex value, use the @code{BUILT_IN_CABS},
+ @code{BUILT_IN_CABSF} or @code{BUILT_IN_CABSL} builtins, as used
+ to implement the C99 @code{cabs}, @code{cabsf} and @code{cabsl}
+ built-in functions.
@item BIT_NOT_EXPR
These nodes represent bitwise complement, and will always have integral
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