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. */
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
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 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
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
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 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
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 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
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 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.
>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
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
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'
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: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 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: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&&
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 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
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 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 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 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
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 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.
26 matches
Mail list logo
