From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4809 invoked by alias); 16 Oct 2013 13:55:50 -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 4795 invoked by uid 89); 16 Oct 2013 13:55:49 -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-f177.google.com Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com) (209.85.223.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 16 Oct 2013 13:55:48 +0000 Received: by mail-ie0-f177.google.com with SMTP id e14so1279109iej.22 for ; Wed, 16 Oct 2013 06:55:46 -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=h+6F38jYssJPeca5xiOFS+UiitAV8rMWjihyo4MzZjE=; b=cRwGFE8sFE+HLoLfqwqbYprRL+XzUrdFkDzxYgtqP4bu+mD89z5gPPxQ6g32sCrvXW RD1mk19/0tqUIney1Yw2PL+wr80yN3fTyRsG1iurbPA+HQamMQj7ctAbclSLc86B0uuP Lz+J2r1OYLHlzxN3r8Pi7sJ18bM6/wBq9n8PFOX+NIrz4KW96iAr2PYicnn/rwqCKWtn hI5IlzcGZfw38jJX6Lgn9R8RhbFeqw1qFKCGQ59QkpgZ19P7ohJvywtmt4zuMm3Pqyr2 pTytTqS7PaAXMSrEw7AURwn0NmP850w6VLQ+RAz+A9mWcpEruqL5/vw8J8bJXpJWzmcE 87MQ== X-Gm-Message-State: ALoCoQlgDgqDrNicXVfo4Bhl78hxN7sMWLmVgZ+Pc5IOm9qSGRix3mw7aNObI+op3qbqq2LkDBSXlyTJvxVwjRtNBbLqyhvUrTOjLiYB+6G92oM8LJGlCWzR/sh3ahMxhSZBWo03jgZYidHDwBH6eO+BiB5ZTVq7owglZ0qnU8uZb3VP3HS7PO13EBRgCefEeHZPSVnpEOiT MIME-Version: 1.0 X-Received: by 10.50.55.65 with SMTP id q1mr21659144igp.4.1381931746208; Wed, 16 Oct 2013 06:55:46 -0700 (PDT) Received: by 10.64.77.134 with HTTP; Wed, 16 Oct 2013 06:55:46 -0700 (PDT) In-Reply-To: <65513286F68AA34992CFC96B7C77DF397697A7FF@srv-exch-mbx2.skoda.cz> References: <65513286F68AA34992CFC96B7C77DF397697A7FF@srv-exch-mbx2.skoda.cz> Date: Wed, 16 Oct 2013 13:55: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/msg00045.txt.bz2 On Wed, Oct 16, 2013 at 4:25 AM, Jan=C3=A1=C4=8Dek Ji=C5=99=C3=AD wrote: > > We have discussed the topic regarding the compiler flag -fno-toplevel-re= order and relative stuff at the GCC ARM forum (https://answers.launchpad.ne= t/gcc-arm-embedded/+question/237324). > > GCC documentation (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.htm= l#Optimize-Options) states: > > "Do not reorder top-level functions, variables, and asm statements. Outpu= t them in the same order that they appear in the input file. When this opti= on is used, unreferenced static variables are not removed. This option is i= ntended to support existing code that relies on a particular ordering. For = new code, it is better to use attributes." > > > The major question sounds - which attributes should be applied in such a = case? Well, what are you trying to do? There are various different things that people used to do based on specific ordering in the source file. One common use was to force functions into particular sections by writing code like asm (".section mysec"); int f() { return 0; } asm (".text"); The way to do that without relying on -fno-toplevel-reorder is to use an attribute for the function. int f() __attribute__ ((section ("mysec"))); int f() { return 0; } Ian