public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: matz@suse.de (Michael Matz)
Cc: avr@gjlay.de (Georg-Johann Lay), gcc@gcc.gnu.org
Subject: Re: [named address] ice-on-valid: in postreload.c:reload_cse_simplify_operands
Date: Fri, 05 Aug 2011 14:29:00 -0000	[thread overview]
Message-ID: <201108051429.p75ETZvf008273@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1108051601140.6789@wotan.suse.de> from "Michael Matz" at Aug 05, 2011 04:09:25 PM

Michael Matz wrote:
> On Fri, 5 Aug 2011, Ulrich Weigand wrote:
> > Instead, if you just have a address and you don't know ahead of time
> > whether it refers to Flash or RAM space, you ought to hold that number
> > in an "int" (or "short" or whatever integer type is most appropriate),
> > and then convert from that integer type to either a "char *" or a
> > "char __pgm *".
> 
> That would leave standard C.  You aren't allowed to construct pointers out 
> of random integers.

C leaves integer-to-pointer conversion *implementation-defined*,
not undefined, and GCC has always chosen to implement this by
(usually) keeping the value unchanged:
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Arrays-and-pointers-implementation.html
This works both for default and non-default address spaces.

Of course, my suggested implementation would therefore rely on
implementation-defined behaviour (but by simply using the __pgm
address space, it does so anyway).

> That would point to a third address space, call it "undef" :)  It would be 
> superset of default and pgm, conversions between undef to {default,pgm} 
> are allowed freely (and value preserving, i.e. trivial).

That would probably violate the named AS specification, since two different
entities in the undef space would share the same pointer value ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

  reply	other threads:[~2011-08-05 14:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-04 13:43 Georg-Johann Lay
2011-08-04 16:20 ` Ulrich Weigand
2011-08-04 16:26   ` DJ Delorie
2011-08-04 16:33     ` Ulrich Weigand
2011-08-04 17:28   ` Georg-Johann Lay
2011-08-05 10:19     ` Ulrich Weigand
2011-08-05 12:47       ` Georg-Johann Lay
2011-08-05 13:24         ` Ulrich Weigand
2011-08-05 14:09           ` Michael Matz
2011-08-05 14:29             ` Ulrich Weigand [this message]
2011-08-05 20:43     ` Ulrich Weigand
2011-08-05 20:47       ` DJ Delorie
2011-08-05 21:01         ` Ulrich Weigand
2011-08-05 21:08           ` DJ Delorie
2011-08-08 11:38       ` Georg-Johann Lay
2011-08-09 17:16         ` Ulrich Weigand
2011-08-10 14:04           ` Georg-Johann Lay
2011-08-17 17:44             ` Georg-Johann Lay
2011-08-18 14:38               ` Ulrich Weigand
2011-08-21 16:43                 ` Georg-Johann Lay
2011-08-22 12:39                   ` Ulrich Weigand

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=201108051429.p75ETZvf008273@d06av02.portsmouth.uk.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=avr@gjlay.de \
    --cc=gcc@gcc.gnu.org \
    --cc=matz@suse.de \
    /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).