From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6067 invoked by alias); 12 Apr 2009 21:34:00 -0000 Received: (qmail 6048 invoked by uid 48); 12 Apr 2009 21:33:46 -0000 Date: Sun, 12 Apr 2009 21:34:00 -0000 Message-ID: <20090412213346.6047.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mikpe at it dot uu dot se" 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: 2009-04/txt/msg01066.txt.bz2 ------- Comment #4 from mikpe at it dot uu dot se 2009-04-12 21:33 ------- (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > There is no undefined behavior here (increment of a short value converts > > > to int, increments then converts back to short, none of which are > > > undefined), so at least the wrong code issue would be the same as bug > > > 35634. > > > > It's not undefined, but the conversion from int back to short provokes > > implementation-defined behaviour when the int value doesn't fit in a short. > > That makes this test program not strictly conforming. > > But converting from short to int for the argument to printf should behave as if > a short value was converted to int, i.e. the int value should be in range > -32768 to 32767, right? Usually but not here. Since you compiled with -fstrict-overflow (implicitly via -O2) the compiler can assume your short variables will have proper short values. As an optimisation the compiler could decide to store short variables in wider int variables and to perform short arithmetic using int arithmetic. Since you promised not to cause signed overflow those int variables would always be the proper sign-extension of the corresponding short variables. But your test program does cause signed overflow, so this optimisation changes behaviour. It's still not the compiler's fault. If you deliberately cause signed overflow, do not compile with -fstrict-overflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736