On Wed, 11 Oct 2023 at 05:48, Joern Rennecke
<joern.renne...@embecosm.com> wrote:
> So I propose we look at the first character of the regexp, and if it's neither
> ^ nor \ (neither caret nor backslash), we consider the regexp un-anchored,
> and prepend ^[^"]* , so it won't allow a match after a double quote.
Looking at the sources for dg-scan / scan-assembler-times / scan-assembler-dem /
scan-assembler-dem-not, and the tcl regexp command and re_syntax manual
pages, I realise it won't work like that. The backslash-escaped
characters in the
source file end up just as single characters if enclosed merely with
double quotes,
so "\t" is a single character, although {\t} and {\m} will be passed
as two characters
to regexp (and "\m" is just an m).
And ^ , by default, matches only the begin of the text, which for the
aforementioned scan-assembler* procs means the entire (demangled for *-dem)
output file.
(The manual is a bit muddled about start of string or start of line,
but a test with
tclsh shows the default is indeed start of string.)
We can make use embedded options to make a prepended string work, i.e.
(?w)^[^"]*?
Although I'm not sure what that'd do on macOS - would the compiler output
contain lines terminated only with \r, and these be invisible to ^ ?
I see that we have a number of scan patterns that start with \n ing++.dg,
so I would hope that we can rely on lines ending with \n .
(\n\r or \r\n are OK for this purpose.)
Incidentally, these patterns should also work with (?w^[^"]*? prepended,
as a line that ends should also have a start, but it could get a low count for
scan-assembler-times. There are a number of tests in gcc.target/s390
that have directives starting with: scan-assembler-times {\n\t
which are perfectly anchored, but we might depress the count if we
prepend a pattern that matches the start of the line that has the newline.
We'd also have to make an exception for regexps that start with a parenthesis
to avoid disabling REs with embedded options.
So it seems we have to except patterns starting wit any of:
\\ \t \n (
Maybe we should also add [ to that list, for "[\n\r]" ?
