On 11/13/20 10:37 AM, Jakub Jelinek via Gcc-patches wrote: > Hi! > > Apparently older GDB versions didn't handle this test right and so while > it has been properly printing 42 on line 14 (e.g. on x86_64), it issued > a weird error on line 17 (and because it didn't print any value, guality > testsuite wasn't marking it as FAIL). > That has been apparently fixed in GDB 10, where it now (on x86_64) prints > properly. > Unfortunately that revealed that the test can suffer from instruction > scheduling, where e.g. on i686 (but various other arches) the very first > insn of the function (or whatever b 14 is on) happens to be load of the > S::i variable from memory and that insn has the inner lexical scope, so > GDB 10 prints there 24 instead of 42. The following insn is then > the first store to l and there the automatic i is in scope and prints as 42 > and then the second store to l where the inner lexical scope is current > and prints 24 again. > The test wasn't meant about insn scheduling but about whether we emit the > DIEs properly, so this hack attempts to prevent the undesirable scheduling. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2020-11-13 Jakub Jelinek <ja...@redhat.com> > > * g++.dg/guality/redeclaration1.C (p): New variable. > (S::f): Increment what p points to before storing S::i into l. Adjust > gdb-test line numbers. > (main): Initialize p to address of an automatic variable.
OK jeff
