diff mbox series

testsuite: Handle empty assembly lines in check-function-bodies

Message ID 20230428155829.F20D120438@pchp3.se.axis.com
State Accepted
Headers
Series testsuite: Handle empty assembly lines in check-function-bodies |

Checks

Context Check Description
snail/gcc-patch-check success Github commit url

Commit Message

Hans-Peter Nilsson April 28, 2023, 3:58 p.m. UTC 
  Ok to commit?
-- >8 --
I tried to make use of check-function-bodies for cris-elf and was a
bit surprised to see it failing.  There's a deliberate empty line
after the filled delay slot of the return-function which was
mishandled.  I thought "aha" and tried to add an empty line
(containing just a "**" prefix) to the match, but that didn't help.
While it was added as input from the function's assembly output
to-be-matched like any other line, it couldn't be matched: I had to
use "...", which works but is...distracting.

Some digging shows that an empty assembly line can't be deliberately
matched because all matcher lines (lines starting with the prefix,
the ubiquitous "**") are canonicalized by trimming leading
whitespace (the "string trim" in check-function-bodies) and instead
adding a leading TAB character, thus empty lines end up containing
just a TAB.  For usability it's better to treat empty lines as fluff
than to uglifying the test-case and the code to properly match them.
Double-checking, no test-case tries to match an line containing just
TAB (by providing an a line containing just "**\s*", i.e. zero or
more whitespace characters).

	* lib/scanasm.exp (parse_function_bodies): Set fluff to include
	empty lines (besides optionally leading whitespace).
---
 gcc/testsuite/lib/scanasm.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Jeff Law April 28, 2023, 10:49 p.m. UTC | #1 
On 4/28/23 09:58, Hans-Peter Nilsson via Gcc-patches wrote:
> Ok to commit?
> -- >8 --
> I tried to make use of check-function-bodies for cris-elf and was a
> bit surprised to see it failing.  There's a deliberate empty line
> after the filled delay slot of the return-function which was
> mishandled.  I thought "aha" and tried to add an empty line
> (containing just a "**" prefix) to the match, but that didn't help.
> While it was added as input from the function's assembly output
> to-be-matched like any other line, it couldn't be matched: I had to
> use "...", which works but is...distracting.
> 
> Some digging shows that an empty assembly line can't be deliberately
> matched because all matcher lines (lines starting with the prefix,
> the ubiquitous "**") are canonicalized by trimming leading
> whitespace (the "string trim" in check-function-bodies) and instead
> adding a leading TAB character, thus empty lines end up containing
> just a TAB.  For usability it's better to treat empty lines as fluff
> than to uglifying the test-case and the code to properly match them.
> Double-checking, no test-case tries to match an line containing just
> TAB (by providing an a line containing just "**\s*", i.e. zero or
> more whitespace characters).
> 
> 	* lib/scanasm.exp (parse_function_bodies): Set fluff to include
> 	empty lines (besides optionally leading whitespace).
OK
jeff
diff mbox series

Patch

diff --git a/gcc/testsuite/lib/scanasm.exp b/gcc/testsuite/lib/scanasm.exp
index fb53544d40c7..be2b83a5dd48 100644
--- a/gcc/testsuite/lib/scanasm.exp
+++ b/gcc/testsuite/lib/scanasm.exp
@@ -791,7 +791,7 @@  proc parse_function_bodies { filename result } {
     set terminator {^\s*\.size}
 
     # Regexp for lines that aren't interesting.
-    set fluff {^\s*(?:\.|//|@)}
+    set fluff {^\s*(?:\.|//|@|$)}
 
     set fd [open $filename r]
     set in_function 0