Pointers Extend Unsigned Question

[Donn Terry]

Particularly to Jeff or either Richard, but if anyone else can 
contribute, please do.  (It's a simple yes/no question, once explained.)
This is "before I go on a wild goose chase".

Alpha 32 is (as far as I can find with a grep) the only architecture
where POINTERS_EXTEND_UNSIGNED is true.  (At least that anyone
will admit to.)  On Alpha32, POINTERS_EXTEND_UNSIGNED is
defined to be 0 (both for Windows and VMS variants, altho I
know very little about the latter.)

For most purposes Alpha32 works.  On NT, user space pointers
are (except in rare circumstances, which may never have been
hit) by definition in the low half of the address
space, so sign extension is in practice not an issue,
most of the time.  (No comment on VMS).

Anyway, I'm running into a problem reflected (but NOT exclusively)
in the following RTL, selected more or less at random from
a lot of samples.  This is something I haven't touched (yet).

    (insn 7 6 8 (set (reg:DI 70)
            (const_int -1 [0xffffffffffffffff])) -1 (nil)
        (nil))

    (insn 8 7 9 (set (reg/i:DI 0 $0)
            (and:DI (reg:DI 70)
                (const_int 4294967295 [0xffffffff]))) -1 (nil)
        (nil))

    (insn 9 8 10 (use (reg/i:DI 0 $0)) -1 (nil)
        (nil))

This is an extract of a trivial function returning a pointer,
where the value is (ptr) (HOST_WIDE_INT) -1.  (Don't say
"don't do that": it's from gcc/calls.c!)

Note that $0 (the return value) is masked (NOT extended) to
32 bits, so the sign information is lost.  This sort of thing
is not at all rare, by any means.  (I've been looking at
LOTS of RTL of late.)

I can interpret the semantics of POINTERS_EXTEND_UNSIGNED in
two ways: it's supposed to be occurring "under the covers"
and not reflected in the RTL, or that the RTL above is incorrect,
and insn 8 should be an extend (optimized to nothing, I'd hope).

Is the above RTL consistent with the intent of POINTERS_EXTEND_UNSIGNED
or not?  (Given an answer to that, I can plan my attack on the
problem.)

My best guess is that the RTL above is not what was intended, but
it would be wise to have confirmation before I go after the
problem. (A response confirming this, or not, would be most
appreciated.)

Donn
-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================