Re: [PATCH][1/n] dwarf2out refactoring for early (LTO) debug

On 08/19/2015 06:45 AM, Richard Biener wrote:

[copying gdb folks]

> 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)
>   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
>   WARNING: remote_expect statement without a default case?!
>   WARNING: remote_expect statement without a default case?!
>   WARNING: remote_expect statement without a default case?!
> @@ -362,12 +362,12 @@
>                  === gdb Summary ===
>
> -# of expected passes           30881
> +# of expected passes           30884
>   # of unexpected failures       284
>   # of unexpected successes      2
> -# of expected failures         85
> +# of expected failures         83
>   # of unknown successes         2
> -# of known failures            60
> +# of known failures            59
>   # of unresolved testcases      6
>   # of untested testcases                32
>   # of unsupported tests         165
>
> the sames changes randomly appear/disappear in the patched case.
> Otherwise patched/unpatched agree.


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.

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.

Aldy