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

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

[Christophe Lyon]

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...

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

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

[Richard Sandiford]

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.

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?

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

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

[Christophe Lyon]

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.

> 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.

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

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

[Christophe Lyon]

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