Patchwork constant that doesn't fit in 32bits in alpha.c

login
register
mail settings
Submitter Richard Henderson
Date June 12, 2012, 1:03 a.m.
Message ID <4FD6955C.4090904@redhat.com>
Download mbox | patch
Permalink /patch/164292/
State New
Headers show

Comments

Richard Henderson - June 12, 2012, 1:03 a.m.
On 2012-06-11 16:23, Mike Stump wrote:
> On Jun 11, 2012, at 4:06 PM, Richard Henderson wrote:
>> Bah.  Wrong patch.
>>
>>
>> r~
>> <z.txt>
> 
> 
> Hum, I'm trying to see how this patch works... I feel like there is
> something I'm missing, like a shift?

Double-bah.  That's what I get for changing the patch at the last minute.


r~
* config/alpha/alpha.c (HWI_HEX2): Add missing shift.
Joseph S. Myers - June 12, 2012, 7:44 p.m.
I'd rather have a macro HOST_WIDE_INT_C in hwint.h (like INTMAX_C etc. in 
stdint.h).  HOST_WIDE_INT_1 is already defined in hwint.h to either 1L or 
1LL; I'd suggest defining HOST_WIDE_INT_C to concatenate with either L or 
LL (and then HOST_WIDE_INT_1 can be HOST_WIDE_INT_C (1), unconditionally).
Pedro Alves - June 13, 2012, 9:13 a.m.
On 06/12/2012 08:44 PM, Joseph S. Myers wrote:

> I'd rather have a macro HOST_WIDE_INT_C in hwint.h (like INTMAX_C etc. in 
> stdint.h).  HOST_WIDE_INT_1 is already defined in hwint.h to either 1L or 
> 1LL; I'd suggest defining HOST_WIDE_INT_C to concatenate with either L or 
> LL (and then HOST_WIDE_INT_1 can be HOST_WIDE_INT_C (1), unconditionally).


Related, does gcc forbid "long long" / ULL ?  In a recent similar GDB discussion,
I noticed that libdecnumber seems to uses both unconditionally (for UINT64, and
e.g., the initialization of reciprocals10_128).  So if libdecnumber
is always built with gcc, gcc is also already depending on "long long" / ULL being
available too.
Richard Henderson - June 13, 2012, 9:35 p.m.
On 2012-06-13 02:13, Pedro Alves wrote:
> Related, does gcc forbid "long long" / ULL ?


Normally, yes.  The vmsdbgout.c file seems to use it all over though.
Cleaning that up is independent of this thread though.



r~
Pedro Alves - June 14, 2012, 9:12 a.m.
On 06/13/2012 10:35 PM, Richard Henderson wrote:

> On 2012-06-13 02:13, Pedro Alves wrote:
>> Related, does gcc forbid "long long" / ULL ?
> 
> 
> Normally, yes.  The vmsdbgout.c file seems to use it all over though.


And git blame shows:

8d60d2bc (kenner   2001-12-02 14:38:07 +0000   41) /* Difference in seconds between the VMS Epoch and the Unix Epoch */
8d60d2bc (kenner   2001-12-02 14:38:07 +0000   42) static const long long vms_epoch_offset = 3506716800ll;
                   ^^^^^^^^^^

That's my point.  We've been using long long / ll for a while now without
noticing (I least I hadn't noticed the libdecnumber uses before), and nobody
seems to have tripped on any host compiler that doesn't support it.  Is it
justifiable nowadays to not assume it's available?

> Cleaning that up is independent of this thread though.


Of course.
Tristan Gingold - June 14, 2012, 9:20 a.m.
On Jun 14, 2012, at 11:12 AM, Pedro Alves wrote:

> On 06/13/2012 10:35 PM, Richard Henderson wrote:
> 
>> On 2012-06-13 02:13, Pedro Alves wrote:
>>> Related, does gcc forbid "long long" / ULL ?
>> 
>> 
>> Normally, yes.  The vmsdbgout.c file seems to use it all over though.
> 
> 
> And git blame shows:
> 
> 8d60d2bc (kenner   2001-12-02 14:38:07 +0000   41) /* Difference in seconds between the VMS Epoch and the Unix Epoch */
> 8d60d2bc (kenner   2001-12-02 14:38:07 +0000   42) static const long long vms_epoch_offset = 3506716800ll;
>                   ^^^^^^^^^^
> 
> That's my point.  We've been using long long / ll for a while now without
> noticing (I least I hadn't noticed the libdecnumber uses before), and nobody
> seems to have tripped on any host compiler that doesn't support it.  Is it
> justifiable nowadays to not assume it's available?

OTOH, this file is compiled only for alpha-vms target, so I doubt it is commonly compiled.

Tristan.
Pedro Alves - June 14, 2012, 9:39 a.m.
On 06/14/2012 10:20 AM, Tristan Gingold wrote:

> 
> On Jun 14, 2012, at 11:12 AM, Pedro Alves wrote:


>> And git blame shows:
>>
>> 8d60d2bc (kenner   2001-12-02 14:38:07 +0000   41) /* Difference in seconds between the VMS Epoch and the Unix Epoch */
>> 8d60d2bc (kenner   2001-12-02 14:38:07 +0000   42) static const long long vms_epoch_offset = 3506716800ll;
>>                   ^^^^^^^^^^
>>
>> That's my point.  We've been using long long / ll for a while now without
>> noticing (I least I hadn't noticed the libdecnumber uses before), and nobody
>> seems to have tripped on any host compiler that doesn't support it.  Is it
>> justifiable nowadays to not assume it's available?
> 
> OTOH, this file is compiled only for alpha-vms target, so I doubt it is commonly compiled.


Ah, the presence of gcc/vmsdbgout.o on my AMD64 GNU/Linux native build make me
believe otherwise.  It's guarded by VMS_DEBUGGING_INFO.

But note that in libdecnumber we have:

10de71e1 (meissner 2007-03-24 17:04:47 +0000 25) typedef unsigned int UINT32;
10de71e1 (meissner 2007-03-24 17:04:47 +0000 26) typedef unsigned long long UINT64;
10de71e1 (meissner 2007-03-24 17:04:47 +0000 27) typedef struct { UINT64 w[2]; } UINT128;
...
10de71e1 (meissner 2007-03-24 17:04:47 +0000    28)   { { 0x3b645a1cac083127ull, 0x0083126e978d4fdfull } }, /* 3 extra digits */
10de71e1 (meissner 2007-03-24 17:04:47 +0000    29)   { { 0x4af4f0d844d013aaULL, 0x00346dc5d6388659ULL } }, /*  10^(-4) * 2^131 */
                   ^^^^^^^^^^
Eric Botcazou - June 15, 2012, 8:12 a.m.
> But note that in libdecnumber we have:
>
> 10de71e1 (meissner 2007-03-24 17:04:47 +0000 25) typedef unsigned int
> UINT32; 10de71e1 (meissner 2007-03-24 17:04:47 +0000 26) typedef unsigned
> long long UINT64; 10de71e1 (meissner 2007-03-24 17:04:47 +0000 27) typedef
> struct { UINT64 w[2]; } UINT128; ...
> 10de71e1 (meissner 2007-03-24 17:04:47 +0000    28)   { {
> 0x3b645a1cac083127ull, 0x0083126e978d4fdfull } }, /* 3 extra digits */
> 10de71e1 (meissner 2007-03-24 17:04:47 +0000    29)   { {
> 0x4af4f0d844d013aaULL, 0x00346dc5d6388659ULL } }, /*  10^(-4) * 2^131 */
> ^^^^^^^^^^

Generally speaking, I'd avoid taking anything in libdecnumber as an example.
Pedro Alves - June 15, 2012, 9:22 a.m.
On 06/15/2012 09:12 AM, Eric Botcazou wrote:

> Generally speaking, I'd avoid taking anything in libdecnumber as an example.


It's not about example, but the fact that host compilers have been
compiling that code as part of building gcc for years, without anyone
complaining, afaik.  It doesn't matter whether the code pointed at
is the ugliest or most beautiful code on earth.  What matters is whether
it uses long long unconditionally on all hosts or not.
IOW, what are the still supported hosts/compilers that don't
support "long long"?  If there are any, it appears none has been used
in at least the past 5 years, IIU the code correctly.


(This is not just an unfounded, OOC, question.  We just recently
went through the exercise of coming up with an interface for an include/
header,

 http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01424.html
 http://sourceware.org/ml/binutils/2012-05/msg00344.html

where we had some back and forth on the use of long long.  After all that,
we ended up finding that libdecnumber uses long long unconditionally,
<http://sourceware.org/ml/gdb-patches/2012-05/msg01078.html>
so in practice, GDB has been relying on "long long" existing for as long as
libdecnumber has been used in GDB.  The same should hold true for gcc.)
Eric Botcazou - June 15, 2012, 9:48 a.m.
> It's not about example, but the fact that host compilers have been
> compiling that code as part of building gcc for years, without anyone
> complaining, afaik.  It doesn't matter whether the code pointed at
> is the ugliest or most beautiful code on earth.  What matters is whether
> it uses long long unconditionally on all hosts or not.
> IOW, what are the still supported hosts/compilers that don't
> support "long long"?  If there are any, it appears none has been used
> in at least the past 5 years, IIU the code correctly.

OK, but GCC still officially requires only an ISO C90 compiler 
  http://gcc.gnu.org/install/prerequisites.html
so the usage of 'long long' in libdecnumber is a bug that could be fixed at 
some point.  That's why using it as a precedent isn't the best thing to do.
Richard Earnshaw - June 15, 2012, 10:29 a.m.
On 15/06/12 10:48, Eric Botcazou wrote:
>> It's not about example, but the fact that host compilers have been
>> compiling that code as part of building gcc for years, without anyone
>> complaining, afaik.  It doesn't matter whether the code pointed at
>> is the ugliest or most beautiful code on earth.  What matters is whether
>> it uses long long unconditionally on all hosts or not.
>> IOW, what are the still supported hosts/compilers that don't
>> support "long long"?  If there are any, it appears none has been used
>> in at least the past 5 years, IIU the code correctly.
> 
> OK, but GCC still officially requires only an ISO C90 compiler 
>   http://gcc.gnu.org/install/prerequisites.html
> so the usage of 'long long' in libdecnumber is a bug that could be fixed at 
> some point.  That's why using it as a precedent isn't the best thing to do.
> 

There are several ports that currently require long long support in the
back-end -- see need_64bit_hwint in config.gcc.

R.
Eric Botcazou - June 15, 2012, 10:55 a.m.
> There are several ports that currently require long long support in the
> back-end -- see need_64bit_hwint in config.gcc.

Yes, all the 64-bit ports at least, but you shouldn't need 'long long' to build 
the compiler e.g. for the AVR.
Mike Stump - June 15, 2012, 5:09 p.m.
On Jun 15, 2012, at 2:22 AM, Pedro Alves <palves@redhat.com> wrote:
> It's not about example, but the fact that host compilers have been
> compiling that code as part of building gcc for years, without anyone
> complaining

Yeah, I think we should just jump to c++ 11 and not look back...  Fighting against using a 10 year old language standard I think is silly; and I like have the old obsolete ports in gcc.
Jay K - June 15, 2012, 6:02 p.m.
----------------------------------------
> CC: ebotcazou gcc-patches gingold rth joseph jay.krell
> From: mikestump
> To: palves
>
> On Jun 15, 2012, at 2:22 AM, Pedro Alves <palves@redhat.com> wrote:
> > It's not about example, but the fact that host compilers have been
> > compiling that code as part of building gcc for years, without anyone
> > complaining
>
> Yeah, I think we should just jump to c++ 11 and not look back... Fighting against using a 10 year old language standard I think is silly; and I like have the old obsolete ports in gcc.


64bit integer might not be called "long long", it could be "long" or "__int64", size_t/ptrdiff_t, etc..





I do find gcc's portability impressive, and one might suggest multiple precision arithmetic,

a pair of longs, but indeed compilers lacking some 64bit integer by some name are rare, and one could always

bootstrap via older gcc or take advantage of "biarch/multiarch" and first build "native 32bit"

and then "native 64bit" with the native 32bit gcc as the bootstrap compiler.



(I relatively recently bootstrapped hppa-hpux-gcc-4.x via K&R cc via gcc 3.x (3.3?). Obviously it is more time and work,
but it does work, and frees mainline gcc from caring.)


Heck, one could even automate this like how there is a multi-pass bootstrap, adding earlier stages
that go via e.g. gcc 3.3. The earlier compiler stages could be stripped down, e.g. no optimizer, no debug info output, no LTO.


 - Jay
Tom Tromey - June 15, 2012, 6:06 p.m.
>>>>> "Eric" == Eric Botcazou <ebotcazou@adacore.com> writes:

Pedro> It's not about example, but the fact that host compilers have been
Pedro> compiling that code as part of building gcc for years, without anyone
Pedro> complaining, afaik.  It doesn't matter whether the code pointed at
Pedro> is the ugliest or most beautiful code on earth.  What matters is whether
Pedro> it uses long long unconditionally on all hosts or not.
Pedro> IOW, what are the still supported hosts/compilers that don't
Pedro> support "long long"?  If there are any, it appears none has been used
Pedro> in at least the past 5 years, IIU the code correctly.

Eric> OK, but GCC still officially requires only an ISO C90 compiler 
Eric>   http://gcc.gnu.org/install/prerequisites.html
Eric> so the usage of 'long long' in libdecnumber is a bug that could be
Eric> fixed at some point.  That's why using it as a precedent isn't the
Eric> best thing to do.

It's true that this is a pedantic violation; but the point here is that
there is no practical barrier to using 'long long'.  This code has been
in the tree since 2007; so if there is some issue with it, it ought to
have surfaced by now.

Tom
Eric Botcazou - June 15, 2012, 6:53 p.m.
> It's true that this is a pedantic violation; but the point here is that
> there is no practical barrier to using 'long long'.  This code has been
> in the tree since 2007; so if there is some issue with it, it ought to
> have surfaced by now.

The whole compiler is written using HOST_WIDE_INT and the like, so using some 
external code that managed to escape a proper review before being merged in 
order to justify an incorrect usage is IMO short-sighted, to say the least.
Tom Tromey - June 15, 2012, 7:13 p.m.
>>>>> "Eric" == Eric Botcazou <ebotcazou@adacore.com> writes:

>> It's true that this is a pedantic violation; but the point here is that
>> there is no practical barrier to using 'long long'.  This code has been
>> in the tree since 2007; so if there is some issue with it, it ought to
>> have surfaced by now.

Eric> The whole compiler is written using HOST_WIDE_INT and the like, so
Eric> using some external code that managed to escape a proper review
Eric> before being merged in order to justify an incorrect usage is IMO
Eric> short-sighted, to say the least.

Not interested in trading barbs about it.  Still, I'll find it in me to
be partly tongue in cheek.

I don't understand what the code being external, or the review, has to
do with anything.  This code is compiled with the same host compiler as
everything else.

HOST_WIDE_INT is also not very persuasive to me.  We did many things in
the past that became obsolete as compilers matured.  You can still
occasionally find workarounds for old compiler bugs in GNU source; but
that doesn't make them relevant.

Maybe strict adherence to C90 gives some benefit, but I don't really
know what that would be.  Of course, I'd rather we -- not GCC obviously,
it is going another route, but the rest of the toolchain -- burn some
bridges and move to C99.  I think we deserve a 13 year old standard.

Tom
Joseph S. Myers - June 15, 2012, 7:58 p.m.
On Fri, 15 Jun 2012, Tom Tromey wrote:

> HOST_WIDE_INT is also not very persuasive to me.  We did many things in

Although HOST_WIDE_INT is used for too many different things (see Diego's 
and my architectural goals documents for more discussion, specifically 
"HOST_WIDE_INT, HOST_WIDEST_INT and associated concepts" at the bottom of 
the conventions document), I don't think we should use "long long" 
directly in the compiler (except in limited places such as hwint.h 
selecting a type to use for some abstraction) simply because it's not the 
right abstraction for saying what the requirements are on the type being 
used.  If the requirement is "at least 64 bits", int_fast64_t would be 
better, for example (gnulib can generate a stdint.h where the host doesn't 
have it).  If it's "big enough for the target address space" then 
HOST_WIDE_INT is what we have at present.  If it's "fast on the host, but 
size doesn't matter", then HOST_WIDEST_FAST_INT.
Eric Botcazou - June 15, 2012, 8:11 p.m.
> I don't understand what the code being external, or the review, has to
> do with anything.  This code is compiled with the same host compiler as
> everything else.

But, precisely, this line of reasoning is barely defensible in my opinion.  If 
you really want to go that route, then let's stop doing comprehensive reviews 
and stop requesting changes to submitted patches in order to make them comply 
with the agreed-upon practices, that would save time for everyone.

> HOST_WIDE_INT is also not very persuasive to me.  We did many things in
> the past that became obsolete as compilers matured.

Why would HOST_WIDE_INT be obsolete?  That's a nice way to abstract the host
and reverting to hardcoded types like 'long long' doesn't seem a progress to 
me.
Tom Tromey - June 15, 2012, 9:01 p.m.
>>>>> "Eric" == Eric Botcazou <ebotcazou@adacore.com> writes:

Tom> I don't understand what the code being external, or the review, has to
Tom> do with anything.  This code is compiled with the same host compiler as
Tom> everything else.

Eric> But, precisely, this line of reasoning is barely defensible in my
Eric> opinion.  If you really want to go that route, then let's stop
Eric> doing comprehensive reviews and stop requesting changes to
Eric> submitted patches in order to make them comply with the
Eric> agreed-upon practices, that would save time for everyone.

I never suggested anything like this.  I suppose you are arguing ad
absurdum here, but I don't think that this conclusion follows from the
antecedents.

I'm merely supporting Pedro's discovery that a rule, previously thought
to have been important, was found by accident not to matter.

Tom> HOST_WIDE_INT is also not very persuasive to me.  We did many things in
Tom> the past that became obsolete as compilers matured.

Eric> Why would HOST_WIDE_INT be obsolete?  That's a nice way to
Eric> abstract the host and reverting to hardcoded types like 'long
Eric> long' doesn't seem a progress to me.

Yes, ok.  I like typedefs too.  I misunderstood what you were saying
here.

Tom
Mike Stump - June 15, 2012, 9:34 p.m.
On Jun 15, 2012, at 1:11 PM, Eric Botcazou wrote:
> Why would HOST_WIDE_INT be obsolete?

For the same reason that we don't use HOST_NARROW_INT instead of int.  In practice, int is portable enough for us now.  In reality, long long is portable for us now.  20 years ago, it wasn't portable enough.  Times change.  What's changed?  We'll we now have a language standard for long long, other implementors have had a chance to implement that standard, systems have had a chance to update and provide implementations of that standard and systems that don't support have died from hardware failure or have been scraped because they consume too much electricity to be useful anymore.

This situation is more like prototypes than patch reviews.  See patch reviews are useful for catching code bugs, HOST_WIDE_INT is not as useful as catching code bugs.  Prototypes used to be new fangled things that very few compiler had.  One could not portably use them.  Guess what, times change, compilers implement them, language standards adopt them, and system vendors provide implementations that support them.  The systems that never supported them go away, the people that know of a world in which compilers that don't support prototypes die.

We allow portability hacks into the source base for important system (implementations) were we don't want to just nix a platform wholesale.  See things like:

          /* This was a conditional expression but it triggered a bug                                     
             in Sun C 5.5.  */

in the source base.  We do this, not for some theoretic beauty but for very practical and pragmatic reasons.  In time, even the above can be safely removed.  We have already removed support for prototypes (not being supported), and yet, we still have patch reviews.

So, to be practical, let us list the systems, platforms and implementations we are thinking of nixing, if we require long long to support at least 64-bit math.  Let me start:, ok, I'm done, now it is your turn.  I'm fine for avoiding long long, if there is a system people want to support that needs it, I am merely ignorant of such a system.

> That's a nice way to abstract the host

Yes, but why abstract the host?  HOST_NARROW_INT is a nice way to abstract the host as well, that is a necessary but not sufficient reason.  We do it to support an actual, real system, platform or implementation that fails to provide long long.  When there are no longer any such systems, then the time is right to switch to the standard.  Now, why do we do this, because we prefer standards to aide in readability and portability.  A person new to gcc, but knows C or C++ knows what long long is.  HOST_WIDE_INT, well, they have to take a mental hit on and figure it out, if they care.
Joseph S. Myers - June 15, 2012, 9:46 p.m.
On Fri, 15 Jun 2012, Mike Stump wrote:

> Yes, but why abstract the host?  HOST_NARROW_INT is a nice way to 

HOST_WIDE_INT is an abstraction about the *target*; the target determines 
the required properties.  The salient properties include:

* At least as wide as target address space.

* Constants for the target can be represented in at most two 
HOST_WIDE_INT.  (This one is why some 32-bit targets require 64-bit 
HOST_WIDE_INT.)

I describe at 
<https://docs.google.com/document/pub?id=10LO8y0YhjlKHya_PKM3jEGrJu0rllv-Nc9qP5LXqH_I> 
what I think are and are not appropriate uses of HOST_WIDE_INT.  Yes, 
target_int / target_uint might be better names for this type as I think it 
should be used.

Even if "long long" has the required properties, use of a type name such 
as target_int serves as documentation for the human reader about the 
intent of an entity in GCC - that it is an integer or size existing in 
some way on the target - and code needs to address the human reader, not 
just the compiler compiling it.
Mike Stump - June 15, 2012, 10:54 p.m.
On Jun 15, 2012, at 2:46 PM, Joseph S. Myers wrote:
> HOST_WIDE_INT is an abstraction about the *target*; the target determines 
> the required properties.  The salient properties include:
> 
> * At least as wide as target address space.

The first person to do a 128 bit address support isn't going to appreciate all the work they are going to have to do.  With some luck, before then, we will have switched to C++ and engineered in some prettier interfaces that will just work with no changes.  Today, it would be a major pain.

> * Constants for the target can be represented in at most two
> HOST_WIDE_INT.

This is nice in theory but no longer true for some of us.  :-(

> Even if "long long" has the required properties, use of a type name such 
> as target_int serves as documentation for the human reader about the 
> intent of an entity in GCC - that it is an integer or size existing in 
> some way on the target - and code needs to address the human reader, not 
> just the compiler compiling it.

It would be nice to have an interface for address constants that can survive migration to a 128 bit address machine.  It would be nice to have an interface for constants that are bigger than 2*HOST_WIDE_INT.  HOST_WIDE_INT provides neither.
Joseph S. Myers - June 16, 2012, 12:11 a.m.
On Fri, 15 Jun 2012, Mike Stump wrote:

> On Jun 15, 2012, at 2:46 PM, Joseph S. Myers wrote:
> > HOST_WIDE_INT is an abstraction about the *target*; the target determines 
> > the required properties.  The salient properties include:
> > 
> > * At least as wide as target address space.
> 
> The first person to do a 128 bit address support isn't going to 
> appreciate all the work they are going to have to do.  With some luck, 
> before then, we will have switched to C++ and engineered in some 
> prettier interfaces that will just work with no changes.  Today, it 
> would be a major pain.

Well, you'll want 128-bit HOST_WIDE_INT to manipulate object sizes etc. 
for a 128-bit target.

Say the compiler used for the host is GCC.  If the host is 64-bit, you 
have __int128 and unsigned __int128 available (with older GCC, __int128_t 
and __uint128_t).  There are just a couple of problems with those types, 
one a technical standards issue and one more serious as a practical issue:

* They are sui generic types that act quite like integer types but aren't 
actually integer types, because of the host ABI defining intmax_t as 
64-bit.

* They lack any printf support (at least with glibc), and such support is 
needed by GCC for HOST_WIDE_INT.

Given control over the host C library, both issues could be addressed by 
changing intmax_t on the host to 128 bits - printf %j formats would then 
be appropriate for 128-bit types.  (You'd need a host GCC change as well 
to define an integer constant suffix for 128-bit constants.)  That 
certainly ought to be practical in glibc with symbol versioning if desired 
- no worse than the way various architectures moved to 128-bit long 
double.

You'd probably also find places in GCC that assume that HOST_WIDE_INT is 
either 32-bit or 64-bit, but I expect it would be straightforward to 
adjust those to support 128-bit as well.

True, C++ may make it possible to use something other than a built-in 
integer-like type of the host compiler, but I don't think that's needed 
for this.

(I'm not particularly concerned about 32-bit host support for this 
hypothetical 128-bit target; anyway, it should be practical to support 
__int128 for 32-bit systems, with some work on the libgcc side of things.)

> > * Constants for the target can be represented in at most two
> > HOST_WIDE_INT.
> 
> This is nice in theory but no longer true for some of us.  :-(

This could also reasonably be cleaned up separately from other uses of 
HOST_WIDE_INT.  Maybe what's really wanted is some abstraction for wide 
target constants - which usually would be much like double-int.[ch], but 
for targets that need it would be larger.

Certainly the const_int / const_double division - where const_double 
represents *either* wide integers *or* floating-point constants - is an 
ugly interface, and it would be better for integers of whatever size to be 
const_int and const_double only to be floating point.

Patch

diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index 3dda9fb..2177288 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -5451,7 +5451,7 @@  alpha_trampoline_init (rtx m_tramp, tree fndecl, rtx chain_value)
   chain_value = convert_memory_address (Pmode, chain_value);
 #endif
 
-#define HWI_HEX2(X,Y)	(((HOST_WIDE_INT)0x ## X ## u) | 0x ## Y ## u)
+#define HWI_HEX2(X,Y)	(((HOST_WIDE_INT)0x ## X ## u << 32) | 0x ## Y ## u)
 
   if (TARGET_ABI_OPEN_VMS)
     {