We run into an xfail that sets core0file to "".

We end up doing "(gdb) core" (so, no argument) which causes the FAIL.

Tentative patch:
...
diff --git a/gdb/testsuite/gdb.threads/gcore-thread.exp b/gdb/testsuite/gdb.threads/gc
ore-thread.exp
index 2a6ab172849..434975ab612 100644
--- a/gdb/testsuite/gdb.threads/gcore-thread.exp
+++ b/gdb/testsuite/gdb.threads/gcore-thread.exp
@@ -114,29 +114,34 @@ if {"$core0file" != ""} {
 # Now restart gdb and load the corefile.
 clean_restart ${testfile}
 
-foreach name { corefile core0file } { with_test_prefix $name {
-    set core_loaded [gdb_core_cmd [subst $$name] "re-load generated corefile"]
-    if { $core_loaded == -1 } {
-       # No use proceeding from here.
+foreach name { corefile core0file } {
+    if { [subst $$name] == "" } {
        continue
     }
+    with_test_prefix $name {
+       set core_loaded [gdb_core_cmd [subst $$name] "re-load generated corefile"]
+       if { $core_loaded == -1 } {
+           # No use proceeding from here.
+           continue
+       }
 
-    # FIXME: now what can we test about the thread state?
-    # We do not know for certain that there should be at least 
-    # three threads, because who knows what kind of many-to-one
-    # mapping various OS's may do?  Let's assume that there must
-    # be at least two threads:
+       # FIXME: now what can we test about the thread state?
+       # We do not know for certain that there should be at least 
+       # three threads, because who knows what kind of many-to-one
+       # mapping various OS's may do?  Let's assume that there must
+       # be at least two threads:
 
-    gdb_test "info threads" "\\* 1 ${horiz}${nl}  2 ${horiz}.*" \
+       gdb_test "info threads" "\\* 1 ${horiz}${nl}  2 ${horiz}.*" \
            "corefile contains at least two threads"
 
-    # One thread in the corefile should be in the "thread2" function.
+       # One thread in the corefile should be in the "thread2" function.
 
-    gdb_test "info threads" ".* thread2 .*" \
+       gdb_test "info threads" ".* thread2 .*" \
            "a corefile thread is executing thread2"
 
-    # The thread2 thread should be marked as the current thread.
+       # The thread2 thread should be marked as the current thread.
 
-    gdb_test "info threads" "\\* ${horiz} thread2 .*${nl}" \
+       gdb_test "info threads" "\\* ${horiz} thread2 .*${nl}" \
            "thread2 is current thread in corefile"
-}}
+    }
+}
...

The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=043bcbaf818f0f699ff223064f3e46ee29b9cb69

commit 043bcbaf818f0f699ff223064f3e46ee29b9cb69
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Apr 6 10:40:11 2021 +0200

    [gdb/testsuite] Fix xfail handling in gdb.threads/gcore-thread.exp
    
    When running test-case gdb.threads/gcore-thread.exp on openSUSE Tumbleweed,
    I run into these XFAILs:
    ...
    XFAIL: gdb.threads/gcore-thread.exp: clear __stack_user.next
    XFAIL: gdb.threads/gcore-thread.exp: clear stack_used.next
    ...
    
    Apart from the xfail, the test-case also sets core0file to "":
    ...
            -re "No symbol \"${symbol}\" in current context\\.\r\n$gdb_prompt $" {
                xfail $test
                # Do not do the verification.
                set core0file ""
            }
    ...
    
    After which we run into this FAIL, because gdb_core_cmd fails to load a
    core file called "":
    ...
    (gdb) core ^M
    No core file now.^M
    (gdb) FAIL: gdb.threads/gcore-thread.exp: core0file: \
      re-load generated corefile
    ...
    
    Fix this FAIL by skipping gdb_core_cmd if the core file is "".
    
    Tested on x86_64-linux.
    
    gdb/testsuite/ChangeLog:
    
    2021-04-06  Tom de Vries  <tdevries@suse.de>
    
            PR testsuite/27691
            * gdb.threads/gcore-thread.exp: Don't call gdb_core_cmd with core
            file "".

Patch committed, marking resolved-fixed.