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
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
> "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 in
> "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 s
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 t
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
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 for
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 floatform
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 54C
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(
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/
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:
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, 0x7ff
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
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_P
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 w
Ok, patch canceled.
Paolo.
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 abou
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 cr
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
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.
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."
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
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);
>>>
>
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
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.
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
impleme
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
do
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_
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?!?
Wha
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_MA
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 Andr
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 = 5
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
34 matches
Mail list logo
