On 5/9/08, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> The idea is to use integer arithmetic to compute the right exponent, and
> the lookup table to estimate the mantissa. I used something like this for
> square root:
>
> 1) shift the entire FP number by 1 to the right (logical right shift)
> 2
On 5/9/08 4:32 PM, Kaz Kojima wrote:
* config/sh/sh.c (sh_gimplify_va_arg_expr): Change pre_p and
post_p types to gimple_seq *.
Thanks. This is certainly OK.
Diego.
Paolo Bonzini wrote:
>
>> I'd like to implement something similar for MaverickCrunch, using the
>> integer 32-bit MAC functions, but there is no reciprocal estimate
>> function on the MaverickCrunch. I guess a lookup table could be
>> implemented, but how many entries will need to be generated, a
Andrew Haley wrote:
> Paolo Bonzini wrote:
>>> I'd like to implement something similar for MaverickCrunch, using the
>>> integer 32-bit MAC functions, but there is no reciprocal estimate
>>> function on the MaverickCrunch. I guess a lookup table could be
>>> implemented, but how many entries will
I want to add target specific tests for AVR.
These would be testcases for PR that fail related to AVR back end
problems - rather than testcases for generic PR.
Do I just add them to directory testsuite/gcc.target/avr? Or are there
some other configuration steps needed?
Andy
On May 9, 2008, Dave Higginbotham <[EMAIL PROTECTED]> wrote:
> I'm getting a " warning: deprecated conversion from string constant to
> ‘char*’" message in g++ (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7).
> I've always understood there is no such thing as deprecation in C++ (and
> have been proud of thi
On May 10, 2008, Andy H <[EMAIL PROTECTED]> wrote:
> These would be testcases for PR that fail related to AVR back end
> problems - rather than testcases for generic PR.
> Do I just add them to directory testsuite/gcc.target/avr? Or are there
> some other configuration steps needed?
You'll want
Hi.
What is the proper way to tell gcc that a
inline assembly statement either modifies
a particular area of memory or needs it
to be updated/in-sync because the assembly
reads from it.
E.g., assume I have a
struct blah {
int sum;
...
};
which is accessed by my assembly code.
int my_chksu
I am still seeing errors such as this bootstrapping trunk with -Werror.
I thought all of this was supposed to be resolved?
../../svn/gcc/bt-load.c: In function 'migrate_btr_defs':
../../svn/gcc/bt-load.c:1415: error: ISO C does not support the 'I64'
ms_printf length modifier
What needs to be
Aaron W. LaFramboise wrote:
I am still seeing errors such as this bootstrapping trunk with -Werror.
I thought all of this was supposed to be resolved?
OK, this is http://gcc.gnu.org/PR25502
Sorry for the noise.
Apparently the reason this has gone on so long is that most people are
crossbuil
10 matches
Mail list logo
