User account creation filtered due to spam.

Bug 20479 - Instruction scheduler falsely reorders insns (ia64)
Summary: Instruction scheduler falsely reorders insns (ia64)
Status: RESOLVED DUPLICATE of bug 21920
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.1.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-15 08:19 UTC by Grigory Zagorodnev
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: ia64-redhat-linux
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Grigory Zagorodnev 2005-03-15 08:19:10 UTC
Test listed below fails when compiled with -02 optimization at IA64. It appears 
that instruction scheduler misses dependency between two assignments in 
the 'set_code' routine and falsely reorders them.

$ cat test.c
typedef struct s_t {
  short a;
  short b;
} *ps;
 
void set_code (ps obj, short code) {
    *((int *) obj) = 0;
    obj->a = code;
}
 
int printf(const char *, ...);
int main() {
    struct s_t obj;
    set_code(&obj, 123);
    
    printf("%s: got %d, expected 123\n", 
        ((obj.a == 123)?"PASS":"FAIL"), obj.a);
}

$ gcc test.c -O2 
$ ./a.out
FAIL: got 0, expected 123

Here is the assembly code of function 'set_code' with incorrectly reordered 
instructions.

$ gcc test.c -S -O2 
        .proc set_code#
set_code:
        .prologue
        .body
        st2 [r32] = r33		;    obj->a = code;
        st4 [r32] = r0		;    *((int *) obj) = 0;
        br.ret.sptk.many b0

PS: the minimal set of optimizations reproducing the failure is "-O1 -fstrict-
aliasing -fschedule-insns".
Comment 1 Andrew Pinski 2005-03-15 08:28:47 UTC
You are violating C89/C99/C++ aliasing rules so this is undefined.
Comment 2 Andrew Pinski 2005-06-05 09:11:30 UTC
Reopening to ...
Comment 3 Andrew Pinski 2005-06-05 09:11:46 UTC
Mark as a dup of bug 21920.

*** This bug has been marked as a duplicate of 21920 ***