Re: i370 port - music/sp - possible generic gcc problem

["Paul Edwards" <mutazilah at gmail dot com>]

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