From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20239 invoked by alias); 22 Feb 2016 20:25:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 20229 invoked by uid 89); 22 Feb 2016 20:25:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=embedded, mighty X-HELO: smtp.ispras.ru Received: from smtp.ispras.ru (HELO smtp.ispras.ru) (83.149.199.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Feb 2016 20:25:44 +0000 Received: from [10.10.3.121] (unknown [83.149.199.91]) by smtp.ispras.ru (Postfix) with ESMTP id 27230203D9; Mon, 22 Feb 2016 23:25:40 +0300 (MSK) Date: Mon, 22 Feb 2016 20:25:00 -0000 From: Alexander Monakov To: Nathan Sidwell cc: gcc-patches@gcc.gnu.org Subject: Re: [gomp-nvptx 3/5] nvptx backend: set up stacks in entry code In-Reply-To: <56CB3539.6050200@acm.org> Message-ID: References: <1455561852-9237-1-git-send-email-amonakov@ispras.ru> <1455561852-9237-4-git-send-email-amonakov@ispras.ru> <56CB3539.6050200@acm.org> User-Agent: Alpine 2.20 (LNX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2016-02/txt/msg01514.txt.bz2 On Mon, 22 Feb 2016, Nathan Sidwell wrote: > On 02/15/16 13:44, Alexander Monakov wrote: > > This patch implements the NVPTX backend part of the transition to > > > + static const char template64[] = ENTRY_TEMPLATE ("64", "8", > > "mad.wide.u32"); > > + static const char template32[] = ENTRY_TEMPLATE ("32", "4", "mad.lo.u32 > > "); > > +#undef ENTRY_TEMPLATE > > + const char *template_1 = TARGET_ABI64 ? template64 : template32; > > + const char *template_2 = template_1 + strlen (template64) + 1; > ^^^ > this looks mighty suspicious -- are you presuming some specific placement of > template64 & template32? (and even then I think it'll only work for > TARGET_ABI64) Template strings have an embedded nul character at the position where ORIG goes, so template_2 is set to point at the position following the embedded nul in template_1. Offset of the embedded nul is the same in each template string, so it doesn't matter which goes into the argument of strlen (but supplying template64 or template32 instead of template_1 allows easier folding). Alexander