From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9093 invoked by alias); 21 Oct 2013 15:12:07 -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 9083 invoked by uid 89); 21 Oct 2013 15:12:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f169.google.com Received: from mail-pd0-f169.google.com (HELO mail-pd0-f169.google.com) (209.85.192.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 21 Oct 2013 15:12:06 +0000 Received: by mail-pd0-f169.google.com with SMTP id q10so6351126pdj.14 for ; Mon, 21 Oct 2013 08:12:03 -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; bh=L7+iQdriNiyGFbSVeTZbzYX1aH2exGe6v5UXM7WVbqM=; b=hgaZgnxof8uvQNxiJiztuTNPbPm72ZWvAPTmFljW8vgrWArKAlLUYWYeHhU84mzuMk qfucTP8w8754UbN99kUtKG3mbiritioDAxSthMxG3i9hpmpvsZ9Q2bXEYbogc7cx/IBS w/e/AOxalWLTQmHi/KWaR5zpqGqDkHqGioMYOn2qPAv1Sn3lkKyNNH2m7YBrLMGOCPqe 0mLbzztgrbAKRgXTktaOuu69spOqf1o3L19Do4c+ahLxQ7B3PL9iCowcz8j3YbJsq7aM Y9mPWpUPdMu/I3AIP7Ra29da2YX3ADURGkir+pODHRl+1ehAMat/Y4l1z0YHqLjvUysX dwWg== X-Gm-Message-State: ALoCoQmVKhaDM3bgoiTZc5aDr0zhV5xwbMPpE25XEUcLhtTHWSJN4+tmPfWf8TjGuHT6J9BAVF+BEJm9X+JBXuS5IM/8x8CVtoqh5L/Usic2r2cJGRnQIG2IMZ7NxAYvi+/Hk9d46boWdOihr1aBZF/4MHgUf4SD9m0tvLcaywT7cegSOfSLtQMsm3hR0ErTV/yZvsoAVeRX MIME-Version: 1.0 X-Received: by 10.68.172.66 with SMTP id ba2mr18208338pbc.92.1382368323316; Mon, 21 Oct 2013 08:12:03 -0700 (PDT) Received: by 10.68.66.9 with HTTP; Mon, 21 Oct 2013 08:12:03 -0700 (PDT) In-Reply-To: <5.2.0.9.1.20131021113552.0631a6f8@localhost> References: <65513286F68AA34992CFC96B7C77DF397697A7FF@srv-exch-mbx2.skoda.cz> <65513286F68AA34992CFC96B7C77DF397697A867@srv-exch-mbx2.skoda.cz> <65513286F68AA34992CFC96B7C77DF397697A92D@srv-exch-mbx2.skoda.cz> <5.2.0.9.1.20131021113552.0631a6f8@localhost> Date: Mon, 21 Oct 2013 15:12:00 -0000 Message-ID: Subject: Re: Variable order and location within the section - optimization level dependent From: Ian Lance Taylor To: Fabian Cenedese Cc: "gcc-help@gcc.gnu.org" Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00098.txt.bz2 On Mon, Oct 21, 2013 at 2:46 AM, Fabian Cenedese wrote: > > I'll have to side with the OP here. We also use code that relies on the order > of the toplevel items so we need to use the no-reorder flag, no problem there. > So I was eagerly reading this thread to find other ways to achieve the same > result (there don't seem to be, that's okay). > > However reading the documentation I find it hard to see any other meaning > than that "there are attributes that do the same as -fno-toplevel-reorder". If > there aren't any attributes for this precise case then what's this sentence > doing in the -fno-toplevel-reorder section? Well, OK. I just committed a patch to add "when possible," so the sentence now reads "For new code, it is better to use attributes when possible." > I think these approaches where one could use attributes to influence > the ordering should be mentioned here and also where it's not possible. > Otherwise people might start looking for these attributes that don't > exist (at least 2 people now :) I don't know how to enumerate the cases because I don't know what people use -fno-toplevel-reorder for. I continue to believe that it is always possible to rework your code using attributes. For the OP's case a struct plus #define macros would have addressed the case, until the code was very unusual. Ian