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

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

[Richard Henderson]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

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 (0xffff0fff0000fff0), 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
>   ((HOST_WIDE_INT)0xffff0fff) << 8) | 0x0fff0
> 
> 
> or such.

Addressed like so.  I couldn't think of any nice way to define this
such that it could be generic, so I left it local to this bit o code.



r~

[-- Attachment #2: z --]
[-- Type: text/plain, Size: 761 bytes --]

        * lib/target-supports.exp
        (check_effective_target_sync_long_long_runtime): Use
        check_effective_target_lp64 instead of
        check_effective_target_powerpc64 for powerpc targets.


diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 568f6b1..c937484 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3796,7 +3796,7 @@ proc check_effective_target_sync_long_long_runtime { } {
 		 && [check_effective_target_lp64]
 		 && [check_effective_target_ultrasparc_hw]) } {
 	return 1
-    } elseif { [check_effective_target_powerpc64] } {
+    } elseif { [istarget powerpc*-*-*] && [check_effective_target_lp64] } {
 	return 1
     } else {
 	return 0

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

[Richard Henderson]

[-- Attachment #1: Type: text/plain, Size: 24 bytes --]

Bah.  Wrong patch.


r~

[-- Attachment #2: z --]
[-- Type: text/plain, Size: 1576 bytes --]

	* 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_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)
+
   if (TARGET_ABI_OPEN_VMS)
     {
       const char *fnname;
@@ -5468,7 +5470,8 @@ alpha_trampoline_init (rtx m_tramp, tree fndecl, rtx chain_value)
 	 the function's procedure descriptor with certain fields zeroed IAW
 	 the VMS calling standard. This is stored in the first quadword.  */
       word1 = force_reg (DImode, gen_const_mem (DImode, fnaddr));
-      word1 = expand_and (DImode, word1, GEN_INT (0xffff0fff0000fff0), NULL);
+      word1 = expand_and (DImode, word1,
+			  GEN_INT (HWI_HEX2(ffff0fff,0000fff0)), NULL);
     }
   else
     {
@@ -5479,10 +5482,12 @@ alpha_trampoline_init (rtx m_tramp, tree fndecl, rtx chain_value)
 	    nop
 	 We don't bother setting the HINT field of the jump; the nop
 	 is merely there for padding.  */
-      word1 = GEN_INT (0xa77b0010a43b0018);
-      word2 = GEN_INT (0x47ff041f6bfb0000);
+      word1 = GEN_INT (HWI_HEX2 (a77b0010,a43b0018));
+      word2 = GEN_INT (HWI_HEX2 (47ff041f,6bfb0000));
     }
 
+#undef HWI_HEX2
+
   /* Store the first two words, as computed above.  */
   mem = adjust_address (m_tramp, DImode, 0);
   emit_move_insn (mem, word1);

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

[Jay K]

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 35067168000000000
vmsdbgout.c:                        + VMS_EPOCH_OFFSET;


 :)

  - Jay


----------------------------------------
> Date: Mon, 11 Jun 2012 16:06:03 -0700
> From: rth@redhat.com
> To: jay.krell@cornell.edu
> CC: gcc-patches@gcc.gnu.org
> Subject: Re: constant that doesn't fit in 32bits in alpha.c
>
> Bah. Wrong patch.
>
>
> r~
 		 	   		  

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

[Mike Stump]

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?

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

[Jay K]

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 in 32bits in alpha.c
> From: mikestump@comcast.net
> Date: Mon, 11 Jun 2012 16:23:57 -0700
> CC: jay.krell@cornell.edu; gcc-patches@gcc.gnu.org
> To: rth@redhat.com
>
> 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?
 		 	   		  

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

[Richard Henderson]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

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~


[-- Attachment #2: zz --]
[-- Type: text/plain, Size: 564 bytes --]

        * config/alpha/alpha.c (HWI_HEX2): Add missing shift.


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)
     {

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

[Richard Henderson]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

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_EPOCH_OFFSET 35067168000000000
> vmsdbgout.c:                        + VMS_EPOCH_OFFSET;
> 


In this case, long long is explicitly referenced in the surrounding code,
so I feel the safest change is just to add LL here.  I've cross-compiled
to alpha-dec-vms just to make sure, but I can't actually test this.


r~

[-- Attachment #2: z --]
[-- Type: text/plain, Size: 389 bytes --]

        * vmsdbgout.c (VMS_EPOCH_OFFSET): Add LL suffix.


diff --git a/gcc/vmsdbgout.c b/gcc/vmsdbgout.c
index 9689653..eedf1bd 100644
--- a/gcc/vmsdbgout.c
+++ b/gcc/vmsdbgout.c
@@ -1676,7 +1676,7 @@ to_vms_file_spec (char *filespec)
 }
 
 #else
-#define VMS_EPOCH_OFFSET 35067168000000000
+#define VMS_EPOCH_OFFSET 35067168000000000LL
 #define VMS_GRANULARITY_FACTOR 10000000
 #endif
 

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

[Joseph S. Myers]

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).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Pedro Alves]

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.

-- 
Pedro Alves

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

[Richard Henderson]

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]

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_INT_1 can be HOST_WIDE_INT_C (1), unconditionally).
> 

Are you happy with this version?


r~

[-- Attachment #2: z --]
[-- Type: text/plain, Size: 4344 bytes --]

diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index 2177288..36f7306 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -5451,8 +5451,6 @@ 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 << 32) | 0x ## Y ## u)
-
   if (TARGET_ABI_OPEN_VMS)
     {
       const char *fnname;
@@ -5471,7 +5469,8 @@ alpha_trampoline_init (rtx m_tramp, tree fndecl, rtx chain_value)
 	 the VMS calling standard. This is stored in the first quadword.  */
       word1 = force_reg (DImode, gen_const_mem (DImode, fnaddr));
       word1 = expand_and (DImode, word1,
-			  GEN_INT (HWI_HEX2(ffff0fff,0000fff0)), NULL);
+			  GEN_INT (HOST_WIDE_INT_C (0xffff0fff0000fff0)),
+			  NULL);
     }
   else
     {
@@ -5482,12 +5481,10 @@ alpha_trampoline_init (rtx m_tramp, tree fndecl, rtx chain_value)
 	    nop
 	 We don't bother setting the HINT field of the jump; the nop
 	 is merely there for padding.  */
-      word1 = GEN_INT (HWI_HEX2 (a77b0010,a43b0018));
-      word2 = GEN_INT (HWI_HEX2 (47ff041f,6bfb0000));
+      word1 = GEN_INT (HOST_WIDE_INT_C (0xa77b0010a43b0018));
+      word2 = GEN_INT (HOST_WIDE_INT_C (0x47ff041f6bfb0000));
     }
 
-#undef HWI_HEX2
-
   /* Store the first two words, as computed above.  */
   mem = adjust_address (m_tramp, DImode, 0);
   emit_move_insn (mem, word1);
diff --git a/gcc/hwint.h b/gcc/hwint.h
index 9885911..1734639 100644
--- a/gcc/hwint.h
+++ b/gcc/hwint.h
@@ -1,5 +1,5 @@
 /* HOST_WIDE_INT definitions for the GNU compiler.
-   Copyright (C) 1998, 2002, 2004, 2008, 2009, 2010
+   Copyright (C) 1998, 2002, 2004, 2008, 2009, 2010, 2012
    Free Software Foundation, Inc.
 
    This file is part of GCC.
@@ -60,20 +60,25 @@ extern char sizeof_long_long_must_be_8[sizeof(long long) == 8 ? 1 : -1];
 #if HOST_BITS_PER_LONG >= 64 || !defined NEED_64BIT_HOST_WIDE_INT
 #   define HOST_BITS_PER_WIDE_INT HOST_BITS_PER_LONG
 #   define HOST_WIDE_INT long
+#   define HOST_WIDE_INT_C(X) X ## L
 #else
 # if HOST_BITS_PER_LONGLONG >= 64
 #   define HOST_BITS_PER_WIDE_INT HOST_BITS_PER_LONGLONG
 #   define HOST_WIDE_INT long long
+#   define HOST_WIDE_INT_C(X) X ## LL
 # else
 #  if HOST_BITS_PER___INT64 >= 64
 #   define HOST_BITS_PER_WIDE_INT HOST_BITS_PER___INT64
 #   define HOST_WIDE_INT __int64
+#   define HOST_WIDE_INT_C(X) X ## i64
 #  else
     #error "Unable to find a suitable type for HOST_WIDE_INT"
 #  endif
 # endif
 #endif
 
+#define HOST_WIDE_INT_1 HOST_WIDE_INT_C(1)
+
 /* This is a magic identifier which allows GCC to figure out the type
    of HOST_WIDE_INT for %wd specifier checks.  You must issue this
    typedef before using the __asm_fprintf__ format attribute.  */
@@ -84,7 +89,6 @@ typedef HOST_WIDE_INT __gcc_host_wide_int__;
 #if HOST_BITS_PER_WIDE_INT == HOST_BITS_PER_LONG
 # define HOST_WIDE_INT_PRINT HOST_LONG_FORMAT
 # define HOST_WIDE_INT_PRINT_C "L"
-# define HOST_WIDE_INT_1 1L
   /* 'long' might be 32 or 64 bits, and the number of leading zeroes
      must be tweaked accordingly.  */
 # if HOST_BITS_PER_WIDE_INT == 64
@@ -97,7 +101,6 @@ typedef HOST_WIDE_INT __gcc_host_wide_int__;
 #else
 # define HOST_WIDE_INT_PRINT HOST_LONG_LONG_FORMAT
 # define HOST_WIDE_INT_PRINT_C "LL"
-# define HOST_WIDE_INT_1 1LL
   /* We can assume that 'long long' is at least 64 bits.  */
 # define HOST_WIDE_INT_PRINT_DOUBLE_HEX \
     "0x%" HOST_LONG_LONG_FORMAT "x%016" HOST_LONG_LONG_FORMAT "x"
@@ -122,14 +125,17 @@ typedef HOST_WIDE_INT __gcc_host_wide_int__;
 # define HOST_WIDEST_INT_PRINT_UNSIGNED	      HOST_WIDE_INT_PRINT_UNSIGNED
 # define HOST_WIDEST_INT_PRINT_HEX	      HOST_WIDE_INT_PRINT_HEX
 # define HOST_WIDEST_INT_PRINT_DOUBLE_HEX     HOST_WIDE_INT_PRINT_DOUBLE_HEX
+# define HOST_WIDEST_INT_C(X)		      HOST_WIDE_INT(X)
 #else
 # if HOST_BITS_PER_LONGLONG >= 64
 #  define HOST_BITS_PER_WIDEST_INT	      HOST_BITS_PER_LONGLONG
 #  define HOST_WIDEST_INT		      long long
+#  define HOST_WIDEST_INT_C(X)		      X ## LL
 # else
 #  if HOST_BITS_PER___INT64 >= 64
 #   define HOST_BITS_PER_WIDEST_INT	      HOST_BITS_PER___INT64
 #   define HOST_WIDEST_INT		      __int64
+#   define HOST_WIDEST_INT_C(X)		      X ## i64
 #  else
     #error "This line should be impossible to reach"
 #  endif

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

[Joseph S. Myers]

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 concatenate with either L or 
> > LL (and then HOST_WIDE_INT_1 can be HOST_WIDE_INT_C (1), unconditionally).
> > 
> 
> Are you happy with this version?

Yes.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Richard Henderson]

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~

long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Pedro Alves]

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.

-- 
Pedro Alves

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Tristan Gingold]

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.

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Pedro Alves]

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 */
                   ^^^^^^^^^^

-- 
Pedro Alves

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Eric Botcazou]

> 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.

-- 
Eric Botcazou

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Pedro Alves]

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.)

-- 
Pedro Alves

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Eric Botcazou]

> 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.

-- 
Eric Botcazou

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Richard Earnshaw]

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.

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Eric Botcazou]

> 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

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Mike Stump]

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.

RE: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Jay K]

----------------------------------------
> 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

 		 	   		  

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Tom Tromey]

>>>>> "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

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Eric Botcazou]

> 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.

-- 
Eric Botcazou

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Tom Tromey]

>>>>> "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

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Joseph S. Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Eric Botcazou]

> 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.

-- 
Eric Botcazou

FW: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Jay K]

[this time as plain text, sorry]
 




> Date: Fri, 15 Jun 2012 19:58:23 +0000
> 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 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.
> 
> -- 
> Joseph S. Myers
> joseph@

 
 
 
 
 > If it's "fast on the host, but size doesn't matter", then HOST_WIDEST_FAST_INT 



 
That is int, right? I guess sometimes long, 64bit integer might be faster on 64bit host that has 32bit int??
 For a local variables, the size difference rarely amounts to much, I think. For data structures that you have many of, size optimizations become interesting. 



 
One can easily dream up many abstractions, too many: 



 
  can at least hold host pointer 
can at least hold target pointer 
can hold the size of a target struct, 32 bits is ok with slightly degraded functionality if 64bits aren't available 
can be a loop index for a certain smallish constant number of iterations -- e.g. what to use for (pass = 0; pass < 2;) or for (i = 0; i < sizeof(integer type);) 
can hold source file size or offset, or seek delta (possibly negative?) 
can hold host object file file size or offset, or seek delta (possibly negative?) 
can hold target object file file size or offset, or seek delta (possibly negative?) 
can hold host executable file file size or offset, or seek delta (possibly negative?) 
can hold target executable file file size or offset, or seek delta (possibly negative?) 
can hold host library/archive file file size or offset, or seek delta (possibly negative?) 
can hold target library/archive file file size or offset, or seek delta (possibly negative?) 
can hold the number of members in a library/archive, or seek delta (possibly negative?) 
can hold the number of files in a directory (e.g. for #include search caching) 
can hold the number of files seen in preprocessor run 
number of instructions in a function (held in memory or in a file?) 
number of basic blocks in a function (held in memory or in a file?) 
number of <something> that is held in a file (same as file size generally) 
number of <something> that is held in memory (size_t) 
number of cycles measured or estimated 
number of bytes allocated 
number of bytes allocated minus number of bytes freed 
length of an in-memory string (size_t strlen(), but rarely does 32bits not suffice) 


One can even imagine a 53bit-mantissa double being used...but after some thought in my own code, I'd really rather depend on their being a 64bit integer. 


It is tempting to "throw up one's hands" in disgust and just smush all the abstractions down to almost nothing. 
Otherwise you have to worry about if the types interoperate well, which one is larger/smaller than the other, how do I safely convert? Are their symbols for the min/max of each type?
 int is always at least 32bits on modern hosts and "reasonable" if not theoretical max for many things.
 ditto long, but is really definitely at least 32bits, and often larger 
similarly HOST_WIDE_INT is pretty fast, maybe slower, often 64bits, and 64bits is usually vastly sufficient for vastly most things..unless manipulating floating point pieces.... 
One can check for overflow so that if a 32bit integer proves too small, there is a clear error instead of silent wraparound and crash or bug. One could encode such overflow checks into a C++ integer-like class with operator overloading. It's not that difficult..
 



Or just provide the stdint.h fast/atleast/exact types and let every "section" of code make its own typedefs thereof. 
Establish a naming convention perhaps such that when I see foo_t, I know at a glance that is "just some integer type".
Maybe by always putting "size" or "count" in the name?
But some things are pervasive -- host/target address sizes/offsets. 



I need to go read the document..


 


 
 - Jay
  		 	   		  

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Tom Tromey]

>>>>> "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

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Mike Stump]

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.

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Joseph S. Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Mike Stump]

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.

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Joseph S. Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com