From: Jakub Jelinek <jakub@redhat.com>
To: Qing Zhao <qing.zhao@oracle.com>
Cc: Richard Biener <rguenther@suse.de>,
Richard Sandiford <richard.sandiford@arm.com>,
Nick Alcock via Gcc-patches <gcc-patches@gcc.gnu.org>,
kees Cook <keescook@chromium.org>
Subject: Re: [PATCH] testsuite: Fix c-c++-common/auto-init-* tests
Date: Thu, 16 Sep 2021 16:56:40 +0200 [thread overview]
Message-ID: <20210916145640.GI304296@tucnak> (raw)
In-Reply-To: <902D3C35-8E78-4A91-99A3-AD644A7A1F53@oracle.com>
On Thu, Sep 16, 2021 at 02:49:23PM +0000, Qing Zhao wrote:
> > Testing for many instructions is always very fragile and dependent on exact
> > compiler flags etc.
>
> Yes, It’s indeed very fragile.
> > So, either the test should have a particular
> > -march=/-mtune= options
>
> I might add specific -march to the testing cases.
Even -mtune= is needed if you want to stay safe, otherwise people testing
with --target_board=unix/-mtune=cascadelake (or whatever else) might get
failures.
> > and ideally also -fno-stack-protector
> > -fno-stack-clash-protection etc.
>
> Could you explain a little bit on this why?
In case people test e.g. with --target_board=unix/\{,-fstack-protector-all\}
etc. (e.g. in Fedora/RHEL we do).
For the RTL scanning checks if they are done fairly early, those options
might not change anything, but with the ones scanning in the assembly,
one needs to watch if those options don't add e.g. in the prologue or
epilogue further copies of the instructions you scan for.
Jakub
next prev parent reply other threads:[~2021-09-16 14:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-21 20:07 [patch][version 8]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc Qing Zhao
2021-09-03 14:47 ` Qing Zhao
2021-09-11 8:03 ` [PATCH] testsuite: Fix c-c++-common/auto-init-* tests Jakub Jelinek
2021-09-11 11:45 ` Richard Biener
2021-09-11 16:58 ` Qing Zhao
2021-09-15 17:59 ` Qing Zhao
2021-09-16 9:19 ` Jakub Jelinek
2021-09-16 14:49 ` Qing Zhao
2021-09-16 14:56 ` Jakub Jelinek [this message]
2021-09-16 15:39 ` Qing Zhao
2021-09-16 15:47 ` Jakub Jelinek
2021-09-16 17:11 ` Qing Zhao
2021-09-16 17:39 ` Iain Sandoe
2021-09-16 18:55 ` Qing Zhao
2021-09-06 10:16 ` [patch][version 8]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc Richard Biener
2021-09-07 16:57 ` Qing Zhao
2021-09-07 18:33 ` Qing Zhao
2021-09-09 22:49 ` [COMMITTED][patch][version 9]add " Qing Zhao
2021-09-09 23:10 ` Kees Cook
2021-09-10 7:23 ` Richard Biener
2021-09-10 13:46 ` Jose E. Marchesi
2021-09-10 14:36 ` Qing Zhao
2021-09-13 9:32 ` Richard Biener
2021-09-13 14:38 ` Jose E. Marchesi
2021-09-10 8:47 ` Christophe LYON
2021-09-10 9:08 ` Martin Liška
2021-09-10 14:01 ` Jeff Law
2021-09-10 9:40 ` Thomas Schwinge
2021-09-10 14:30 ` Qing Zhao
2021-09-10 14:26 ` Qing Zhao
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=20210916145640.GI304296@tucnak \
--to=jakub@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=keescook@chromium.org \
--cc=qing.zhao@oracle.com \
--cc=rguenther@suse.de \
--cc=richard.sandiford@arm.com \
/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).