This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR fortran/12632: -fbounds-check ICE


On Tue, 30 Dec 2003, Richard Henderson wrote:
> On Sun, Dec 21, 2003 at 11:19:13PM -0700, Roger Sayle wrote:
> > 	PR fortran/12632
> > 	* fold-const.c (fold) <COND_EXPR>: Don't fold a constant condition,
> > 	if the type of the selected branch doesn't match its' parent.
>
> Ok.

Many thanks.

Unfortunately, the regression testers have picked up the failure of
two libstdc++-v3 tests, that for completely inexplicable reasons I must
have missed during my testing.  My apologies to all for the inconvenience.

23_containers/bitset/cons/1.cc
23_containers/bitset/test/1.cc

Both failures contain the error message below:

libstdc++-v3/include/bitset:839: error: non-constant
`( false ? 0u : 1u)' cannot be used as template argument


Clearly, either the g++ front-end itself or a related non-type-preserving
transformation/bug in the middle-end means that strict/exact type checking
is inappropriate.  One solution would be to compare TYPE_MAIN_VARIANT,
another would be to compare TYPE_MODEs.  But my preferred solution is for
the middle-end to avoid type checking issues whenever possible.  The patch
below is sufficient to both resolve PR fortran/12632 and fix the two
libstdc++-v3 failures.  The documentation of COND_EXPR explains that the
operand types match (without defining what "match" means) or have void
type.  Hence the fix below recognizes the acknowledged "void type"
exception,  and assumes that if an operand's type isn't void, it must be
a suitable replacement for its parent.

Fortran to the left of me, C++ to the right...

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.  I've left the
comment unchanged as it describes the "intent" of the modified code.

Ok for mainline?


Sorry again.  Very many thanks in advance,


2003-12-30  Roger Sayle  <roger@eyesopen.com>

	* fold-const.c (fold) <COND_EXPR>: Don't require strict type
	equality, instead just prevent replacing a COND_EXPR of non-void
	type by one of its operands of void type.


Index: fold-const.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.319
diff -c -3 -p -r1.319 fold-const.c
*** fold-const.c	29 Dec 2003 16:16:33 -0000	1.319
--- fold-const.c	30 Dec 2003 04:25:43 -0000
*************** fold (tree expr)
*** 7869,7875 ****
  	  /* Only optimize constant conditions when the selected branch
  	     has the same type as the COND_EXPR.  This avoids optimizing
  	     away "c ? x : throw", where the throw has a void type.  */
! 	  if (TREE_TYPE (tem) == TREE_TYPE (t))
  	    return pedantic_non_lvalue (tem);
  	  return t;
  	}
--- 7869,7876 ----
  	  /* Only optimize constant conditions when the selected branch
  	     has the same type as the COND_EXPR.  This avoids optimizing
  	     away "c ? x : throw", where the throw has a void type.  */
! 	  if (! VOID_TYPE_P (TREE_TYPE (tem))
! 	      || VOID_TYPE_P (TREE_TYPE (t)))
  	    return pedantic_non_lvalue (tem);
  	  return t;
  	}

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]