public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "schlie at comcast dot net" <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 14:14:00 -0000	[thread overview]
Message-ID: <20050304141354.2910.qmail@sourceware.org> (raw)
In-Reply-To: <20050302181643.20288.bob.paddock@gmail.com>


------- Additional Comments From schlie at comcast dot net  2005-03-04 14:13 -------
(In reply to comment #10)
Upon further thought, and agreeing that the explicit use of an asm macro is likely
the most appropriate near term solution; it would appear the most ideal longer
term solution would be to figure out how to comprehensively enable both explictly
and implicitly declared objects optionally tagged with target specific attributes to
influence the selection of the access method (generated code) used to access them.

Thereby allocated objects may be identified as potentially being allocated to either
ROM(progmem), EEPROM, RAM(by defalut), or even requiring a particular access
sequence (which in theory may even include the automatic wraping of interrupt
disable/enable around the access automatically).

(but it appears that a few things wihtin GCC may need to be refined to broadly
 enable the use of attributes to accomplish this, which I'm attempting to document).


-- 


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


  parent reply	other threads:[~2005-03-04 14:14 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 [this message]
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
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=20050304141354.2910.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).