From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Compiler doesn't respect 'Size for atomic object
Date: Thu, 21 Dec 2017 01:10:39 -0600
Organization: JSA Research & Innovation
Message-ID: <p1fmpg$inr$1@franka.jacob-sparre.dk>
References: <lyy3lxfufs.fsf@pushface.org> <p1edbj$flb$1@dont-email.me>
 <lytvwlf8zj.fsf@pushface.org> <p1ei5v$fqc$1@dont-email.me>
Injection-Date: Thu, 21 Dec 2017 07:10:40 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="19195"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader02.eternal-september.org comp.lang.ada:49564
Date: 2017-12-21T01:10:39-06:00
List-Id: <comp.lang.ada>

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:p1ei5v$fqc$1@dont-email.me...
> On 2017-12-20, Simon Wright <simon@pushface.org> wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>> If you use a naturally 32-bit variable instead of your Interrupt_ID
>>> data type, does it work ok ?
>>
>> Yes. My workround is to declare the atomic object as Integer, and
>> convert the Interrupt_ID to Integer (the ARM says only that Interrupt_ID
>> is discrete, but that's a bridge to cross when we come to it; it's
>> naturally an Integer on Cortex-M).
>
> Unless Randy and company come up with something around the use of
> Size to extend the size of the base data type[*], I would consider
> this to be a compiler bug.

I tend to agree. The reason is 13.1(7/2). The extra bits in this case are 
defined to be "padding bits", and 13.1(7/2) says that "padding bits are 
normally read and updated along with the others".

AI12-0128-1 adds some rules for non-atomic subcomponents of atomic objects, 
but it shouldn't change the behavior of an *elementary* atomic object, like 
this one. Perhaps GNAT is treating this like a record type with two 
components, the actual integer value, and some padding bits. Then it would 
be right. (But that's not how the language defines this object.)

Still, you'll always have less issues if you avoid padding bits and have the 
subtype Object_Size (this is now in Ada 2020, so we can talk about it) be 
32.

Which is something you (Simon Wright, not Simon Clubley) might try, since 
Object_Size can be specified for any subtype. So try declaring:

    subype Simons_Interrupt_Id is Interrupt_Id with Object_Size => 32;

and declare your object of that subtype. Then there are no padding bits (as 
defined  by 13.1(7.2)).

                            Randy.