From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-425334-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 8642 invoked by alias); 21 Apr 2016 14:00:24 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 8607 invoked by uid 89); 21 Apr 2016 14:00:21 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=
X-HELO: mail-qg0-f43.google.com
Received: from mail-qg0-f43.google.com (HELO mail-qg0-f43.google.com) (209.85.192.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 21 Apr 2016 14:00:20 +0000
Received: by mail-qg0-f43.google.com with SMTP id c6so46784847qga.1        for <gcc-patches@gcc.gnu.org>; Thu, 21 Apr 2016 07:00:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20130820;        h=x-gm-message-state:sender:subject:to:references:from:message-id         :date:user-agent:mime-version:in-reply-to:content-transfer-encoding;        bh=LnHLsDMa8EtCKYn+eG7XF5Ehs7tKuzO0P+ZHtrZfawo=;        b=gRJrd8FKfq94in/OD+3YDx8xdmXMkn50kqNyofUX94/laAkAgvsR2TdGM3aWAJcEXr         vXaTM7oD+nGUYkGWhRhX9uF0jlVMxzGi4CGYwtUMF0eFV7nghRZyPVJVh0i0Ho0BVeAo         bFD518ujwTzpNCAdRjRu/prdQLPof6VZM0w6FG2qphavLgSrHZ5owsjyY7LWwrGTbd/L         sL4WCDn+q609RVmt0VuGBdrGpHNavuOV7XhGs1zD3u5ujoNW4itGt6CUfGLErzQsW0kR         Z005hPFrW2WIyfb3BVPpvapcbrwfKp0PYKK9iW1XRRJpwy7csU0yZyAoWcSL5eb1Z5CT         lEOQ==
X-Gm-Message-State: AOPr4FUc9AhadcgX3dXM/a1P00g+DS9jHw4fngg5SEvU4IQYJXBG8dpTedwEFcA9nPIDcw==
X-Received: by 10.140.29.246 with SMTP id b109mr16904208qgb.2.1461247218011;        Thu, 21 Apr 2016 07:00:18 -0700 (PDT)
Received: from ?IPv6:2601:181:c003:1930:a2a8:cdff:fe3e:b48? ([2601:181:c003:1930:a2a8:cdff:fe3e:b48])        by smtp.googlemail.com with ESMTPSA id e84sm473843qhd.26.2016.04.21.07.00.16        (version=TLSv1/SSLv3 cipher=OTHER);        Thu, 21 Apr 2016 07:00:17 -0700 (PDT)
Subject: Re: [PATCH] add support for placing variables in shared memory
To: Alexander Monakov <amonakov@ispras.ru>, gcc-patches@gcc.gnu.org
References: <alpine.LNX.2.20.1604201957570.14803@monopod.intra.ispras.ru>
From: Nathan Sidwell <nathan@acm.org>
Message-ID: <5718DCF0.5000808@acm.org>
Date: Thu, 21 Apr 2016 14:00:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <alpine.LNX.2.20.1604201957570.14803@monopod.intra.ispras.ru>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2016-04/txt/msg01175.txt.bz2

On 04/20/16 12:58, Alexander Monakov wrote:
> Allow using __attribute__((shared)) to place static variables in '.shared'
> memory space.

What is the rationale for a new attribute, rather than leveraging the existing 
section(".shared") machinery?

> +  else if (current_function_decl && !TREE_STATIC (decl))
> +    {
> +      error ("%qE attribute only applies to non-stack variables", name);

'non-stack'?  don't you mean 'static' or 'static storage'?

Needs a test case.

nathan