target/10222: Wrong code with -mcpu=ultrasparc using gcc 3.2.2

[kostis@csd.uu.se]

>Number:         10222
>Category:       target
>Synopsis:       Wrong code with -mcpu=ultrasparc using gcc 3.2.2
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 26 14:16:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Kostis Sagonas
>Release:        version 3.2.2
>Organization:
>Environment:
Solaris 9 (probably on all Solaris versions)
>Description:
The attached file contains a very small and simple function extracted from a big application. The code produced by -03 is  correct. The code produced using -03 -mcpu=ultrasparc is
wrong and causes the application to go into an infinite loop.

>From what I can see, the problem is partly caused by the fact that the code lies about types when it appends elements to the free list. My guess is that -mcpu=ultrasparc triggers a scheduling pass, which assumes one store cannot affect another load, since they are of different types. I can pass -fno-strict-aliasing to gcc to work around that, but arguably this is unsatisfactory for various reasons:
 1. What I naively expect from -mcpu=ultrasparc is to      
    perform target specific code generation; not to affect
    the alias analysis which is used.
 2. This behaviour is not something that happened with
    previous versions of gcc (e.g. 2.95.x) and gcc 3.2
    on x86 with -mcpu=pentiumpro does not exhibit such
    behaviour.
>How-To-Repeat:
Compile using:
gcc -c -O3 -S file.c
gcc -c -O3 -mcpu=ultrasparc -S file.c
>Fix:
IMHO, -mcpu=... should not imply a specific sort of alias analysis.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="tr_reclaim.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tr_reclaim.c"

c3RydWN0IHN1YmdvYWxfZnJhbWUgewogIHN0cnVjdCBjb21wbGV0aW9uX3N0YWNrX2ZyYW1lICpj
b21wbF9zdGFja19wdHI7Cn07CgpzdHJ1Y3QgY29tcGxldGlvbl9zdGFja19mcmFtZSB7CiAgc3Ry
dWN0IEFuc3dlcl9MaXN0X05vZGUgKmRlbF9yZXRfbGlzdDsKfTsKCnN0cnVjdCBBbnN3ZXJfTGlz
dF9Ob2RlIHsKICBzdHJ1Y3QgQW5zd2VyX0xpc3RfTm9kZSAqbGluazsKfTsKCnN0cnVjdCBTdHJ1
Y3R1cmVfTWFuYWdlciB7CiAgc3RydWN0IHsKICAgIHZvaWQgKmRlYWxsb2M7CiAgfSBzdHJ1Y3Rf
bGlzdHM7Cn07CmV4dGVybiBzdHJ1Y3QgU3RydWN0dXJlX01hbmFnZXIgc21BTE47Cgp2b2lkIHJl
Y2xhaW1fZGVsX3JldF9saXN0KHN0cnVjdCBzdWJnb2FsX2ZyYW1lICpzZ19mcmFtZSkKewogIHN0
cnVjdCBBbnN3ZXJfTGlzdF9Ob2RlICp4LCAqeTsKICAKICB4ID0gc2dfZnJhbWUtPmNvbXBsX3N0
YWNrX3B0ci0+ZGVsX3JldF9saXN0OwogIHdoaWxlICh4KSB7CiAgICB5ID0geDsKICAgIHggPSB4
LT5saW5rOwogICAgKih2b2lkKiopeSA9IHNtQUxOLnN0cnVjdF9saXN0cy5kZWFsbG9jOwogICAg
c21BTE4uc3RydWN0X2xpc3RzLmRlYWxsb2MgPSB5OwogIH0KfQoK