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 fi
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
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.
* Constant
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.
> "Eric" == Eric Botcazou 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> opini
[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 a
> 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 do
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 a
> "Eric" == Eric Botcazou 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
> 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 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 beau
> CC: ebotcazou gcc-patches gingold rth joseph jay.krell
> From: mikestump
> To: palves
>
> On Jun 15, 2012, at 2:22 AM, Pedro Alves wrote:
> > It's not about example, but the fact that host compilers have been
> > compiling that code as part of building g
On Jun 15, 2012, at 2:22 AM, Pedro Alves 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
> 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 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 ea
> 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 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 mat
> 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]; } UINT1
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 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
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) /* Dif
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~
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-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 HOST_WIDE
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_
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).
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 VMS_
On 2012-06-11 16:23, Mike Stump wrote:
> On Jun 11, 2012, at 4:06 PM, Richard Henderson wrote:
>> Bah. Wrong patch.
>>
>>
>> r~
>>
>
>
> 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 pa
Oops, agreed, shift missing. Also, I've been bitten, unable to find stuff
(grep) due to token pasting, so I am a little slower to use it.
But I understand it is useful in general for reuse.
- Jay
> Subject: Re: constant that doesn't fit
On Jun 11, 2012, at 4:06 PM, Richard Henderson wrote:
> Bah. Wrong patch.
>
>
> r~
>
Hum, I'm trying to see how this patch works... I feel like there is something
I'm missing, like a shift?
: + VMS_EPOCH_OFFSET;
:)
- Jay
> Date: Mon, 11 Jun 2012 16:06:03 -0700
> From: r...@redhat.com
> To: jay.kr...@cornell.edu
> CC: gcc-patches@gcc.gnu.org
> Subject: Re: constant that doesn't fit in 32bits in al
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 @@ alpha_trampoline
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, lik
33 matches
Mail list logo
