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

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

[Eric Botcazou]

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

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: kostis@csd.uu.se
Cc: gcc-gnats@gcc.gnu.org,
 gcc-bugs@gcc.gnu.org
Subject: Re: target/10222: Wrong code with -mcpu=ultrasparc using gcc 3.2.2
Date: Sun, 30 Mar 2003 23:05:22 +0200

 > The attached file contains a very small and simple function extracted from
 > a big application. The code produced by -03 is  correct.
 
 Yes, but only by chance.
 
 > The code produced using -03 -mcpu=ultrasparc is wrong and causes the
 > application to go into an infinite loop.
 
 Well, the code is wrong according to your expectations, but right according 
 to the C standard (more precisely, gcc is allowed to produce this code in 
 this situation).
 
 > 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
 
 Right. Your code violates the ISO C aliasing rules:
 
 void reclaim_del_ret_list(struct subgoal_frame *sg_frame)
 {
   struct Answer_List_Node *x, *y;
   
   x = sg_frame->compl_stack_ptr->del_ret_list;
   while (x) {
     y = x;
 1    x = x->link;
 2    *(void**)y = smALN.struct_lists.dealloc;
     smALN.struct_lists.dealloc = y;
   }
 }
 
 The compiler is allowed to assume that load #1 and store #2 are independent 
 since they are made through pointers of different types. So the first 
 scheduling pass transforms the code into:
 
   while (x) {
     y = x;
 2    *(void**)y = smALN.struct_lists.dealloc;
 1    x = x->link;
     smALN.struct_lists.dealloc = y;
   }
 
 hence the infinite loop.
 
 > 1. What I naively expect from -mcpu=ultrasparc is to
 >     perform target specific code generation; not to affect
 >     the alias analysis which is used.
 
 -mcpu doesn't modify the alias analysis, but it affects scheduling. The 
 default scheduling is simply less aggressive than the ultrasparc scheduling, 
 in that it doesn't reorder the insns to the same extent.
 
 >  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.
 
 -fstrict-aliasing was not enabled by default at -O2 for gcc 2.95.x. As for 
 the behaviour on x86, it's again by chance, another scheduling could give the 
 same infinite loop.
 
 The solution is really the one you have proposed: to compile with 
 -fno-strict-aliasing.
 
 -- 
 Eric Botcazou

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

[kostis]

>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