public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "bjoern dot m dot haase at web dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
Date: Fri, 04 Mar 2005 19:38:00 -0000	[thread overview]
Message-ID: <20050304193825.26574.qmail@sourceware.org> (raw)
In-Reply-To: <20050302181643.20288.bob.paddock@gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]


------- Additional Comments From bjoern dot m dot haase at web dot de  2005-03-04 19:38 -------
In reply to comment #10. 
 
I agree with you Jörg, it is not a dramatic loss if you have a bit less 
efficient use of volatile pointers :-) and IMHO anybody in the avr community 
could live with it. I think it's possibly rather a question of style. 
 
I'd like to suggest that the explicit use of a macro while sticking to the 
standard convention for use of the volatile keyword might make it more 
transparent *why* and *that* an explicit treatment is required for 16 bit 
registers. Imagine the case of a person who is reading code written by someone 
else. Just seeing the "volatile" keyword would not make the possible danger 
clear. 
 
Maybe the "volatile" solution makes it easier for some programers and I agree 
with anybody that using macros tends to turn the code uglier. Possibly, 
however, there is the danger that one makes "things easier than they are in 
fact": 
 
With either approach, the user will be required to be avare of the possible 
problem and would have to handle the code accordingly. My personal opinion is: 
If there is a pitfall with 16 bit registers, write code that names it by it's 
real name. 
 
Anyway I could also live with a solution that patches the compiler. 
 
Yours, 
 
Björn 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288


  parent reply	other threads:[~2005-03-04 19:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-02 18:17 [Bug c/20288] New: " bob dot paddock at gmail dot com
2005-03-02 18:19 ` [Bug c/20288] " ericw at evcohs dot com
2005-03-02 18:20 ` ericw at evcohs dot com
2005-03-02 18:21 ` [Bug target/20288] " pinskia at gcc dot gnu dot org
2005-03-02 21:24 ` giovannibajo at libero dot it
2005-03-02 22:01 ` ericw at evcohs dot com
2005-03-02 23:07 ` schlie at comcast dot net
2005-03-03 13:13 ` bob dot paddock at gmail dot com
2005-03-03 19:47 ` schlie at comcast dot net
2005-03-03 19:50 ` ericw at evcohs dot com
2005-03-03 22:21 ` bjoern dot m dot haase at web dot de
2005-03-03 22:49 ` j dot gnu at uriah dot heep dot sax dot de
2005-03-03 23:02 ` giovannibajo at libero dot it
2005-03-04 14:14 ` schlie at comcast dot net
2005-03-04 14:19 ` ericw at evcohs dot com
2005-03-04 15:26 ` schlie at comcast dot net
2005-03-04 19:38 ` bjoern dot m dot haase at web dot de [this message]
2005-03-04 19:42 ` bjoern dot m dot haase at web dot de
2005-03-06 21:50 ` cvs-commit at gcc dot gnu dot org
2005-03-06 23:56 ` pinskia at gcc dot gnu dot org
2005-03-13 21:47 ` cvs-commit at gcc dot gnu dot org
2005-03-13 21:49 ` cvs-commit at gcc dot gnu dot org
2005-03-13 22:03 ` pinskia at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050304193825.26574.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).