This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR fortran/12632: -fbounds-check ICE
- From: Roger Sayle <roger at eyesopen dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 30 Dec 2003 07:14:11 -0700 (MST)
- Subject: 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