On Tue, Dec 18, 2012 at 2:39 PM, Arthur Schwarz wrote:
>
> I have run some tests to determine the gcc 4.5.3 integer promotion policies.
This message is not appropriate for the mailing list gcc@gcc.gnu.org,
which is for the development of GCC itself. It would be appropriate
on the mailing list g
Hi,
I am trying to submit my x32 extension to x86-64 discussion
mailing list. But my email was bounced back. Do we need
a more reliable place for x86-64 psABI?
H.J.
-- Forwarded message --
From: Mail Delivery Subsystem
Date: Fri, Dec 7, 2012 at 1:02 PM
Subject: Delivery Status
My primary concern centers whether any 386 w/o fpu IP cores or space hardened
i386dx/sx or 486sx CPUs are impacted. These could be used in new designs.
This also eliminates gcc from use on any older embedded x86 boards w/o fpu.
RTEMS still supports these but depends on gcc as the foundation. We
On Wed, 12 Dec 2012, Steven Bosscher wrote:
> Linux support for i386 has been removed. Should we do the same for GCC?
FWIW, glibc hasn't really supported i386 for several years (at least with
the Linux kernel; I don't know about Hurd), since NPTL requires atomic
operations that i386 doesn't hav
On Fri, 14 Dec 2012, Michael Zolotukhin wrote:
> Currently, I think the problem could be tackled in the following way:
> In gimple we'll need to add a pass that would a) find regions with
> constant, compile-time known rounding mode, b) replace operations with
> subcodes like plus/minus/div/etc. w
Cygwin gcc 4.5.3
I have run some tests to determine the gcc 4.5.3 integer promotion policies.
The
tests show that for 'char' input, "char << long" and "char >> long" promote to
INT while other operations using a long promote to" long", and that "char <<
ulong" and "char >> ulong" promote to I
The official DJGPP triplet is for i586, not i386. I don't mind
djgpp-wise if we deprecate i386, as long as we keep i586. Anyone
still using djgpp for i386 can dig out old versions from the archives :-)
On Tue, Dec 18, 2012 at 8:38 AM, Andris Pavenis wrote:
> On 12/12/2012 11:07 PM, David Brown wrote:
>>
>> On 12/12/12 20:54, Robert Dewar wrote:
>>>
>>> On 12/12/2012 2:52 PM, Steven Bosscher wrote:
>>>
And as usual: If you use an almost 30 years old architecture, why
would you need the
On 12/12/2012 11:07 PM, David Brown wrote:
On 12/12/12 20:54, Robert Dewar wrote:
On 12/12/2012 2:52 PM, Steven Bosscher wrote:
And as usual: If you use an almost 30 years old architecture, why
would you need the latest-and-greatest compiler technology?
Seriously...
Well the embedded folk of
On Tue, Dec 18, 2012 at 4:34 PM, Richard Henderson wrote:
> On 12/14/2012 04:20 AM, Richard Biener wrote:
>> Exposing known rounding modes as new operation codes may sound like
>> a good idea (well, I went a similar way with trying to make operations with
>> undefined overflow explicit ... but the
On 12/14/2012 04:20 AM, Richard Biener wrote:
> Exposing known rounding modes as new operation codes may sound like
> a good idea (well, I went a similar way with trying to make operations with
> undefined overflow explicit ... but the fallout was quite large even though
> there is only one kind of
On Fri, 14 Dec 2012, Michael Zolotukhin wrote:
I found quite an old bug PR34768 and was thinking of doing what was
suggested there.
Wrong bug number? 34678 probably.
Particularly, I was wondering about adding new subcodes to gimple and
rtl for describing operations with rounding.
Currently,
On 18 December 2012 03:06, ETANI NORIKO wrote:
>
> Of course, we can use GCC on a host core, and we can use MPFR and GMP.
> However, as long as we use LD to link object files and create a binary file
> for a computing device core, we cannot use MPFR and GMP.
>
> Here, we would like to ask you as
Just a quick note that the proposals deadline for the C++Now 2013
conference has been extended to January 5th:
http://cppnow.org/2013-call-for-submissions/
C++Now is the largest general C++ conference, that is, it is not specific
to any library/framework or compiler vendor. C++Now has three track
14 matches
Mail list logo
