From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <java-return-26497-listarch-java=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 16075 invoked by alias); 30 Nov 2009 10:07:23 -0000
Received: (qmail 16030 invoked by uid 22791); 30 Nov 2009 10:07:21 -0000
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Nov 2009 10:07:15 +0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) 	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAUA7BLH030965 	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); 	Mon, 30 Nov 2009 05:07:11 -0500
Received: from zebedee.pink (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) 	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAUA78SJ016771; 	Mon, 30 Nov 2009 05:07:09 -0500
Message-ID: <4B13994B.4060604@redhat.com>
Date: Mon, 30 Nov 2009 10:07:00 -0000
From: Andrew Haley <aph@redhat.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090825)
MIME-Version: 1.0
To: Ben Elliston <bje@au1.ibm.com>
CC: java <java@gcc.gnu.org>, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: PATCH, boehm-gc: silence warning
References: <1259555306.23081.4.camel@bapbop>
In-Reply-To: <1259555306.23081.4.camel@bapbop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <java.gcc.gnu.org>
List-Id: <java.gcc.gnu.org>
List-Subscribe: <mailto:java-subscribe@gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/java/>
List-Post: <mailto:java@gcc.gnu.org>
List-Help: <mailto:java-help@gcc.gnu.org>, <http://gcc.gnu.org/ml/#faqs>
Sender: java-owner@gcc.gnu.org
X-SW-Source: 2009-11/txt/msg00077.txt.bz2

Ben Elliston wrote:
> When compiling mark_rts.c, GCC warns about taking the address of a local
> variable.  This is not a bug, but an explicit hack to get the
> approximate address of a new stack frame, to calculate the limits of the
> current frame.  There is a cleaner way to do this with GCC: use
> __builtin_frame_address.  My reading of the code suggests that this will
> work just as well.
> 
> Tested with a bootstrap on x86_64-linux and a full regression testsuite
> run, including make check-target-boehm-gc. Okay for mainline?

OK, but make sure this goes upstream to gc@linux.hpl.hp.com

Andrew.