On 08/19/2015 02:55 PM, Aldy Hernandez wrote:
> On 08/19/2015 06:45 AM, Richard Biener wrote:
>
> [copying gdb folks]
Thanks.
>
>> On Tue, 18 Aug 2015, Aldy Hernandez wrote:
>>
>>> On 08/18/2015 07:20 AM, Richard Biener wrote:
>
> [snip]
>
>> The patch below has passed bootstrap & regtest on x86_64-unknown-linux-gnu
>> as well as gdb testing. Twice unpatched, twice patched - results seem
>> to be somewhat unstable!? I even refrained from using any -j with
>> make check-gdb... maybe it's just contrib/test_summary not coping well
>> with gdb? any hints? Difference between unpatched run 1 & 2 is
>> for example
>>
>> --- results.unpatched 2015-08-19 15:08:36.152899926 +0200
>> +++ results.unpatched2 2015-08-19 15:29:46.902060797 +0200
>> @@ -209,7 +209,6 @@
>> WARNING: remote_expect statement without a default case?!
>> WARNING: remote_expect statement without a default case?!
>> WARNING: remote_expect statement without a default case?!
>> -FAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3,
>> fc4)
if {![target_info exists gdb,skip_float_tests]} {
gdb_test_stdio "print find_max_double(5,1.0,17.0,2.0,3.0,4.0)" \
"find_max\\(.*\\) returns 17\\.000000\[ \r\n\]+" \
".\[0-9\]+ = 17" \
"print find_max_double(5,1.0,17.0,2.0,3.0,4.0)"
}
# Test _Complex type here if supported.
if [support_complex_tests] {
global gdb_prompt
set test "print find_max_float_real(4, fc1, fc2, fc3, fc4)"
gdb_test $test ".*= 4 \\+ 4 \\* I" $test
>> FAIL: gdb.cp/inherit.exp: print g_vD
>> FAIL: gdb.cp/inherit.exp: print g_vE
>> FAIL: gdb.cp/no-dmgl-verbose.exp: setting breakpoint at 'f(std::string)'
>> @@ -238,6 +237,7 @@
>> UNRESOLVED: gdb.fortran/types.exp: set print sevenbit-strings
>> FAIL: gdb.fortran/whatis_type.exp: run to MAIN__
>> WARNING: remote_expect statement without a default case?!
>> +FAIL: gdb.gdb/complaints.exp: print symfile_complaints->root->fmt
# Prime the system
gdb_test_stdio "call complaint (&symfile_complaints, \"Register a
complaint\")" \
"During symbol reading, Register a complaint."
# Check that the complaint was inserted and where
gdb_test "print symfile_complaints->root->fmt" \
".\[0-9\]+ =.*\"Register a complaint\""
So in both cases, there was a "gdb_test_stdio" test just before
the test that failed. gdb_test_stdio is new, and it expects output
from two different spawn ids simultaneously. Sounds like it still
needs fixing... I'll guess that Richard has a much faster machine than
my getting-old laptop, which exposes races that I didn't trip on...
> This is somewhat expected. Well, at least I never found a good
> explanation. Some tests seemed to be thread related and inconsistent.
> Others, I have no idea.
>
Indeed there are still some threading tests that unfortunately still
cause intermittent fails. We've been fixing them but it's a
slow process. Judging by the GDB build bots, x86_64 GNU/Linux
testing seems to be mostly stable though. There's one DejaGNU issue
that is consistently causing trouble -- see below.
> After running the tests enough times I got a feeling of which tests
> would always pass, and use those as reference. It was confusing at
> first. Perhaps the GDB folks could shed some light? I've found them very
> helpful.
>
> Also, -j made things worse. I never used it.
It gets much better if you use git master DejaGNU, to pick this up:
http://lists.gnu.org/archive/html/dejagnu/2015-07/msg00005.html
Thanks,
Pedro Alves
