From patchwork Wed Feb 4 10:07:05 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ramana Radhakrishnan X-Patchwork-Id: 436214 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 8010F140216 for ; Wed, 4 Feb 2015 21:07:50 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:content-type; q=dns; s=default; b=lvJZSYhD0tFh4B0S/FKkkv14xBit6iUZZFjmxatGakt 5TY2xFaCU61EvjIloVDjF/WyW2HnU+X+dkRHamQUZB+6M9mf2H6LwMcvE7/UKJYY cfZU8YSulZQ1HWDP6zLUhrgCyVe48t8j5BDH4DfsPZqWMNGnZP9A7zL+m4PvM3Qo = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:content-type; s=default; bh=3/cPqafU8nmRnkG+K4XqE1KAkqs=; b=Xled4vaDASyhiIKk7 +f42KIjpCmTVtS8nRErAxHYzJYxTmhx+z4Ve9AqTxA0ue1xmDH9ZJDbRbpGIvDxm 8y1kJAaSaX5Na9k1QyysMFgjFXS53fYyXMpPlpqAdOcg3f0ibPxNksArWAa3RfCJ ejjwNqTIHBhqtQ0uB6RDzKpWEg= Received: (qmail 8647 invoked by alias); 4 Feb 2015 10:07:20 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 8629 invoked by uid 89); 4 Feb 2015 10:07:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: foss-mx-na.foss.arm.com Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com) (217.140.108.86) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Feb 2015 10:07:18 +0000 Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8]) by foss-mx-na.foss.arm.com (Postfix) with ESMTP id C71AF4E4; Wed, 4 Feb 2015 04:07:14 -0600 (CST) Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com [10.112.81.134]) by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id A6A3B5FAC1; Wed, 4 Feb 2015 04:07:12 -0600 (CST) Received: from [127.0.0.1] (unknown [10.37.12.5]) by collaborate-mta1.arm.com (Postfix) with ESMTP id 5D4BD13F6EE; Wed, 4 Feb 2015 04:07:09 -0600 (CST) Message-ID: <54D1EF49.5080809@arm.com> Date: Wed, 04 Feb 2015 10:07:05 +0000 From: Ramana Radhakrishnan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: gcc-patches@gcc.gnu.org CC: jakub@redhat.com Subject: [Patch ARM] Improve guality tests - part 1 - pr36728-1.c X-IsSubscribed: yes Hi, I decided to spend some time looking at the large number of guality test failures on arm. I see a number of fails with gcc.dg/guality/pr36728-1.c as below. pr36728-2.c also fails in similar sort of ways. Before I go adjusting too many other tests I'd like to get some feedback regarding this from folks. On ARM parameters are passed in r0 - r3 which maps to arg1 - arg4. The code generated appears to use r0 for the return value and as a temporary. r2 and r3 are used as temporaries to adjust the stack as those are the first temporaries used in the register allocaton order. Therefore it is understandeable that arg1, arg3 and arg4 end up being "optimized" out and there is no chance of reclaiming the information at line #16 or line #18 in the testcase linked. r1 gets used at O2 and therefore that starts failing at O2 and above. Depending on optimization levels, registers used for arg1 - arg4 get reused at various optimization levels therefore we have no choice but to disable this lot. Once you do that the only failures left are with the variable 'y' at optimization levels O2 and O3 which I'm going to leave as is until the time as I understand what's going on here. My initial thought is that this also appears to be a testism, but I'm not a 100% sure yet. I pondered adding a testsuite keyword for this but it appears to be so special cased per target, that I don't see any easy way of handling this as each target appears to be special in the way in which it handles this - fundamentally would end up depending on the number of registers used as parameter registers and being caller saved registers and that varies from port to port. FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 y == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 y == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 18 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 18 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 18 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 18 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O3 -fomit-frame-pointer line 18 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O3 -fomit-frame-pointer line 18 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O3 -fomit-frame-pointer line 18 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O3 -fomit-frame-pointer line 18 y == 2 FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 18 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 18 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 18 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 18 y == 2 to FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 y == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 y == 2 FAIL: gcc.dg/guality/pr36728-1.c -O3 -fomit-frame-pointer line 16 y == 2 FAIL: gcc.dg/guality/pr36728-1.c -O3 -fomit-frame-pointer line 18 y == 2 FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 16 y == 2 FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 18 y == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 y == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 y == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 16 y == 2 Changelog: * gcc.dg/guality/pr36728-1.c: Skip some tests for arm. Ok ? Thoughts ? regards, Ramana P.S. I got caught out by the yama security module in the kernel preventing me from running some of the guality tests on the chromebook I was running this on. https://www.kernel.org/doc/Documentation/security/Yama.txt. JFTR it may be a good idea to do echo 0 > /proc/sys/kernel/yama/ptrace_scope to get these things to work. Also I was using a trunk gdb to get these results. diff --git a/gcc/testsuite/gcc.dg/guality/pr36728-1.c b/gcc/testsuite/gcc.dg/guality/pr36728-1.c index ba7a6c2..6e6ba3f 100644 --- a/gcc/testsuite/gcc.dg/guality/pr36728-1.c +++ b/gcc/testsuite/gcc.dg/guality/pr36728-1.c @@ -23,20 +23,23 @@ foo (int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7) when adjusting the addresses in order to meet the alignment requirements above. They usually hold the function arguments arg1 and arg2. So it is expected that these values are unavailable in - some of these tests. */ + some of these tests. On ARM, a similar problem occurs with registers + r0-r3 which contain arg1-arg4. The registers r0-r3 are caller saved + and are used for various purposes including aligning the stack and + holding temporaries, thereby destroying the values in their parameters. */ -/* { dg-final { gdb-test 16 "arg1" "1" { target { ! "s390*-*-*" } } } } */ -/* { dg-final { gdb-test 16 "arg2" "2" { target { ! "s390*-*-*" } } } } */ -/* { dg-final { gdb-test 16 "arg3" "3" } } */ -/* { dg-final { gdb-test 16 "arg4" "4" } } */ +/* { dg-final { gdb-test 16 "arg1" "1" { target { { ! "s390*-*-*" } && { ! "arm*-*-*" } } } } } */ +/* { dg-final { gdb-test 16 "arg2" "2" { target { { ! "s390*-*-*" } && { ! "arm*-*-*" } } } } } */ +/* { dg-final { gdb-test 16 "arg3" "3" { target { ! "arm*-*-*" } } } } */ +/* { dg-final { gdb-test 16 "arg4" "4" { target { ! "arm*-*-*" } } } } */ /* { dg-final { gdb-test 16 "arg5" "5" } } */ /* { dg-final { gdb-test 16 "arg6" "6" } } */ /* { dg-final { gdb-test 16 "arg7" "30" } } */ /* { dg-final { gdb-test 16 "y" "2" } } */ -/* { dg-final { gdb-test 18 "arg1" "1" { target { ! "s390*-*-*" } } } } */ -/* { dg-final { gdb-test 18 "arg2" "2" { target { ! "s390*-*-*" } } } } */ -/* { dg-final { gdb-test 18 "arg3" "3" } } */ -/* { dg-final { gdb-test 18 "arg4" "4" } } */ +/* { dg-final { gdb-test 18 "arg1" "1" { target { { ! "s390*-*-*" } && { ! "arm*-*-*" } } } } } */ +/* { dg-final { gdb-test 18 "arg2" "2" { target { { ! "s390*-*-*" } && { ! "arm*-*-*" } } } } } */ +/* { dg-final { gdb-test 18 "arg3" "3" { target { ! "arm*-*-*" } } } } */ +/* { dg-final { gdb-test 18 "arg4" "4" { target { ! "arm*-*-*" } } } } */ /* { dg-final { gdb-test 18 "arg5" "5" } } */ /* { dg-final { gdb-test 18 "arg6" "6" } } */ /* { dg-final { gdb-test 18 "arg7" "30" } } */