[avr-libc-dev] [bug #50270] Article "Problems with reordering code" misleading

[anonymous]

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: address@hidden
             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/