i370 port - music/sp - possible generic gcc problem

[Paul Edwards]

>> 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.