bugAVR C Runtime Library - Bugs: bug #50270, Article "Problems with...


bug #50270: Article "Problems with reordering code" misleading

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:  -email is unavailable-
Open/Closed:  Open Release:  2.0.0
Fixed Release:  None

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Fri 10 Feb 2017 02:46:46 PM UTC, comment #6: 

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

Joerg Wunsch <joerg_wunsch>
Project Administrator
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
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.

Joerg Wunsch <joerg_wunsch>
Project Administrator
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
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".

Joerg Wunsch <joerg_wunsch>
Project Administrator
Thu 09 Feb 2017 10:07:34 PM UTC, original submission:  

The article available here:
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.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mrn_ (Posted a comment)
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)



    No changes have been made to this item

    Back to the top

    Powered by Savane 3.5