On Wed, 11 Sep 2019 at 11:56, Richard Sandiford
<richard.sandif...@arm.com> wrote:
>
> Christophe Lyon <christophe.l...@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
