* Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 @ 2019-04-15 15:22 Rainer Emrich 2019-04-15 15:30 ` Rainer Emrich 0 siblings, 1 reply; 16+ messages in thread From: Rainer Emrich @ 2019-04-15 15:22 UTC (permalink / raw) To: gcc Mailing List [-- Attachment #1.1: Type: text/plain, Size: 2033 bytes --] Today I had the chance to bootstrap and runthe testsuite for trunk on x86_64-w64-mingw32. Bootstrap is done with all supported languages enabled including "D". Testsuite results can be found here: https://gcc.gnu.org/ml/gcc-testresults/2019-04/msg01795.html Complete logs here: https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W There's are two issues with the gdc testsuite. 1. The failed tests are printed twenty times to the test_summary.txt file. 2. couldn't open "gdc.test/compilable/99bottles.d" ERROR: tcl error sourcing /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp. ERROR: couldn't open "gdc.test/compilable/99bottles.d": no such file or directory while executing "open $file r" (procedure "grep" line 19) invoked from within "grep $prog "{\[ \t\]\+dg-\[-a-z\]\+\[ \t\]\+.*\[ \t\]\+}" line" (procedure "dg-get-options" line 4) invoked from within "dg-get-options $prog" (procedure "saved-dg-test" line 75) invoked from within "saved-dg-test gdc.test/compilable/99bottles.d { } -I/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/compilable" ("eval" body line 1) invoked from within "eval saved-dg-test $args " (procedure "dg-test" line 4) invoked from within "dg-test $test "$flags $flags_t" ${default-extra-flags}" (procedure "gdc-dg-runtest" line 23) invoked from within "gdc-dg-runtest $filename $flags $imports" (procedure "gdc-do-test" line 86) invoked from within "gdc-do-test" (file "/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp" line 465) invoked from within "source /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp" invoked from within "catch "uplevel #0 source $test_file_name"" Hope this is of any help [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-15 15:22 Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 Rainer Emrich @ 2019-04-15 15:30 ` Rainer Emrich 2019-04-15 15:38 ` Jakub Jelinek 0 siblings, 1 reply; 16+ messages in thread From: Rainer Emrich @ 2019-04-15 15:30 UTC (permalink / raw) To: gcc Mailing List [-- Attachment #1.1: Type: text/plain, Size: 6399 bytes --] Am 15.04.2019 um 17:22 schrieb Rainer Emrich: > Today I had the chance to bootstrap and runthe testsuite for trunk on > x86_64-w64-mingw32. Bootstrap is done with all supported languages > enabled including "D". > > Testsuite results can be found here: > https://gcc.gnu.org/ml/gcc-testresults/2019-04/msg01795.html > > Complete logs here: > https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W > > There's are two issues with the gdc testsuite. > 1. The failed tests are printed twenty times to the test_summary.txt file. > > 2. couldn't open "gdc.test/compilable/99bottles.d" > ERROR: tcl error sourcing > /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp. > ERROR: couldn't open "gdc.test/compilable/99bottles.d": no such file or > directory > while executing > "open $file r" > (procedure "grep" line 19) > invoked from within > "grep $prog "{\[ \t\]\+dg-\[-a-z\]\+\[ \t\]\+.*\[ \t\]\+}" line" > (procedure "dg-get-options" line 4) > invoked from within > "dg-get-options $prog" > (procedure "saved-dg-test" line 75) > invoked from within > "saved-dg-test gdc.test/compilable/99bottles.d { } > -I/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/compilable" > ("eval" body line 1) > invoked from within > "eval saved-dg-test $args " > (procedure "dg-test" line 4) > invoked from within > "dg-test $test "$flags $flags_t" ${default-extra-flags}" > (procedure "gdc-dg-runtest" line 23) > invoked from within > "gdc-dg-runtest $filename $flags $imports" > (procedure "gdc-do-test" line 86) > invoked from within > "gdc-do-test" > (file > "/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp" > line 465) > invoked from within > "source > /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp" > ("uplevel" body line 1) > invoked from within > "uplevel #0 source > /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp" > invoked from within > "catch "uplevel #0 source $test_file_name"" > > Hope this is of any help > There seems to be a generic issue with the tests in gcc/testsuite. The log files do not contain the logs. g++.log contains the following for example: Test run by rainer on Mon Apr 15 10:52:52 2019 Native configuration is x86_64-w64-mingw32 === g++ tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/asan/asan.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/bprob/bprob.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/charset/charset.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/compat/compat.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/compat/struct-layout-1.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/debug/debug.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/dfp/dfp.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/dg.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/gcov/gcov.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/goacc-gomp/goacc-gomp.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/goacc/goacc.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/gomp/gomp.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/graphite/graphite.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/guality/guality.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/lto/lto.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/pch/pch.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/plugin/plugin.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/simulate-thread/simulate-thread.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/special/ecos.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/tls/tls.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/tm/tm.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/torture/dg-torture.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/torture/stackalign/stackalign.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/tree-prof/tree-prof.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/tsan/tsan.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/ubsan/ubsan.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/vect/vect.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.old-deja/old-deja.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.target/aarch64/aarch64.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.target/aarch64/sve/aarch64-sve.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.target/arm/arm.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.target/i386/i386.exp ... Running /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.target/riscv/riscv.exp ... === g++ Summary === # of expected passes 124159 # of unexpected failures 796 # of unexpected successes 3 # of expected failures 530 # of unresolved testcases 5 # of unsupported tests 6068 runtest completed at Mon Apr 15 14:23:42 2019 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-15 15:30 ` Rainer Emrich @ 2019-04-15 15:38 ` Jakub Jelinek 2019-04-15 15:43 ` Rainer Emrich 0 siblings, 1 reply; 16+ messages in thread From: Jakub Jelinek @ 2019-04-15 15:38 UTC (permalink / raw) To: Rainer Emrich; +Cc: gcc Mailing List On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: > There seems to be a generic issue with the tests in gcc/testsuite. The > log files do not contain the logs. Perhaps contrib/dg-extract-results* misbehaved? Can you look for the testsuite/g++*/g++.log.sep files? Do they contain everything? If yes, can you try to say mv contrib/dg-extract-results.py{,.bad} and retry, to see if there isn't a problem with the python version thereof? Jakub ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-15 15:38 ` Jakub Jelinek @ 2019-04-15 15:43 ` Rainer Emrich 2019-04-15 18:12 ` Rainer Emrich 0 siblings, 1 reply; 16+ messages in thread From: Rainer Emrich @ 2019-04-15 15:43 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc Mailing List [-- Attachment #1.1: Type: text/plain, Size: 694 bytes --] Am 15.04.2019 um 17:38 schrieb Jakub Jelinek: > On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: >> There seems to be a generic issue with the tests in gcc/testsuite. The >> log files do not contain the logs. > > Perhaps contrib/dg-extract-results* misbehaved? > Can you look for the testsuite/g++*/g++.log.sep files? Do they contain > everything? > If yes, can you try to say > mv contrib/dg-extract-results.py{,.bad} > and retry, to see if there isn't a problem with the python version thereof? Unfortunately I already deleted the build directory. So, I will run a new bootstrap an testsuite run reduced with reduced languages. Will take some hours. Rainer [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-15 15:43 ` Rainer Emrich @ 2019-04-15 18:12 ` Rainer Emrich 2019-04-16 9:59 ` Rainer Emrich 0 siblings, 1 reply; 16+ messages in thread From: Rainer Emrich @ 2019-04-15 18:12 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc Mailing List [-- Attachment #1.1: Type: text/plain, Size: 667 bytes --] Am 15.04.2019 um 17:43 schrieb Rainer Emrich: > Am 15.04.2019 um 17:38 schrieb Jakub Jelinek: >> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: >>> There seems to be a generic issue with the tests in gcc/testsuite. The >>> log files do not contain the logs. >> >> Perhaps contrib/dg-extract-results* misbehaved? >> Can you look for the testsuite/g++*/g++.log.sep files? Do they contain >> everything? The *.log.sep files seem to be ok. >> If yes, can you try to say >> mv contrib/dg-extract-results.py{,.bad} >> and retry, to see if there isn't a problem with the python version thereof? I will try this over the night. Rainer [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-15 18:12 ` Rainer Emrich @ 2019-04-16 9:59 ` Rainer Emrich 2019-04-16 11:04 ` dg-extract-results broken since rev 268511, was " Rainer Emrich 0 siblings, 1 reply; 16+ messages in thread From: Rainer Emrich @ 2019-04-16 9:59 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc Mailing List [-- Attachment #1.1: Type: text/plain, Size: 1022 bytes --] Am 15.04.2019 um 20:12 schrieb Rainer Emrich: > Am 15.04.2019 um 17:43 schrieb Rainer Emrich: >> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek: >>> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: >>>> There seems to be a generic issue with the tests in gcc/testsuite. The >>>> log files do not contain the logs. >>> >>> Perhaps contrib/dg-extract-results* misbehaved? >>> Can you look for the testsuite/g++*/g++.log.sep files? Do they contain >>> everything? > The *.log.sep files seem to be ok. > >>> If yes, can you try to say >>> mv contrib/dg-extract-results.py{,.bad} >>> and retry, to see if there isn't a problem with the python version thereof? > I will try this over the night. The shell version of dg-extract-results does not work either. AFAIS, there were changes to the dg-extract-results script 5th of March. Looks like these changes are causing the issue, but I'm not sure. What I can say, my setup works at least for the gcc-8 branch and used to work in the past. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-16 9:59 ` Rainer Emrich @ 2019-04-16 11:04 ` Rainer Emrich 2019-04-16 12:11 ` Christophe Lyon 0 siblings, 1 reply; 16+ messages in thread From: Rainer Emrich @ 2019-04-16 11:04 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc Mailing List, christophe.lyon [-- Attachment #1.1: Type: text/plain, Size: 1393 bytes --] Am 16.04.2019 um 11:59 schrieb Rainer Emrich: > Am 15.04.2019 um 20:12 schrieb Rainer Emrich: >> Am 15.04.2019 um 17:43 schrieb Rainer Emrich: >>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek: >>>> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: >>>>> There seems to be a generic issue with the tests in gcc/testsuite. The >>>>> log files do not contain the logs. >>>> >>>> Perhaps contrib/dg-extract-results* misbehaved? >>>> Can you look for the testsuite/g++*/g++.log.sep files? Do they contain >>>> everything? >> The *.log.sep files seem to be ok. >> >>>> If yes, can you try to say >>>> mv contrib/dg-extract-results.py{,.bad} >>>> and retry, to see if there isn't a problem with the python version thereof? >> I will try this over the night. > The shell version of dg-extract-results does not work either. > > AFAIS, there were changes to the dg-extract-results script 5th of March. > Looks like these changes are causing the issue, but I'm not sure. > > What I can say, my setup works at least for the gcc-8 branch and used to > work in the past. I tested dg-extractresults.sh manually and found that the change from 4th of February, revision 268411 broke the log extraction. Easy to test with version from 23rd of September last year which works. I don't have the time to analyze the python version, but my bet, it's the same issue. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-16 11:04 ` dg-extract-results broken since rev 268511, was " Rainer Emrich @ 2019-04-16 12:11 ` Christophe Lyon 2019-04-16 12:35 ` Rainer Emrich 0 siblings, 1 reply; 16+ messages in thread From: Christophe Lyon @ 2019-04-16 12:11 UTC (permalink / raw) To: Rainer Emrich; +Cc: Jakub Jelinek, gcc Mailing List, Christophe Lyon Linaro On Tue, 16 Apr 2019 at 13:04, Rainer Emrich <rainer@emrich-ebersheim.de> wrote: > > Am 16.04.2019 um 11:59 schrieb Rainer Emrich: > > Am 15.04.2019 um 20:12 schrieb Rainer Emrich: > >> Am 15.04.2019 um 17:43 schrieb Rainer Emrich: > >>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek: > >>>> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: > >>>>> There seems to be a generic issue with the tests in gcc/testsuite. The > >>>>> log files do not contain the logs. > >>>> > >>>> Perhaps contrib/dg-extract-results* misbehaved? > >>>> Can you look for the testsuite/g++*/g++.log.sep files? Do they contain > >>>> everything? > >> The *.log.sep files seem to be ok. > >> > >>>> If yes, can you try to say > >>>> mv contrib/dg-extract-results.py{,.bad} > >>>> and retry, to see if there isn't a problem with the python version thereof? > >> I will try this over the night. > > The shell version of dg-extract-results does not work either. > > > > AFAIS, there were changes to the dg-extract-results script 5th of March. > > Looks like these changes are causing the issue, but I'm not sure. > > > > What I can say, my setup works at least for the gcc-8 branch and used to > > work in the past. > I tested dg-extractresults.sh manually and found that the change from > 4th of February, revision 268411 broke the log extraction. Easy to test > with version from 23rd of September last year which works. > > I don't have the time to analyze the python version, but my bet, it's > the same issue. > Hi, Sorry for the breakage, I really wanted to improve those scripts. Could you give me a reproducer, since we didn't notice problems in our validations? Thanks, Christophe ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-16 12:11 ` Christophe Lyon @ 2019-04-16 12:35 ` Rainer Emrich 2019-04-16 12:49 ` Christophe Lyon 0 siblings, 1 reply; 16+ messages in thread From: Rainer Emrich @ 2019-04-16 12:35 UTC (permalink / raw) To: Christophe Lyon; +Cc: Jakub Jelinek, gcc Mailing List [-- Attachment #1.1: Type: text/plain, Size: 2227 bytes --] Am 16.04.2019 um 14:10 schrieb Christophe Lyon: > On Tue, 16 Apr 2019 at 13:04, Rainer Emrich <rainer@emrich-ebersheim.de> wrote: >> >> Am 16.04.2019 um 11:59 schrieb Rainer Emrich: >>> Am 15.04.2019 um 20:12 schrieb Rainer Emrich: >>>> Am 15.04.2019 um 17:43 schrieb Rainer Emrich: >>>>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek: >>>>>> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: >>>>>>> There seems to be a generic issue with the tests in gcc/testsuite. The >>>>>>> log files do not contain the logs. >>>>>> >>>>>> Perhaps contrib/dg-extract-results* misbehaved? >>>>>> Can you look for the testsuite/g++*/g++.log.sep files? Do they contain >>>>>> everything? >>>> The *.log.sep files seem to be ok. >>>> >>>>>> If yes, can you try to say >>>>>> mv contrib/dg-extract-results.py{,.bad} >>>>>> and retry, to see if there isn't a problem with the python version thereof? >>>> I will try this over the night. >>> The shell version of dg-extract-results does not work either. >>> >>> AFAIS, there were changes to the dg-extract-results script 5th of March. >>> Looks like these changes are causing the issue, but I'm not sure. >>> >>> What I can say, my setup works at least for the gcc-8 branch and used to >>> work in the past. >> I tested dg-extractresults.sh manually and found that the change from >> 4th of February, revision 268411 broke the log extraction. Easy to test >> with version from 23rd of September last year which works. >> >> I don't have the time to analyze the python version, but my bet, it's >> the same issue. >> > Hi, > > Sorry for the breakage, I really wanted to improve those scripts. > Could you give me a reproducer, since we didn't notice problems in our > validations? Hi Christope, I executed the dg-extract-results.sh manually in the gcc/testsuite directory after a complete testsuite run which didn't give the correct results. Rev. 240429 gives the expected results, where rev 268511 fails. I'm on windows using msys2 with bash 4.4.23. I'm bootsrapping at the moment but that's really slow on windows. When the testsuite run is finished I try to assemble a reproducer. This will take a while. Thanks, Rainer [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-16 12:35 ` Rainer Emrich @ 2019-04-16 12:49 ` Christophe Lyon 2019-04-16 13:00 ` Rainer Emrich 2019-04-16 13:44 ` Jakub Jelinek 0 siblings, 2 replies; 16+ messages in thread From: Christophe Lyon @ 2019-04-16 12:49 UTC (permalink / raw) To: Rainer Emrich; +Cc: Jakub Jelinek, gcc Mailing List On Tue, 16 Apr 2019 at 14:34, Rainer Emrich <rainer@emrich-ebersheim.de> wrote: > > Am 16.04.2019 um 14:10 schrieb Christophe Lyon: > > On Tue, 16 Apr 2019 at 13:04, Rainer Emrich <rainer@emrich-ebersheim.de> wrote: > >> > >> Am 16.04.2019 um 11:59 schrieb Rainer Emrich: > >>> Am 15.04.2019 um 20:12 schrieb Rainer Emrich: > >>>> Am 15.04.2019 um 17:43 schrieb Rainer Emrich: > >>>>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek: > >>>>>> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: > >>>>>>> There seems to be a generic issue with the tests in gcc/testsuite. The > >>>>>>> log files do not contain the logs. > >>>>>> > >>>>>> Perhaps contrib/dg-extract-results* misbehaved? > >>>>>> Can you look for the testsuite/g++*/g++.log.sep files? Do they contain > >>>>>> everything? > >>>> The *.log.sep files seem to be ok. > >>>> > >>>>>> If yes, can you try to say > >>>>>> mv contrib/dg-extract-results.py{,.bad} > >>>>>> and retry, to see if there isn't a problem with the python version thereof? > >>>> I will try this over the night. > >>> The shell version of dg-extract-results does not work either. > >>> > >>> AFAIS, there were changes to the dg-extract-results script 5th of March. > >>> Looks like these changes are causing the issue, but I'm not sure. > >>> > >>> What I can say, my setup works at least for the gcc-8 branch and used to > >>> work in the past. > >> I tested dg-extractresults.sh manually and found that the change from > >> 4th of February, revision 268411 broke the log extraction. Easy to test > >> with version from 23rd of September last year which works. > >> > >> I don't have the time to analyze the python version, but my bet, it's > >> the same issue. > >> > > Hi, > > > > Sorry for the breakage, I really wanted to improve those scripts. > > Could you give me a reproducer, since we didn't notice problems in our > > validations? > Hi Christope, > > I executed the dg-extract-results.sh manually in the gcc/testsuite > directory after a complete testsuite run which didn't give the correct > results. Rev. 240429 gives the expected results, where rev 268511 fails. > I'm on windows using msys2 with bash 4.4.23. > > I'm bootsrapping at the moment but that's really slow on windows. When > the testsuite run is finished I try to assemble a reproducer. This will > take a while. > OK, thanks! Do you mean the problem happens on Windows only? > Thanks, > > Rainer > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-16 12:49 ` Christophe Lyon @ 2019-04-16 13:00 ` Rainer Emrich 2019-04-16 13:44 ` Jakub Jelinek 1 sibling, 0 replies; 16+ messages in thread From: Rainer Emrich @ 2019-04-16 13:00 UTC (permalink / raw) To: Christophe Lyon; +Cc: Jakub Jelinek, gcc Mailing List [-- Attachment #1.1: Type: text/plain, Size: 2880 bytes --] Am 16.04.2019 um 14:49 schrieb Christophe Lyon: > On Tue, 16 Apr 2019 at 14:34, Rainer Emrich <rainer@emrich-ebersheim.de> wrote: >> >> Am 16.04.2019 um 14:10 schrieb Christophe Lyon: >>> On Tue, 16 Apr 2019 at 13:04, Rainer Emrich <rainer@emrich-ebersheim.de> wrote: >>>> >>>> Am 16.04.2019 um 11:59 schrieb Rainer Emrich: >>>>> Am 15.04.2019 um 20:12 schrieb Rainer Emrich: >>>>>> Am 15.04.2019 um 17:43 schrieb Rainer Emrich: >>>>>>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek: >>>>>>>> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: >>>>>>>>> There seems to be a generic issue with the tests in gcc/testsuite. The >>>>>>>>> log files do not contain the logs. >>>>>>>> >>>>>>>> Perhaps contrib/dg-extract-results* misbehaved? >>>>>>>> Can you look for the testsuite/g++*/g++.log.sep files? Do they contain >>>>>>>> everything? >>>>>> The *.log.sep files seem to be ok. >>>>>> >>>>>>>> If yes, can you try to say >>>>>>>> mv contrib/dg-extract-results.py{,.bad} >>>>>>>> and retry, to see if there isn't a problem with the python version thereof? >>>>>> I will try this over the night. >>>>> The shell version of dg-extract-results does not work either. >>>>> >>>>> AFAIS, there were changes to the dg-extract-results script 5th of March. >>>>> Looks like these changes are causing the issue, but I'm not sure. >>>>> >>>>> What I can say, my setup works at least for the gcc-8 branch and used to >>>>> work in the past. >>>> I tested dg-extractresults.sh manually and found that the change from >>>> 4th of February, revision 268411 broke the log extraction. Easy to test >>>> with version from 23rd of September last year which works. >>>> >>>> I don't have the time to analyze the python version, but my bet, it's >>>> the same issue. >>>> >>> Hi, >>> >>> Sorry for the breakage, I really wanted to improve those scripts. >>> Could you give me a reproducer, since we didn't notice problems in our >>> validations? >> Hi Christope, >> >> I executed the dg-extract-results.sh manually in the gcc/testsuite >> directory after a complete testsuite run which didn't give the correct >> results. Rev. 240429 gives the expected results, where rev 268511 fails. >> I'm on windows using msys2 with bash 4.4.23. >> >> I'm bootsrapping at the moment but that's really slow on windows. When >> the testsuite run is finished I try to assemble a reproducer. This will >> take a while. >> > > OK, thanks! Do you mean the problem happens on Windows only? I don't know at the moment, because im only bootstrapping and testing on windows on a semi regular basis. AFAIK I'm the only person which is doing semi regular testsuite runs on windows and pushing the results to gcc-testresults mailing list. I doubt that I will find the time for bootstrapping and running the testsuite on linux in the next few days. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-16 12:49 ` Christophe Lyon 2019-04-16 13:00 ` Rainer Emrich @ 2019-04-16 13:44 ` Jakub Jelinek 2019-04-16 15:36 ` Jakub Jelinek 2019-04-16 15:48 ` Martin Jambor 1 sibling, 2 replies; 16+ messages in thread From: Jakub Jelinek @ 2019-04-16 13:44 UTC (permalink / raw) To: Christophe Lyon; +Cc: Rainer Emrich, gcc Mailing List On Tue, Apr 16, 2019 at 02:49:13PM +0200, Christophe Lyon wrote: > > I executed the dg-extract-results.sh manually in the gcc/testsuite > > directory after a complete testsuite run which didn't give the correct > > results. Rev. 240429 gives the expected results, where rev 268511 fails. > > I'm on windows using msys2 with bash 4.4.23. > > > > I'm bootsrapping at the moment but that's really slow on windows. When > > the testsuite run is finished I try to assemble a reproducer. This will > > take a while. > > > > OK, thanks! Do you mean the problem happens on Windows only? It is not on Windows only, I e.g. see the same problem on Linux too, unfortunately only when doing package builds. E.g. https://kojipkgs.fedoraproject.org//work/tasks/3883/34193883/build.log In the ===TESTING=== section where it emits result of contrib/test_summary the results look reasonable (though, the ordering looks random-ish even when it is always LC_ALL=C, so if there are multiple FAILs, diffing them from one build to another has -FAIL and +FAIL lines for the same tests), but if you uudecode the file (with more recent uudecode one needs to extract the begin ... end part manually, what a progress :( ) in the tarball any *.log files changed with dg-extract-results.py contain just Running lines and no further details. Others like libgomp.log are complete, but those are not merged. I get those almost empty *.log files even after rm -f contrib/dg-extract-results.py (which should force the *.sh version). I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though, the *.log files are complete there. And I have no idea if it was introduced with your change or earlier. Jakub ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-16 13:44 ` Jakub Jelinek @ 2019-04-16 15:36 ` Jakub Jelinek 2019-04-16 15:57 ` Rainer Emrich 2019-04-16 19:27 ` Christophe Lyon 2019-04-16 15:48 ` Martin Jambor 1 sibling, 2 replies; 16+ messages in thread From: Jakub Jelinek @ 2019-04-16 15:36 UTC (permalink / raw) To: Christophe Lyon, David Malcolm; +Cc: Rainer Emrich, gcc Mailing List On Tue, Apr 16, 2019 at 03:44:44PM +0200, Jakub Jelinek wrote: > I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though, > the *.log files are complete there. > > And I have no idea if it was introduced with your change or earlier. Actually, I managed to reproduce in a Fedora 31 chroot, in which I don't have /usr/bin/python installed (I think in Fedora 30+ there is /usr/bin/python2 and /usr/bin/python3 but not /usr/bin/python, at least not in the default buildroot). The changes to contrib/dg-extract-results.sh look wrong to me: --- contrib/dg-extract-results.sh 2018-04-25 09:40:40.139659386 +0200 +++ contrib/dg-extract-results.sh 2019-03-05 21:49:34.471573434 +0100 @@ -298,6 +298,8 @@ BEGIN { cnt=0 print_using=0 need_close=0 + has_timeout=0 + timeout_cnt=0 } /^EXPFILE: / { expfiles[expfileno] = \$2 @@ -329,16 +331,37 @@ BEGIN { # Ugly hack for gfortran.dg/dg.exp if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//) testname="h"testname + if (\$1 == "WARNING:" && \$2 == "program" && \$3 == "timed" && (\$4 == "out" || \$4 == "out.")) { + has_timeout=1 + timeout_cnt=cnt + } else { + # Prepare timeout replacement message in case it's needed + timeout_msg=\$0 + sub(\$1, "WARNING:", timeout_msg) + } } /^$/ { if ("$MODE" == "sum") next } { if (variant == curvar && curfile) { if ("$MODE" == "sum") { - printf "%s %08d|", testname, cnt >> curfile - cnt = cnt + 1 + # Do not print anything if the current line is a timeout + if (has_timeout == 0) { + # If the previous line was a timeout, + # insert the full current message without keyword + if (timeout_cnt != 0) { + printf "%s %08d|%s program timed out.\n", testname, timeout_cnt, timeout_msg >> curfile + timeout_cnt = 0 + cnt = cnt + 1 + } + printf "%s %08d|", testname, cnt >> curfile + cnt = cnt + 1 + filewritten[curfile]=1 + need_close=1 + if (timeout_cnt == 0) + print >> curfile + } + + has_timeout=0 } - filewritten[curfile]=1 - need_close=1 - print >> curfile } else next } First of all, I don't see why the WARNING: program timed out stuff should be handled in any way specially in -L mode, there is no sorting at all and all the lines go together. But more importantly, the above changes broke completely the -L mode, previously the filewritten, need_close and print lines were done for both sum and log modes, but now they are done only in the sum mode (and in that case only if has_timeout is 0, which is desirable). I believe the following patch should fix it, but I don't actually have any WARNING: program timed out lines in my *.sep files in any of the last 12 bootstraps I have around. Additionally, perhaps we should change dg-extract-results.sh, so that it doesn't try just python, but also python3? I think in some distros /usr/bin/python even warns users that they should decide if they mean python2 or python3. 2019-04-16 Jakub Jelinek <jakub@redhat.com> * dg-extract-results.sh: Only handle WARNING: program timed out lines specially in "$MODE" == "sum". Restore previous behavior for "$MODE" != "sum". Clear has_timeout and timeout_cnt if in a different variant or curfile is empty. * dg-extract-results.py: Fix a typo. --- contrib/dg-extract-results.sh.jj 2019-03-05 21:49:34.471573434 +0100 +++ contrib/dg-extract-results.sh 2019-04-16 17:09:02.710004553 +0200 @@ -331,13 +331,15 @@ BEGIN { # Ugly hack for gfortran.dg/dg.exp if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//) testname="h"testname - if (\$1 == "WARNING:" && \$2 == "program" && \$3 == "timed" && (\$4 == "out" || \$4 == "out.")) { - has_timeout=1 - timeout_cnt=cnt - } else { - # Prepare timeout replacement message in case it's needed - timeout_msg=\$0 - sub(\$1, "WARNING:", timeout_msg) + if ("$MODE" == "sum") { + if (\$0 ^ /^WARNING: program timed out/) { + has_timeout=1 + timeout_cnt=cnt + } else { + # Prepare timeout replacement message in case it's needed + timeout_msg=\$0 + sub(\$1, "WARNING:", timeout_msg) + } } } /^$/ { if ("$MODE" == "sum") next } @@ -345,25 +347,30 @@ BEGIN { if ("$MODE" == "sum") { # Do not print anything if the current line is a timeout if (has_timeout == 0) { - # If the previous line was a timeout, - # insert the full current message without keyword - if (timeout_cnt != 0) { - printf "%s %08d|%s program timed out.\n", testname, timeout_cnt, timeout_msg >> curfile - timeout_cnt = 0 - cnt = cnt + 1 - } - printf "%s %08d|", testname, cnt >> curfile - cnt = cnt + 1 - filewritten[curfile]=1 - need_close=1 - if (timeout_cnt == 0) - print >> curfile + # If the previous line was a timeout, + # insert the full current message without keyword + if (timeout_cnt != 0) { + printf "%s %08d|%s program timed out.\n", testname, timeout_cnt, timeout_msg >> curfile + timeout_cnt = 0 + cnt = cnt + 1 + } + printf "%s %08d|", testname, cnt >> curfile + cnt = cnt + 1 + filewritten[curfile]=1 + need_close=1 + print >> curfile } - has_timeout=0 + } else { + filewritten[curfile]=1 + need_close=1 + print >> curfile } - } else + } else { + has_timeout=0 + timeout_cnt=0 next + } } END { n=1 --- contrib/dg-extract-results.py.jj 2019-03-05 21:49:34.471573434 +0100 +++ contrib/dg-extract-results.py 2019-04-16 17:14:54.447248209 +0200 @@ -296,7 +296,7 @@ class Prog: # If we have a time out warning, make sure it appears # before the following testcase diagnostic: we insert # the testname before 'program' so that sort faces a - # list of testhanes. + # list of testnames. if line.startswith ('WARNING: program timed out'): has_warning = 1 else: Jakub ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-16 15:36 ` Jakub Jelinek @ 2019-04-16 15:57 ` Rainer Emrich 2019-04-16 19:27 ` Christophe Lyon 1 sibling, 0 replies; 16+ messages in thread From: Rainer Emrich @ 2019-04-16 15:57 UTC (permalink / raw) To: Jakub Jelinek, Christophe Lyon, David Malcolm; +Cc: gcc Mailing List [-- Attachment #1.1: Type: text/plain, Size: 3558 bytes --] Am 16.04.2019 um 17:36 schrieb Jakub Jelinek: > On Tue, Apr 16, 2019 at 03:44:44PM +0200, Jakub Jelinek wrote: >> I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though, >> the *.log files are complete there. >> >> And I have no idea if it was introduced with your change or earlier. > > Actually, I managed to reproduce in a Fedora 31 chroot, in which I don't > have /usr/bin/python installed (I think in Fedora 30+ there is > /usr/bin/python2 and /usr/bin/python3 but not /usr/bin/python, at least not > in the default buildroot). On msys2 there is no python executable but /usr/bin/python2. Optionally you may install python3. > > The changes to contrib/dg-extract-results.sh look wrong to me: > --- contrib/dg-extract-results.sh 2018-04-25 09:40:40.139659386 +0200 > +++ contrib/dg-extract-results.sh 2019-03-05 21:49:34.471573434 +0100 > @@ -298,6 +298,8 @@ BEGIN { > cnt=0 > print_using=0 > need_close=0 > + has_timeout=0 > + timeout_cnt=0 > } > /^EXPFILE: / { > expfiles[expfileno] = \$2 > @@ -329,16 +331,37 @@ BEGIN { > # Ugly hack for gfortran.dg/dg.exp > if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//) > testname="h"testname > + if (\$1 == "WARNING:" && \$2 == "program" && \$3 == "timed" && (\$4 == "out" || \$4 == "out.")) { > + has_timeout=1 > + timeout_cnt=cnt > + } else { > + # Prepare timeout replacement message in case it's needed > + timeout_msg=\$0 > + sub(\$1, "WARNING:", timeout_msg) > + } > } > /^$/ { if ("$MODE" == "sum") next } > { if (variant == curvar && curfile) { > if ("$MODE" == "sum") { > - printf "%s %08d|", testname, cnt >> curfile > - cnt = cnt + 1 > + # Do not print anything if the current line is a timeout > + if (has_timeout == 0) { > + # If the previous line was a timeout, > + # insert the full current message without keyword > + if (timeout_cnt != 0) { > + printf "%s %08d|%s program timed out.\n", testname, timeout_cnt, timeout_msg >> curfile > + timeout_cnt = 0 > + cnt = cnt + 1 > + } > + printf "%s %08d|", testname, cnt >> curfile > + cnt = cnt + 1 > + filewritten[curfile]=1 > + need_close=1 > + if (timeout_cnt == 0) > + print >> curfile > + } > + > + has_timeout=0 > } > - filewritten[curfile]=1 > - need_close=1 > - print >> curfile > } else > next > } > First of all, I don't see why the WARNING: program timed out > stuff should be handled in any way specially in -L mode, there is no sorting > at all and all the lines go together. But more importantly, the above > changes broke completely the -L mode, previously the filewritten, need_close > and print lines were done for both sum and log modes, but now they are done > only in the sum mode (and in that case only if has_timeout is 0, which is > desirable). > > I believe the following patch should fix it, but I don't actually have any > WARNING: program timed out > lines in my *.sep files in any of the last 12 bootstraps I have around. I do have several "program timed out" in libgomp, so I may test this. > > Additionally, perhaps we should change dg-extract-results.sh, so that it > doesn't try just python, but also python3? I think in some distros > /usr/bin/python even warns users that they should decide if they mean > python2 or python3. As explained above I vote for this change. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-16 15:36 ` Jakub Jelinek 2019-04-16 15:57 ` Rainer Emrich @ 2019-04-16 19:27 ` Christophe Lyon 1 sibling, 0 replies; 16+ messages in thread From: Christophe Lyon @ 2019-04-16 19:27 UTC (permalink / raw) To: Jakub Jelinek; +Cc: David Malcolm, Rainer Emrich, gcc Mailing List On Tue, 16 Apr 2019 at 17:36, Jakub Jelinek <jakub@redhat.com> wrote: > > On Tue, Apr 16, 2019 at 03:44:44PM +0200, Jakub Jelinek wrote: > > I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though, > > the *.log files are complete there. > > > > And I have no idea if it was introduced with your change or earlier. > > Actually, I managed to reproduce in a Fedora 31 chroot, in which I don't > have /usr/bin/python installed (I think in Fedora 30+ there is > /usr/bin/python2 and /usr/bin/python3 but not /usr/bin/python, at least not > in the default buildroot). > > The changes to contrib/dg-extract-results.sh look wrong to me: > --- contrib/dg-extract-results.sh 2018-04-25 09:40:40.139659386 +0200 > +++ contrib/dg-extract-results.sh 2019-03-05 21:49:34.471573434 +0100 > @@ -298,6 +298,8 @@ BEGIN { > cnt=0 > print_using=0 > need_close=0 > + has_timeout=0 > + timeout_cnt=0 > } > /^EXPFILE: / { > expfiles[expfileno] = \$2 > @@ -329,16 +331,37 @@ BEGIN { > # Ugly hack for gfortran.dg/dg.exp > if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//) > testname="h"testname > + if (\$1 == "WARNING:" && \$2 == "program" && \$3 == "timed" && (\$4 == "out" || \$4 == "out.")) { > + has_timeout=1 > + timeout_cnt=cnt > + } else { > + # Prepare timeout replacement message in case it's needed > + timeout_msg=\$0 > + sub(\$1, "WARNING:", timeout_msg) > + } > } > /^$/ { if ("$MODE" == "sum") next } > { if (variant == curvar && curfile) { > if ("$MODE" == "sum") { > - printf "%s %08d|", testname, cnt >> curfile > - cnt = cnt + 1 > + # Do not print anything if the current line is a timeout > + if (has_timeout == 0) { > + # If the previous line was a timeout, > + # insert the full current message without keyword > + if (timeout_cnt != 0) { > + printf "%s %08d|%s program timed out.\n", testname, timeout_cnt, timeout_msg >> curfile > + timeout_cnt = 0 > + cnt = cnt + 1 > + } > + printf "%s %08d|", testname, cnt >> curfile > + cnt = cnt + 1 > + filewritten[curfile]=1 > + need_close=1 > + if (timeout_cnt == 0) > + print >> curfile > + } > + > + has_timeout=0 > } > - filewritten[curfile]=1 > - need_close=1 > - print >> curfile > } else > next > } > First of all, I don't see why the WARNING: program timed out > stuff should be handled in any way specially in -L mode, there is no sorting > at all and all the lines go together. But more importantly, the above The "WARNING: program timed out" stuff needs to be handled specially in non-L mode (when handling .sum), because in that case we are using "sort", which used to put all "WARNING:" lines together before most of the report. > changes broke completely the -L mode, previously the filewritten, need_close > and print lines were done for both sum and log modes, but now they are done > only in the sum mode (and in that case only if has_timeout is 0, which is > desirable). > I did check my patch against .sum and .log files, but it looks like my tests were incomplete, sorry for that. > I believe the following patch should fix it, but I don't actually have any > WARNING: program timed out > lines in my *.sep files in any of the last 12 bootstraps I have around. You can just insert one such line in your .sum/.log manually, and possibly replace a PASS with a FAIL to check that the WARNING and FAIL are kept next to each other in the .sum (that was my original intention). Christophe > > Additionally, perhaps we should change dg-extract-results.sh, so that it > doesn't try just python, but also python3? I think in some distros > /usr/bin/python even warns users that they should decide if they mean > python2 or python3. > > 2019-04-16 Jakub Jelinek <jakub@redhat.com> > > * dg-extract-results.sh: Only handle WARNING: program timed out > lines specially in "$MODE" == "sum". Restore previous behavior > for "$MODE" != "sum". Clear has_timeout and timeout_cnt if in > a different variant or curfile is empty. > * dg-extract-results.py: Fix a typo. > > --- contrib/dg-extract-results.sh.jj 2019-03-05 21:49:34.471573434 +0100 > +++ contrib/dg-extract-results.sh 2019-04-16 17:09:02.710004553 +0200 > @@ -331,13 +331,15 @@ BEGIN { > # Ugly hack for gfortran.dg/dg.exp > if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//) > testname="h"testname > - if (\$1 == "WARNING:" && \$2 == "program" && \$3 == "timed" && (\$4 == "out" || \$4 == "out.")) { > - has_timeout=1 > - timeout_cnt=cnt > - } else { > - # Prepare timeout replacement message in case it's needed > - timeout_msg=\$0 > - sub(\$1, "WARNING:", timeout_msg) > + if ("$MODE" == "sum") { > + if (\$0 ^ /^WARNING: program timed out/) { > + has_timeout=1 > + timeout_cnt=cnt > + } else { > + # Prepare timeout replacement message in case it's needed > + timeout_msg=\$0 > + sub(\$1, "WARNING:", timeout_msg) > + } > } > } > /^$/ { if ("$MODE" == "sum") next } > @@ -345,25 +347,30 @@ BEGIN { > if ("$MODE" == "sum") { > # Do not print anything if the current line is a timeout > if (has_timeout == 0) { > - # If the previous line was a timeout, > - # insert the full current message without keyword > - if (timeout_cnt != 0) { > - printf "%s %08d|%s program timed out.\n", testname, timeout_cnt, timeout_msg >> curfile > - timeout_cnt = 0 > - cnt = cnt + 1 > - } > - printf "%s %08d|", testname, cnt >> curfile > - cnt = cnt + 1 > - filewritten[curfile]=1 > - need_close=1 > - if (timeout_cnt == 0) > - print >> curfile > + # If the previous line was a timeout, > + # insert the full current message without keyword > + if (timeout_cnt != 0) { > + printf "%s %08d|%s program timed out.\n", testname, timeout_cnt, timeout_msg >> curfile > + timeout_cnt = 0 > + cnt = cnt + 1 > + } > + printf "%s %08d|", testname, cnt >> curfile > + cnt = cnt + 1 > + filewritten[curfile]=1 > + need_close=1 > + print >> curfile > } > - > has_timeout=0 > + } else { > + filewritten[curfile]=1 > + need_close=1 > + print >> curfile > } > - } else > + } else { > + has_timeout=0 > + timeout_cnt=0 > next > + } > } > END { > n=1 > --- contrib/dg-extract-results.py.jj 2019-03-05 21:49:34.471573434 +0100 > +++ contrib/dg-extract-results.py 2019-04-16 17:14:54.447248209 +0200 > @@ -296,7 +296,7 @@ class Prog: > # If we have a time out warning, make sure it appears > # before the following testcase diagnostic: we insert > # the testname before 'program' so that sort faces a > - # list of testhanes. > + # list of testnames. > if line.startswith ('WARNING: program timed out'): > has_warning = 1 > else: > > > Jakub ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 2019-04-16 13:44 ` Jakub Jelinek 2019-04-16 15:36 ` Jakub Jelinek @ 2019-04-16 15:48 ` Martin Jambor 1 sibling, 0 replies; 16+ messages in thread From: Martin Jambor @ 2019-04-16 15:48 UTC (permalink / raw) To: Jakub Jelinek, Christophe Lyon; +Cc: Rainer Emrich, gcc Mailing List Hi, On Tue, Apr 16 2019, Jakub Jelinek wrote: > On Tue, Apr 16, 2019 at 02:49:13PM +0200, Christophe Lyon wrote: >> > I executed the dg-extract-results.sh manually in the gcc/testsuite >> > directory after a complete testsuite run which didn't give the correct >> > results. Rev. 240429 gives the expected results, where rev 268511 fails. >> > I'm on windows using msys2 with bash 4.4.23. >> > >> > I'm bootsrapping at the moment but that's really slow on windows. When >> > the testsuite run is finished I try to assemble a reproducer. This will >> > take a while. >> > >> >> OK, thanks! Do you mean the problem happens on Windows only? > > It is not on Windows only, I e.g. see the same problem on Linux too, > unfortunately only when doing package builds. > > E.g. > https://kojipkgs.fedoraproject.org//work/tasks/3883/34193883/build.log > In the ===TESTING=== section where it emits result of contrib/test_summary > the results look reasonable (though, the ordering looks random-ish even > when it is always LC_ALL=C, so if there are multiple FAILs, diffing them > from one build to another has -FAIL and +FAIL lines for the same tests), > but if you uudecode the file (with more recent uudecode one needs to extract > the begin ... end part manually, what a progress :( ) in the tarball any > *.log files changed with dg-extract-results.py contain just Running lines > and no further details. Others like libgomp.log are complete, but those are > not merged. I get those almost empty *.log files even after > rm -f contrib/dg-extract-results.py > (which should force the *.sh version). > > I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though, > the *.log files are complete there. > My experience might be completely unrelated, but I was getting empty *.sum files (the big merged ones) - and I believe also empty .log files but I am not longer sure - on a big Linux machine where a lot people build stuff and the reason was that I was hitting some maximum cgroup PID number limit that SUSE systemd invented for me/us in: /sys/fs/cgroup/pids/user.slice/user-$UID.slice/pids.max After setting that to "max" the problems never again materialized. In any event, it is worth checking whether some system limits do not prevent spawning new processes, I believe there were messages about it extractable from logs (or rather journalctl). Martin ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2019-04-16 19:27 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-15 15:22 Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 Rainer Emrich 2019-04-15 15:30 ` Rainer Emrich 2019-04-15 15:38 ` Jakub Jelinek 2019-04-15 15:43 ` Rainer Emrich 2019-04-15 18:12 ` Rainer Emrich 2019-04-16 9:59 ` Rainer Emrich 2019-04-16 11:04 ` dg-extract-results broken since rev 268511, was " Rainer Emrich 2019-04-16 12:11 ` Christophe Lyon 2019-04-16 12:35 ` Rainer Emrich 2019-04-16 12:49 ` Christophe Lyon 2019-04-16 13:00 ` Rainer Emrich 2019-04-16 13:44 ` Jakub Jelinek 2019-04-16 15:36 ` Jakub Jelinek 2019-04-16 15:57 ` Rainer Emrich 2019-04-16 19:27 ` Christophe Lyon 2019-04-16 15:48 ` Martin Jambor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).