This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
- From: "baldrick at free dot fr" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Mar 2007 16:06:20 -0000
- Subject: [Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
- References: <bug-26797-7210@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #27 from baldrick at free dot fr 2007-03-08 16:06 -------
Subject: Re: [4.3 regression] ACATS cxh1001 fails
> > y = __builtin_nop(x); valid = (y>=lower_bound && y <=upper_bound);
> > The point is that the intrinsic would be opaque to the optimizers,
> > and would only be lowered to the identity function *after* the tree
> > optimizers have run. One annoyance is that presumably intrinsics
> > would be needed for all integer and float precisions, eg
> > __builtin_nop8, __builtin_nop16, etc.
>
> More than each precision. The VIEW_CONVERT_EXPR is to the base type
> and there can be an unlimited number of them for each precision.
I don't see what the problem is - you don't have to convert to the base
type, you can always convert to some standard type of that precision,
eg int32, before calling the builtin.
> Because it has to work with arbitrary types, a builtin won't do it.
See above.
> We could certainly add a new tree expression that says "don't look through
> this for VRP purposes", but we already have V_C_E.
Sure, it's just that overloading V_C_E like this feels somehow wrong to me.
However I haven't been able to put my finger on any technical obstacle to
this use of V_C_E.
Ciao,
D.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797