On 02/13/2012 08:00 PM, Geert Bosch wrote:
> GNU Linux is quite good, but has issues with the "pow" function for
> large exponents, even in current versions
Really? Even on 64-bit? I know this is a problem for the 32-bit
legacy architecture, but I thought the 64-bit pow() was OK.
Andrew.
Hello,
the default ARM EABI configuration uses short enums by default (from
"gcc/config/arm/arm.c":
/* AAPCS based ABIs use short enums by default. */
static bool
arm_default_short_enums (void)
{
return TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAPCS_LINUX;
}
This causes a major headache f
On 2012-02-13 15:00:54 -0500, Geert Bosch wrote:
> Properties:
>
> [ ] Conforms to C99 for exceptional values
>(accepting/producing NaNs, infinities)
>
> [ ] Handles non-default rounding modes,
>trapping math, errno, etc.
>
> [ ] Requires IEEE compliant binary64 arithme
On 2012-02-14 09:51:28 +, Andrew Haley wrote:
> On 02/13/2012 08:00 PM, Geert Bosch wrote:
> > GNU Linux is quite good, but has issues with the "pow" function for
> > large exponents, even in current versions
>
> Really? Even on 64-bit? I know this is a problem for the 32-bit
> legacy archit
On 02/14/2012 04:51 AM, Andrew Haley wrote:
On 02/13/2012 08:00 PM, Geert Bosch wrote:
GNU Linux is quite good, but has issues with the "pow" function for
large exponents, even in current versions
Really? Even on 64-bit? I know this is a problem for the 32-bit
legacy architecture, but I thou
On 2012-02-14 14:26:05 +0100, Vincent Lefevre wrote:
> On 2012-02-14 09:51:28 +, Andrew Haley wrote:
> > On 02/13/2012 08:00 PM, Geert Bosch wrote:
> > > GNU Linux is quite good, but has issues with the "pow" function for
> > > large exponents, even in current versions
> >
> > Really? Even on
On 02/14/2012 08:26 AM, Vincent Lefevre wrote:
On 2012-02-14 09:51:28 +, Andrew Haley wrote:
On 02/13/2012 08:00 PM, Geert Bosch wrote:
GNU Linux is quite good, but has issues with the "pow" function for
large exponents, even in current versions
Really? Even on 64-bit? I know this is a
Sebastian Huber writes:
> the default ARM EABI configuration uses short enums by default (from
> "gcc/config/arm/arm.c":
>
> /* AAPCS based ABIs use short enums by default. */
>
> static bool
> arm_default_short_enums (void)
> {
> return TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAPCS_LINUX;
>
On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:
Sebastian Huber writes:
the default ARM EABI configuration uses short enums by default (from
"gcc/config/arm/arm.c":
/* AAPCS based ABIs use short enums by default. */
static bool
arm_default_short_enums (void)
{
return TARGET_AAPCS_BASED&&
On Feb 14, 2012, at 08:22, Vincent Lefevre wrote:
> Please do not use the term binary80, as it is confusing (and
> there is a difference between this format and the formats of
> the IEEE binary{k} class concerning the implicit bit).
Yes, I first wrote extended precision, though that really is
a ge
On 02/14/2012 04:41 PM, Geert Bosch wrote:
> Right now we don't have a library either that conforms to C99
Are you sure? As far as I know we do. We might not meet
C99 Annex F, but that's not required.
> and meets the far more relaxed accuracy criteria of OpenCL and
> Ada.
Andrew.
On Feb 14, 2012, at 11:44, Andrew Haley wrote:
> On 02/14/2012 04:41 PM, Geert Bosch wrote:
>> Right now we don't have a library either that conforms to C99
>
> Are you sure? As far as I know we do. We might not meet
> C99 Annex F, but that's not required.
>
>> and meets the far more relaxed
On 02/14/2012 04:54 PM, Geert Bosch wrote:
>
> On Feb 14, 2012, at 11:44, Andrew Haley wrote:
>
>> On 02/14/2012 04:41 PM, Geert Bosch wrote:
>>> Right now we don't have a library either that conforms to C99
>>
>> Are you sure? As far as I know we do. We might not meet
>> C99 Annex F, but that'
Sebastian Huber writes:
> On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:
>> Sebastian Huber writes:
>>
>>> the default ARM EABI configuration uses short enums by default (from
>>> "gcc/config/arm/arm.c":
>>>
>>> /* AAPCS based ABIs use short enums by default. */
>>>
>>> static bool
>>> arm_def
>spill_failure does return for asms since we don't want to ICE on bad
>user code. That's all that's going on here.
ahh, thanks.
>It sounds like ifcvt needs to be fixed. Your example:
>> block 44:
>> set cc = x;
>> set cc = y; (*)
>> if cc jump;
>
>looks like an invalid transformation, but I suspe
On Feb 13, 2012, at 09:59, Vincent Lefevre wrote:
> On 2012-02-09 15:49:37 +, Andrew Haley wrote:
>> I'd start with INRIA's crlibm.
>
> I point I'd like to correct. GNU MPFR has mainly (> 95%) been
> developed by researchers and engineers paid by INRIA. But this
> is not the case of CRlibm.
Hello,
first of all, let me apologize for my late answer to this very exciting
email thread.
As pointed out several times, the current libm suffers from several
disadvantages:
* The current libm code is a mix of codes coming from different sources,
with tables generated by different people
On 02/14/2012 06:54 PM, Christoph Lauter wrote:
> My colleagues Jean-Michel Muller, Florent de Dinechin at École Normale
> Supérieure de Lyon/ INRIA/ CNRS and myself at Université Pierre et Marie
> Curie, Paris Sorbonne, we have been thinking of starting such a project
> for quite a while. We've
Hi,
I was trying to compile gcc-4.7 snapshots on Debian GNU/Linux wheezy
(testing/unstable) i386, and found problem releated to multiarch.
This is my configure and compile script:
unset LC_ALL
unset LANG
export TEMP=/scratch/baryluk/gcc/tmp
export TMP=/scratch/baryluk/gcc/tmp
export TMPDIR=/scr
On 14 February 2012 22:26, Witold Baryluk wrote:
>
> I was trying to compile gcc-4.7 snapshots on Debian GNU/Linux wheezy
> (testing/unstable) i386, and found problem releated to multiarch.
This is a known issue with Debian that has been discussed several
times on the gcc and gcc-help lists, most
Snapshot gcc-4.4-20120214 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20120214/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Tue, Feb 14, 2012 at 10:35:16PM +, Jonathan Wakely wrote:
> On 14 February 2012 22:26, Witold Baryluk wrote:
> >
> > I was trying to compile gcc-4.7 snapshots on Debian GNU/Linux wheezy
> > (testing/unstable) i386, and found problem releated to multiarch.
>
> This is a known issue with Debi
On Tue, 14 Feb 2012, Geert Bosch wrote:
> However, the glibc math library comes very close, and we can
> surely fix any remaining issues there may be. So, if we can
> use that as base, or as "fallback" library, we suddenly
> achieve some minimal accuracy guarantees across a wide
> range of platfor
Witold Baryluk writes:
> On Tue, Feb 14, 2012 at 10:35:16PM +, Jonathan Wakely wrote:
>> On 14 February 2012 22:26, Witold Baryluk wrote:
>> >
>> > I was trying to compile gcc-4.7 snapshots on Debian GNU/Linux wheezy
>> > (testing/unstable) i386, and found problem releated to multiarch.
>>
>
On 02-14 17:34, Ian Lance Taylor wrote:
> Witold Baryluk writes:
>
> > On Tue, Feb 14, 2012 at 10:35:16PM +, Jonathan Wakely wrote:
> >> On 14 February 2012 22:26, Witold Baryluk wrote:
> >> >
> >> > I was trying to compile gcc-4.7 snapshots on Debian GNU/Linux wheezy
> >> > (testing/unstable
On 02/14/2012 06:51 PM, Ian Lance Taylor wrote:
Sebastian Huber writes:
On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:
Sebastian Huber writes:
the default ARM EABI configuration uses short enums by default (from
"gcc/config/arm/arm.c":
/* AAPCS based ABIs use short enums by default. */
26 matches
Mail list logo
