target/10664: GCC incorrectly reorders loads and stores for a powerpc-unknown-eabi target when optimizing

[Toni.Kettula@hut.fi]

>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