Re: Erroneous code generation from GNAT or GCC?

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Mon, 29 Apr 2013 00:35:03 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

>         Element : Character := Item; -- <<< Copy of argument

If this, is changed into:

           Element :
              Character := Item
              with Volatile => True;

The issue is solved. Here is the generated code:


     library__write__2:
     .LFB7:
        .cfi_startproc
        pushl   %ebx              #
        .cfi_def_cfa_offset 8
        .cfi_offset 3, -8
        subl    $24, %esp         #,
        .cfi_def_cfa_offset 32
        movl    32(%esp), %eax    # item, item
        movb    %al, 15(%esp)     # item, element
        movl    $1, %edx          #, tmp65
        leal    15(%esp), %ecx    #, element.19
        movl    $4, %eax          #, tmp64
        movl    %edx, %ebx        # tmp65, tmp65


It is still reading at a non‑32 bits aligned address even if there is only  
one character at that address (well, why not, Intel 32 bits CPU does not  
triggers exceptions for this), but now it is at least making a copy of  
`Item`, which is fetched from [esp+32] as I expected in the previous  
message, then store it at [esp+15], so the address stored in ecx is now an  
address which really correspond to an initialized memory area. The  
system‑call invocation succeed.

I wonder if this is normal or not. What's your opinion?

Here is what the RM says:

http://www.ada-auth.org/standards/12rm/html/RM-C-6.html#p20
> The external effect of a program (see 1.1.3) is definedto include each  
> read and update of a volatile or atomicobject. The implementation shall  
> not generate any memoryreads or updates of atomic or volatile objects  
> other thanthose specified by the program.

This is quoted from “C.6 Shared Variable Control”. But this is a local  
variable, not a shared object, and I don't intuitively agree with GNAT or  
GCC optimization here. Unless I'm wrong, in which case I welcome any  
rationale relevant to explain why.

The parameters passed to a sub‑program may also be used or not, and GNAT  
does not dropped them all. As it can be noticed, it did not dropped  
parameter passing, and the parameter is not declared as being of a  
volatile type.

Seems less care is taken by the compiler, with foreign machine‑code  
insertion, even if via some level of indirection, than with it's own  
generated code, while it should be the opposite.

Until now, I though the volatile aspect was typically to be used with  
object which may be updated as a non‑visible side effect, like with a  
peripheral writing at some memory area, asynchronously (or not, that's  
still not directly visible anyway). But here, that's a local variable,  
which is explicitly referred to and explicitly assigned. If the address is  
passed, that should implies the address means something, especially if the  
address is an input parameter as it is here. And what means the address of  
an uninitialised area when that area was directed to be explicitly  
initialized by the source? Isn't GNAT of GCC lacking some semantic  
dependency tracking here?

May be I should make parameter types of the system‑call's generic  
declaration, all volatile? If so, this would implies that can be said of  
all machine‑code insertions?

But then, why isn't it automatic so?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University