This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
bad dynamic mem access in final.c
- To: gcc at gcc dot gnu dot org
- Subject: bad dynamic mem access in final.c
- From: Robert Lipe <robertl at sco dot com>
- Date: Sun, 27 Feb 2000 23:07:30 -0600
I just tried a bootstrap with electric fence. It triggered on a naughty
access that I pray is the source of much recent weirdness for me. The
host is i686-sco-sco3.2v5.0.5 and the test case is bootstrapping. The
file being compiled is libgcc2.c and the specific entry is __fixunsdfdi.
Strangely, I can't get electric fence to trigger this case on rh6.1,
but if I breakpoint at the key addresses, I can see the same thing is
happening.
shorten_branches computes max_uid as 218 and then calls xcalloc to get
space for 218 ints and calls it "insn_addresses".
So later, final() comes along and loops over the available insns
for (insn = NEXT_INSN (first); insn;)
insn_current_address = insn_addresses[INSN_UID (insn)];
Boom! We just walked past the end of insn_addresses. Interestingly,
it computes max_uid to be 219 and that is the value of INSN_UID(insn)
in the evaluated expression that causes grief. It's not clear, but I
suspect this is an "off by two" error and not an "off by one".
I don't know which is right. I don't know why they're different. I
don't know if it should be reallocating/copying something in here. But
my gut tells me this is wrong somehow.
If there additional information I can provide, please let me know. I hope
the resolution to this problem gets me back into three-stage-land.
Thanx,
RJL