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!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Compiler doesn't respect 'Size for atomic object Date: Wed, 20 Dec 2017 20:45:52 -0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Wed, 20 Dec 2017 20:45:52 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="b730f3f8a4a99b3edd32530cc8db11a2"; logging-data="16204"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Vzo810/71MNMEzMbHHIouy/+eBiShFA8=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:vtb45cTpKQXcbYRcTIXmjEWA4vM= Xref: reader02.eternal-september.org comp.lang.ada:49555 Date: 2017-12-20T20:45:52+00:00 List-Id: On 2017-12-20, Simon Wright wrote: > Simon Clubley 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. [*] That qualifier is there because I seem to have a vague recollection of previous discussions around problems that occurred when Size was used to extend a data type but I can't remember the details. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world