From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::241; helo=mail-io0-x241.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0F26521122E2A for ; Wed, 20 Jun 2018 12:01:37 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id e15-v6so735788iog.1 for ; Wed, 20 Jun 2018 12:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=syHfRiKbxwauUvKyfb5MjCDrcBf81W+ezyKmmjzRqdM=; b=NciJpqJOesKj7SaPP8nScj0z1H0+St/n9eogL7Jem/Uw5GvkyV+xvDuEBSmw5R8yFG jBBO6HHnwbRgLHuDWlwVDMFt7tXmUYhd8lecjvesytEQxEdYH9nA7E/QlpCzYp96OuuC Tv1L5+BmVup3y42WZ3dM6pPKKf4/wCc2IlugM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=syHfRiKbxwauUvKyfb5MjCDrcBf81W+ezyKmmjzRqdM=; b=t2yMnEtkWRJNAQsPy2HMSp+eJcJchcGUE6eP0QhuNltmbH1kxhQSgU5tmlM+dmx4jG DCC+/cpgxH0iaFnsenDgnE2HgJgq0wFeugntvxZSilq9oFkjfUr0NRm3msrqD7ihmuFP ez9glKgMpuaGrgsIU3rhcw7eGSk1y6XwYUZT/Zfe7JpqHhiQ5V3M7SM0NSYoBYfY0VN2 w+m/k41BAkSmnMTnQFy3BlxzGhYkJMQDfOpcK9Bx5kJGlT6NKyrBdosk7s8b1zMMoXrV 97Yt1c1k4uoohZUmtCkMg7jTP6ZlJiOSVx5tfhl1riIHQVwGsmb1Kq4Zq2kaF+DwWkvV amHg== X-Gm-Message-State: APt69E00hr0gE4640HmiA4dFkN94If1VrDIUwTy7FrYtCWFGtFv46H0X UdQTUZJRndhdFcEMZXMSoOA8EjzqODEdxgWylkN1D/k9 X-Google-Smtp-Source: ADUXVKJi3Ei9Lx+Q+OK9kI0KlEBjRkCkRqpT+smvFvvV5GstHLTLmDNiUSzITOoQTh6ottHjclgTd7SAzQlvBKsryXo= X-Received: by 2002:a6b:520d:: with SMTP id g13-v6mr19079267iob.60.1529521297162; Wed, 20 Jun 2018 12:01:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bbc7:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 12:01:36 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Wed, 20 Jun 2018 21:01:36 +0200 Message-ID: To: Laszlo Ersek Cc: Evan Lloyd , "edk2-devel@lists.01.org" , nd , Stephanie Hughes-Fitt , Leif Lindholm Subject: Re: Query about variable initialization X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 19:01:38 -0000 Content-Type: text/plain; charset="UTF-8" On 20 June 2018 at 20:57, Laszlo Ersek wrote: > On 06/20/18 20:03, Ard Biesheuvel wrote: >> On 20 June 2018 at 19:48, Evan Lloyd wrote: >>> Hi Ard, Leif. >>> I've noticed a number of comments like Ard's recent "We don't permit initialized automatic variables.", >>> and similar changes have been made to Sami's AcpiView. Note: I'm not objecting to doing it the way maintainers prefer, which is why this is not a response. >>> >>> My understanding was that the CCS was changed some time back to remove the restriction on initializing variables (and I further think I remember Leif being a prime mover in that). >> >> I don't remember, to be honest. But I think it is a stupid rule, and >> so if we haven't already, I hope we can get rid of it. >> >> IIRC, this limitation had something to do with a particularly nice >> exhibit in the Tianocore toolchain museum that generated bigger >> binaries for initialized automatic variables (as compared to >> assignments performed separately). But let's not get into the >> toolchain situation, shall we? > > One special case of initialization is when the variable in question has > structure type. For such initialization the compiler may generate calls > to internal helper functions (memset and friends), and then the module > fails to link. I've seen this myself earlier, although I can't tell > whether on gcc-4.4 or gcc-4.8. > That is a very good point. Note that this does not affect ARM, given that we already have to provide the AEABI intrinsics (and memset and memcpy for GCC), but I can see how other architectures may be bitten by this. I suppose the compiler is free to apply the same optimization to a block of automatic POD type variables, although I'd be surprised if that ever occurs in practice.