From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5163 invoked by alias); 28 May 2008 12:58:37 -0000 Received: (qmail 4264 invoked by alias); 28 May 2008 12:57:53 -0000 Date: Wed, 28 May 2008 12:58:00 -0000 Message-ID: <20080528125753.4262.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/36300] Incorrect type used for inlined expression 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-05/txt/msg02076.txt.bz2 ------- Comment #15 from rguenther at suse dot de 2008-05-28 12:57 ------- Subject: Re: Incorrect type used for inlined expression On Wed, 28 May 2008, acarmeli at mathworks dot com wrote: > ------- Comment #14 from acarmeli at mathworks dot com 2008-05-28 12:25 ------- > You are correct. But step 6 did not reveal that, and provided a correct s64 > result. This result should have been carried over to step 7 to lead to a > correct result. Well, step 6 has a "correct" result by luck - the undefinedness doesn't expose an optimization opportunity. In step 7 the result from step 6 is not used, but instead its expression is inserted and the intermediate result from step 6 is unused (and so is combined with the added expression, exploiting the undefined behavior for a transformation the folding code thinks is worthwhile). > Otherwise, it will not be possible to get the result through a folded > expression. The code invokes undefined behavior if the expression in step 5 overflows. Undefined behavior can be also strange and "inconsistent" behavior as you see in your testcase. > It seems to me that adding more to the expression changes the optimization to > inner expressions in a way that compromizes the numerical stability. Yep. The folding code is run early and sees the whole C expression. Obviously this exploits more "interesting" opportunities to mangle the expressions. > We also tried masking to eliminate unwanted bits. The masks seem to have no > effect and we suspect they get optimized out. It was an unfavorable solution > anyway, due to the cost of the mask. > > In effect, there is no reliable way to grow a folded expression and > consistently preserve the result of inner expressions. The only solution we > have is temporary variables, which might get optimized out and folded as well. True. The only reliable way is to only write (partial) expressions that do not invoke undefined behavior in any case ;) This can be either done by carefully doing operations that may overflow in unsigned arithmetic or by providing -fwrapv as a compiler option. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300