Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Rainer Emrich]

[-- 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 --]

Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Rainer Emrich]

[-- 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 --]

Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[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?

	Jakub

Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Rainer Emrich]

[-- 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 --]

Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Rainer Emrich]

[-- 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 --]

Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Rainer Emrich]

[-- 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 --]

dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Rainer Emrich]

[-- 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 --]

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[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?

Thanks,

Christophe

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Rainer Emrich]

[-- 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 --]

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[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?

> Thanks,
>
> Rainer
>

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Rainer Emrich]

[-- 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 --]

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Jakub Jelinek]

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

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[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).

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

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Rainer Emrich]

[-- 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 --]

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Christophe Lyon]

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

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Martin Jambor]

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