AVR C Runtime Library - Bugs: bug #38021, pgm_read macros don't model the...
You are not allowed to post comments on this tracker with your current authentication level.
bug #38021: pgm_read macros don't model the memory accesses
Submitter: | Georg-Johann Lay <gjlayde> | ||
Submitted: | Fri 04 Jan 2013 01:05:37 PM UTC | ||
Category: | Header | Severity: | 3 - Normal |
Priority: | 5 - Normal | Item Group: | Header files |
Status: | None | Assigned to: | None |
Percent Complete: | 0% | Open/Closed: | Open |
Release: | 1.8.0 | Fixed Release: | None |
Sat 05 Jan 2013 08:56:58 AM UTC, comment #2: |
Georg-Johann Lay <gjlayde> |
Fri 04 Jan 2013 10:23:48 PM UTC, comment #1: It is a very bad idea overall. It would increase code size of existing programs, with little to no benefit except of a negligibly small group of applications.
|
Jan Waclawek <wek> |
Fri 04 Jan 2013 01:05:37 PM UTC, original submission:
The current (1.8.0) implementation of the pgm_read inline assembler does not model the memory accesses it performs. This can lead to problems in the following situations:
|
Georg-Johann Lay <gjlayde> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Powered by Savane 3.13-f8d8.
Corresponding source code
Jan Waclawek wrote in comment #1:
Would you give a test case from the real world?
I don't see how this would increase the code size in ordinary programs -- except in the case where a clear if RAMPZ is missing and must be added to comply with avr-gcc. But in that case, the code size increase is inevitable.
No, that is not true. The pgm-macros don't model a memory access at all. Notice that the memory access can be modeled and there is no need for a volatile. Please read my example code again and try to understand it.
The problem is that it is very hard for the user to cover the remaining, uncommon cases, whereas providing proper macros does not do harm. Not even a memory barrier will help to fix the uncommon cases because there is no memory access in the asm.
It's not a pessimization, it's inevitable so that your code will still work with GCC 4.7. I don't see a point in code that is efficient but incorrect.