Bug 113899 - Vect module test failures while running on remote host due to default dg-do set to compile and additional-sources being used
Summary: Vect module test failures while running on remote host due to default dg-do s...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: testsuite (show other bugs)
Version: 13.2.0
: P3 normal
Target Milestone: 14.0
Assignee: Andrew Pinski
URL:
Keywords: testsuite-fail
Depends on:
Blocks:
 
Reported: 2024-02-13 08:37 UTC by sadineniharish8446
Modified: 2024-08-13 23:23 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2024-02-13 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sadineniharish8446 2024-02-13 08:37:30 UTC
We've seen a few test failures on gcc vect module, while running gcc testsuite on Yocto framework for the custom target with Remote host testing via ssh . Below is the error message,
	 xgcc: fatal error: cannot specify '-o' with '-c', '-S' or '-E' with multiple files
	 compilation terminated.
	 compiler exited with status 1
	 FAIL: gcc.dg/vect/vect-simd-clone-12.c -flto -ffat-lto-objects (test for excess errors)
	 Excess errors:
	 xgcc: fatal error: cannot specify '-o' with '-c', '-S' or '-E' with multiple files
	 compilation terminated
 
Below is the cmd causing the error:
/poky/build2-st/tmp/work/core2-64-poky-linux/gcc-runtime/13.2.0/gcc-13.2.0/build.x86_64-poky-linux.x86_64-poky-linux/gcc/xgcc -B/poky/build2-st/tmp/work/core2-64-poky-linux/gcc-runtime/13.2.0/gcc-13.2.0/build.x86_64-poky-linux.x86_64-poky-linux/gcc/  /poky/build2-st/tmp/work-shared/gcc-13.2.0-r0/gcc-13.2.0/gcc/testsuite/gcc.dg/vect/vect-simd-clone-12.c     --sysroot=/poky/build2-st/tmp/work/core2-64-poky-linux/gcc-runtime/13.2.0/recipe-sysroot -fdiagnostics-plain-output --sysroot=/poky/build2-st/tmp/work/core2-64-poky-linux/gcc-runtime/13.2.0/recipe-sysroot  -msse2 -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -fopenmp-simd  /poky/build2-st/tmp/work-shared/gcc-13.2.0-r0/gcc-13.2.0/gcc/testsuite/gcc.dg/vect/vect-simd-clone-12a.c -dumpbase "" -S -o vect-simd-clone-12.s 
There are two .c files (vect-simd-clone-12.c & vect-simd-clone-12a.c) are passed to test case.
 
As per our analysis,
- When the test suite executed on host machine (w/o Remote host testing), the '-o' option is passed with .exe file as output (eg: -dumpbase "" -o vect-simd-clone-12.exe ). In this case, the two .c files are compiled and .exe is generating and no issues with test execution.
- In remote tesing with ssh, there is an additional '-S' option is passed with "-o vect-simd-clone-12.s" (See above given test command), here the compiler is trying to compile both .c files and forced to create a single assembly file as output and fails with below error.
xgcc: fatal error: cannot specify '-o' with '-c', '-S' or '-E' with multiple files

This might be a bug in test suite when doing remote testing.
Please confirm the issue and let us know if any further inputs needed.
Comment 1 Andrew Pinski 2024-02-13 21:04:47 UTC
Confirmed.

Basically the testcases with additional-sources should always have a `{ dg-do run } ` set for them instead of doing the default (which can either be run or compile depending on what target-supports.exp sets).

There is only 2 testcases which uses additional-sources:
gcc.dg/vect/vect-simd-clone-10.c
gcc.dg/vect/vect-simd-clone-12.c


So I am going to fix those 2 to use `{ dg-do run }`
Comment 2 Andrew Pinski 2024-02-13 21:46:06 UTC
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645507.html
Comment 3 Andrew Pinski 2024-02-13 21:52:52 UTC
Note I do think there is something wrong with your remote testing too but that is only slightly related.

check_sse_hw_available should still be returning 1 there since SSE should always be available for x86_64-linux. You might want to check the full log to see why check_sse_hw_available is not working.  Maybe it is not picking up the libraries or something like that.

Maybe the run testcases are failing but you might not be noticing that.
Comment 4 GCC Commits 2024-02-14 13:41:56 UTC
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:

https://gcc.gnu.org/g:948dbc5ee45f9ffd5f41fd6782704081cc7c8c27

commit r14-8978-g948dbc5ee45f9ffd5f41fd6782704081cc7c8c27
Author: Andrew Pinski <quic_apinski@quicinc.com>
Date:   Tue Feb 13 13:39:16 2024 -0800

    vect/testsuite: Fix vect-simd-clone-1[02].c when dg-do default is compile [PR113899]
    
    The vect testsuite will chose the dg-do default based on if it knows the
    running target does not support running with the vector extensions enabled
    (for easy of testing). The problem is when it is decided the default is compile
    instead of run, dg-additional-sources does not work. So the fix is to set
    dg-do on these two testcases to run explicitly.
    
    Tested on x86_64 with a hack to check_vect_support_and_set_flags to set the dg-default
    to compile.
    
    gcc/testsuite/ChangeLog:
    
            PR testsuite/113899
            * gcc.dg/vect/vect-simd-clone-10.c: Add `dg-do run`
            * gcc.dg/vect/vect-simd-clone-12.c: Likewise.
    
    Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Comment 5 Andrew Pinski 2024-02-14 13:42:43 UTC
Fixed.
Comment 6 sadineniharish8446 2024-02-15 08:55:05 UTC
After adding given patch, vect-simd-clone-10.c & vect-simd-clone-12.c test case were not running the below error observed in gcc.sum,

ERROR: tcl error sourcing /poky/build-st/tmp/work-shared/gcc-13.2.0-r0/gcc-13.2.0/gcc/testsuite/gcc.dg/vect/vect.exp.
ERROR: tcl error code NONE
UNRESOLVED: testcase '/poky/build-st/tmp/work-shared/gcc-13.2.0-r0/gcc-13.2.0/gcc/testsuite/gcc.dg/vect/vect.exp' aborted due to Tcl error

Also as you said in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899#c3 (Maybe the run testcases are failing but you might not be noticing that.), 
I have gone through summary file and i checked a few 'dg-do run' tests and those were marked as unresolved. We have observed some failure from the gcc.log as below,
Executing on ssh: mkdir -p /tmp/runtest.3549458   (timeout = 300)
spawn [open ...]^M
kex_exchange_identification: read: Connection reset by peer^M
Connection reset by 192.168.7.2 port 22^M
ERROR: Couldn't create remote directory /tmp/runtest.3549458 on ssh
Download of ./sse_hw_available3549458.exe to ssh failed.

Executing on ssh: mkdir -p /tmp/runtest.1880844   (timeout = 300)
spawn [open ...]^M
Host key verification failed.^M
ERROR: Couldn't create remote directory /tmp/runtest.1880844 on ssh
Download of ./sse2_hw_available1880844.exe to ssh failed.

what could be the reason for this and how can we fix this? .
Comment 7 Andrew Pinski 2024-02-15 09:05:44 UTC
(In reply to sadineniharish8446 from comment #6)
> Also as you said in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899#c3
> (Maybe the run testcases are failing but you might not be noticing that.), 
> I have gone through summary file and i checked a few 'dg-do run' tests and
> those were marked as unresolved. We have observed some failure from the
> gcc.log as below,
> Executing on ssh: mkdir -p /tmp/runtest.3549458   (timeout = 300)
> spawn [open ...]^M
> kex_exchange_identification: read: Connection reset by peer^M
> Connection reset by 192.168.7.2 port 22^M
> ERROR: Couldn't create remote directory /tmp/runtest.3549458 on ssh
> Download of ./sse_hw_available3549458.exe to ssh failed.
> 
> Executing on ssh: mkdir -p /tmp/runtest.1880844   (timeout = 300)
> spawn [open ...]^M
> Host key verification failed.^M
> ERROR: Couldn't create remote directory /tmp/runtest.1880844 on ssh
> Download of ./sse2_hw_available1880844.exe to ssh failed.
> 
> what could be the reason for this and how can we fix this? .

Well it is ssh that is failing so you need to check why ssh to the host is no longer working. Note one trick is to use one ssh connection but multiple sessions which should speed up things.  See https://tutonics.com/articles/allow-multiple-ssh-sessions-over-an-existing-connection/ for more info on that.