Re: [PATCH] testsuite: aarch64: Adjust SVE ACLE tests to new generated code
Hello Richard, Richard Sandiford writes: > Thiago Jung Bauermann via Gcc-patches writes: >> Since commit e7a36e4715c7 "[PATCH] RISC-V: Support simplify (-1-x) for >> vector." these tests fail on aarch64-linux: >> >> === g++ tests === >> >> Running g++:g++.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp ... >> FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu++98 -O2 >> -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL >> check-function-bodies subr_m1_s8_m >> FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu++98 -O2 >> -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS >> check-function-bodies subr_m1_s8_m >> FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu++98 -O2 >> -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL >> check-function-bodies subr_m1_u8_m >> FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu++98 -O2 >> -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS >> check-function-bodies subr_m1_u8_m >> >> === gcc tests === >> >> Running gcc:gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp ... >> FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu90 -O2 >> -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL >> check-function-bodies subr_m1_s8_m >> FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu90 -O2 >> -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS >> check-function-bodies subr_m1_s8_m >> FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu90 -O2 >> -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL >> check-function-bodies subr_m1_u8_m >> FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu90 -O2 >> -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS >> check-function-bodies subr_m1_u8_m >> >> Andrew Pinski's analysis in PR testsuite/111071 is that the new code is >> better and the testcase should be updated. I also asked Prathamesh Kulkarni >> in private and he agreed. >> >> Here is the update. With this change, all tests in >> gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp pass on aarch64-linux. >> >> gcc/testsuite/ >> PR testsuite/111071 >> * gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_s8.c: Adjust to >> new code. >> * gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_u8.c: Likewise. > > Thanks, pushed to trunk. And sorry for the delay. I somehow > missed this earlier. :( No problem. Thank you for pushing it! -- Thiago
[PATCH] testsuite: aarch64: Adjust SVE ACLE tests to new generated code
Since commit e7a36e4715c7 "[PATCH] RISC-V: Support simplify (-1-x) for vector." these tests fail on aarch64-linux: === g++ tests === Running g++:g++.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp ... FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu++98 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies subr_m1_s8_m FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu++98 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS check-function-bodies subr_m1_s8_m FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu++98 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies subr_m1_u8_m FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu++98 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS check-function-bodies subr_m1_u8_m === gcc tests === Running gcc:gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp ... FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies subr_m1_s8_m FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS check-function-bodies subr_m1_s8_m FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies subr_m1_u8_m FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS check-function-bodies subr_m1_u8_m Andrew Pinski's analysis in PR testsuite/111071 is that the new code is better and the testcase should be updated. I also asked Prathamesh Kulkarni in private and he agreed. Here is the update. With this change, all tests in gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp pass on aarch64-linux. gcc/testsuite/ PR testsuite/111071 * gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_s8.c: Adjust to new code. * gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_u8.c: Likewise. Suggested-by: Andrew Pinski --- gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_s8.c | 3 +-- gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_u8.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_s8.c b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_s8.c index b9615de6655f..3e521bc9ae32 100644 --- a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_s8.c +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_s8.c @@ -76,8 +76,7 @@ TEST_UNIFORM_Z (subr_1_s8_m_untied, svint8_t, /* ** subr_m1_s8_m: -** mov (z[0-9]+\.b), #-1 -** subrz0\.b, p0/m, z0\.b, \1 +** not z0\.b, p0/m, z0\.b ** ret */ TEST_UNIFORM_Z (subr_m1_s8_m, svint8_t, diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_u8.c b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_u8.c index 65606b6dda03..4922bdbacc47 100644 --- a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_u8.c +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/subr_u8.c @@ -76,8 +76,7 @@ TEST_UNIFORM_Z (subr_1_u8_m_untied, svuint8_t, /* ** subr_m1_u8_m: -** mov (z[0-9]+\.b), #-1 -** subrz0\.b, p0/m, z0\.b, \1 +** not z0\.b, p0/m, z0\.b ** ret */ TEST_UNIFORM_Z (subr_m1_u8_m, svuint8_t,
Re: [PATCH] Remove XFAIL from gcc/testsuite/gcc.dg/unroll-7.c
Richard Sandiford writes: > Thiago Jung Bauermann via Gcc-patches writes: >> This test passes since commit e41103081bfa "Fix undefined behaviour in >> profile_count::differs_from_p", so remove the xfail annotation. >> >> Tested on aarch64-linux-gnu, armv8l-linux-gnueabihf and x86_64-linux-gnu. >> >> gcc/testsuite/ChangeLog: >> * gcc.dg/unroll-7.c: Remove xfail. > > Thanks, pushed to trunk. Sorry for the slow response. Thank you! No problem. -- Thiago
Re: [PATCH] testsuite: Adjust g++.dg/gomp/pr58567.C to new compiler message
Hello Tobias, Tobias Burnus writes: > On 18.08.23 23:24, Thiago Jung Bauermann wrote: >> Tobias Burnus writes: >>> the patch looks good to me. Thanks! Can you commit the patch yourself or >>> do you need someone to do this for you? >> Thank you! I don't have commit access, so I would need someone to do >> this for me. > > Done now in commit r14-3344-g40a6803c6d8ca2. Thank you! -- Thiago
Re: [PATCH] testsuite: Adjust g++.dg/gomp/pr58567.C to new compiler message
Hello Tobias,
Tobias Burnus writes:
> Hello Thiago,
>
> the patch looks good to me. Thanks! Can you commit the patch yourself or
> do you need someone to do this for you?
Thank you! I don't have commit access, so I would need someone to do
this for me.
> On 15.08.23 18:17, Thiago Jung Bauermann via Gcc-patches wrote:
>> Thiago Jung Bauermann writes:
>>
>>> Commit 92d1425ca780 "c++: redundant targ coercion for var/alias tmpls"
>>> changed the compiler error message in this testcase from
>>>
>>> : In instantiation of 'void foo() [with T = int]':
>>> :14:11: required from here
>>> :8:22: error: 'int' is not a class, struct, or union type
>>> :8:22: error: 'int' is not a class, struct, or union type
>>> :8:22: error: 'int' is not a class, struct, or union type
>>> :8:3: error: expected iteration declaration or initialization
>>> compiler exited with status 1
>>>
>>> to:
>>>
>>> : In instantiation of 'void foo() [with T = int]':
>>> :14:11: required from here
>>> :8:22: error: 'int' is not a class, struct, or union type
>>> :8:3: error: invalid type for iteration variable 'i'
>>> compiler exited with status 1
>>> Excess errors:
>>> :8:3: error: invalid type for iteration variable 'i'
>>>
>>> Andrew Pinski analysed the issue in PR 110756 and considered that it was a
>>> testsuite issue in that the error message changed slightly. Also, it's a
>>> better error message.
>>>
>>> Therefore, we only need to adjust the testcase to expect the new message.
>>>
>>> gcc/testsuite/ChangeLog:
>>> PR testsuite/110756
>>> g++.dg/gomp/pr58567.C: Adjust to new compiler error message.
>>> ---
>>> gcc/testsuite/g++.dg/gomp/pr58567.C | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/gcc/testsuite/g++.dg/gomp/pr58567.C
>>> b/gcc/testsuite/g++.dg/gomp/pr58567.C
>>> index 35a5bb027ffe..866d831c65e4 100644
>>> --- a/gcc/testsuite/g++.dg/gomp/pr58567.C
>>> +++ b/gcc/testsuite/g++.dg/gomp/pr58567.C
>>> @@ -5,7 +5,7 @@
>>> template void foo()
>>> {
>>> #pragma omp parallel for
>>> - for (typename T::X i = 0; i < 100; ++i) /* { dg-error "'int' is not a
>>> class, struct, or union type|expected iteration declaration or
>>> initialization" } */
>>> + for (typename T::X i = 0; i < 100; ++i) /* { dg-error "'int' is not a
>>> class, struct, or union type|invalid type for iteration variable 'i'" } */
>>> ;
>>> }
>>>
>> Ping? I just tested trunk. It still fails this test, and this patch
>> still fixes the failures.
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
> München;
> Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank
> Thürauf;
> Sitz der Gesellschaft: München; Registergericht München, HRB 106955
--
Thiago
Re: [PATCH] testsuite: Improve test in dg-require-python-h
Eric Feng writes:
> Thanks for the patch, Thiago. I've pushed it to trunk:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6785917c9103e18bba0d718ac3b65a386d9a14f7.
Thank you, Eric and Dave.
> On Fri, Aug 18, 2023 at 2:11 PM David Malcolm wrote:
>>
>> On Thu, 2023-08-17 at 23:30 -0300, Thiago Jung Bauermann wrote:
>> > If GCC is tested with a sysroot which doesn't contain a Python
>> > installation (e.g., with a command such as
>> > "make check-gcc-c FLAGS_UNDER_TEST="--sysroot=/some/path"), but
>> > there's
>> > a python3-config in $PATH, then the testsuite will pick up the host's
>> > Python.h which can't actually be used:
>> >
>> > Executing on host: python3-config --includes(timeout = 300)
>> > spawn -ignore SIGHUP python3-config --includes
>> > -I/usr/include/python3.10 -I/usr/include/python3.10
>> > Executing on host: /some/sysroot/bin/aarch64-unknown-linux-gnu-gcc --
>> > sysroot=/some/sysroot/libc -Wl,-dynamic-
>> > linker=/some/sysroot/libc/lib/ld-linux-aarch64.so.1 -Wl,-
>> > rpath=/some/sysroot/libc/lib
>> > /some/src/gcc.git/gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-
>> > 2.c-fdiagnostics-plain-output -
>> > fplugin=./analyzer_cpython_plugin.so -fanalyzer -
>> > I/usr/include/python3.10 -I/usr/include/python3.10 -S -o cpython-
>> > plugin-test-2.s(timeout = 600)
>> > spawn -ignore SIGHUP /some/sysroot/bin/aarch64-unknown-linux-gnu-gcc
>> > --sysroot=/some/sysroot/libc -Wl,-dynamic-
>> > linker=/some/sysroot/libc/lib/ld-linux-aarch64.so.1 -Wl,-
>> > rpath=/some/sysroot/libc/lib
>> > /some/src/gcc.git/gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-2.c
>> > -fdiagnostics-plain-output -fplugin=./analyzer_cpython_plugin.so -
>> > fanalyzer -I/usr/include/python3.10 -I/usr/include/python3.10 -S -o
>> > cpython-plugin-test-2.s
>> > In file included from /usr/include/python3.10/Python.h:8,
>> > from
>> > /some/src/gcc.git/gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-
>> > 2.c:8:
>> > /usr/include/python3.10/pyconfig.h:9:12: fatal error: aarch64-linux-
>> > gnu/python3.10/pyconfig.h: No such file or directory
>> > compilation terminated.
>> > compiler exited with status 1
>> >
>> > This problem causes these testsuite failures:
>> >
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for warnings, line 17)
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for warnings, line 18)
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for warnings, line 21)
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for warnings, line 31)
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for warnings, line 32)
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for warnings, line 35)
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for warnings, line 45)
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for warnings, line 55)
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for warnings, line 63)
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for warnings, line 66)
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for warnings, line 68)
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for warnings, line 69)
>> > FAIL: gcc.dg/plugin/cpython-plugin-test-2.c -
>> > fplugin=./analyzer_cpython_plugin.so (test for excess errors)
>> > Excess errors:
>> > /usr/include/python3.10/pyconfig.h:9:12: fatal error: aarch64-linux-
>> > gnu/python3.10/pyconfig.h: No such file or directory
>> > compilation terminated.
>> >
>> > So try to compile a test file so that the testcase can be marked as
>> > unsupported instead.
>> >
>> > gcc/testsuite/ChangeLog:
>> > * gcc/testsuite/lib/target-supports.exp (dg-require-python-
>> > h): Test
>> > whether Python.h can really be used.
>> > ---
>> > gcc/testsuite/lib/target-supports.exp | 14 --
>> > 1 file changed, 12 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/gcc/testsuite/lib/target-supports.exp
>> > b/gcc/testsuite/lib/target-supports.exp
>> > index 92b6f69730e9..5b5f86551844 100644
>> > --- a/gcc/testsuite/lib/target-supports.exp
>> > +++ b/gcc/testsuite/lib/target-supports.exp
>> > @@ -12570,11 +12570,21 @@ proc dg-require-python-h { args } {
>> >
>> > verbose "ENTER dg-require-python-h" 2
>> >
>> > +set supported 0
>> > set result [remote_exec host "python3-config --includes"]
>> > set status [lindex $result 0]
>> > if { $status == 0 } {
>> > -set python_flags [lindex $result 1]
>> > -
[PATCH] testsuite: Improve test in dg-require-python-h
If GCC is tested with a sysroot which doesn't contain a Python
installation (e.g., with a command such as
"make check-gcc-c FLAGS_UNDER_TEST="--sysroot=/some/path"), but there's
a python3-config in $PATH, then the testsuite will pick up the host's
Python.h which can't actually be used:
Executing on host: python3-config --includes(timeout = 300)
spawn -ignore SIGHUP python3-config --includes
-I/usr/include/python3.10 -I/usr/include/python3.10
Executing on host: /some/sysroot/bin/aarch64-unknown-linux-gnu-gcc
--sysroot=/some/sysroot/libc
-Wl,-dynamic-linker=/some/sysroot/libc/lib/ld-linux-aarch64.so.1
-Wl,-rpath=/some/sysroot/libc/lib
/some/src/gcc.git/gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-2.c
-fdiagnostics-plain-output -fplugin=./analyzer_cpython_plugin.so -fanalyzer
-I/usr/include/python3.10 -I/usr/include/python3.10 -S -o
cpython-plugin-test-2.s(timeout = 600)
spawn -ignore SIGHUP /some/sysroot/bin/aarch64-unknown-linux-gnu-gcc
--sysroot=/some/sysroot/libc
-Wl,-dynamic-linker=/some/sysroot/libc/lib/ld-linux-aarch64.so.1
-Wl,-rpath=/some/sysroot/libc/lib
/some/src/gcc.git/gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-2.c
-fdiagnostics-plain-output -fplugin=./analyzer_cpython_plugin.so -fanalyzer
-I/usr/include/python3.10 -I/usr/include/python3.10 -S -o
cpython-plugin-test-2.s
In file included from /usr/include/python3.10/Python.h:8,
from
/some/src/gcc.git/gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-2.c:8:
/usr/include/python3.10/pyconfig.h:9:12: fatal error:
aarch64-linux-gnu/python3.10/pyconfig.h: No such file or directory
compilation terminated.
compiler exited with status 1
This problem causes these testsuite failures:
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for warnings, line 17)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for warnings, line 18)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for warnings, line 21)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for warnings, line 31)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for warnings, line 32)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for warnings, line 35)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for warnings, line 45)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for warnings, line 55)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for warnings, line 63)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for warnings, line 66)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for warnings, line 68)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for warnings, line 69)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c
-fplugin=./analyzer_cpython_plugin.so (test for excess errors)
Excess errors:
/usr/include/python3.10/pyconfig.h:9:12: fatal error:
aarch64-linux-gnu/python3.10/pyconfig.h: No such file or directory
compilation terminated.
So try to compile a test file so that the testcase can be marked as
unsupported instead.
gcc/testsuite/ChangeLog:
* gcc/testsuite/lib/target-supports.exp (dg-require-python-h): Test
whether Python.h can really be used.
---
gcc/testsuite/lib/target-supports.exp | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 92b6f69730e9..5b5f86551844 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -12570,11 +12570,21 @@ proc dg-require-python-h { args } {
verbose "ENTER dg-require-python-h" 2
+set supported 0
set result [remote_exec host "python3-config --includes"]
set status [lindex $result 0]
if { $status == 0 } {
-set python_flags [lindex $result 1]
-} else {
+ # Remove trailing newline from python3-config output.
+ set python_flags [string trim [lindex $result 1]]
+ if [check_no_compiler_messages python_h assembly {
+ #include
+ int main (void) { return 0; }
+ } $python_flags] {
+ set supported 1
+ }
+}
+
+if { $supported == 0 } {
verbose "Python.h not supported" 2
upvar dg-do-what dg-do-what
set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
base-commit: 1eb2433ff9e85008a289db03ff7eb802d51c42a8
[PATCH] Remove XFAIL from gcc/testsuite/gcc.dg/unroll-7.c
This test passes since commit e41103081bfa "Fix undefined behaviour in
profile_count::differs_from_p", so remove the xfail annotation.
Tested on aarch64-linux-gnu, armv8l-linux-gnueabihf and x86_64-linux-gnu.
gcc/testsuite/ChangeLog:
* gcc.dg/unroll-7.c: Remove xfail.
---
gcc/testsuite/gcc.dg/unroll-7.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/unroll-7.c b/gcc/testsuite/gcc.dg/unroll-7.c
index 650448df5db1..17c5e533c2cb 100644
--- a/gcc/testsuite/gcc.dg/unroll-7.c
+++ b/gcc/testsuite/gcc.dg/unroll-7.c
@@ -15,4 +15,4 @@ int t(void)
/* { dg-final { scan-rtl-dump "upper bound: 99" "loop2_unroll" } } */
/* { dg-final { scan-rtl-dump "realistic bound: 99" "loop2_unroll" } } */
/* { dg-final { scan-rtl-dump "considering unrolling loop with constant number
of iterations" "loop2_unroll" } } */
-/* { dg-final { scan-rtl-dump-not "Invalid sum" "loop2_unroll" {xfail *-*-* }
} } */
+/* { dg-final { scan-rtl-dump-not "Invalid sum" "loop2_unroll" } } */
base-commit: 5da4c0b85a97727e6802eaf3a0d47bcdb8da5f51
Re: [PATCH] testsuite: Adjust g++.dg/gomp/pr58567.C to new compiler message
Hello,
Thiago Jung Bauermann writes:
> Commit 92d1425ca780 "c++: redundant targ coercion for var/alias tmpls"
> changed the compiler error message in this testcase from
>
> : In instantiation of 'void foo() [with T = int]':
> :14:11: required from here
> :8:22: error: 'int' is not a class, struct, or union type
> :8:22: error: 'int' is not a class, struct, or union type
> :8:22: error: 'int' is not a class, struct, or union type
> :8:3: error: expected iteration declaration or initialization
> compiler exited with status 1
>
> to:
>
> : In instantiation of 'void foo() [with T = int]':
> :14:11: required from here
> :8:22: error: 'int' is not a class, struct, or union type
> :8:3: error: invalid type for iteration variable 'i'
> compiler exited with status 1
> Excess errors:
> :8:3: error: invalid type for iteration variable 'i'
>
> Andrew Pinski analysed the issue in PR 110756 and considered that it was a
> testsuite issue in that the error message changed slightly. Also, it's a
> better error message.
>
> Therefore, we only need to adjust the testcase to expect the new message.
>
> gcc/testsuite/ChangeLog:
> PR testsuite/110756
> g++.dg/gomp/pr58567.C: Adjust to new compiler error message.
> ---
> gcc/testsuite/g++.dg/gomp/pr58567.C | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/g++.dg/gomp/pr58567.C
> b/gcc/testsuite/g++.dg/gomp/pr58567.C
> index 35a5bb027ffe..866d831c65e4 100644
> --- a/gcc/testsuite/g++.dg/gomp/pr58567.C
> +++ b/gcc/testsuite/g++.dg/gomp/pr58567.C
> @@ -5,7 +5,7 @@
> template void foo()
> {
>#pragma omp parallel for
> - for (typename T::X i = 0; i < 100; ++i) /* { dg-error "'int' is not a
> class, struct, or union type|expected iteration declaration or
> initialization" } */
> + for (typename T::X i = 0; i < 100; ++i) /* { dg-error "'int' is not a
> class, struct, or union type|invalid type for iteration variable 'i'" } */
> ;
> }
>
Ping? I just tested trunk. It still fails this test, and this patch
still fixes the failures.
--
Thiago
[PATCH] testsuite: Adjust g++.dg/gomp/pr58567.C to new compiler message
Commit 92d1425ca780 "c++: redundant targ coercion for var/alias tmpls"
changed the compiler error message in this testcase from
: In instantiation of 'void foo() [with T = int]':
:14:11: required from here
:8:22: error: 'int' is not a class, struct, or union type
:8:22: error: 'int' is not a class, struct, or union type
:8:22: error: 'int' is not a class, struct, or union type
:8:3: error: expected iteration declaration or initialization
compiler exited with status 1
to:
: In instantiation of 'void foo() [with T = int]':
:14:11: required from here
:8:22: error: 'int' is not a class, struct, or union type
:8:3: error: invalid type for iteration variable 'i'
compiler exited with status 1
Excess errors:
:8:3: error: invalid type for iteration variable 'i'
Andrew Pinski analysed the issue in PR 110756 and considered that it was a
testsuite issue in that the error message changed slightly. Also, it's a
better error message.
Therefore, we only need to adjust the testcase to expect the new message.
gcc/testsuite/ChangeLog:
PR testsuite/110756
g++.dg/gomp/pr58567.C: Adjust to new compiler error message.
---
gcc/testsuite/g++.dg/gomp/pr58567.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/g++.dg/gomp/pr58567.C
b/gcc/testsuite/g++.dg/gomp/pr58567.C
index 35a5bb027ffe..866d831c65e4 100644
--- a/gcc/testsuite/g++.dg/gomp/pr58567.C
+++ b/gcc/testsuite/g++.dg/gomp/pr58567.C
@@ -5,7 +5,7 @@
template void foo()
{
#pragma omp parallel for
- for (typename T::X i = 0; i < 100; ++i) /* { dg-error "'int' is not a
class, struct, or union type|expected iteration declaration or initialization"
} */
+ for (typename T::X i = 0; i < 100; ++i) /* { dg-error "'int' is not a
class, struct, or union type|invalid type for iteration variable 'i'" } */
;
}
Re: Fix profile update in scale_profile_for_vect_loop
Hello, Jan Hubicka via Gcc-patches writes: > Hi, > when vectorizing 4 times, we sometimes do > for > <4x vectorized body> > for > <2x vectorized body> > for > <1x vectorized body> > > Here the second two fors handling epilogue never iterates. > Currently vecotrizer thinks that the middle for itrates twice. > This turns out to be scale_profile_for_vect_loop that uses > niter_for_unrolled_loop. > > At that time we know epilogue will iterate at most 2 times > but niter_for_unrolled_loop does not know that the last iteration > will be taken by the epilogue-of-epilogue and thus it think > that the loop may iterate once and exit in middle of second > iteration. > > We already do correct job updating niter bounds and this is > just ordering issue. This patch makes us to first update > the bounds and then do updating of the loop. I re-implemented > the function more correctly and precisely. > > The loop reducing iteration factor for overly flat profiles is bit funny, but > only other method I can think of is to compute sreal scale that would have > similar overhead I think. > > Bootstrapped/regtested x86_64-linux, comitted. > > gcc/ChangeLog: > > PR middle-end/110649 > * tree-vect-loop.cc (scale_profile_for_vect_loop): > (vect_transform_loop): > (optimize_mask_stores): Our CI detected regressions on aarch64-linux-gnu with this commit in gcc.target/aarch64/sve/aarch64-sve.exp. I checked today's trunk and it still fails. I filed the following bug report with the details: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110727 Could you please check? -- Thiago
Re: [PATCH] [vect]Use intermiediate integer type for float_expr/fix_trunc_expr when direct optab is not existed.
Hello, liuhongt via Gcc-patches writes: > I notice there's some refactor in vectorizable_conversion > for code_helper,so I've adjusted my patch to that. > Here's the patch I'm going to commit. > > We have already use intermidate type in case WIDEN, but not for NONE, > this patch extended that. > > gcc/ChangeLog: > > PR target/110018 > * tree-vect-stmts.cc (vectorizable_conversion): Use > intermiediate integer type for float_expr/fix_trunc_expr when > direct optab is not existed. > > gcc/testsuite/ChangeLog: > > * gcc.target/i386/pr110018-1.c: New test. > --- > gcc/testsuite/gcc.target/i386/pr110018-1.c | 94 ++ > gcc/tree-vect-stmts.cc | 66 ++- > 2 files changed, 158 insertions(+), 2 deletions(-) > create mode 100644 gcc/testsuite/gcc.target/i386/pr110018-1.c Our CI detected regressions on aarch64-linux-gnu with this commit, in some aarch64-sve and gfortran tests. I filed the following bug report with the details: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371 Could you please check? -- Thiago
Re: [PATCH 2/2] cprop_hardreg: Enable propagation of the stack pointer if possible.
Hello, Jeff Law writes: > On 6/19/23 22:52, Tamar Christina wrote: > >>> It's a bit hackish, but could we reject the stack pointer for operand1 in >>> the >>> stack-tie? And if we do so, does it help? >> Yeah this one I had to defer until later this week to look at closer because >> what I'm >> wondering about is whether the optimization should apply to frame related >> RTX as well. >> Looking at the description of RTX_FRAME_RELATED_P that this optimization may >> end up de-optimizing RISC targets by creating an offset that is larger than >> offset >> which can be used from a SP making reload having to spill. i.e. sometimes >> the >> move was explicitly done. So perhaps it should not apply it to >> RTX_FRAME_RELATED_P in find_oldest_value_reg and copyprop_hardreg_forward_1? >> Other parts of this pass already seems to bail out in similar situations. So >> I needed >> to >> write some testcases to check what would happen in these cases hence the >> deferral. >> to later in the week. > Rejecting for RTX_FRAME_RELATED_P would seem reasonable and probably better > in general to > me. The cases where we're looking to clean things up aren't really in the > prologue/epilogue, but instead in the main body after register elimination > has turned fp > into sp + offset, thus making all kinds of things no longer valid. The problems I reported were fixed by commits: 580b74a79146 "aarch64: Robustify stack tie handling" 079f31c55318 "aarch64: Fix gcc.target/aarch64/sve/pcs failures" Thanks! But unfortunately I'm still seeing bootstrap failures (ICE segmentation fault) in today's trunk with build config bootstrap-lto in both armv8l-linux-gnueabihf and aarch64-linux-gnu. If I revert commit 6a2e8dcbbd4b "cprop_hardreg: Enable propagation of the stack pointer if possible" from trunk then both bootstraps succeed. Here's the command I'm using to build on armv8l: ~/src/configure \ SHELL=/bin/bash \ --with-gnu-as \ --with-gnu-ld \ --disable-libmudflap \ --enable-lto \ --enable-shared \ --without-included-gettext \ --enable-nls \ --with-system-zlib \ --disable-sjlj-exceptions \ --enable-gnu-unique-object \ --enable-linker-build-id \ --disable-libstdcxx-pch \ --enable-c99 \ --enable-clocale=gnu \ --enable-libstdcxx-debug \ --enable-long-long \ --with-cloog=no \ --with-ppl=no \ --with-isl=no \ --disable-multilib \ --with-float=hard \ --with-fpu=neon-fp-armv8 \ --with-mode=thumb \ --with-arch=armv8-a \ --enable-threads=posix \ --enable-multiarch \ --enable-libstdcxx-time=yes \ --enable-gnu-indirect-function \ --disable-werror \ --enable-checking=yes \ --enable-bootstrap \ --with-build-config=bootstrap-lto \ --enable-languages=c,c++,fortran,lto \ && make \ profiledbootstrap \ SHELL=/bin/bash \ -w \ -j 40 \ CFLAGS_FOR_BUILD="-pipe -g -O2" \ CXXFLAGS_FOR_BUILD="-pipe -g -O2" \ LDFLAGS_FOR_BUILD="-static-libgcc" \ MAKEINFOFLAGS=--force \ BUILD_INFO="" \ MAKEINFO=echo And here's the slightly different one for aarch64-linux: ~/src/configure \ SHELL=/bin/bash \ --with-gnu-as \ --with-gnu-ld \ --disable-libmudflap \ --enable-lto \ --enable-shared \ --without-included-gettext \ --enable-nls \ --with-system-zlib \ --disable-sjlj-exceptions \ --enable-gnu-unique-object \ --enable-linker-build-id \ --disable-libstdcxx-pch \ --enable-c99 \ --enable-clocale=gnu \ --enable-libstdcxx-debug \ --enable-long-long \ --with-cloog=no \ --with-ppl=no \ --with-isl=no \ --disable-multilib \ --enable-fix-cortex-a53-835769 \ --enable-fix-cortex-a53-843419 \ --with-arch=armv8-a \ --enable-threads=posix \ --enable-multiarch \ --enable-libstdcxx-time=yes \ --enable-gnu-indirect-function \ --disable-werror \ --enable-checking=yes \ --enable-bootstrap \ --with-build-config=bootstrap-lto \ --enable-languages=c,c++,fortran,lto \ && make \ profiledbootstrap \ SHELL=/bin/bash \ -w \ -j 40 \ LDFLAGS_FOR_TARGET="-Wl,-fix-cortex-a53-843419" \ CFLAGS_FOR_BUILD="-pipe -g -O2" \ CXXFLAGS_FOR_BUILD="-pipe -g -O2" \ LDFLAGS_FOR_BUILD="-static-libgcc" \ MAKEINFOFLAGS=--force \ BUILD_INFO="" \ MAKEINFO=echo -- Thiago
Re: [PATCH 2/2] cprop_hardreg: Enable propagation of the stack pointer if possible.
Hello Manolis,
Philipp Tomsich writes:
> On Thu, 8 Jun 2023 at 00:18, Jeff Law wrote:
>>
>> On 5/25/23 06:35, Manolis Tsamis wrote:
>> > Propagation of the stack pointer in cprop_hardreg is currenty forbidden
>> > in all cases, due to maybe_mode_change returning NULL. Relax this
>> > restriction and allow propagation when no mode change is requested.
>> >
>> > gcc/ChangeLog:
>> >
>> > * regcprop.cc (maybe_mode_change): Enable stack pointer
>> > propagation.
>> Thanks for the clarification. This is OK for the trunk. It looks
>> generic enough to have value going forward now rather than waiting.
>
> Rebased, retested, and applied to trunk. Thanks!
Our CI found a couple of tests that started failing on aarch64-linux
after this commit. I was able to confirm manually that they don't happen
in the commit immediately before this one, and also that these failures
are still present in today's trunk.
I have testsuite logs for last good commit, first bad commit and current
trunk here:
https://people.linaro.org/~thiago.bauermann/gcc-regression-6a2e8dcbbd4b/
Could you please check?
These are the new failures:
Running gcc:gcc.target/aarch64/aarch64.exp ...
FAIL: gcc.target/aarch64/stack-check-cfa-3.c scan-assembler-times mov\\tx11, sp
1
Running gcc:gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp ...
FAIL: gcc.target/aarch64/sve/pcs/args_1.c -march=armv8.2-a+sve
-fno-stack-protector check-function-bodies caller_pred
FAIL: gcc.target/aarch64/sve/pcs/args_2.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tmov\\t(z[0-9]+\\.b),
#8\\n.*\\tst1b\\t\\1, p[0-7], \\[x4\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_3.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tmov\\t(z[0-9]+\\.b),
#8\\n.*\\tst1b\\t\\1, p[0-7], \\[x4\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_4.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tfmov\\t(z[0-9]+\\.h),
#8\\.0.*\\tst1h\\t\\1, p[0-7], \\[x4\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_be_bf16.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2h\\t{(z[0-9]+\\.h) -
z[0-9]+\\.h}.*\\tst1h\\t\\1, p[0-7], \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_be_f16.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2h\\t{(z[0-9]+\\.h) -
z[0-9]+\\.h}.*\\tst1h\\t\\1, p[0-7], \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_be_f32.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2w\\t{(z[0-9]+\\.s) -
z[0-9]+\\.s}.*\\tst1w\\t\\1, p[0-7], \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_be_f64.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2d\\t{(z[0-9]+\\.d) -
z[0-9]+\\.d}.*\\tst1d\\t\\1, p[0-7], \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_be_s16.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2h\\t{(z[0-9]+\\.h) -
z[0-9]+\\.h}.*\\tst1h\\t\\1, p[0-7], \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_be_s32.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2w\\t{(z[0-9]+\\.s) -
z[0-9]+\\.s}.*\\tst1w\\t\\1, p[0-7], \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_be_s64.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2d\\t{(z[0-9]+\\.d) -
z[0-9]+\\.d}.*\\tst1d\\t\\1, p[0-7], \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_be_s8.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2b\\t{(z[0-9]+\\.b) -
z[0-9]+\\.b}.*\\tst1b\\t\\1, p[0-7], \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_be_u16.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2h\\t{(z[0-9]+\\.h) -
z[0-9]+\\.h}.*\\tst1h\\t\\1, p[0-7], \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_be_u32.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2w\\t{(z[0-9]+\\.s) -
z[0-9]+\\.s}.*\\tst1w\\t\\1, p[0-7], \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_be_u64.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2d\\t{(z[0-9]+\\.d) -
z[0-9]+\\.d}.*\\tst1d\\t\\1, p[0-7], \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_be_u8.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2b\\t{(z[0-9]+\\.b) -
z[0-9]+\\.b}.*\\tst1b\\t\\1, p[0-7], \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_le_bf16.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2h\\t{(z[0-9]+)\\.h -
z[0-9]+\\.h}.*\\tstr\\t\\1, \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_le_f16.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2h\\t{(z[0-9]+)\\.h -
z[0-9]+\\.h}.*\\tstr\\t\\1, \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_le_f32.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2w\\t{(z[0-9]+)\\.s -
z[0-9]+\\.s}.*\\tstr\\t\\1, \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_le_f64.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler \\tld2d\\t{(z[0-9]+)\\.d -
z[0-9]+\\.d}.*\\tstr\\t\\1, \\[x1\\]\\n
FAIL: gcc.target/aarch64/sve/pcs/args_5_le_s16.c -march=armv8.2-a+sve
-fno-stack-protector scan-assembler
Re: [PATCH] [contrib] validate_failures.py: Don't consider summary line in wrong place
Jeff Law writes: > On 6/16/23 06:02, Thiago Jung Bauermann via Gcc-patches wrote: >> contrib/ChangeLog: >> * testsuite-management/validate_failures.py (IsInterestingResult): >> Add result_set argument and use it. Adjust callers. > Thanks. I pushed this to the trunk. Thank you! -- Thiago
[PATCH] [contrib] validate_failures.py: Don't consider summary line in wrong place
When parsing a summary or manifest file, if we're not either after a tool
line (e.g. "=== gdb tests ===") or before a summary line (e.g.,
"=== gdb Summary ===") then the current line can't be a valid result line
so ignore it.
This addresses a problem we're seeing when running the GDB testsuite in
our CI environment where it produces a valid summary file, but then after
the "=== gdb Summary ===" section it outputs a series of Tcl errors that
match _VALID_TEST_RESULTS_REX and thus confuse the parsing logic:
05: 14:32 .sum file seems to be broken: tool="None", exp="None",
summary_line="ERROR: ---"
05: 14:32 Traceback (most recent call last):
05: 14:32 File
"/path/to/gcc/contrib/testsuite-management/validate_failures.py", line 706, in
05: 14:32 retval = Main(sys.argv)
05: 14:32 File
"/path/to/gcc/contrib/testsuite-management/validate_failures.py", line 697, in
Main
05: 14:32 retval = CheckExpectedResults()
05: 14:32 File
"/path/to/gcc/contrib/testsuite-management/validate_failures.py", line 572, in
CheckExpectedResults
05: 14:32 actual = GetResults(sum_files)
05: 14:32 File
"/path/to/gcc/contrib/testsuite-management/validate_failures.py", line 447, in
GetResults
05: 14:32 build_results.update(ParseSummary(sum_fname))
05: 14:32 File
"/path/to/gcc/contrib/testsuite-management/validate_failures.py", line 389, in
ParseSummary
05: 14:32 result = result_set.MakeTestResult(line, ordinal)
05: 14:32 File
"/path/to/gcc/contrib/testsuite-management/validate_failures.py", line 236, in
MakeTestResult
05: 14:32 return TestResult(summary_line, ordinal,
05: 14:32 File
"/path/to/gcc/contrib/testsuite-management/validate_failures.py", line 148, in
__init__
05: 14:32 raise
contrib/ChangeLog:
* testsuite-management/validate_failures.py (IsInterestingResult):
Add result_set argument and use it. Adjust callers.
---
.../testsuite-management/validate_failures.py | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/contrib/testsuite-management/validate_failures.py
b/contrib/testsuite-management/validate_failures.py
index 4dfd9cda4e24..11bb6f7e9c7c 100755
--- a/contrib/testsuite-management/validate_failures.py
+++ b/contrib/testsuite-management/validate_failures.py
@@ -295,10 +295,20 @@ def SplitAttributesFromSummaryLine(line):
return (attrs, line)
-def IsInterestingResult(line):
+def IsInterestingResult(result_set, line):
"""Return True if line is one of the summary lines we care about."""
(_, line) = SplitAttributesFromSummaryLine(line)
- return bool(_VALID_TEST_RESULTS_REX.match(line))
+ valid_result = bool(_VALID_TEST_RESULTS_REX.match(line))
+
+ # If there's no tool defined it means that either the results section hasn't
+ # started yet, or it is already over.
+ if valid_result and result_set.current_tool is None:
+if _OPTIONS.verbosity >= 3:
+ print(f'WARNING: Result "{line}" found outside sum file boundaries.',
+file=sys.stderr)
+return False
+
+ return valid_result
def IsToolLine(line):
@@ -354,7 +364,7 @@ def ParseManifestWorker(result_set, manifest_path):
result_set.remove(result_set.MakeTestResult(GetNegativeResult(line)))
elif IsInclude(line):
ParseManifestWorker(result_set, GetIncludeFile(line, manifest_path))
-elif IsInterestingResult(line):
+elif IsInterestingResult(result_set, line):
result = result_set.MakeTestResult(line)
if result.HasExpired():
# Ignore expired manifest entries.
@@ -391,7 +401,7 @@ def ParseSummary(sum_fname):
ordinal=0
sum_file = open(sum_fname, encoding='latin-1', mode='r')
for line in sum_file:
-if IsInterestingResult(line):
+if IsInterestingResult(result_set, line):
result = result_set.MakeTestResult(line, ordinal)
ordinal += 1
if result.HasExpired():
