On Tue, 24 Jul 2018 at 06:53, 陈龙 <18116491546@xxxxxxx> wrote:
>
> Hi,
>
>
> It is a great pleasure for me to got your help a while ago.Thanks.
>
>
> I got new questions about gcc version8.1.0 testsuite failure cases when I analyzed the log, there were some description I couldn't understand, please look at it below:
>
>
> Testing g++.dg/pr80481.C, -std=gnu++98
> replacement dg-process-target: `{ target { i?86-*-* x86_64-*-* } && { ! *-*-solaris* } }'
> dg-process-target-1: `{target { i?86-*-* x86_64-*-* } && { ! *-*-solaris* }}'
> replacement dg-process-target: `{target i?86-*-* x86_64-*-*}'
> dg-process-target-1: `{target i?86-*-* x86_64-*-*}'
> selector_list: ` i?86-*-* x86_64-*-* ' 1
> selector_expression: ` i?86-*-* x86_64-*-* ' 1
> C:/msys64/mingw64/././libio/_G_config.h
> /c/Users/.../Desktop/work/test/gcc-8.1.0/gcc/C:/msys64/../libio/_G_config.h
> /c/Users/.../Desktop/work/test/gcc-8.1.0/gcc/C:/../../libio/_G_config.h
> /c/Users/.../Desktop/work/test/gcc-8.1.0/gcc/../../../libio/_G_config.h
> /c/Users/.../Desktop/work/test/gcc-8.1.0/../../../../libio/_G_config.h
> C:/msys64/mingw64/././libio/iostream.list
> /c/Users/.../Desktop/work/test/gcc-8.1.0/gcc/C:/msys64/../libio/iostream.list
> /c/Users/.../Desktop/work/test/gcc-8.1.0/gcc/C:/../../libio/iostream.list
> /c/Users/.../Desktop/work/test/gcc-8.1.0/gcc/../../../libio/iostream.list
> /c/Users/.../Desktop/work/test/gcc-8.1.0/../../../../libio/iostream.list
> ./testsuite/./libio/Makefile.in
> /c/Users/.../Desktop/work/test/gcc-8.1.0/gcc/../libio/Makefile.in
> /c/Users/.../Desktop/work/test/gcc-8.1.0/../../libio/Makefile.in
> /c/Users/.../Desktop/work/test/../../../libio/Makefile.in
> /c/Users/.../Desktop/work/../../../../libio/Makefile.in
> Choosing /mingw64/bin/c++
> doing compile
> Invoking the compiler as c++ ./testsuite/g++.dg/pr80481.C -fno-diagnostics-show-caret -fdiagnostics-color=never -fmessage-length=0 -std=gnu++98 -Ofast -funroll-loops -fopenmp -march=knl -ffat-lto-objects -S -o pr80481.s
> Setting timeout to 300
> Executing on host: c++ ./testsuite/g++.dg/pr80481.C -fno-diagnostics-show-caret -fdiagnostics-color=never -fmessage-length=0 -std=gnu++98 -Ofast -funroll-loops -fopenmp -march=knl -ffat-lto-objects -S -o pr80481.s (timeout = 300)
> spawn -ignore SIGHUP c++ ./testsuite/g++.dg/pr80481.C -fno-diagnostics-show-caret -fdiagnostics-color=never -fmessage-length=0 -std=gnu++98 -Ofast -funroll-loops -fopenmp -march=knl -ffat-lto-objects -S -o pr80481.s
> pid is 172120 -172120
> pid is -1
> waitres is 172120 exp8 0 0
> output is status 0
> Checking pattern "sparc-*-sunos*" with x86_64-pc-mingw64
> Checking pattern "alpha*-*-*" with x86_64-pc-mingw64
> Checking pattern "hppa*-*-hpux*" with x86_64-pc-mingw64
> Checking pattern "sparc-*-sunos*" with x86_64-pc-mingw64
> Checking pattern "alpha*-*-*" with x86_64-pc-mingw64
> Checking pattern "hppa*-*-hpux*" with x86_64-pc-mingw64
> PASS: g++.dg/pr80481.C -std=gnu++98 (test for excess errors)
> FAIL: g++.dg/pr80481.C -std=gnu++98 scan-assembler-not vmovaps
>
>
> Q1:Does the first highlight part mean target process is a list including i?86 and x86_64?
I don't see any highlighting, this is a plain text email.
Those patterns come from the test file, not from your system. If your
system matches one of the patterns then the test will run.
> but the second highlight part show some differernt processes pattern like 'sparc','alpha','hppa',so how could I confirm which architecture the testsuite use?
Your system is x86_64-pc-mingw64.
The testsuite is comparing your target triplet (x86_64-pc-ming64) to
some other patterns to see if it matches. It doesn't mean your machine
is a sparc, alpha or hppa machine.
> Q2:The third highlight part shows different results which under the same running condition in general from the log,why is it?
I don't understand what you're asking.
The log shows that the "test for excess errors" part got a PASS,
meaning it compiled without errors. But the "scan-assembler-not
vmovaps" part got a FAIL, meaning that checking the generated code
failed. It is expected that the generated code does not contain the
vmovaps instruction, and apparently for your target that instruction
gets used.
