* [testsuite] Effective-target depending on current compiler flags? @ 2019-09-10 16:13 Christophe Lyon 2019-09-11 9:56 ` Richard Sandiford 0 siblings, 1 reply; 4+ messages in thread From: Christophe Lyon @ 2019-09-10 16:13 UTC (permalink / raw) To: gcc Mailing List, Mike Stump 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [testsuite] Effective-target depending on current compiler flags? 2019-09-10 16:13 [testsuite] Effective-target depending on current compiler flags? Christophe Lyon @ 2019-09-11 9:56 ` Richard Sandiford 2019-09-11 12:22 ` Christophe Lyon 0 siblings, 1 reply; 4+ messages in thread From: Richard Sandiford @ 2019-09-11 9:56 UTC (permalink / raw) To: Christophe Lyon; +Cc: gcc Mailing List, Mike Stump 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [testsuite] Effective-target depending on current compiler flags? 2019-09-11 9:56 ` Richard Sandiford @ 2019-09-11 12:22 ` Christophe Lyon 2019-09-20 13:01 ` Christophe Lyon 0 siblings, 1 reply; 4+ messages in thread From: Christophe Lyon @ 2019-09-11 12:22 UTC (permalink / raw) To: Richard Sandiford, Andre Simoes Dias Vieira; +Cc: gcc Mailing List, Mike Stump 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [testsuite] Effective-target depending on current compiler flags? 2019-09-11 12:22 ` Christophe Lyon @ 2019-09-20 13:01 ` Christophe Lyon 0 siblings, 0 replies; 4+ messages in thread From: Christophe Lyon @ 2019-09-20 13:01 UTC (permalink / raw) To: Richard Sandiford, Andre Simoes Dias Vieira; +Cc: gcc Mailing List, Mike Stump 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-09-20 13:01 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-10 16:13 [testsuite] Effective-target depending on current compiler flags? Christophe Lyon 2019-09-11 9:56 ` Richard Sandiford 2019-09-11 12:22 ` Christophe Lyon 2019-09-20 13:01 ` Christophe Lyon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).