But note that in libdecnumber we have:
10de71e1 (meissner 2007-03-24 17:04:47 + 25) typedef unsigned int
UINT32; 10de71e1 (meissner 2007-03-24 17:04:47 + 26) typedef unsigned
long long UINT64; 10de71e1 (meissner 2007-03-24 17:04:47 + 27) typedef
struct { UINT64 w[2]; } UINT128;
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
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
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.
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.
--
Eric Botcazou
On Jun 15, 2012, at 2:22 AM, Pedro Alves pal...@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
CC: ebotcazou gcc-patches gingold rth joseph jay.krell
From: mikestump
To: palves
On Jun 15, 2012, at 2:22 AM, Pedro Alves pal...@redhat.com wrote:
It's not about example, but the fact that host compilers have been
compiling that code as part of
Eric == Eric Botcazou ebotca...@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
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
Eric == Eric Botcazou ebotca...@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.
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
[this time as plain text, sorry]
Date: Fri, 15 Jun 2012 19:58:23 +
From: joseph
To: tromey
CC: ebotcazou palves gcc-patches gingold rth mikestump
Subject: Re: long long availability in host compiler (Re: constant that
doesn't fit in 32bits in alpha.c)
On Fri, 15 Jun
Eric == Eric Botcazou ebotca...@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
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.
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
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 + 41) /* Difference
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:
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 + 41) /* Difference in seconds
between the VMS Epoch and the Unix Epoch */
8d60d2bc (kenner 2001-12-02 14:38:07 +
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
On 2012-06-12 12:44, 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
On Wed, 13 Jun 2012, Richard Henderson wrote:
On 2012-06-12 12:44, 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
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~
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),
On 2012-06-10 02:18, Jay K wrote:
gcc-4.7.0/gcc/config/alpha/alpha.c
word1 = expand_and (DImode, word1, GEN_INT (0x0ffffff0), NULL);
That big constant isn't portable since it doesn't fit in 32bits.
1) append LL
or 2) break it up into an expression, like
Bah. Wrong patch.
r~
* config/alpha/alpha.c (alpha_trampoline_init): Split large constants.
diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index 6d15bf7..3dda9fb 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -5451,6 +5451,8 @@
Thank you. I like it. May I have another?
book2:gcc jay$ grep -i epoch vms*
vmsdbgout.c:/* Difference in seconds between the VMS Epoch and the Unix Epoch */
vmsdbgout.c:static const long long vms_epoch_offset = 3506716800ll;
vmsdbgout.c:#define VMS_EPOCH_OFFSET 350671680
vmsdbgout.c:
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?
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
On 2012-06-11 16:23, Jay K wrote:
Thank you. I like it. May I have another?
book2:gcc jay$ grep -i epoch vms*
vmsdbgout.c:/* Difference in seconds between the VMS Epoch and the Unix Epoch
*/
vmsdbgout.c:static const long long vms_epoch_offset = 3506716800ll;
vmsdbgout.c:#define
29 matches
Mail list logo
