From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20412 invoked by alias); 25 Mar 2012 05:13:32 -0000 Received: (qmail 20403 invoked by uid 22791); 25 Mar 2012 05:13:30 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_CP X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 25 Mar 2012 05:13:17 +0000 From: "pinskia at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/52705] Loop optimization failure with -O2 versus -O1 Date: Sun, 25 Mar 2012 05:50:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: pinskia at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2012-03/txt/msg02153.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52705 --- Comment #1 from pinskia at gmail dot com 2012-03-25 05:12:44 UTC --- You are volating c/c++ aliasing rules. Use memcpy or -fno-strict-aliasing . Sent from my Palm Pre on AT&T On Mar 24, 2012 21:27, veiokej at gmail dot com <gcc-bugzilla@gcc.gnu.org> wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52705 Bug #: 52705 Summary: Loop optimization failure with -O2 versus -O1 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned@gcc.gnu.org ReportedBy: veiokej@gmail.com Created attachment 26976 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26976 Intermediate of bug.c When I compile with these different optimization levels, I get different output. This isn't confusion over floats or uninitialized variables, as far as I can tell. It appears to relate to casted memory accesses. First of all, this relates to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49938, which _might_ solve the problem (but I don't know, because I'm unable to upgrade from 4.6.1 under MinGW). So please try the latest GCC before you try to debug this. Here's the command line: gcc -save-temps -O2 -obug.exe bug.c This bug is very easy to reproduce. Here's the entire source of bug.c: ---------------------------------------------------- #include <stdint.h> #include <stdio.h> void func(uint32_t a[8],uint32_t b[8]){ uint32_t i; uint32_t c; int64_t d; for(i=0;i<=1;i++){ ((uint64_t *)(b))[0]=((uint64_t *)(a))[0]; ((uint64_t *)(b))[1]=((uint64_t *)(a))[0]; ((uint64_t *)(b))[2]=((uint64_t *)(a))[0]; ((uint64_t *)(b))[3]=((uint64_t *)(a))[0]; c=1; d=b[0]; d-=c; b[0]=d; c=b[0]; d=b[1]; d-=c<<1; b[1]=d; } return; } int main(int argc, char *argv[]){ uint32_t a[8]={1,0,0,0,0,0,0,0}; uint32_t b[8]; func(a,b); printf("%08X%08X%08X%08X%08X%08X%08X%08X\n",b[0],b[1],b[2],b[3],b[4],b[5],b[6],b[7]); return 0; } ---------------------------------------------------- As you will see, you get different outputs depending on whether you use -O1 or -O2. The relation to Bug 49930 is this: Look at the above code. If you change: ---------------------------------------------------- d=b[1]; d-=c<<1; b[1]=d; ---------------------------------------------------- to: ---------------------------------------------------- d=b[0]; d-=c<<1; b[0]=d; ---------------------------------------------------- Then you will see bug 49930. Note that b[] appears to be only half-initialized because I only write to subscripts 0 through 3. But that's not the case, because I've casted 8 32-bit integers to 4 64-bit integers. I notice that when I change the lines involving (uint64_t *) casts to normal (uint32_t *) memory accesses, i.e. when I get rid of the casts, it seems to work better (but didn't investigate at length). But I don't want to do that for performance reasons. (bug.c is just an adaptation that's filtered from a "real" function where performance matters.)