This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb
- From: "wilson at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Mar 2005 03:46:47 -0000
- Subject: [Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb
- References: <20050202233416.19769.dberlin@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From wilson at gcc dot gnu dot org 2005-03-16 03:46 -------
I confirmed that I don't see the problem if I compile with -m32 on a x86-64 system.
This happens with 32-bit x86 code because update_equiv_regs deletes and
reinserts the instruction that loads the value of the variable i. This causes
us to lose the block info for this insn, as block info is based on insn uid.
This does not happen for 64-bit code because CLASS_LIKELY_SPILLED_P is true for
the register destination. For 32-bit code, the register has a preferred class
of GENERAL_REGS, and for 64-bit code, the register has a preferred class of
DIREG_CLASS. So the 32-bit x86 case doesn't fail because we lost some debug info.
I can make the 32-bit case fail by adding the -fpic option, which prevents
update_equiv_regs from optimizing this instructions.
So
./xgcc -B./ -O -g -fpic -m32 tmp.cc
reproduces the problem for me on an x86_64 machine. It should do likewise on a
32-bit machine, without the -m32 option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769