From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25615 invoked by alias); 28 Nov 2009 15:14:19 -0000 Received: (qmail 25603 invoked by uid 22791); 28 Nov 2009 15:14:18 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-gx0-f228.google.com (HELO mail-gx0-f228.google.com) (209.85.217.228) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 28 Nov 2009 15:14:14 +0000 Received: by gxk28 with SMTP id 28so63149gxk.9 for ; Sat, 28 Nov 2009 07:14:12 -0800 (PST) Received: by 10.150.70.13 with SMTP id s13mr3531622yba.319.1259421252829; Sat, 28 Nov 2009 07:14:12 -0800 (PST) Received: from Paullaptop (203-158-49-56.dyn.iinet.net.au [203.158.49.56]) by mx.google.com with ESMTPS id 15sm1176405gxk.0.2009.11.28.07.14.10 (version=SSLv3 cipher=RC4-MD5); Sat, 28 Nov 2009 07:14:11 -0800 (PST) Message-ID: <7B52F224E6EE465EB95237D5A0D9A15F@Paullaptop> From: "Paul Edwards" To: References: <200911241405.nAOE5Jsd022678@d12av02.megacenter.de.ibm.com> In-Reply-To: <200911241405.nAOE5Jsd022678@d12av02.megacenter.de.ibm.com> Subject: i370 port - music/sp - possible generic gcc problem Date: Sat, 28 Nov 2009 15:14:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit 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/msg00789.txt.bz2 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. It's this one (showing 3.2.3): C:\devel\gcc\gcc>cvs diff -l -c15 cvs diff: Diffing . Index: ggc-page.c =================================================================== 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 15 Feb 2006 10:22:25 -0000 1.1.1.1 --- ggc-page.c 28 Nov 2009 14:13:41 -0000 *************** *** 640,670 **** #ifdef USING_MALLOC_PAGE_GROUPS else { /* Allocate a large block of memory and serve out the aligned pages therein. This results in much less memory wastage than the traditional implementation of valloc. */ char *allocation, *a, *enda; size_t alloc_size, head_slop, tail_slop; int multiple_pages = (entry_size == G.pagesize); if (multiple_pages) alloc_size = GGC_QUIRE_SIZE * G.pagesize; else alloc_size = entry_size + G.pagesize - 1; ! allocation = xmalloc (alloc_size); page = (char *) (((size_t) allocation + G.pagesize - 1) & -G.pagesize); head_slop = page - allocation; if (multiple_pages) tail_slop = ((size_t) allocation + alloc_size) & (G.pagesize - 1); else tail_slop = alloc_size - entry_size - head_slop; enda = allocation + alloc_size - tail_slop; /* We allocated N pages, which are likely not aligned, leaving us with N-1 usable pages. We plan to place the page_group structure somewhere in the slop. */ if (head_slop >= sizeof (page_group)) group = (page_group *)page - 1; else --- 640,670 ---- #ifdef USING_MALLOC_PAGE_GROUPS else { /* Allocate a large block of memory and serve out the aligned pages therein. This results in much less memory wastage than the traditional implementation of valloc. */ char *allocation, *a, *enda; size_t alloc_size, head_slop, tail_slop; int multiple_pages = (entry_size == G.pagesize); if (multiple_pages) alloc_size = GGC_QUIRE_SIZE * G.pagesize; else alloc_size = entry_size + G.pagesize - 1; ! allocation = xcalloc (1, alloc_size); page = (char *) (((size_t) allocation + G.pagesize - 1) & -G.pagesize); head_slop = page - allocation; if (multiple_pages) tail_slop = ((size_t) allocation + alloc_size) & (G.pagesize - 1); else tail_slop = alloc_size - entry_size - head_slop; enda = allocation + alloc_size - tail_slop; /* We allocated N pages, which are likely not aligned, leaving us with N-1 usable pages. We plan to place the page_group structure somewhere in the slop. */ if (head_slop >= sizeof (page_group)) group = (page_group *)page - 1; 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 # define MAP_FAILED -1 # endif # if !defined (MAP_ANONYMOUS) && defined (MAP_ANON) # define 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. :-) 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. -O0 and -O2 get slightly different register allocations, although all versions of the code are correct. If 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. Paul.