From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13243 invoked by alias); 7 May 2003 16:06:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 13191 invoked by uid 71); 7 May 2003 16:06:01 -0000 Resent-Date: 7 May 2003 16:06:01 -0000 Resent-Message-ID: <20030507160601.13190.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, Toni.Kettula@hut.fi Received: (qmail 8995 invoked by uid 48); 7 May 2003 16:00:01 -0000 Message-Id: <20030507160001.8994.qmail@sources.redhat.com> Date: Wed, 07 May 2003 16:06:00 -0000 From: Toni.Kettula@hut.fi Reply-To: Toni.Kettula@hut.fi To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: target/10664: GCC incorrectly reorders loads and stores for a powerpc-unknown-eabi target when optimizing X-SW-Source: 2003-05/txt/msg00479.txt.bz2 List-Id: >Number: 10664 >Category: target >Synopsis: GCC incorrectly reorders loads and stores for a powerpc-unknown-eabi target when optimizing >Confidential: no >Severity: critical >Priority: medium >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Wed May 07 16:06:00 UTC 2003 >Closed-Date: >Last-Modified: >Originator: Toni.Kettula@hut.fi >Release: 3.2.3 >Organization: >Environment: Output of "powerpc-unknown-eabi-gcc -v": --- Reading specs from /usr/local/xgcc/3.2.3/lib/gcc-lib/powerpc-unknown-eabi/3.2.3/specs Configured with: /root/software/installed/gcc-3.2.3/configure --target=powerpc-unknown-eabi --prefix=/usr/local/xgcc/3.2.3 --program-prefix=ppc-unknown-eabi- Thread model: single gcc version 3.2.3 >Description: GCC targeted for powerpc-unknown-eabi produces incorrect code when the attached small source code file is compiled with the command line "powerpc-unknown-eabi-gcc -S -Wall -O3 bug.c -o bug.s". GCC compiles the source without any error or warning messages. The issue concerns the assembler output corresponding to the first two statements of the following function. The function is here for illustration purposes, complete source is in the attachment. void FreeMsg(void ** ppMsg) { msgBufHd_t * pMsgHd; /* Get the message pointer and clear the user variable */ pMsgHd = *((msgBufHd_t **) ppMsg); *ppMsg = 0; /* Step back to see the private header */ pMsgHd--; /* Must have been freed by the owner */ if (pMsgHd->owner != CurrentThread()) { panic(); } } With optimization setting -O3, GCC incorrectly reorders the assignment (stw) before reading the previous value (lwz): FreeMsg: stwu 1,-24(1) mflr 6 li 5,0 stw 6,28(1) stw 5,0(3) <-- *ppMsg = 0 lwz 4,0(3) <-- Read *ppMsg => TOO LATE stw 29,12(1) addi 29,4,-4 bl CurrentThread ... The same problem can be seen when optimizing with -O2. Reducing optimization to -O1 or not optimizing at all solves the problem: FreeMsg: stwu 1,-24(1) mflr 0 stw 29,12(1) stw 0,28(1) lwz 29,0(3) <-- Read *ppMsg li 0,0 stw 0,0(3) <-- *ppMsg = 0 ... The problem seems to be very sensitive to the contents of the function and comes and goes when you make small and seemingly insignificant changes to the function. >How-To-Repeat: Compile the attached file bug.c with gcc targeted for powerpc-unknown-eabi using the following command line: "powerpc-unknown-eabi-gcc -S -Wall -O3 bug.c -o bug.s". Examining the assembler code reveals the problem. >Fix: A specific instance of the problem can theoretically be worked around by examing the assembler output and changing the C code slightly until the problem goes away. This, however, is obviously infeasible for anything but an extremely short single file project. Hence the suggested severity "critical". >Release-Note: >Audit-Trail: >Unformatted: ----gnatsweb-attachment---- Content-Type: application/octet-stream; name="bug.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bug.c" LyoKICogQSBkZW1vbnN0cmF0aW9uIG9mIHRoZSBHQ0MgYnVnIGRpc2NvdmVyZWQgd2l0aCB0aGUg dGFyZ2V0CiAqIHBvd2VycGMtdW5rbm93bi1lYWJpCiAqCiAqIENvbXBpbGVkIHdpdGggY29tbWFu ZCBsaW5lOgogKiBwb3dlcnBjLXVua25vd24tZWFiaS1nY2MgLVMgLVdhbGwgLU8zIGJ1Zy5jIC1v IGJ1Zy5zCiAqLwoKdHlwZWRlZiBzdHJ1Y3QgX21zZ0J1ZkhkX3QgewogIGludCAgICAgICAgICAg b3duZXI7ICAgIC8qIFRoZSBvd25lciBvZiB0aGUgbWVzc2FnZSAqLwp9IG1zZ0J1ZkhkX3Q7Cgpp bnQgQ3VycmVudFRocmVhZCh2b2lkKTsKdm9pZCBwYW5pYyh2b2lkKTsKCnZvaWQgRnJlZU1zZyh2 b2lkICoqIHBwTXNnKQp7CiAgbXNnQnVmSGRfdCAqIHBNc2dIZDsKCiAgLyogR2V0IHRoZSBtZXNz YWdlIHBvaW50ZXIgYW5kIGNsZWFyIHRoZSB1c2VyIHZhcmlhYmxlICovCiAgcE1zZ0hkID0gKigo bXNnQnVmSGRfdCAqKikgcHBNc2cpOwogICpwcE1zZyA9IDA7CgogIC8qIFN0ZXAgYmFjayB0byBz ZWUgdGhlIHByaXZhdGUgaGVhZGVyICovCiAgcE1zZ0hkLS07CgogIC8qIE11c3QgaGF2ZSBiZWVu IGZyZWVkIGJ5IHRoZSBvd25lciAqLwogIGlmIChwTXNnSGQtPm93bmVyICE9IEN1cnJlbnRUaHJl YWQoKSkgewogICAgcGFuaWMoKTsKICB9Cn0K