ICE while compiling libstdc++ (IA32)
Donn Terry
donnte@microsoft.com
Tue Feb 15 09:45:00 GMT 2000
This is a very difficult to reproduce bug, but it's easy enough
to describe. The reason it's difficult to reproduce is that it
only shows up (at least as an ICE) if the allocation of the heap
is EXACTLY right (er... wrong). It's a SIGSEGV due to access off the end of
a calloc()ed array. Since this is sensitive to everything including
the content of the environment, no useful testcase is possible.
(However a range check inserted at the point of failure will
catch the failure easily enough; compare against insn_lengths_max_uid in
final.c. Expect lots of failures in (at least) templated code.)
The offending condition is near line 2028 of final.c, specificlally
insn_current_address = insn_addresses[INSN_UID (insn)];
insn_addresses was allocated based on get_max_uid() when shorten_branches
was called by toplev.c. However, due to the call to reg_to_stack() which
follows the call in toplev.c, additional UIDs have been allocated and access
to insn_addresses off the end of the calloc()d space is made at line 2028.
This appears to be related to a recent change to toplev.c where the order
of reg_to_stack() and shorten_branches() was reversed due to problems
for the ia32 backend.
It's easy enough to rangecheck the access and plug junk into
insn_current_address
(since that's what's happening anyway when it doesn't SIGSEGV) but that
doesn't seem the right fix. However, since the comment in toplev.c
indicates that that change is temporary it might be a good corresponding
temporary fix until the final fix (whatever it is) is made.
Donn Terry
... all the usual disclaimers about speaking only for myself.
More information about the Gcc-bugs
mailing list