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

2017-02-09 Thread Marcin Godlewski
Dear All, The site http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder/optimization_1optim_code_reorder.html still contains buggy description of memory barriers in avr-gcc. As this site is popular among avr users I think it's really worth fixing. What is more the sa

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

2017-02-09 Thread David Brown
You could file this as a bug on the website: As far as I understand it, the documentation (both on the website and the Atmel documentation) is generated directly from the library code and comments - so this would be a change to the library source.

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

2017-02-09 Thread Bob Paddock
Are the functions like macros in atomic.h correct? They attempt to deal properly with critical sections/code motion etc, in what this thread is discussing. http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html On Thu, Feb 9, 2017 at 9:14 AM, David Brown wrote: > You could file th

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

2017-02-09 Thread David Brown
The functions in atomic.h are correct, but their description is not quite accurate. The description says that inside an atomic block, the code cannot be interrupted. But as we have seen, /code/ can be moved inside and outside of an atomic block just as it can be moved around the "cli()" instr

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

2017-02-09 Thread Bob Paddock
On Thu, Feb 9, 2017 at 1:13 PM, David Brown wrote: > Note also that it is only control > of the memory access that is needed for code correctness - moving > instruction execution affects timing, but not the results. As I'm sure you are aware even if the code if mathematically correct, giving the

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

2017-02-09 Thread David Brown
On 09/02/17 19:49, Bob Paddock wrote: On Thu, Feb 9, 2017 at 1:13 PM, David Brown wrote: Note also that it is only control of the memory access that is needed for code correctness - moving instruction execution affects timing, but not the results. As I'm sure you are aware even if the code

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

2017-02-09 Thread Marcin Godlewski
David, Thanks for pointing out the right place to submit the bug report. I have submitted one here: https://savannah.nongnu.org/bugs/index.php?50270 Best regards, Marcin Godlewski W dniu 2017-02-09 15:14:11 użytkownik David Brown napisał: > You could file this as a bug on the website: >

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

2017-02-09 Thread Stu Bell
I hate to stick my nose in this after years away from the list, but... David is right about the problems with atomic functions in C. The good news is that there /is/ another solution: Use assembly language. That does not solve the problem within the domain of C, but it /does/ solve the problem

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

2017-02-09 Thread David Brown
Hi Stu, Feel free to stick your nose in here - there is always room for experienced opinions. Yes, exactly the same thing applies to Arm as to the AVR. And exactly the same macros with empty inline assembly will solve the problem. In particular, you do not need to write any actual assembly