testsuite: guality/redeclaration1.C test workaround
authorJakub Jelinek <jakub@redhat.com>
Fri, 13 Nov 2020 22:27:23 +0000 (23:27 +0100)
committerJakub Jelinek <jakub@redhat.com>
Fri, 13 Nov 2020 22:27:23 +0000 (23:27 +0100)
commit5cd4f8901adbd8b4040cafaed7fef850047461ee
treee67fc541da3102dd14da9589154fd16e5dbe4714
parent1d9a8675d379f02f5e39639f469ae8dfcf33fea9
testsuite: guality/redeclaration1.C test workaround

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.

2020-11-13  Jakub Jelinek  <jakub@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.
gcc/testsuite/g++.dg/guality/redeclaration1.C