From patchwork Sun Jan 27 13:45:21 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oleg Endo X-Patchwork-Id: 215990 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 8CFC92C008C for ; Mon, 28 Jan 2013 00:45:46 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1359899149; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:Mime-Version:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=FRwpSCByUcjBVYvVO5q3WibggJM=; b=qwHVSkSSXOUThHO UxtwtcxKZFNuVlM8g/cMouY45CL0bMyyXFuqk2LwX8iyAoUASa4FkiLKbuHdvGki P/T8tJ03xdsfibuAHTetpguGHm1tD/5Xeq+9HAoB/an1Ye0VXT7NjfZd4litGD8L /SXQrFyQiaCwQjly6wxqR+dSAZS4= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:Content-Type:Mime-Version:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=pNRiYvxPQSh9yqGhF3f8NMqSH+bacp8RW15j0M8nnXWj/c9ICVyZCNaryH87L8 Bn8z/l084IT38ERGUMlRQBhLR+Lsh+sGn8A29WZqc1VK122KI7bE3LOm4bHsxh/e y792xdS/r5Fpw6IdJkTN/S50fNPJjsDyev8YChfmS0tWA=; Received: (qmail 14267 invoked by alias); 27 Jan 2013 13:45:37 -0000 Received: (qmail 14256 invoked by uid 22791); 27 Jan 2013 13:45:34 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL, BAYES_00, KHOP_SPAMHAUS_DROP, KHOP_THREADED, RCVD_IN_DNSWL_NONE, RCVD_IN_HOSTKARMA_NO, RP_MATCHES_RCVD, UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Received: from mailout10.t-online.de (HELO mailout10.t-online.de) (194.25.134.21) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 27 Jan 2013 13:45:26 +0000 Received: from fwd07.aul.t-online.de (fwd07.aul.t-online.de ) by mailout10.t-online.de with smtp id 1TzSXy-0001RU-NG; Sun, 27 Jan 2013 14:45:22 +0100 Received: from [192.168.0.103] (E48VoZZJZhEGpTMx5AE-se03i2EdVoA6psOLiPb3P0zxOLsX2vXpABrT7fXT+knwP8@[93.218.191.18]) by fwd07.t-online.de with esmtp id 1TzSXy-1uu09o0; Sun, 27 Jan 2013 14:45:22 +0100 Message-ID: <1359294321.2367.31.camel@yam-132-YW-E178-FTW> Subject: Re: [wwwdocs] SH 4.8 changes - document thread pointer built-ins From: Oleg Endo To: Gerald Pfeifer Cc: gcc-patches@gcc.gnu.org, Kaz Kojima Date: Sun, 27 Jan 2013 14:45:21 +0100 In-Reply-To: <1357395569.20631.12.camel@yam-132-YW-E178-FTW> References: <1349733920.21984.52.camel@yam-132-YW-E178-FTW> <1350428236.2348.110.camel@yam-132-YW-E178-FTW> <1357395569.20631.12.camel@yam-132-YW-E178-FTW> Mime-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Sat, 2013-01-05 at 15:19 +0100, Oleg Endo wrote: > Hi, > > On Wed, 2013-01-02 at 19:13 -1000, Gerald Pfeifer wrote: > > Hi Oleg, > > > > On Wed, 17 Oct 2012, Oleg Endo wrote: > > >> +
  • Added support for the built-in functions > > >> + __builtin_thread_pointer and > > >> + __builtin_set_thread_pointer. This assumes that > > >> + GBR is used to hold the thread pointer of the current thread, > > >> + which has been the case since a while already. > > >> > > >> "since a while" -> "for a while", and I made that change. > > >> That said, why is this important, and is there a fixed date or version? > > > It might be important for some embedded systems software that does not > > > use the GBR for storing the thread pointer, but for something else (like > > > a pointer to some global table of frequently used stuff or something > > > like that). I just thought it might be better to mention this. But > > > you're right, the last "for a while" part sounds strange, and should > > > probably just be removed, reducing it to "This assumes that > > > GBR is used to hold the thread pointer of the current > > > thread." > > > > That sounds good. I noticed this has not been changed yet, so I > > assume you were probably waiting for my response? Will you be > > making this change? > > I also assume I was waiting for your response ;) > (it's been a while, can't remember exactly). > > I'll send a patch with the change. Thanks for reminding me. > > Cheers, > Oleg > > I have just committed the attached patch to fix the issue mentioned above. Cheers, Oleg ? www_4_8_sh_changes_4.patch Index: htdocs/gcc-4.8/changes.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.88 diff -u -r1.88 changes.html --- htdocs/gcc-4.8/changes.html 20 Jan 2013 13:41:25 -0000 1.88 +++ htdocs/gcc-4.8/changes.html 27 Jan 2013 13:42:23 -0000 @@ -671,10 +671,10 @@
  • Added support for the built-in functions __builtin_thread_pointer and __builtin_set_thread_pointer. This assumes that - GBR is used to hold the thread pointer of the current thread, - which has been the case for a while already. Memory loads and stores - relative to the address returned by __builtin_thread_pointer - will now also utilize GBR based displacement address modes. + GBR is used to hold the thread pointer of the current thread. + Memory loads and stores relative to the address returned by + __builtin_thread_pointer will now also utilize GBR + based displacement address modes.