public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: "Maciej W. Rozycki" <macro@embecosm.com>, gcc-patches@gcc.gnu.org
Cc: Rainer Orth <ro@cebitec.uni-bielefeld.de>,
	Mike Stump <mikestump@comcast.net>
Subject: Re: [PATCH] testsuite: Fix subexpressions with `scan-assembler-times'
Date: Sun, 19 Nov 2023 16:44:58 -0700	[thread overview]
Message-ID: <cc037c9c-b4c8-45a0-8cf0-bd91147b962c@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.2311190446360.5892@tpp.orcam.me.uk>



On 11/19/23 04:27, Maciej W. Rozycki wrote:
> We have an issue with `scan-assembler-times' handling expressions using
> subexpressions as produced by capturing parentheses `()' in an odd way,
> and one that is inconsistent with `scan-assembler', `scan-assembler-not',
> etc.  The problem comes from calling `regexp' with `-inline -all', which
> causes a list to be returned that would otherwise be placed in match
> variables.
> 
> Consequently if we have say:
> 
> /* { dg-final { scan-assembler-times "\\s(foo|bar)\\s" 1 } } */
> 
> in a test case and there is a lone `foo' present in output being matched,
> then our invocation of `regexp -inline -all' in `scan-assembler-times'
> will return:
> 
> { foo } foo
> 
> and that in turn will confuse our match count calculation as `llength'
> will return 2 rather than 1, making the test fail even though `foo' was
> only actually matched once.
> 
> It seems unclear why we chose to call `regexp' in such an odd way in the
> first place just to figure out the number of matches.  The first version
> of TCL that supports the `-all' option to `regexp' is 8.3, and according
> to its documentation[1][2] `regexp' already returns the number of matches
> found whenever `-all' has been used *unless* `-inline' has also been used.
> 
> Remove the `-inline' option then along with the `llength' invocation.
> 
> References:
> 
> [1] "Tcl Built-In Commands - regexp manual page",
>      <https://www.tcl.tk/man/tcl8.2.3/TclCmd/regexp.html>
> 
> [2] "Tcl Built-In Commands - regexp manual page",
>      <https://www.tcl.tk/man/tcl8.3/TclCmd/regexp.html>
> 
> 	gcc/testsuite/
> 	* lib/scanasm.exp (scan-assembler-times): Remove the `-inline'
> 	option to `regexp' and the wrapping `llength' call.
> ---
> Hi,
> 
>   Verified with the `riscv64-linux-gnu' target and the C language
> testsuite.  OK to apply?
Not sure why it is the way it is -- I walked back to Zdenek's change 
which introduced the scan-assembler-times and nothing about the -inline 
argument.

OK, but be on the lookout for scan-asm problems on other targets over 
the next few days.

Jeff

  reply	other threads:[~2023-11-19 23:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-19 11:27 Maciej W. Rozycki
2023-11-19 23:44 ` Jeff Law [this message]
2023-11-22  2:13   ` Maciej W. Rozycki

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=cc037c9c-b4c8-45a0-8cf0-bd91147b962c@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=macro@embecosm.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).