From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id B9BEC38582A6 for ; Mon, 20 Nov 2023 13:58:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B9BEC38582A6 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B9BEC38582A6 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700488694; cv=none; b=D7BCXdtyrQnQKyKcIJn8bS4/CLcPFz5tRXiMRNqVx4c9aPIjsDzktcPz0iu7rkU0W1owJ4Rro1PN/jLGDVkDlvRkLSH9ue6C7B5TMxNpbrCHVbMiRG1i16qPamoAz6Y2MR9I/6gubEklMWOfLJsvcmOPqiUVjovvrTLErpeT0/s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700488694; c=relaxed/simple; bh=y69l4u67PaGAukWl92Ll4rt7/WJE6dvbIRH6prIelMc=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=uT11TCHFfFwsW7ykBTU8d6Kqj1UHMPYEfbVZGG2297zUJJuwykBI3Nt6w9QoAGpdhr/O07AsmWhD0Mya6JPWvQAHbht2alCrHxlUhVo0xT0Siay9c/PHNBCIK4hgJEj5rLOREo7lq6JGAzG7Tl9yJRlddhD97wxKyT0BEh6tDUc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4FC94FEC; Mon, 20 Nov 2023 05:58:58 -0800 (PST) Received: from [10.57.38.109] (unknown [10.57.38.109]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 715E73F6C4; Mon, 20 Nov 2023 05:58:11 -0800 (PST) Message-ID: <724d822d-7bf1-4284-8688-cc834fd90817@foss.arm.com> Date: Mon, 20 Nov 2023 13:58:10 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march Content-Language: en-GB To: Christophe Lyon Cc: Richard Earnshaw , "gcc-patches@gcc.gnu.org" References: <20231113142658.69039-1-rearnsha@arm.com> <20231113142658.69039-4-rearnsha@arm.com> From: Richard Earnshaw In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3489.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 20/11/2023 13:36, Christophe Lyon wrote: > On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw > wrote: >> >> >> >> On 20/11/2023 10:23, Christophe Lyon wrote: >>> Hi Richard, >>> >>> On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw wrote: >>>> >>>> >>>> A number of tests in the gcc testsuite, especially for arm-specific >>>> targets, add various flags to control the architecture. These run >>>> into problems when the compiler is configured with -mfpu=auto if the >>>> new architecture lacks an architectural feature that implies we have >>>> floating-point instructions. >>>> >>>> The testsuite makes this worse as it falls foul of this requirement in >>>> the base architecture strings provided by target-supports.exp. >>>> >>>> To fix this we add "+fp", or something equivalent to this, to all the >>>> base architecture specifications. The feature will be ignored if the >>>> float ABI is set to soft. >>>> >>>> gcc/testsuite: >>>> >>>> * lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok): >>>> Add base FPU specifications to all architectures that can support >>>> one. >>>> --- >>>> gcc/testsuite/lib/target-supports.exp | 50 +++++++++++++-------------- >>>> 1 file changed, 25 insertions(+), 25 deletions(-) >>>> >>> >>> Our CI has detected some regressions with this patch, in particular >>> when testing for cortex-m55: >>> >>> with >>> -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto >>> and GCC configured with --disable-multilib --with-mode=thumb >>> --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard >>> >>> you can see our logs here: >>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ >>> >>> Thanks, >>> >>> Christophe >> >> What exactly am I supposed to be looking at here? I see no description >> of what those logs represent. If they are supposed to be before and >> after, then why does the after only run a tiny fraction of the testsuite >> (Running gcc.git~master/gcc/testsuite/gcc.target/arm/arm.exp ... >> Running gcc.git~master/gcc/testsuite/gcc.target/arm/cmse/cmse.exp ... >> Running gcc.git~master/gcc/testsuite/gcc.target/arm/lto/lto.exp ...) >> >> The logs give no clue as to why the reminder of the testsuite wasn't run. >> >> Please don't make me guess. >> > > Here is a summary with the list of regressions: > https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/ OK, that's much more useful. But how was I supposed to know that link existed? > > I thought you'd be able to find your way in the logs above, the .0 > files contain the logs of the initial full testsuite run, and .1 ones > contain the logs of the second run of the testsuite, restricted to the > .exp files where we detected regressions. So looking at gcc.log.1.xz > will give you details of the regressions shown in the link above. There's nothing in the page you sent me to that gives any clue as to how to read the logs there. So my assumption was that the .0 was a before run and .1 an after. Please, if you're going to direct people to the log files, provide some way for them to understand what the log files show. Now, to the specific issues: Running gcc:gcc.target/arm/arm.exp ... FAIL: gcc.target/arm/attr_thumb-static2.c (test for excess errors) UNRESOLVED: gcc.target/arm/attr_thumb-static2.c scan-assembler-times blx 2 This was fixed with "arm: testsuite: avoid problems with -mfpu=auto in attr_thumb-static2.c", which is a later patch in the series (patch 6). I don't think it's useful to try to regression test each individual patch, it wasn't practical to try to get every patch into order in the series (it would have made for a lot of churn on some files, especially target-supports.exp), so only a fully before and a fully after run is useful. If there are issues once the whole series has been applied, then that is much more interesting. R.