https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121943

            Bug ID: 121943
           Summary: Testsuite support check broken on Windows (and fragile
                    on other targets)
           Product: gcc
           Version: 16.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tmgross at umich dot edu
  Target Milestone: ---

Summary: `check_no_compiler_messages_nocache` doesn't seem to strip
nonprintable characters, meaning many tests are incorrectly skipped on Windows.

Discovered while running `dg-torture.exp` on Windows, the logs contain lines
like the following:

    UNSUPPORTED: gcc.dg/torture/float32-basic.c   -O0
    Testing torture/float32-basic.c,   -O1


This isn’t correct, `_Float32` is supported on the target. Looking at the test
file this requires `float32_runtime`, which invokes the following chain in
`gcc/testsuite/lib/target-supports.exp`:

- `check_effective_target_float32_runtime`
- `check_effective_target_float32 `
- `check_no_compiler_messages_nocache`
- `check_compile`

Applying the following patch:

```diff
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 1acfb373beb..cf8c8778d71 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -184,12 +184,20 @@ proc clear_effective_target_cache { } {

 # Like check_compile, but delete the output file and return true if the
 # compiler printed no messages.
-proc check_no_compiler_messages_nocache {args} {
-    set result [eval check_compile $args]
+proc check_no_compiler_messages_nocache {basename args} {
+    set result [eval check_compile $basename $args]
     set lines [lindex $result 0]
     set output [lindex $result 1]
     remote_file build delete $output
-    return [string match "" $lines]
+    set ret [string match "" $lines]
+
+    set lines_hex [binary encode hex [encoding convertto utf-8 $lines]]
+    verbose "$basename lines '$lines'"
+    verbose "$basename lines hex '$lines_hex'"
+    verbose "$basename out '$output'"
+    verbose "$basename ret '$ret'"
+
+    return $ret
 }

 # Like check_no_compiler_messages_nocache, but cache the result.
```

The problem isn't visible looking at the string, but shows up with the hex:

```text
Testing torture/float32-basic.c,   -O1
check_compile tool: gcc for float32
doing compile
Executing on host: ~/projects/ws-gcc/gcc-build-no-bootstrap/gcc/xgcc
-B~/projects/ws-gcc/gcc-build-no-bootstrap/gcc/     -fdiagnostics-plain-output 
 -Wno-complain-wrong-lang -c -o float32465171.o float32465171.c    (timeout =
300)
spawn -ignore SIGHUP ~/projects/ws-gcc/gcc-build-no-bootstrap/gcc/xgcc
-B~/projects/ws-gcc/gcc-build-no-bootstrap/gcc/ -fdiagnostics-plain-output
-Wno-complain-wrong-lang -c -o float32465171.o float32465171.c
pid is 476577 -476577
pid is -1
output is  status 0
float32 lines ''
float32 lines hex '1b5b366e'
float32 out 'float32465171.o'
float32 ret '0'
UNSUPPORTED: gcc.dg/torture/float32-basic.c   -O1
```

The output seems to contain an escape sequence `ESC[6n` so the checks
incorrectly thinks `_Float32` is unsupported. I am not sure where this is
coming from, there is no output when running the same commands in shell.

This could probably be fixed by stripping nonprintable characters from the
output. However, why is this doing string comparison in the first place? It
seems like checking the exit code would be more robust.

Reply via email to