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!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: MatthiasR <MatthiasR@invalid.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Forcing GNAT to use 32-bit load/store instructions on ARM?
Date: Sun, 10 Aug 2014 13:20:42 +0200
Organization: -
Message-ID: <ls7kvh$2uv$1@dont-email.me>
References: <0e0b9ac2-e793-4cc5-8d8d-d3441ca28a58@googlegroups.com>
 <1j7b0m3yptffy$.1cztnkty8elrv$.dlg@40tude.net> <lou8e0$7u2$3@dont-email.me>
 <ee4cjxhhe7yi$.kqeq5ati5vrg$.dlg@40tude.net> <loupft$48j$1@dont-email.me>
 <nboccqyjxkzx$.10p3g2l6gzzdd.dlg@40tude.net> <lov4ga$3v9$1@dont-email.me>
 <lp20qc$iju$1@loke.gir.dk> <lpcck1$vtv$1@dont-email.me>
 <lpf7hv$am9$1@loke.gir.dk> <lqg9ve$svj$1@dont-email.me>
 <lqgodn$ur3$1@dont-email.me> <lr02dr$ql9$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
Injection-Date: Sun, 10 Aug 2014 11:27:45 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="e5ec6e7d446d78c0edf2b783817335a0";
	logging-data="3039"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/froj3a8Wc7yZZ5H/HtLXJnN7f9deVa48="
User-Agent: KNode/4.7.2
Cancel-Lock: sha1:D7Rgo0Ic5jLR75wQc2SWOLbymho=
Xref: news.eternal-september.org comp.lang.ada:21640
Date: 2014-08-10T13:20:42+02:00
List-Id: <comp.lang.ada>

Latest GNAT Pro emits a warning on accesses to components of atomic records:

http://www.adacore.com/developers/development-log/NF-73-M715-002-gnat/

At least, one knows that something can go wrong here...


Some background story:
We stumbled upon this problem some time ago. After I had realised that the 
RM doesn't give any guarantees in this case (at least the RM can be 
interpreted in this way...), I filed an enhancement request to Adacore. I 
proposed to add a (implementation specific, since there isn't anything in 
standard and I didn't want to wait until Ada 202x) pragma and/or aspect 
which should enforce a specific access width.

That's basically the same as Simon Clubleys proposal in his second issue for 
'Ada-comments'.

After some discussions, the proposal was rejected, because
- there is a working way to solve the problem (the temporary variable)
- 'no one would know this implementation specific pragma/aspect'
- there is little chance to get this in the standard

The new warning is apparently the result of these discussions.


Matthias