AVR C Runtime Library - Bugs: bug #50270, Article "Problems with...
You are not allowed to post comments on this tracker with your current authentication level.
bug #50270: Article "Problems with reordering code" misleading
Submitter: | None | ||
Submitted: | 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: | -email is unavailable- |
Open/Closed: | Open | Release: | 2.0.0 |
Fixed Release: | None |
( Jump to the original submission )
Sat 05 Sep 2020 01:26:03 PM UTC, comment #11: |
Marcin Godlewski <mrn_> |
Mon 16 Dec 2019 08:18:02 PM UTC, comment #10: Well, as already proposed 3 years ago, the below sentences:
memory barriers ensure proper ordering of volatile accesses
may be replaced with:
memory barriers ensure proper ordering of global variables accesses
or if the word "global" and "local" are not accurate, maybe this way:
memory barriers ensure proper ordering of global variables accesses
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. |
Marcin Godlewski <mrn_> |
Sun 15 Dec 2019 01:59:06 PM UTC, comment #9: 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. |
Joerg Wunsch <joerg_wunsch>![]() |
Sun 15 Dec 2019 11:46:05 AM UTC, comment #8: 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!
|
David Brown <davidmbrown> |
Sun 15 Dec 2019 09:39:22 AM UTC, comment #7: Why this thread is dead? Is the auuthor of the article reachable so that he can share his opinion? |
Anonymous |
Fri 10 Feb 2017 02:46:46 PM UTC, comment #6: Yes, he can discuss it there, but he cannot append anything
|
Joerg Wunsch <joerg_wunsch>![]() |
Fri 10 Feb 2017 02:36:56 PM UTC, comment #5: As I can see, all the discussion is automatically sent to avr-libc-dev@nongnu.org, so I guess the author of the text can see the discussion and join it. Isn't this right? |
Marcin Godlewski <mrn_> |
Fri 10 Feb 2017 02:32:18 PM UTC, comment #4: 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.
|
Marcin Godlewski <mrn_> |
Fri 10 Feb 2017 02:06:14 PM UTC, comment #3: The bug report is fine for a clear bug. However, for
If you've got a suggestion for a better explanation and/or
|
Joerg Wunsch <joerg_wunsch>![]() |
Fri 10 Feb 2017 11:06:23 AM UTC, comment #2: 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 -email is unavailable- 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.
|
Marcin Godlewski <mrn_> |
Fri 10 Feb 2017 09:03:53 AM UTC, comment #1: Your criticism seems to confuse volatile memory access with
After all, that article has been written for a reason, after
As it is now, even after re-reading it, the wording and
|
Joerg Wunsch <joerg_wunsch>![]() |
Thu 09 Feb 2017 10:07:34 PM UTC, original submission:
The article available here:
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. |
Anonymous |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
So there is a new wording proposal for 9 months now and not a single response. Looks like nobody is interested in updating the manual and fixing the issues.