From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30664 invoked by alias); 26 Mar 2003 14:16:02 -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 30614 invoked by uid 71); 26 Mar 2003 14:16:01 -0000 Resent-Date: 26 Mar 2003 14:16:01 -0000 Resent-Message-ID: <20030326141601.30613.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, ebotcazou@libertysurf.fr, kostis@csd.uu.se Resent-Reply-To: gcc-gnats@gcc.gnu.org, kostis@csd.uu.se Received: (qmail 28353 invoked by uid 48); 26 Mar 2003 14:06:05 -0000 Message-Id: <20030326140605.28352.qmail@sources.redhat.com> Date: Wed, 26 Mar 2003 14:16:00 -0000 From: kostis@csd.uu.se Reply-To: kostis@csd.uu.se To: gcc-gnats@gcc.gnu.org Cc: ebotcazou@libertysurf.fr, kostis@csd.uu.se X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) X-GNATS-Notify: ebotcazou@libertysurf.fr, kostis@csd.uu.se Subject: target/10222: Wrong code with -mcpu=ultrasparc using gcc 3.2.2 X-SW-Source: 2003-03/txt/msg01798.txt.bz2 List-Id: >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