Re: Query about variable initialization

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 20 June 2018 at 20:57, Laszlo Ersek <lersek@redhat.com> wrote:
> On 06/20/18 20:03, Ard Biesheuvel wrote:
>> On 20 June 2018 at 19:48, Evan Lloyd <Evan.Lloyd@arm.com> 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.