[bug #50270] Article "Problems with reordering code" misleading

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[bug #50270] Article "Problems with reordering code" misleading

Kevin Cuzner-2
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: [hidden email]
             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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|

[bug #50270] Article "Problems with reordering code" misleading

Kevin Cuzner-2
Follow-up Comment #1, bug #50270 (project avr-libc):

Your criticism seems to confuse volatile memory access with
volatile asm statements.  Given the matter is known to be
tricky, it would have been better to subscribe to the
avr-libc mailing list, and discuss the wording there with
the other developers (including the author of that snippet),
rather than immediately declaring it a "bug".

After all, that article has been written for a reason, after
certain observations have been analyzed and discussed prior
in Internet forums and mailing lists.

As it is now, even after re-reading it, the wording and
examples of the article still look much more reasonable to
me than your blunt statement "it cannot be what is not
supposed to be".

    _______________________________________________________

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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|

[bug #50270] Article "Problems with reordering code" misleading

Kevin Cuzner-2
Follow-up Comment #2, bug #50270 (project avr-libc):

1. I don't think I confuse volatile memory access with volatile asm
statements.What is your point here?

2. I've already discussed the problem in the list [hidden email] and
I got feedback to submit a bug report. Please search for a topic
Avr-libc-user-manual: "Problems with reordering code".

3. I don't say the article is written without a reason. But it simply seems to
give inaccurate conclusions.

4. I also don't understand your last point. What blunt statement did I give? I
simply explained why I think the conclusions in article are wrong. I
understand that something may "look much more reasonable" to you, but such
comments doesn't bring any value in the discussion. I hope to have a
content-related discussion.


    _______________________________________________________

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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|

[bug #50270] Article "Problems with reordering code" misleading

Kevin Cuzner-2
Follow-up Comment #3, bug #50270 (project avr-libc):

The bug report is fine for a clear bug.  However, for
something to be discussed first, it's a poor medium: if
the author of that text (who is on the developers
mailinglist) wants to reply something, he stands no chance
to add it to the bug report.  If we discuss it on the list,
you'll miss the replies.

If you've got a suggestion for a better explanation and/or
wording of the phenomenon shown there, please tell us so.
The entire purpose of the text is to make users aware that
there are potential pitfalls in optimization which at least
currently cannot be controlled by any compiler statement.

    _______________________________________________________

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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|

[bug #50270] Article "Problems with reordering code" misleading

Kevin Cuzner-2
Follow-up Comment #4, bug #50270 (project avr-libc):

I'm sorry if I have chosen the wrong medium. I tried to point out the problem
on a mailing list already, but hardly anyone was interested to discuss it. I
may have chosen the wrong mailing list, but this was the only one I found.

But I still don't get you. If the author or anybody else wants to discuss the
problems reported by me, they are free to do it here - in the discussion of a
bug report.

I have provided an explanation of the problem that was - I believe - wrongly
explained in the article. Surely my explanation is not perfectly worded.

And to be clear, my intention is to improve online documentation of avr-libc
to make it more useful for everybody. If you have any remarks regarding the
subject, please provide them. Discussing whether this should be a bug report
or a mail on this or that mailing list, without any points regarding the
subject of the report, is really not the right direction.


    _______________________________________________________

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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|

[bug #50270] Article "Problems with reordering code" misleading

Kevin Cuzner-2
Follow-up Comment #5, bug #50270 (project avr-libc):

As I can see, all the discussion is automatically sent to
[hidden email], so I guess the author of the text can see the
discussion and join it. Isn't this right?

    _______________________________________________________

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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|

[bug #50270] Article "Problems with reordering code" misleading

Kevin Cuzner-2
Follow-up Comment #6, bug #50270 (project avr-libc):

Yes, he can discuss it there, but he cannot append anything
to the bug report itself.

    _______________________________________________________

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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|

[bug #50270] Article "Problems with reordering code" misleading

Kevin Cuzner-2
Follow-up Comment #7, bug #50270 (project avr-libc):

Why this thread is dead? Is the auuthor of the article reachable so that he
can share his opinion?

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?50270>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/


Reply | Threaded
Open this post in threaded view
|

[bug #50270] Article "Problems with reordering code" misleading

Kevin Cuzner-2
Follow-up Comment #8, bug #50270 (project avr-libc):

I've been involved in a couple of discussions about this page in the manual.
I must admit that it annoys me a little that nothing has been done to update
the page.  It means people have been getting the same limited and slightly
inaccurate information for years, when there are a number of solutions to the
problem discussed.

Here are a few threads I could dig up:

https://lists.nongnu.org/archive/html/avr-libc-dev/2015-06/msg00006.html

https://lists.nongnu.org/archive/html/avr-gcc-list/2016-12/msg00002.html

https://lists.nongnu.org/archive/html/avr-gcc-list/2016-12/msg00005.html

The avr gcc and libc experts might not agree entirely with my comments in
these threads - that's fine, of course.  But surely someone who has write
access to the user manual page can improve it?  This it a page of a user
manual, not a personal publicised article that can't be changed without the
author's permission!


    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?50270>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/


Reply | Threaded
Open this post in threaded view
|

[bug #50270] Article "Problems with reordering code" misleading

Kevin Cuzner-2
Follow-up Comment #9, bug #50270 (project avr-libc):

Just propose (best on the list where it can be discussed better) a new wording
of that entry.

If a new formulation is agreed on, it is then quite simple to update the
article. So far, I see a discussion, but barely already a complete agreement,
let alone a new wording for the article.

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?50270>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/


Reply | Threaded
Open this post in threaded view
|

[bug #50270] Article "Problems with reordering code" misleading

Kevin Cuzner-2
Follow-up Comment #10, bug #50270 (project avr-libc):

Well, as already proposed 3 years ago, the below sentences:

memory barriers ensure proper ordering of volatile accesses
memory barriers don't ensure statements with no volatile accesses to be
reordered across the barrier

may be replaced with:

memory barriers ensure proper ordering of global variables accesses
memory barriers don't ensure local variables accesses to be reordered across
the barrier

or if the word "global" and "local" are not accurate, maybe this way:

memory barriers ensure proper ordering of global variables accesses
(as every global variable is possibly a subject of sharing across different
execution contexts)
memory barriers don't ensure automatic variables accesses to be reordered
across the barrier
(as by definition, automatic variables cannot be shared across different
execution contexts)

I would also propose to add a note, that applying a memory barrier is a way of
ordering memory accesses and not a way of ordering general code execution.

Please treat this as a starting point of the discussion. Hopefully we can
achieve an agreement on new wording. The article conclusion is at least
strongly misleading and really requires an update.

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?50270>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/