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 11:19:17 +0200 [thread overview]
Message-ID: <20210916091917.GF304296@tucnak> (raw)
In-Reply-To: <9C40E343-B36F-46DC-8A41-383B8EF97A48@oracle.com>
On Wed, Sep 15, 2021 at 05:59:08PM +0000, Qing Zhao wrote:
> > Note, the gcc.dg/i386/auto-init* tests fail also, just don't have time to
> > deal with that right now, just try
> > make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} i386.exp=auto-init*'
>
> It’s strange that the above testing on my local x86 machine with the latest gcc had less failure than the following:
>
> [opc@qinzhao-ol8u3-x86 build-boot]$ make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} i386.exp=auto-init*' &> log &
> [1] 3885164
> [opc@qinzhao-ol8u3-x86 build-boot]$
> [1]+ Done make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} i386.exp=auto-init*' &> log
> [opc@qinzhao-ol8u3-x86 build-boot]$ egrep FAIL gcc/testsuite/gcc/gcc.sum
> FAIL: gcc.target/i386/auto-init-2.c scan-rtl-dump-times expand "0xfffffffffefefefe" 2
> FAIL: gcc.target/i386/auto-init-2.c scan-rtl-dump-times expand "0xfefefefefefefefe" 3
> FAIL: gcc.target/i386/auto-init-3.c scan-assembler-times pxor\t\\%xmm0, \\%xmm0 3
> FAIL: gcc.target/i386/auto-init-4.c scan-rtl-dump-times expand "0xfffffffffefefefe" 1
> FAIL: gcc.target/i386/auto-init-4.c scan-rtl-dump-times expand "\\[0xfefefefefefefefe\\]" 1
> FAIL: gcc.target/i386/auto-init-4.c scan-rtl-dump-times expand "0xfffffffffffffffe\\]\\) repeated x16" 1
> FAIL: gcc.target/i386/auto-init-5.c scan-assembler-times \\.long\t0 14
> FAIL: gcc.target/i386/auto-init-padding-3.c scan-assembler movl\t\\$16,
> FAIL: gcc.target/i386/auto-init-padding-3.c scan-assembler rep stosq
> FAIL: gcc.target/i386/auto-init-padding-7.c scan-assembler-times movq\t\\$0, 2
> FAIL: gcc.target/i386/auto-init-padding-8.c scan-assembler-times movq\t\\$0, 2
> FAIL: gcc.target/i386/auto-init-padding-9.c scan-assembler rep stosq
Testing for many instructions is always very fragile and dependent on exact
compiler flags etc. So, either the test should have a particular
-march=/-mtune= options and ideally also -fno-stack-protector
-fno-stack-clash-protection etc. if they could change the expected matching,
or test it at runtime instead (I know, it is playing with fire, because you
are testing the behavior of UB, but perhaps making the functions that use
the uninitialized vars __attribute__((noipa)) and checking whether the vars
contain the expected values might be ok.
Jakub
next prev parent reply other threads:[~2021-09-16 9:19 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 [this message]
2021-09-16 14:49 ` Qing Zhao
2021-09-16 14:56 ` Jakub Jelinek
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=20210916091917.GF304296@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).