| Message ID | 4FD6955C.4090904@redhat.com |
|---|---|
| State | New |
| Headers | show |
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 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.
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 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.
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.
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 */ ^^^^^^^^^^
> 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.
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.)
> 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.
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.
> 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.
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.
---------------------------------------- > 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
>>>>> "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
> 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" == 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
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.
> 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" == 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
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.
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.
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.
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.
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) {