From: Christophe Lyon <christophe.lyon@linaro.org>
To: gcc Mailing List <gcc@gcc.gnu.org>, Mike Stump <mikestump@comcast.net>
Subject: [testsuite] Effective-target depending on current compiler flags?
Date: Tue, 10 Sep 2019 16:13:00 -0000 [thread overview]
Message-ID: <CAKdteOYkpFH0t1dRgA_B1jc7uhpm5cMtMGEaG63gdRTuD9Rf9A@mail.gmail.com> (raw)
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
next reply other threads:[~2019-09-10 16:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-10 16:13 Christophe Lyon [this message]
2019-09-11 9:56 ` Richard Sandiford
2019-09-11 12:22 ` Christophe Lyon
2019-09-20 13:01 ` Christophe Lyon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKdteOYkpFH0t1dRgA_B1jc7uhpm5cMtMGEaG63gdRTuD9Rf9A@mail.gmail.com \
--to=christophe.lyon@linaro.org \
--cc=gcc@gcc.gnu.org \
--cc=mikestump@comcast.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).