On 04/27/2016 05:33 AM, Bernd Schmidt wrote:
On 04/27/2016 06:02 AM, Jeff Law wrote:
AFAICT the sra-1.c expects to see the incremented value and I'm at a
loss to understand what's really going on here. Can you give more
details?
Yeah, maybe my first impression wasn't very accurate.
When I try to run gdb manually, it just crashes:
(gdb) show version
GNU gdb (Gentoo 7.10.1 vanilla) 7.10.1
(gdb) b 43
Breakpoint 1 at 0x40059b: file sra-1.c, line 43.
(gdb) run
Starting program: /local/src/egcs/bscommit/gcc/a.out
Breakpoint 1, f3 (k=<optimized out>) at sra-1.c:43
43 bar (a.j); /* { dg-final { gdb-test 43 "a.j" "14" } } */
(gdb) p a.j
Segmentation fault (core dumped)
[ ... ]
I don't really understand the var-tracking stuff too well, so no idea
where to go from here. I suppose I'm withdrawing my patch.
Based on the above, there's some kind of GDB bug. So your patch may
still be a good thing.
I did a build on F23 which has effectively the same version of gdb and
can reproduce the gdb segfault. It also reproduces on F24 which has
gdb-7.11.1
AFAICT gdb thinks the value of "a" has been optimized out, but goes
absolutely bananas and segfaults if you try to examine a field within "a".
[law@torsion gcc]$ ./xgcc -B./ -g sra-1.c -O2
[law@torsion gcc]$ gdb ./a.out
GNU gdb (GDB) Fedora 7.10.1-30.fc23
[ ... ]
(gdb) b 43
Breakpoint 1 at 0x40056b: file sra-1.c, line 43.
(gdb) r
Starting program: /opt/notnfs/law/gcc-testing/obj/gcc/a.out
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.22-10.fc23.x86_64
Breakpoint 1, f3 (k=<optimized out>) at sra-1.c:43
43 bar (a.j); /* { dg-final { gdb-test 43 "a.j" "14" }
} */
(gdb) p a
$1 = <optimized out>
(gdb) p a.i
Segmentation fault (core dumped)
My gdb skills are far too rusty to take this further. I've filed an
upstream report (BZ20295 in the gdb tracker). Probably not much we can
do until the GDB side gets fixed.
I'm going to attach this to 56069 for future reference.
jeff
