From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7553 invoked by alias); 8 Mar 2007 16:06:30 -0000 Received: (qmail 7490 invoked by alias); 8 Mar 2007 16:06:20 -0000 Date: Thu, 08 Mar 2007 16:06:00 -0000 Message-ID: <20070308160620.7489.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug ada/26797] [4.3 regression] ACATS cxh1001 fails In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "baldrick at free dot fr" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-03/txt/msg00601.txt.bz2 ------- 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