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

[Marcin Godlewski]

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.

> 
> The code example you quoted above is actually due to a subtle
> implementation detail of division, modulo and some other arithmetic
> of GCC's avr backend (the division is _not_ a call actually).
> 
> IIRC the solution for me back then was -fno-tree-ter as any messing
> with inline asm doesn't hit the point.
> 
> Johann
> 
> > I don't know whether this group is the right place to post it however I do 
> > not know any better place. Hope someone here can trigger the change of the 
> > documentation and I also hope to be corrected if I am wrong.
> > 
> > Thanks and regards,
> > Marcin
>