From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Menage Subject: Re: ACPI global lock macros Date: Thu, 11 Dec 2003 00:27:54 -0800 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <3FD82A8A.9050307@google.com> References: <3ACA40606221794F80A5670F0AF15F8401720C21@PDSMSX403.ccr.corp.intel.com> <20031211090716.0c3662d3.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20031211090716.0c3662d3.ak-l3A5Bk7waGM@public.gmane.org> Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Andi Kleen Cc: "Yu, Luming" , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-acpi@vger.kernel.org Andi Kleen wrote: > > It has even more bugs, e.g. it doesn't tell gcc that GLptr is modified (this hurts with > newer versions that optimize more aggressively) GLptr itself isn't modified - *GLptr is, but none of the actual C code accesses *GLptr, so how does this affect the compiler's optimization efforts? Is it because gcc treats the call as a pure function that maps a pointer to an acquired value, and hence believes that it can move it around? There aren't any instances of ACPI_ACQUIRE_GLOBAL_LOCK being called twice in the same function, so it wouldn't be able to cache a result. But I agree that it ought to declare that it clobbers memory. Paul ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/