[RFH] A simple way to figure out the number of bits used by a long double
Hi, I'm trying to simplify somewhat code in the library hashing floating point numbers, and I would find very useful a simple "recipe" giving the total number of bits actually used by a long double: the basic issue is that for formats like the 80-bit Intel, I can't just rely on sizeof, because the last 6 bytes are unused. At the moment I'm trying to cook up something fixing that count with LDBL_MANT_DIG, but maybe there is something simpler, maybe using preprocessor builtins?!? Thanks in advance for any help... Paolo.
Re: [RFH] A simple way to figure out the number of bits used by a long double
Paolo Carlini writes: > At the moment I'm trying to cook up something fixing that count with > LDBL_MANT_DIG, but maybe there is something simpler, maybe using > preprocessor builtins?!? What's wrong with LDBL_MANT_DIG? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 02/26/2010 01:03 PM, Andreas Schwab wrote: > Paolo Carlini writes: >> At the moment I'm trying to cook up something fixing that count with >> LDBL_MANT_DIG, but maybe there is something simpler, maybe using >> preprocessor builtins?!? >> > What's wrong with LDBL_MANT_DIG? > Nothing Andreas, the information is all there, essentially. I was hoping in something more "clever", and closer to the actual number, including the exponent, etc. Paolo.
Re: [RFH] A simple way to figure out the number of bits used by a long double
Paolo Carlini wrote: On 02/26/2010 01:03 PM, Andreas Schwab wrote: Paolo Carlini writes: At the moment I'm trying to cook up something fixing that count with LDBL_MANT_DIG, but maybe there is something simpler, maybe using preprocessor builtins?!? What's wrong with LDBL_MANT_DIG? Nothing Andreas, the information is all there, essentially. I was hoping in something more "clever", and closer to the actual number, including the exponent, etc. Paolo. Huh. I would have *sworn* that sizeof(long double) was 10 not 16 even though we know it was 80 bits. How about (in the language of numeric_limits): bits = 1 // sign bit + ::digits// significand bits + log2(1 + ::max_exponent - ::min_exponent) // exponent bits There are preprocessor macros for each these things IIRC if you would rather use those. Another possibility: ask our Fortran brethren who support real*4, real*8, real*10, real*16, etc. Ed
Re: [RFH] A simple way to figure out the number of bits used by a long double
Ed Smith-Rowland wrote: Paolo Carlini wrote: On 02/26/2010 01:03 PM, Andreas Schwab wrote: Paolo Carlini writes: At the moment I'm trying to cook up something fixing that count with LDBL_MANT_DIG, but maybe there is something simpler, maybe using preprocessor builtins?!? What's wrong with LDBL_MANT_DIG? Nothing Andreas, the information is all there, essentially. I was hoping in something more "clever", and closer to the actual number, including the exponent, etc. Paolo. Huh. I would have *sworn* that sizeof(long double) was 10 not 16 even though we know it was 80 bits. How about (in the language of numeric_limits): bits = 1 // sign bit + ::digits// significand bits + log2(1 + ::max_exponent - ::min_exponent) // exponent bits There are preprocessor macros for each these things IIRC if you would rather use those. Another possibility: ask our Fortran brethren who support real*4, real*8, real*10, real*16, etc. Ed Except you probably have that already.
Re: [RFH] A simple way to figure out the number of bits used by a long double
Hi, >> Huh. I would have *sworn* that sizeof(long double) was 10 not 16 >> even though we know it was 80 bits. normally, it's either 12, for 32-bit machines, or 16, for 64-bit machines. In any case, there are padding bytes, which we don't want to hash. >> >> How about (in the language of numeric_limits): >> >> bits = 1 // sign bit >> + ::digits// significand bits >> + log2(1 + ::max_exponent - ::min_exponent) // exponent bits >> >> There are preprocessor macros for each these things IIRC if you would >> rather use those. Thanks. Currently I'm thinking of doing something very simple, like: const size_t __size = __LDBL_MANT_DIG__ == 64 ? 10 : sizeof(__val); seems conservative and I think it covers all the cases we really support. But if people are aware of counterexamples, for the targets actually supported by the C++ library, I'm all ears... No hurry, anyway, we can tweak the above to take care of special cases whenever we want... Paolo.
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 2/26/2010 5:44 AM, Ed Smith-Rowland wrote: Huh. I would have *sworn* that sizeof(long double) was 10 not 16 even though we know it was 80 bits. As you indicated before, sizeof gives the amount of memory displaced by the object, including padding. In my experience with gcc, sizeof(long double) is likely to be 12 on 32-bit platforms, and 16 on 64-bit platforms. These choices are made to preserve alignment for 32-bit and 128-bit objects respectively, and to improve performance in the 64-bit case, for hardware which doesn't like to straddle cache lines. It seems the topic would have been more appropriate for gcc-help, if related to gcc, or maybe comp.lang.c, if a question about implementation in accordance with standard C. -- Tim Prince
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 02/26/2010 03:47 PM, Tim Prince wrote: > It seems the topic would have been more appropriate for gcc-help, if > related to gcc, or maybe comp.lang.c, if a question about > implementation in accordance with standard C. It's neither. I was asking for the advice of the compiler people while implementing some bits of libstdc++. But the issue seems simple, actually. Paolo.
Re: [RFH] A simple way to figure out the number of bits used by a long double
Paolo Carlini writes: > Thanks. Currently I'm thinking of doing something very simple, like: > > const size_t __size = __LDBL_MANT_DIG__ == 64 ? 10 : sizeof(__val); > > seems conservative and I think it covers all the cases we really > support. What is __size supposed to represent? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 02/26/2010 03:56 PM, Andreas Schwab wrote: > Paolo Carlini writes: > > >> Thanks. Currently I'm thinking of doing something very simple, like: >> >> const size_t __size = __LDBL_MANT_DIG__ == 64 ? 10 : sizeof(__val); >> >> seems conservative and I think it covers all the cases we really >> support. >> > What is __size supposed to represent? > A size. Paolo.
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 02/26/2010 03:57 PM, Paolo Carlini wrote: > On 02/26/2010 03:56 PM, Andreas Schwab wrote: > >> Paolo Carlini writes: >> >> >> >>> Thanks. Currently I'm thinking of doing something very simple, like: >>> >>> const size_t __size = __LDBL_MANT_DIG__ == 64 ? 10 : sizeof(__val); >>> >>> seems conservative and I think it covers all the cases we really >>> support. >>> >>> >> What is __size supposed to represent? >> > A size. > Andreas, more seriously, if you mean that __CHAR_BIT__ can be != 8, I don't think we are *really* supporting that kind of non-Posix target anyway in the C++ runtime. And here we are talking only about C++1x features. Anyway, do you think I should write something like: (80 + __CHAR_BIT__ - 1) / __CHAR_BIT__ instead of 10? Not a big deal... Paolo.
Re: [RFH] A simple way to figure out the number of bits used by a long double
Paolo Carlini writes: > On 02/26/2010 03:56 PM, Andreas Schwab wrote: >> Paolo Carlini writes: >> >> >>> Thanks. Currently I'm thinking of doing something very simple, like: >>> >>> const size_t __size = __LDBL_MANT_DIG__ == 64 ? 10 : sizeof(__val); >>> >>> seems conservative and I think it covers all the cases we really >>> support. >>> >> What is __size supposed to represent? >> > A size. Of what? What is the 10 magic number supposed to represent? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [RFH] A simple way to figure out the number of bits used by a long double
Paolo Carlini writes: > Andreas, more seriously, if you mean that __CHAR_BIT__ can be != 8, I Don't be silly. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 02/26/2010 04:41 PM, Andreas Schwab wrote: > Of what? What is the 10 magic number supposed to represent? > A size_t. Thus the number of consecutive chars occupied by the long double. By the way, in the meanwhile I grepped config for BITS_PER_UNIT and *finally* there are no 16 or 32 anymore. At all. Thus, really, I don't see your point. Paolo.
Re: [RFH] A simple way to figure out the number of bits used by a long double
Paolo Carlini writes: > On 02/26/2010 04:41 PM, Andreas Schwab wrote: >> Of what? What is the 10 magic number supposed to represent? >> > A size_t. Thus the number of consecutive chars occupied by the long double. How does that handle padding? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 02/26/2010 04:51 PM, Andreas Schwab wrote: > How does that handle padding? > Andreas, I can spend the whole afternoon discussing with you one word at a time in a kind of Socratic question and answer exchange. You mean the padding can be *in the middle*? I didn't consider that, seems quite crazy to me. If you are sure, please say it, let's skip those 2 or 6 bytes, and be done with it. I have the patch otherwise ready. Paolo.
Re: [RFH] A simple way to figure out the number of bits used by a long double
Paolo Carlini writes: > You mean the padding can be *in the middle*? I didn't consider that, > seems quite crazy to me. How is that crazy in any way? > If you are sure, please say it, let's skip > those 2 or 6 bytes, and be done with it. I have the patch otherwise ready. If you don't care about internal padding why do you care about padding at all? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [RFH] A simple way to figure out the number of bits used by a long double
Ok, patch canceled. Paolo.
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 02/26/2010 05:03 PM, Andreas Schwab wrote: > If you don't care about internal padding why do you care about padding By the way, this doesn't make any sense to me: I don't see what the CPU gains from having padding between mantissa and exponent, or different bytes of the mantissa. If you really want to help the C++ library, please give me a a link to the Intel documentation explaining this, I want to study it, with my time. Paolo.
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 26/02/2010 15:45, Paolo Carlini wrote: > On 02/26/2010 04:41 PM, Andreas Schwab wrote: >> Of what? What is the 10 magic number supposed to represent? >> > A size_t. Thus the number of consecutive chars occupied by the long double. > > By the way, in the meanwhile I grepped config for BITS_PER_UNIT and > *finally* there are no 16 or 32 anymore. At all. > > Thus, really, I don't see your point. > > Paolo. And there was me all ready to start feeding bugfixes back upstream from the private port I'm working on with BITS_PER_UNIT=24! cheers, DaveK
Re: [RFH] A simple way to figure out the number of bits used by a long double
Paolo Carlini writes: > By the way, this doesn't make any sense to me: I don't see what the CPU > gains from having padding between mantissa and exponent, or different > bytes of the mantissa. It's a fact of life. I didn't design the motorola floating point format. > If you really want to help the C++ library, please give me a a link to > the Intel documentation explaining this See libiberty/floatformat.c. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 02/26/2010 05:36 PM, Andreas Schwab wrote:
> See libiberty/floatformat.c.
>
Ok, thanks. Actually, it looks like there is *no* padding in the middle
for the Intel x87 format I truly care about:
const struct floatformat floatformat_i387_ext =
{
floatformat_little, 80, 0, 1, 15, 0x3fff, 0x7fff, 16, 64,
I read it as meaning 0 sign, 1-15 exponent, 16-79 mantissa.
But really we don't want to deal with all those special cases for other
formats, for now at least. Too bad.
Paolo.
Gcc plugin: error: ‘LAST_AND_UNUSED_RTX_CODE’ undeclared
Hi,
I am trying to write a simple gcc plugin and am getting the following errors.
In file included from /home/aj/gcc/trunk/gcc/rtl.h:49,
from /home/aj/gcc/testcode/plugin/ctla_gcc_plugin.c:22:
/home/aj/gcc/trunk/gcc/rtl.def:336: error: expected identifier before ‘const’
In file included from /home/aj/gcc/testcode/plugin/ctla_gcc_plugin.c:22:
/home/aj/gcc/trunk/gcc/rtl.h:99: error: ‘LAST_AND_UNUSED_RTX_CODE’ undeclared
here (not in a function)
In file included from /home/aj/gcc/trunk/gcc/basic-block.h:28,
from /home/aj/gcc/testcode/plugin/ctla_gcc_plugin.c:23:
/home/aj/gcc/trunk/gcc/hard-reg-set.h: In function ‘hard_reg_set_iter_set’:
/home/aj/gcc/trunk/gcc/hard-reg-set.h:545: error: ‘FIRST_PSEUDO_REGISTER’
undeclared (first use in this function)
/home/aj/gcc/trunk/gcc/hard-reg-set.h:545: error: (Each undeclared identifier
is reported only once
/home/aj/gcc/trunk/gcc/hard-reg-set.h:545: error: for each function it appears
in.)
/home/aj/gcc/trunk/gcc/hard-reg-set.h: At top level:
/home/aj/gcc/trunk/gcc/hard-reg-set.h:583: error: ‘FIRST_PSEUDO_REGISTER’
undeclared here (not in a function)
/home/aj/gcc/trunk/gcc/hard-reg-set.h:644: error: ‘N_REG_CLASSES’ undeclared
here (not in a function)
In file included from /home/aj/gcc/trunk/gcc/basic-block.h:31,
from /home/aj/gcc/testcode/plugin/ctla_gcc_plugin.c:23:
/home/aj/gcc/trunk/gcc/function.h:222: error: expected specifier-qualifier-list
before ‘CUMULATIVE_ARGS’
/home/aj/gcc/trunk/gcc/function.h:698: error: expected ‘)’ before ‘*’ token
/home/aj/gcc/trunk/gcc/function.h:700: error: expected ‘)’ before ‘*’ token
In file included from /home/aj/gcc/testcode/plugin/ctla_gcc_plugin.c:32:
/home/aj/gcc/trunk/gcc/target.h:910: error: expected ‘)’ before ‘*’ token
/home/aj/gcc/trunk/gcc/target.h:913: error: expected ‘;’ before ‘rtx’
I googled for a solution and found a similar message in which it was suggested
to include "tm.h". I verified my code, and I am getting the same error even
after including the file.
My CMake file is as follows:
set( GCC_SRC_DIR "/home/aj/gcc/trunk")
set( GCC_BUILD_DIR "/home/aj/gcc/trunk-obj" )
include_directories( ${CMAKE_CURRENT_SOURCE_DIR} )
include_directories( ${GCC_BUILD_DIR}/gcc )
include_directories( ${GCC_SRC_DIR}/gcc )
include_directories( ${GCC_SRC_DIR}/libcpp/include )
include_directories( ${GCC_SRC_DIR}/include )
include_directories( ${GCC_SRC_DIR}/host-i686-pc-linux-gnu/gcc )
I am not able to figure out what is going wrong, can you please guide me on
where am I making a mistake?
Thanks,
Ashish
Your Mail works best with the New Yahoo Optimized IE8. Get it NOW!
http://downloads.yahoo.com/in/internetexplorer/
Re: Gcc plugin: error: ‘LAST_AND_UNUSED_RTX_CODE’ undeclared
On Fri, Feb 26, 2010 at 9:26 AM, ashish jain wrote: > Hi, > > I am trying to write a simple gcc plugin and am getting the following errors. > > In file included from /home/aj/gcc/trunk/gcc/rtl.h:49, > from /home/aj/gcc/testcode/plugin/ctla_gcc_plugin.c:22: > /home/aj/gcc/trunk/gcc/rtl.def:336: error: expected identifier before ‘const’ From the looks of it, you have a define for CONST as const. This first error is the reason for the rest of the errors. Thanks, Andrew Pinski
Parallelization of tokenizer in GCC!!!
Dear Sirs/Madams, I am doing a project on Cell Broadband Engine to parallelize the tokenization process of a given C program. As we are done with the tokenization part we want it to replace the tokenization part of an open source compiler. I mean the compiler that can run in Cell BE environment(ppu-gcc). If any of you would be able to help me locate the tokenization part of GCC and the input / output format for tokenizer part of GCC, it would be very useful to us. Thanks in Advance Regards Vivek
Re: [RFH] A simple way to figure out the number of bits used by a long double
Paolo Carlini writes: > But really we don't want to deal with all those special cases for other > formats, for now at least. Too bad. But LDBL_MANT_DIG == 64 is ambigous for identifying the floating point format. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [RFH] A simple way to figure out the number of bits used by a long double
On Fri, Feb 26, 2010 at 06:09:37PM +0100, Paolo Carlini wrote:
> On 02/26/2010 05:36 PM, Andreas Schwab wrote:
> > See libiberty/floatformat.c.
> >
> Ok, thanks. Actually, it looks like there is *no* padding in the middle
> for the Intel x87 format I truly care about:
>
> const struct floatformat floatformat_i387_ext =
> {
> floatformat_little, 80, 0, 1, 15, 0x3fff, 0x7fff, 16, 64,
>
> I read it as meaning 0 sign, 1-15 exponent, 16-79 mantissa.
>
> But really we don't want to deal with all those special cases for other
> formats, for now at least. Too bad.
Despite all that exchange, I don't think you ever answered Andreas's
question - at least not in a way that I could understand. A size of
what? The size of the *type* on x86 is 16; the size of the *data
bits* is 10. But what cares about the size of the data bits rather
than e.g. the size of the mantissa?
--
Daniel Jacobowitz
CodeSourcery
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 02/26/2010 07:05 PM, Andreas Schwab wrote: >> But really we don't want to deal with all those special cases for other >> formats, for now at least. Too bad. >> > But LDBL_MANT_DIG == 64 is ambigous for identifying the floating point > format. > Sure, sure. I meant, there are too many formats and quirks, I'm not going to optimize this for now. Sorry if my reply wasn't clear. Paolo.
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 02/26/2010 07:07 PM, Daniel Jacobowitz wrote: > Despite all that exchange, I don't think you ever answered Andreas's > question - at least not in a way that I could understand. A size of > what? The size of the *type* on x86 is 16; the size of the *data > bits* is 10. But what cares about the size of the data bits rather > than e.g. the size of the mantissa? > I'm tired. Anyway, I meant of course the size of the *data bits*, using your terminology. For *some* formats, like x87, where there are no holes, no padding bits in the middle of the representation, that is all I would need. In the meanwhile, Andreas made me notice that unfortunately this is not the general case. Thanks again about that. Paolo.
Re: [RFH] A simple way to figure out the number of bits used by a long double
Paolo Carlini writes: > I'm tired. Anyway, I meant of course the size of the *data bits*, using > your terminology. For *some* formats, like x87, where there are no > holes, no padding bits in the middle of the representation, that is all > I would need. In the meanwhile, Andreas made me notice that > unfortunately this is not the general case. Thanks again about that. Even the x87 floating point format has don't-care bits in some cases. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Dumping CPP symbol table stats
> "Victor" == Victor Norman writes: Victor> I would like to tweak cpp to dump some usage stats from its symbol Victor> table -- like dumping which #defines were not used at all, etc. In addition to what Ian said, for this particular case, search for warn_unused_macros in libcpp. That will show you the implementation of a similar feature. Tom
Re: Parallelization of tokenizer in GCC!!!
> "Vivek" == vivhari writes: Vivek> If any of you would be able to help me locate the tokenization Vivek> part of GCC and the input / output format for tokenizer part of Vivek> GCC, it would be very useful to us. Tokenization is handled by the preprocessor, see the libcpp directory. The input is just files. There isn't really any "output format", it just returns tokens to the caller. But perhaps I misunderstand what you are asking for here. Tom
Re: [RFH] A simple way to figure out the number of bits used by a long double
Paolo Carlini writes: > I'm trying to simplify somewhat code in the library hashing floating > point numbers, and I would find very useful a simple "recipe" giving the > total number of bits actually used by a long double: the basic issue is > that for formats like the 80-bit Intel, I can't just rely on sizeof, > because the last 6 bytes are unused. At the moment I'm trying to cook up > something fixing that count with LDBL_MANT_DIG, but maybe there is > something simpler, maybe using preprocessor builtins?!? I saw that this led into a long discussion which I didn't fully understand. I just want to comment that you can't reasonably hash floating point representations by simply hashing the bits, even if you can figure out how many bits there are. A hash function is necessarily tied to an equality function, and when comparing floating point numbers for equality some bits are ignored. In particular you can have multiple representations of NaN, which for most hashing purposes would be considered to be the same. Ian
Re: Re: [RFH] A simple way to figure out the number of bits used by a long double
Feb 26, 2010 01:43:15 PM, sch...@linux-m68k.org wrote: Paolo Carlini writes: > I'm tired. Anyway, I meant of course the size of the *data bits*, using > your terminology. For *some* formats, like x87, where there are no > holes, no padding bits in the middle of the representation, that is all > I would need. In the meanwhile, Andreas made me notice that > unfortunately this is not the general case. Thanks again about that. Even the x87 floating point format has don't-care bits in some cases. Andreas. Is this when denormalizing? Ed -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
