From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24537 invoked by alias); 15 Apr 2008 08:59:05 -0000 Received: (qmail 24322 invoked by alias); 15 Apr 2008 08:58:21 -0000 Date: Tue, 15 Apr 2008 08:59:00 -0000 Message-ID: <20080415085821.24321.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenther at suse dot de" 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: 2008-04/txt/msg01040.txt.bz2 ------- Comment #11 from rguenther at suse dot de 2008-04-15 08:58 ------- Subject: Re: [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution On Tue, 15 Apr 2008, ghazi at gcc dot gnu dot org wrote: > > > ------- Comment #10 from ghazi at gcc dot gnu dot org 2008-04-15 01:36 ------- > (In reply to comment #8) > > I propose that we do the following: > > - add a warning to the C/C++ frontends that isinf (x) CMP isinf (y) is > > only well-defined for !isinf (x) && !isinf (y). > > this doesn't result in a runtime penalty and informs people about the possible > > problem in their code (it is non-portable). > > IMHO the above warning would have limited coverage because there are other ways > users can test the results of isinf that would run into the sign problem. Well, of course. > > A different workaround would be to canonicalize the return value of isinf to > > bool. > > Doesn't this change the interface defined by c99? Yes, we would need to hide that fact and always add promotion code to int via isinf() != 0. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35509