From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30971 invoked by alias); 20 Sep 2019 13:01:02 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 30724 invoked by uid 89); 20 Sep 2019 13:00:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=visible, sk:advsimd, armv8.2-a X-HELO: mail-lf1-f48.google.com Received: from mail-lf1-f48.google.com (HELO mail-lf1-f48.google.com) (209.85.167.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Sep 2019 13:00:23 +0000 Received: by mail-lf1-f48.google.com with SMTP id u3so4977300lfl.10 for ; Fri, 20 Sep 2019 06:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GDt21QOCU4ZhjmzpJlIScSU0QBqzHUe+MVNpvJmY2uA=; b=jDST1Wf7H/5gT0llvBElkXbtnqWGFSh0c/qD2/ogiv6Em7F8lA8sUbtCpYgXiS1qSD FBT1p0vZgz16A3bkTPeWI8Jz+pP8OwBm5mfdPiJN4bQRuN3rqXxAaotg43apbDa1/f6f 943u8SVSi1DPyQ6a5JGRV8tq+UbqgoKrBoBnDpLHbzZIQywj/byLRuJcCnL5ZVdpNwAn jgMuOEOqGfsfDpSlYA0BOM9U/29hTsInLl8MziFLTCNwBfvq6JsMj9I2H3j9pahMqxQt LV5DAs5jY/ewFkPKBXMJF0DXuWwUjQOU063J9U3qJgvlTFxs4iauJv1OziMTblGPxtiq rIPg== MIME-Version: 1.0 References: In-Reply-To: From: Christophe Lyon Date: Fri, 20 Sep 2019 13:01:00 -0000 Message-ID: Subject: Re: [testsuite] Effective-target depending on current compiler flags? To: Richard Sandiford , Andre Simoes Dias Vieira Cc: gcc Mailing List , Mike Stump Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00156.txt.bz2 On Wed, 11 Sep 2019 at 14:21, Christophe Lyon wrote: > > On Wed, 11 Sep 2019 at 11:56, Richard Sandiford > wrote: > > > > Christophe Lyon writes: > > > Hi, > > > > > > While looking at GCC validation results when configured for ARM > > > cortex-m33 by default, I noticed that > > > FAIL: gcc.target/arm/cmse/mainline/soft/cmse-5.c -march=armv8-m.main > > > -mthumb -mfloat-abi=soft -O0 scan-assembler msr\tAPSR_nzcvqg, lr > > > > > > The corresponding line in the testcase is (are): > > > /* { dg-final { scan-assembler "msr\tAPSR_nzcvq, lr" { target { ! > > > arm_dsp } } } } */ > > > /* { dg-final { scan-assembler "msr\tAPSR_nzcvqg, lr" { target arm_dsp } } } */ > > > > > > So the arm_dsp effective target is true and the test tries to match > > > APSR_nzcvqg, while APSR_nzcvq is generated, as expected. > > > > > > There is an inconsistency because the testcase is compiled with > > > -march=armv8-m.main, while arm_dsp is not: like most effective > > > targets, it does not take the current cflags into account. > > > In the present case, the -march flag is added by cmse.exp in the > > > arguments to gcc-dg-runtest. > > > > > > I tried to add [current_compiler_flags] to all arm effective targets > > > (for consistency, it wouldn't make sense to add it to arm_dsp only), > > > but then I noticed further problems... > > > > Yeah, effective targets shouldn't depend on the compiler flags. > > They're supposed to be properties of the testing target (what it > > supports, what it enables by default, etc.) and are cached between > > tests that run with different options. > > > Thanks for the clarification/confirmation it currently works as intended. Actually I've just realized that effective targets also depend on compiler flags passed via RUNTESTFLAGS / -target-board, so this is getting tricky... > > > CMSE isn't my area, so I don't know why the scan-assembler lines > > were written this way. Is the { target arm_dsp } line there for > > cases in which a user-specified -march flag manages to override > > -march=armv8-m.main? > > > I've added Andre in cc:, as he originally wrote that test. > If I add -march=armv8-m.main+dsp via RUNTESTFLAGS/-target-board, arm_dsp succeeds, but the testcase (cmse-5.c) is compiled with -march=armv8-m.main+dsp [...] -march=armv8-m.main the last flag comes from cmse.exp via add_options_for_arm_arch_v8m_main But IIRC the order between RUNTESTFLAGS and dg-options depends on the dejagnu version (somewhere near 1.6) Anyway, this makes me wonder what's the supposed/recommended way of running validations for non-default cpu? 1- configure --with-cpu=cortex-XX ; make check 2- configure (using default cpu setting) ; RUNTESTFLAGS=-mcpu=cortex-XX make check I use (1), but I think most others use (2) ? Thanks, Christophe > Thanks, > > Christophe > > > Thanks, > > Richard > > > > > For instance, in my configuration, when advsimd-intrinsics.exp is > > > executed, it tries > > > check_effective_target_arm_v8_2a_fp16_neon_hw > > > which fails, and then tries check_effective_target_arm_neon_fp16_ok > > > which succeeds and thus adds -mfloat-abi=softfp -mfp16-format=ieee to > > > additional_flags. > > > > > > Since $additional_flags is passed to gcc-dg-runtest, these flags are > > > visible by current_compiler_flags and taken into account when > > > computing effective_targets (since I modified them). > > > > > > So... when computing arm_v8_2a_fp16_scalar_ok, it uses > > > -mfloat-abi=softfp -mfp16-format=ieee and doesn't need to add any flag > > > beyond -march=armv8.2-a+fp16. > > > So et_arm_v8_2a_fp16_scalar_flags contains -march=armv8.2-a+fp16 only. > > > > > > Later on, while executing arm.exp, -mfloat-abi=softfp > > > -mfp16-format=ieee are not part of $DEFAULT_CFLAGS as used by > > > dg-runtest, but et_arm_v8_2a_fp16_scalar_flags is still in the cache > > > and it's not valid anymore. > > > > > > So..... before burying myself, is there already a way to make > > > effective-targets take the current compiler flags into account as > > > needed in gcc.target/arm/cmse/mainline/soft/cmse-5.c ? > > > > > > Not sure my explanation is clear enough :-) > > > > > > Thanks, > > > > > > Christophe