public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
To: Mike Stump <mikestump@comcast.net>
Cc: rep.dot.nop@gmail.com, GCC Patches <gcc-patches@gcc.gnu.org>,
	Rainer Orth <ro@cebitec.uni-bielefeld.de>,
	Jeff Law <law@redhat.com>
Subject: testsuite -fno-file [was: Re: [PATCH] PR52665 do not let .ident confuse assembler scan tests]
Date: Tue, 26 Apr 2022 01:00:29 +0200	[thread overview]
Message-ID: <20220426010029.2b476337@nbbrfq> (raw)
In-Reply-To: <CAC1BbcTVixoh3cZVDKtF_6KCWd+Fcg10AFxQFkOWOGSTLRCmcg@mail.gmail.com>

On Fri, 2 Feb 2018 14:25:22 +0100
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:

> On 19 June 2016 at 22:21, Mike Stump <mikestump@comcast.net> wrote:
> > On Jun 18, 2016, at 12:31 PM, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:  
> >>
> >> A branch with a name matching scan-assembler pattern triggers
> >> inappropriate FAIL.  
> >  
> >> The patch below adds -fno-ident if a testcase contains one of
> >> scan-assembler, scan-assembler-not or scan-assembler-times.  
> >
> > Kinda gross.  I'd like to consensus build a little, as I don't know that I have a better solution than the solution you propose to fix the issue.  I'd love it if one or more of Jacob, Law and Richard can chime in on direction here.  I'll have to think about this some more and see if I can come up with something that I like better.
> >
> > If no one has a better solution, I'll approve the proposed solution.  Let's give people a little time to chime in.  
> 
> Given the overwhelming silence this proposal has received, i take it
> for granted that folks are thrilled and even up until now speechless
> :)
> 
> So how should we proceed with -fno-ident.
> And, btw, -fno-file to inhibit .file directives for the same reason,

AFAICS we still do not pass -fno-file in tests.
Every now and then this still results in unnecessary, silly workarounds
like this one:

> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01785.html and all our

which we should not have to afford.

> ugly filenames like gcc.target/powerpc/swps-p8-36.c which strive to
> workaround the assembler-scans.
> 
> All those non-automatic hacks like naming swap() tests swps-,
> uglifying scan-patterns (which are not terribly straight forward to
> read anyway even without uglifying them) are error prone and costly.
> IMHO we should make sure time is spent for useful stuff and not be
> wasted to fight our very own testsuite.
> 
> -fno-ident ok for stage1?

We've fixed the ident thing some time ago.

> What about -fno-file? Clever alternative suggestions? Don't care?

We still didn't fix the .file directives in assembler output.

It's about the same as always.
See if the target supports -fno-file and/or -ffile.
If the testcase does NOT specify -fno-file or -ffile ¹)
then pass an appropriate default like -fno-file, otherwise do not add
anything.

¹) The real complication seems to be that there is neither a -fno-file
nor a (let's say) -ffile=foo.c implemented anywhere. And TBH we do
not need it nor want it for the purpose at hand. That suggests
that it would probably be cheaper to run sed on the (remote) output
file -- or do it locally and only then copy it to the remote. The net
effect being that .file directives in the testsuite are gone and can no
longer compromise tests.

thanks,

  parent reply	other threads:[~2022-04-25 23:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-18 19:31 [PATCH] PR52665 do not let .ident confuse assembler scan tests Bernhard Reutner-Fischer
2016-06-18 23:49 ` Hans-Peter Nilsson
2016-06-19 20:21 ` Mike Stump
2018-02-02 13:25   ` Bernhard Reutner-Fischer
2018-02-02 18:56     ` Mike Stump
2018-05-01 17:47     ` Jeff Law
2022-04-25 23:00     ` Bernhard Reutner-Fischer [this message]
2016-06-20 22:20 ` Jeff Law
2018-09-05 15:32   ` Bernhard Reutner-Fischer
2023-05-31 18:50     ` Bernhard Reutner-Fischer

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=20220426010029.2b476337@nbbrfq \
    --to=rep.dot.nop@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=mikestump@comcast.net \
    --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).