From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-20256-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6918 invoked by alias); 9 Jul 2002 08:46:03 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 6898 invoked by uid 71); 9 Jul 2002 08:46:02 -0000
Date: Tue, 09 Jul 2002 01:46:00 -0000
Message-ID: <20020709084602.6897.qmail@sources.redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
Subject: Re: optimization/7232: Incorrect code generate for volatiles
Reply-To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
X-SW-Source: 2002-07/txt/msg00258.txt.bz2
List-Id: <gcc-prs.sourceware.org>

The following reply was made to PR optimization/7232; it has been noted by GNATS.

From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: svlu@enea.se
Cc: gcc-gnats@gcc.gnu.org,karm@enea.se,steby@enea.se
Subject: Re: optimization/7232: Incorrect code generate for volatiles
Date: Tue, 09 Jul 2002 10:45:13 +0200

 At 23:29 08.07.2002, Sven Lundblad wrote:
 >Hi,
 >
 >Thanks for the fast response! The generated code is still incorrect. Note the
 >two lwz instructtions that loads from the same address (r11+8). Please see my
 >comments below (and please correct me if I'm wrong).
 >
 >Regards,
 >Sven Lundblad
 >
 >  .file   "test.c"
 >           .section        ".text"
 >           .align 2
 >           .type   force_gcc_ppc_bug,@function
 >  force_gcc_ppc_bug:
 >           lis 11,ll@ha     /* load address of ll into r11 high */
 >           li 0,4660
 >           la 11,ll@l(11)   /* load address of ll into r11 low */
 >           lwz 10,8(11)    /* load ll.rtFreeList into r10, should be
 >                                  ll.rtFreeList->next (the lnk variable) 
 > ??? */
 >           lwz 9,8(11)      /* load ll.rtFreeList into r9 */
 >           stw 0,0(10)     /* store 0x1234 into ll.rtFreeList->dummy WRONG! */
 >           mr 3,10          /* put ll.rtFreeList into r3 (but should be 
 > the lnk
 >                                  pointer) */
 >           lwz 0,4(9)       /* load ll.rtFreeList->next into r0 */
 >           li 9,0
 >           stw 0,8(11)     /* store ll.rtFreeList->next into ll.rtFreeList */
 >           li 0,18
 >           stw 9,4(10)
 >           stb 0,42(10)    /* store 0x12 into space outside allocated data! */
 >           blr
 >  .Lfe1:
 >           .size   force_gcc_ppc_bug,.Lfe1-force_gcc_ppc_bug
 >           .comm   ll,12,4
 >           .ident  "GCC: (GNU) 3.1.1 20020704 (prerelease)"
 
 Ah, now I understand your complaint, but this is not a compiler bug. If you 
 look at your code
 
 static
 a_link *force_gcc_ppc_bug(void)
 {
    FreeList *freeNode;
    a_link    *lnk;
 
     /* pop one node */
     freeNode = ll.rtFreeList;
     ll.rtFreeList = ll.rtFreeList->next;
     freeNode->next = 0;
 
     lnk    = (a_link *) freeNode;
     lnk->a = 0x1234;
     lnk->l = 0x12;
 
     return lnk;
 }
 
 and check against the aliasing rules in the C standard, you'll notice that 
 you violate these rules thus invoking undefined behaviour. According to the 
 C standard, the compiler can assume that lnk and FreeNode point to 2 
 _distinct_ objects and optimizes accordingly.
 Either fixup your code or use -fno-strict-aliasing to turn off this 
 optimization at the price of slower code.
 
 I'll close the bug report.
 
 Franz.