public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>
Cc: gcc-patches@gcc.gnu.org,
	Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>,
	Mike Stump <mikestump@comcast.net>,
	Nick Clifton <nickc@redhat.com>,
	Ramana Radhakrishnan <ramana.gcc@gmail.com>
Subject: Re: [PATCH] [testsuite] [arm] require arm_v8_1m_main for pacbti tests
Date: Fri, 19 Apr 2024 09:45:08 -0300	[thread overview]
Message-ID: <or7cgta5d7.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <13aceb3c-47b3-44f6-9ba0-2f8cfcd0d9ef@arm.com> (Richard Earnshaw's message of "Tue, 16 Apr 2024 09:56:25 +0100")

On Apr 16, 2024, "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com> wrote:

> The require-effective-target flags test whether a specific set of
> flags will make the compilation work, so they need to be used in
> conjunction with the corresponding dg-add-options flags that then
> apply those options.

*nod*, that's the theory.  Problem is the architectures suported by
[add_options_for_]arm_arch_*[_ok] do not match exactly those expected by
the tests, and I can't quite tell whether the subtle changes they would
introduce would change what they intend to test, or even whether the
differences are irrelevant, or would be sensible to add as variants to
the dg machinery.  I think it would take someone more familiar than I am
with all of the ARM variants to do this correctly.  I don't even know
how these changes would need to be tested to be sure they remain
correct.

Would you be willing to take it from here, or would you accept the patch
as an incremental yet imperfect improvement, or would you prefer to
guide me in making it correct, and in verifying it (there are questions
below)?  I don't have a lot of cycles to put into this (we've already
worked around the testsuite bugs we ran into), but it would be desirable
to get a fix into GCC as well, if we can converge on one without
unreasonably burdening anyone.


	v8_1m_main "-march=armv8.1-m.main+fp -mthumb" __ARM_ARCH_8M_MAIN__
	v8_1m_main_pacbti "-march=armv8.1-m.main+pacbti+fp -mthumb"
		"__ARM_ARCH_8M_MAIN__ && __ARM_FEATURE_BTI && __ARM_FEATURE_PAUTH

Why do these have +fp in -march but not in the v8_1m* arch name?


gcc/testsuite/g++.target/arm/pac-1.C:
/* { dg-options "-march=armv8.1-m.main+mve+pacbti -mbranch-protection=pac-ret -mthumb -mfloat-abi=hard -g -O0" } */

v8_1m_main_pacbti plus +mve minus +fp.
Do we need a dg arch for that?


gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c:
/* { dg-additional-options "-march=armv8.1-m.main+pacbti+fp --save-temps -mfloat-abi=hard" } */
gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c:
/* { dg-options "-march=armv8.1-m.main+fp+pacbti" } */

v8_1m_main_pacbti minus -mthumb.
AFAICT the -mthumb is redundant.


gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c:
/* { dg-options "-march=armv8-m.main+fp -mfloat-abi=softfp" } */

v8_1m_main minus -mthumb.
AFAICT the -mthumb is redundant.


gcc/testsuite/gcc.target/arm/bti-1.c:
/* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp -mbranch-protection=bti --save-temps" } */
gcc/testsuite/gcc.target/arm/bti-2.c:
/* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp -mbranch-protection=bti --save-temps" } */

v8_1m_main minus +fp.

Can these be bumped to +fp, or do we need an extra dg arch?

Are these missing +pacbti?


Thanks,

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

  reply	other threads:[~2024-04-19 12:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-16  3:48 Alexandre Oliva
2024-04-16  8:56 ` Richard Earnshaw (lists)
2024-04-19 12:45   ` Alexandre Oliva [this message]
2024-04-19 13:13     ` Richard Earnshaw (lists)
2024-04-19 16:37       ` [PATCH v2] [testsuite] [arm] add effective target and options " Alexandre Oliva
2024-05-25  8:20         ` Alexandre Oliva

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=or7cgta5d7.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mikestump@comcast.net \
    --cc=nickc@redhat.com \
    --cc=ramana.gcc@gmail.com \
    --cc=ro@CeBiTec.Uni-Bielefeld.DE \
    /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).