URL:
<http://savannah.nongnu.org/bugs/?50270>
Summary: Article "Problems with reordering code" misleading
Project: AVR C Runtime Library
Submitted by: None
Submitted on: Thu 09 Feb 2017 10:07:34 PM UTC
Category: Documentation
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Documentation
Status: None
Percent Complete: 0%
Assigned to: None
Originator Email: marcin.godlew...@onet.pl
Open/Closed: Open
Discussion Lock: Any
Release: 2.0.0
Fixed Release: None
_______________________________________________________
Details:
The article available here:
http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder/optimization_1optim_code_reorder.html
contains an essential mistake and is misleading for avr-gcc users.
In short: the author of the article in online documentation makes some
analysis of a tricky case of using memory barrier in gcc and makes false
conclusions. Quote:
"To sum it up:
memory barriers ensure proper ordering of volatile accesses
memory barriers don't ensure statements with no volatile accesses to be
reordered across the barrier"
Point 1 makes no sense - volatile accesses are ensured to be properly ordered
without any barriers - this is guaranteed by C standard.
Point 2 is false - a memory barrier ensures proper ordering of all, including
non-volatile, memory accesses. This covers all global data, but not
necesserily local data which can be placed in registers. In the analyzed case,
variable val is a local variable. This is the real reason why memory barrier
does not ensure strict ordering of operations on val. Memory barriers won't
influence management of local variables stored in registers And this is
perfectly fine, as only variables stored in memory can be accessed from
various CPU contexts.
So the sentence "Unfortunately, at the moment, in avr-gcc (nor in the C
standard), there is no mechanism to enforce complete match of written and
executed code ordering" is correct. But the further conclusions (the two
points quoted earlier) are incorrect and strongly misleading.
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?50270>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
