For help:Unexpected fail about testsuite of GCC
U.Mutlu
um@mutluit.com
Mon Jul 9 09:51:00 GMT 2018
陈龙 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@163.com> 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@mutluit.com <mailto:um@mutluit.com>> wrote:
> >Jonathan Wakely wrote on 07/06/2018 02:20 PM:
> >> On Fri, 6 Jul 2018 at 11:46, U.Mutlu <um@mutluit.com <mailto:um@mutluit.com>> 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
> >
>
More information about the Gcc-help
mailing list