Re: [testsuite] Effective-target depending on current compiler flags?

[Christophe Lyon <christophe.lyon@linaro.org>]

On Wed, 11 Sep 2019 at 14:21, Christophe Lyon
<christophe.lyon@linaro.org> wrote:
>
> On Wed, 11 Sep 2019 at 11:56, Richard Sandiford
> <richard.sandiford@arm.com> wrote:
> >
> > Christophe Lyon <christophe.lyon@linaro.org> 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