From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26675 invoked by alias); 4 Mar 2005 19:38:29 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 26575 invoked by uid 48); 4 Mar 2005 19:38:25 -0000 Date: Fri, 04 Mar 2005 19:38:00 -0000 Message-ID: <20050304193825.26574.qmail@sourceware.org> From: "bjoern dot m dot haase at web dot de" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050302181643.20288.bob.paddock@gmail.com> References: <20050302181643.20288.bob.paddock@gmail.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code X-Bugzilla-Reason: CC X-SW-Source: 2005-03/txt/msg00571.txt.bz2 List-Id: ------- 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