From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-158394-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 20300 invoked by alias); 28 Nov 2009 16:35:55 -0000
Received: (qmail 20286 invoked by uid 22791); 28 Nov 2009 16:35:54 -0000
X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 	tests=BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail-yw0-f180.google.com (HELO mail-yw0-f180.google.com) (209.85.211.180)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 28 Nov 2009 16:35:46 +0000
Received: by ywh10 with SMTP id 10so6163172ywh.8         for <gcc@gcc.gnu.org>; Sat, 28 Nov 2009 08:35:45 -0800 (PST)
Received: by 10.150.45.37 with SMTP id s37mr3657788ybs.281.1259426145099;         Sat, 28 Nov 2009 08:35:45 -0800 (PST)
Received: from Paullaptop (203-158-49-56.dyn.iinet.net.au [203.158.49.56])         by mx.google.com with ESMTPS id 13sm650852gxk.9.2009.11.28.08.35.42         (version=SSLv3 cipher=RC4-MD5);         Sat, 28 Nov 2009 08:35:44 -0800 (PST)
Message-ID: <A8127E96608848FDB5D1167911A9BACE@Paullaptop>
From: "Paul Edwards" <mutazilah@gmail.com>
To: "Richard Guenther" <richard.guenther@gmail.com>
Cc: <gcc@gcc.gnu.org>
References: <200911241405.nAOE5Jsd022678@d12av02.megacenter.de.ibm.com> <7B52F224E6EE465EB95237D5A0D9A15F@Paullaptop> <84fc9c000911280802j3a0be6b1p1241d81d91f0672e@mail.gmail.com>
In-Reply-To: <84fc9c000911280802j3a0be6b1p1241d81d91f0672e@mail.gmail.com>
Subject: Re: i370 port - music/sp - possible generic gcc problem
Date: Sat, 28 Nov 2009 16:35: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: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2009-11/txt/msg00794.txt.bz2

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

Hi Richard.

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
why is the surrounding code (in GCC 4.4's alloc_page())
calling XCNEWVEC instead of XNEWVEC?

Thanks.  Paul.