If GC does that, then how come there is all this effort to do
mmap testing to see if it has the facility to zero memory, and
I can't see what you are refering to.
I obviously misinterpreted that then.
why is the surrounding code (in GCC 4.4's alloc_page())
calling XCNEWVEC instead of XNEWVEC?
That's the page table entries, not the data itself.
There wouldn't be the need for ggc_alloc_cleared if ggc_alloc
would already zero pages.
Ok, based on this, I traced it back further:
rtx
gen_rtx_fmt_e0 (code, mode, arg0)
RTX_CODE code;
enum machine_mode mode;
rtx arg0;
{
rtx rt;
rt = ggc_alloc_rtx (2);
memset (rt, 0, sizeof (struct rtx_def) - sizeof (rtunion));
rtx
gen_rtx_MEM (mode, addr)
enum machine_mode mode;
rtx addr;
{
rtx rt = gen_rtx_raw_MEM (mode, addr);
/* This field is not cleared by the mere allocation of the rtx, so
we clear it here. */
MEM_ATTRS (rt) = 0;
return rt;
}
void
init_caller_save ()
{
...
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
for (mode = 0 ; mode < MAX_MACHINE_MODE; mode++)
if (HARD_REGNO_MODE_OK (i, mode))
{
rtx mem = gen_rtx_MEM (mode, address);
And indeed, this code - caller_save, shows up as one of the symptoms.
One of the symptoms is that where it is meant to be saving a register
prior to a function call, it instead generates a completely stupid
instruction - and that stupid instruction happens to be the first
instruction listed in i370.md.
Right at the moment the symptom is:
/ID SAVE-JOB-123456 @BLD000 9999 9999 9999 9999
/SYS REGION=9999,XREGION=64M
/FILE SYSPRINT PRT OSRECFM(F) OSLRECL(256)
/FILE SYSIN N(MATH.C) SHR
/FILE O N(MATH.S) NEW RECFM(V) SP(1000)
/FILE SYSINCL PDS(*.H)
/FILE INCLUDE PDS(*.H)
/PARM -Os -S -DUSE_MEMMGR -DMUSIC -o dd:o -
/LOAD XMON
<stdin>: In function `acos':
<stdin>:137: Internal compiler error in ?, at <stdin>:724
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
compiling something from my C runtime library. But I basically get
different behaviour depending on what I initialize uninitialized memory
to.
Any ideas on what to look for now? I can probably isolate which bit
of the malloc()ed memory is being referenced before initialization.
But finding out who is doing the reference could be tricky.
I might be able to trace it from a different approach, getting more
information about that internal error, now that I know where some
of the involved memory is. I'll get that <stdin> converted into a
PC filename first.
BFN. Paul.
