From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6740 invoked by alias); 28 Nov 2009 16:03:10 -0000 Received: (qmail 6712 invoked by uid 22791); 28 Nov 2009 16:03:07 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pw0-f57.google.com (HELO mail-pw0-f57.google.com) (209.85.160.57) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 28 Nov 2009 16:03:00 +0000 Received: by pwi2 with SMTP id 2so1553893pwi.16 for ; Sat, 28 Nov 2009 08:02:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.251.12 with SMTP id y12mr152158rvh.236.1259424179124; Sat, 28 Nov 2009 08:02:59 -0800 (PST) In-Reply-To: <7B52F224E6EE465EB95237D5A0D9A15F@Paullaptop> References: <200911241405.nAOE5Jsd022678@d12av02.megacenter.de.ibm.com> <7B52F224E6EE465EB95237D5A0D9A15F@Paullaptop> Date: Sat, 28 Nov 2009 16:03:00 -0000 Message-ID: <84fc9c000911280802j3a0be6b1p1241d81d91f0672e@mail.gmail.com> Subject: Re: i370 port - music/sp - possible generic gcc problem From: Richard Guenther To: Paul Edwards Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00791.txt.bz2 On Sat, Nov 28, 2009 at 4:13 PM, Paul Edwards wrote: > I think I have found a bug in gcc, that still exists in gcc 4.4 > > I found the problem on 3.2.3 though. > > While MVS and VM have basically been working fine, when I did > the port to MUSIC/SP I started getting strange compilation failures. > > Initializing the stack to NULs made the problem go away, but I > persisted, and instead initialized the stack to x'01' to try to get > consistent failures. > > Even with that, and the malloced memory initialized to consistent > garbage, I still didn't get the desired consistency in failures. > But it was consistent enough that I could just run it 6 times and > see if there were any failures. > > > Anyway, I tracked down the particular malloc() which gave changed > behaviour depending on whether the malloc() did a memory initialization > to NULs or not. Well, GC hands out non-zeroed memory - the callers are responsible for initializing it. So the fix below is not a fix but papering over an issue elswhere. Richard. > It's this one (showing 3.2.3): > > C:\devel\gcc\gcc>cvs diff -l -c15 > cvs diff: Diffing . > Index: ggc-page.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: c:\cvsroot/gcc/gcc/ggc-page.c,v > retrieving revision 1.1.1.1 > diff -c -1 -5 -r1.1.1.1 ggc-page.c > *** ggc-page.c =A015 Feb 2006 10:22:25 -0000 =A0 =A0 =A01.1.1.1 > --- ggc-page.c =A028 Nov 2009 14:13:41 -0000 > *************** > *** 640,670 **** > =A0#ifdef USING_MALLOC_PAGE_GROUPS > =A0 else > =A0 =A0 { > =A0 =A0 =A0 /* Allocate a large block of memory and serve out the aligned > =A0 =A0 =A0 =A0pages therein. =A0This results in much less memory wastage > =A0 =A0 =A0 =A0than the traditional implementation of valloc. =A0*/ > > =A0 =A0 =A0 char *allocation, *a, *enda; > =A0 =A0 =A0 size_t alloc_size, head_slop, tail_slop; > =A0 =A0 =A0 int multiple_pages =3D (entry_size =3D=3D G.pagesize); > > =A0 =A0 =A0 if (multiple_pages) > =A0 =A0 =A0 alloc_size =3D GGC_QUIRE_SIZE * G.pagesize; > =A0 =A0 =A0 else > =A0 =A0 =A0 alloc_size =3D entry_size + G.pagesize - 1; > ! =A0 =A0 =A0 allocation =3D xmalloc (alloc_size); > > =A0 =A0 =A0 page =3D (char *) (((size_t) allocation + G.pagesize - 1) & > -G.pagesize); > =A0 =A0 =A0 head_slop =3D page - allocation; > =A0 =A0 =A0 if (multiple_pages) > =A0 =A0 =A0 tail_slop =3D ((size_t) allocation + alloc_size) & (G.pagesiz= e - 1); > =A0 =A0 =A0 else > =A0 =A0 =A0 tail_slop =3D alloc_size - entry_size - head_slop; > =A0 =A0 =A0 enda =3D allocation + alloc_size - tail_slop; > > =A0 =A0 =A0 /* We allocated N pages, which are likely not aligned, leaving > =A0 =A0 =A0 =A0us with N-1 usable pages. =A0We plan to place the page_gro= up > =A0 =A0 =A0 =A0structure somewhere in the slop. =A0*/ > =A0 =A0 =A0 if (head_slop >=3D sizeof (page_group)) > =A0 =A0 =A0 group =3D (page_group *)page - 1; > =A0 =A0 =A0 else > --- 640,670 ---- > =A0#ifdef USING_MALLOC_PAGE_GROUPS > =A0 else > =A0 =A0 { > =A0 =A0 =A0 /* Allocate a large block of memory and serve out the aligned > =A0 =A0 =A0 =A0pages therein. =A0This results in much less memory wastage > =A0 =A0 =A0 =A0than the traditional implementation of valloc. =A0*/ > > =A0 =A0 =A0 char *allocation, *a, *enda; > =A0 =A0 =A0 size_t alloc_size, head_slop, tail_slop; > =A0 =A0 =A0 int multiple_pages =3D (entry_size =3D=3D G.pagesize); > > =A0 =A0 =A0 if (multiple_pages) > =A0 =A0 =A0 alloc_size =3D GGC_QUIRE_SIZE * G.pagesize; > =A0 =A0 =A0 else > =A0 =A0 =A0 alloc_size =3D entry_size + G.pagesize - 1; > ! =A0 =A0 =A0 allocation =3D xcalloc (1, alloc_size); > > =A0 =A0 =A0 page =3D (char *) (((size_t) allocation + G.pagesize - 1) & > -G.pagesize); > =A0 =A0 =A0 head_slop =3D page - allocation; > =A0 =A0 =A0 if (multiple_pages) > =A0 =A0 =A0 tail_slop =3D ((size_t) allocation + alloc_size) & (G.pagesiz= e - 1); > =A0 =A0 =A0 else > =A0 =A0 =A0 tail_slop =3D alloc_size - entry_size - head_slop; > =A0 =A0 =A0 enda =3D allocation + alloc_size - tail_slop; > > =A0 =A0 =A0 /* We allocated N pages, which are likely not aligned, leaving > =A0 =A0 =A0 =A0us with N-1 usable pages. =A0We plan to place the page_gro= up > =A0 =A0 =A0 =A0structure somewhere in the slop. =A0*/ > =A0 =A0 =A0 if (head_slop >=3D sizeof (page_group)) > =A0 =A0 =A0 group =3D (page_group *)page - 1; > =A0 =A0 =A0 else > > > I suspect that it has stayed hidden for so long because most people > probably have this mmap_anon: > > /* Define if mmap can get us zeroed pages using MAP_ANON(YMOUS). */ > #undef HAVE_MMAP_ANON > > > #ifdef HAVE_MMAP_ANON > # undef HAVE_MMAP_DEV_ZERO > > # include > # ifndef MAP_FAILED > # =A0define MAP_FAILED -1 > # endif > # if !defined (MAP_ANONYMOUS) && defined (MAP_ANON) > # =A0define MAP_ANONYMOUS MAP_ANON > # endif > # define USING_MMAP > > #endif > > #ifndef USING_MMAP > #define USING_MALLOC_PAGE_GROUPS > #endif > > > Seems pretty clear that zeroed pages are required. > > Looking at the code above and below this block, it uses xcalloc > instead. > > It will take a couple of days to confirm that this is the last > presumed bug affecting the MUSIC/SP port. > > In the meantime, can someone confirm that this code is wrong, > and that xcalloc is definitely required? > > I had a look at the gcc4 code, and it is calling XNEWVEC which > is also using xmalloc instead of xcalloc, so I presume it is still > a problem today, under the right circumstances. > > It took about a week to track this one down. =A0:-) > > One problem I have had for years, even on the MVS port, is that > I need to use -Os to get the exact same register selection on the > PC as the mainframe. =A0-O0 and -O2 get slightly different register > allocations, although all versions of the code are correct. =A0If I'm > lucky, this fix may make that problem go away, but as I said, > it'll take a couple of days before the results are in, as each build > takes about 2 hours (partly because i need to use -Os for > consistency). > > Thanks. =A0Paul. > >