Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

[Marcin Godlewski]

Please see my answer at the bottom.

W dniu 2016-12-09 09:15:24 użytkownik David Brown <address@hidden> napisał:
> On 08/12/16 21:55, Marcin Godlewski wrote:
> > 
> > 
> > W dniu 2016-12-08 21:46:40 użytkownik Georg-Johann Lay <address@hidden> 
> > napisał:
> >> Marcin Godlewski schrieb:
> >>> Dear all,
> >>>
> >>> Thanks for the reply to David. However I'm not trying to find a solution 
> >>> for the described issue. What I'm trying to say in this e-mail is that 
> >>> this part of Atmel documentation: 
> >>> http://www.atmel.com/webdoc/AVRLibcReferenceManual/optimization_1optim_code_reorder.html
> >>>  is innacurate and should be corrected. The conclusion says:
> >>>
> >>>     memory barriers ensure proper ordering of volatile accesses
> >>>
> >>>     memory barriers don't ensure statements with no volatile accesses to 
> >>> be reordered across the barrier 
> >>>
> >>> while it should say:
> >>>
> >>>     memory barriers ensure proper ordering of global variables accesses
> >>>
> >>>     memory barriers don't ensure local variables accesses to be reordered 
> >>> across the barrier
> >>
> >> At least the "local" vs. "global" is not completely correct.  After
> >> all it's about memory accesses, and it doesn't matter if the memory
> >> is local (e.g. local static) or if you are dereferencing a pointer
> >> (which might point to a local auto or to an object on heap).
> > 
> > Ok, let's define it "global" vs "automatic". After all it is all
> > about the possibility that the memory can be shared. Global variables > in
> general can be shared, automatic variables cannot. But for sure
> > it's not the matter of volatile. A barrier that orders only volatile >
> accesses is a nonsense - this is already guaranteed by the volatile
> > itself.
> 
> Local variables that are only in registers, or are optimised away, are
> still "automatic" and are unaffected by memory barriers.  And it is not
> always easy to know whether a variable has gone in memory or not.  Even
> if you take the address of a local variable, it may never move from a
> register if the compiler can find a way to avoid it.
> 
> Memory barriers will affect all data that is in memory, and that can be
> legally accessed as memory from within an assembly statement.  So global
> (or file static) data is definitely ordered by a memory clobber,
> regardless of whether or not it is volatile.  Local variables whose
> /address/ has "escaped" (i.e., been assigned to global data, passed to
> external functions, etc.) are also ordered.  Local variables which
> remain local need not be ordered, I believe.
> 
> What the page here should really be saying here is that memory barriers
> do not order /operations/ or /calculations/, only memory accesses.
> 
> Does that help?
> 
> 
> 
> 

Yes, I find your description understandable, exhaustive and accurate. So the 
site should be corrected, preferably both here:
http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder
and here:
http://www.atmel.com/webdoc/AVRLibcReferenceManual/optimization_1optim_code_reorder.html
Anyone knows who maintains the sites?

Thanks and regards,
Marcin