[Info-vax] LLVM, volatile and async VMS I/O and system calls

[chris]

On 09/27/21 20:03, Simon Clubley wrote:
> On 2021-09-26, chris<chris-nospam at tridac.net>  wrote:
>> On 09/25/21 19:46, Simon Clubley wrote:
>>>
>>> Looking at the generated code has proved interesting at times. :-)
>>>
>>> The following Ada Issue is a direct result of me looking at someone's
>>> problem on comp.lang.ada a number of years ago which was caused by
>>> the code the Ada compiler had generated:
>>>
>>> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0128-1.txt?rev=1.15&raw=N
>>>
>>> The following AI is also directly related to this:
>>>
>>> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0127-1.txt?rev=1.27&raw=N
>>>
>>> [I am _not_ a member of the ARG or anything like that. I am just a
>>> normal programmer who includes Ada in the list of languages I know.]
>>>
>>
>> Interesting examples, but just how much of that was due to system
>> complexity ?.
>>
>
> Not directly in this case IIRC. Ada is about modelling the problem
> using a very strict type system and a very strong type system that
> allows a problem to be modelled in detail.
>
> However, in this case IIRC, the optimiser simply did something
> unexpected when a bitfield within a record instead of the 32-bit
> record itself (as would be the case in C) was updated even through
> the 32-bit record was marked as Atomic.
>
> As you can see, the suggested changes allow Ada to still be Ada but
> also make sure the correct sized memory read and write occurs.
>
> To be honest however, I'm surprised the issue wasn't discovered prior
> to the problem report showing up in comp.lang.ada.
>
> Simon.
>

Sometimes bugs are discovered decades later, but usually something to
do with a corner case that is infrequently used. They say all software
has bugs, even the most proven and best maintained :-).

Program C in a fairly strict subset here. Never use bitfields at all,
which are not portable across architectures. Much better to use masks
or short lookup tables for bit level access...


Chris