陈龙 wrote on 07/09/2018 04:19 AM:
/Sorry ,the site
//https://docs.philips.com/:f:/r/personal/long_chen_philips_com/Documents/g++log?csf=1&e=L28vsv// have
a wrong direction,please ignore it, refer to
//https://gcc.gnu.org/ml/gcc-testresults/2018-05/msg00583.html//./
> Is that mean my test is right even if there are so many unexpected
> failures?And could I use the latest gcc version(8.1.0) before I correct
> these fails in my environment?/
Hi,
I had not the time to look further on the failing tests.
I'm just a user like yourself :-)
If you need just a working compiler then take a precompiled stable version
from the repository of your linux distribution. It will be an older version,
not the current 8.1/9 version.
The 8.1/9 version is the "developer version", ie. unfinished work-in-progress
version. This is intented for testers and gcc-developers (patch submitters etc.).
FYI: yesterday an official snapshot of v9 has been released by gccadmin:
https://gcc.gnu.org/ml/gcc/2018-07/msg00119.html
I would say yes, take the latest version, but if your program behaves
differently than expected, then remember that it could be a compiler issue.
Cheers
U.Mutlu
/Best regards,/
/CL/
At 2018-07-09 10:01:46, "陈龙" <18116491546@xxxxxxx> wrote:
/Hi,all/
/Thanks for the response./
/I know we need analyse the log if we want to deal with the failures. But
before that ,I want to confirm some things described in my first mail ,I
bring them here as below:/
//
>> I have run the testsuite of GCC and compared with results from a
similar configuration in the gcc-testresults mailing list, the results
just have a little difference,and my test summary is in chapter Summary as
below,. Both of the results have many unexpected fails, I want to know why
they failed but the g++.log couldn’t affort enough fail case
information,they were all almost described like this:'FAIL:
g++.dg/pr80481.C -std=gnu++14 scan-assembler-not vmovaps'.So was it
right with so many fails? And could you tell me how could I debug the fail
case please?Thanks.
>>
>>
>>
>> Test Environment
>>
>>
>>
>>
>> - x86_64-pc-mingw64 and msys2
>>
>> - gcc8.1.0
>>
>>
>>
>>
>> Summary
>>
>> === g++ Summary ===
>>
>> # of expected passes 115078
>> # of unexpected failures 628
>> # of unexpected successes 3
>> # of expected failures 493
>> # of unresolved testcases 5
>> # of unsupported tests 5122
>> /mingw64/bin/c++ version 8.1.0 (x86_64-posix-seh-rev0, Built by
MinGW-W64 project)
/please look at the sentence with yellow background , my test got 628
unexpected failures,which is a little of difference from the result with
a similar configuration in the gcc-testresults mailing list(refer to
//https://docs.philips.com/:f:/r/personal/long_chen_philips_com/Documents/g++log?csf=1&e=L28vsv/
<https://docs.philips.com/:f:/r/personal/long_chen_philips_com/Documents/g++log?csf=1&e=L28vsv%20>/).
Is that mean my test is right even if there are so many unexpected
failures?And could I use the latest gcc version(8.1.0) before I correct
these fails in my environment?/
/Best regards,/
/CL/
At 2018-07-06 20:54:33, "U.Mutlu" <um@xxxxxxxxxxx <mailto:um@xxxxxxxxxxx>> wrote:
>Jonathan Wakely wrote on 07/06/2018 02:20 PM:
>> On Fri, 6 Jul 2018 at 11:46, U.Mutlu <um@xxxxxxxxxxx <mailto:um@xxxxxxxxxxx>> wrote:
>>>
>>> Hello CL,
>>>
>>> [as said, I'm new to the gcc testsuite, much like you, so take my answer with
>>> grain of salt, or so to say :-)]
>>>
>>>
>>> In your original posting you had this failing example:
>>> 'FAIL: g++.dg/pr80481.C -std=gnu++14 scan-assembler-not vmovaps'
>>>
>>> The test source file pr80481.C is in the source directory under:
>>> $ find ../gcc_trunk/ -iname "pr80481.C" -print
>>> ../gcc_trunk/gcc/testsuite/g++.dg/pr80481.C
>>> and is handled by the make-target "check-c++" (see the log file of "make -k
>>> check"; you have to save that log file for reference & searching...).
>>
>> Nope, see my previous email:
>> https://gcc.gnu.org/ml/gcc-help/2018-07/msg00020.html
>>
>>> So, now in the next step you have to make the following test that will
>>> test just the "check-c++" category of the tests but with the additional
>>> flags "RUNTESTFLAGS="-v -v" as it will give more verbosity in the log file:
>>> make -k check-c++ RUNTESTFLAGS="-v -v"
>>> And again redirect the output into a log file for analysis.
>>
>> Look in $builddir/gcc/testsuite/g++/g++.log which already has the info
>> you need, and why it failed.
>
>I see, thx, but there is only the following short log excerpt with
>no indication of any "error: " entries for the said FAIL case.
>Is this maybe caused by the fact that I used "make -j ...",
>ie. is the log file maybe "garbled" by the many threads, and
>the "error: " entries are somewhere outside of this range below?
>
>
>Testing g++.dg/pr80481.C, -std=gnu++14
>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
>/data/sw/src/gcc_dev/my_build_dir_for_gcc/x86_64-linux-gnu/./libio/_G_config.h
>/data/sw/src/gcc_dev/my_build_dir_for_gcc/x86_64-linux-gnu/libio/_G_config.h
>/data/sw/src/gcc_dev/my_build_dir_for_gcc/libio/_G_config.h
>/data/sw/src/gcc_dev/libio/_G_config.h
>/data/sw/src/gcc_dev/my_build_dir_for_gcc/x86_64-linux-gnu/./libio/iostream.list
>/data/sw/src/gcc_dev/my_build_dir_for_gcc/x86_64-linux-gnu/libio/iostream.list
>/data/sw/src/gcc_dev/my_build_dir_for_gcc/libio/iostream.list
>/data/sw/src/gcc_dev/libio/iostream.list
>/sw/src/gcc_dev/gcc_trunk/gcc/testsuite/libio/Makefile.in
>/sw/src/gcc_dev/gcc_trunk/gcc/libio/Makefile.in
>/sw/src/gcc_dev/gcc_trunk/libio/Makefile.in
>/sw/src/gcc_dev/libio/Makefile.in
>doing compile
>Invoking the compiler as
>/data/sw/src/gcc_dev/my_build_dir_for_gcc/gcc/testsuite/g++3/../../xg++
>-B/data/sw/src/gcc_dev/my_build_dir_for_gcc/gcc/testsuite/g++3/../../
>/sw/src/gcc_dev/gcc_trunk/gcc/testsuite/
>Setting timeout to 300
>Executing on host:
>/data/sw/src/gcc_dev/my_build_dir_for_gcc/gcc/testsuite/g++3/../../xg++
>-B/data/sw/src/gcc_dev/my_build_dir_for_gcc/gcc/testsuite/g++3/../../
>/sw/src/gcc_dev/gcc_trunk/gcc/testsuite/g++.dg
>spawn /data/sw/src/gcc_dev/my_build_dir_for_gcc/gcc/testsuite/g++3/../../xg++
>-B/data/sw/src/gcc_dev/my_build_dir_for_gcc/gcc/testsuite/g++3/../../
>/sw/src/gcc_dev/gcc_trunk/gcc/testsuite/g++.dg/pr80481.C -f
>pid is 23149 -23149
>waitres is 23149 exp8 0 0
>output is status 0
>Checking pattern "sparc-*-sunos*" with x86_64-pc-linux-gnu
>Checking pattern "alpha*-*-*" with x86_64-pc-linux-gnu
>Checking pattern "hppa*-*-hpux*" with x86_64-pc-linux-gnu
>Checking pattern "sparc-*-sunos*" with x86_64-pc-linux-gnu
>Checking pattern "alpha*-*-*" with x86_64-pc-linux-gnu
>Checking pattern "hppa*-*-hpux*" with x86_64-pc-linux-gnu
>PASS: g++.dg/pr80481.C -std=gnu++14 (test for excess errors)
>FAIL: g++.dg/pr80481.C -std=gnu++14 scan-assembler-not vmovaps
>
