From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4055 invoked by alias); 16 Oct 2013 14:30:02 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 4042 invoked by uid 89); 16 Oct 2013 14:30:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f173.google.com Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 16 Oct 2013 14:30:01 +0000 Received: by mail-ie0-f173.google.com with SMTP id u16so1417626iet.18 for ; Wed, 16 Oct 2013 07:29:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=le3cOkZMB2SDRyAjLC8+3/mWc0RVxFSZD6xwdgNu/3A=; b=Zc7V/bCvqdeamswB13AJSeDGkCMZ6FLjiZijK3pvzn8SfEEu+xkKiMVxrdFGAHwMCS yMPMM7B3HQo2D3XgNAhVc7zyF3eEhRahtUzwUAxt8hL0j7787D6iuNgnwJxnRrrj6NUi ub311QYi0aHZTZcDuzNXi6N+z3p4QdzSMPd/4xzYS/JufJLlw0CcRqRNk10wN+Oaj/q3 SW+dU7FBAMDMSqIquFgodx6eH2niFT95N/jB1IXwkn7wy9mnGdhr6DE+FbpcnjdUEiDD Kcry2q+4FRv7Qk3tyX9r7sg8YUHEqQzfV8Du8WYNCodeFHSGz/qvIAoIhcHVBZ1jYReg UuKA== X-Gm-Message-State: ALoCoQmLGfxbbnN2ilktSjF5ap7PnbToGuH90pyXTY0hKnS7lqsA+iOFIMijEFolfgg/x1vma0FtS3w67ZPFifZrxgpmFPen7rUaO+SeGUdvd3iTsfDjiNp2o4v+Ryj7hnFWOUtUQK04Lbk7MHnRrMS5e0FSKAsF0VR79v/GX3akmmdO+ZRa7cZo6/G/vCFlwZEMQW2ZGeTU MIME-Version: 1.0 X-Received: by 10.50.85.115 with SMTP id g19mr17465343igz.1.1381933798939; Wed, 16 Oct 2013 07:29:58 -0700 (PDT) Received: by 10.64.77.134 with HTTP; Wed, 16 Oct 2013 07:29:58 -0700 (PDT) In-Reply-To: <65513286F68AA34992CFC96B7C77DF397697A867@srv-exch-mbx2.skoda.cz> References: <65513286F68AA34992CFC96B7C77DF397697A7FF@srv-exch-mbx2.skoda.cz> <65513286F68AA34992CFC96B7C77DF397697A867@srv-exch-mbx2.skoda.cz> Date: Wed, 16 Oct 2013 14:30:00 -0000 Message-ID: Subject: Re: Variable order and location within the section - optimization level dependent From: Ian Lance Taylor To: =?ISO-8859-2?B?SmFu4ehlayBKafjt?= Cc: "gcc-help@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00047.txt.bz2 On Wed, Oct 16, 2013 at 7:06 AM, Jan=C3=A1=C4=8Dek Ji=C5=99=C3=AD wrote: > > I do know this approach. I have created sections with the appropriate add= ress ranges and located the variables into those sections by the below ment= ioned attribute. > If no optimization is turned on, then the order (means also the address o= ffset of the variable) is correct. > If -O1 is turned on, the variables order within the section is exactly op= posite. > If -O1 is turned on and the flag -fno-toplevel-reorder is turned on as we= ll, then the order is equal to the requested one. But I would like to apply= such a behavior (no reorder) just for some variables in some modules. Othe= r modules should be optimized by -O1 level. > So I am curious which attributes can define this behavior. Please don't top-post. Thanks. It sounds like you are saying that you want to have your global variables appear in a specific order in a specific section. There is no attribute that will make that happen. Sorry. The obvious workaround would be to use a struct. Ian