On Thu, 13 Dec 2012, John Marino wrote:
> FreeBSD ports have every modern version of GCC in them, nothing stops a
> user from building and using the latest GCC on FreeBSD (Note the ports
> are well maintained).
Thanks, John. :-) (Note to those not aware I am taking care of those.)
On Thu, 13 D
On 12/14/2012 10:09 PM, Richard Biener wrote:
On Fri, Dec 14, 2012 at 9:16 PM, Robert Dewar wrote:
On 12/14/2012 3:13 PM, Cynthia Rempel wrote:
Hi,
RTEMS still supports the i386, and there are many i386 machines still
in use. Deprecating the i386 will negatively impact RTEMS ability to
supp
On 12/14/2012 09:16 PM, Robert Dewar wrote:
On 12/14/2012 3:13 PM, Cynthia Rempel wrote:
Hi,
RTEMS still supports the i386, and there are many i386 machines still
in use. Deprecating the i386 will negatively impact RTEMS ability to
support the i386. As Steven Bosscher said, the "benefits" are
Hi Richard Biener and Robert Dewar,
Thanks for the fast response, I really appreciate it!
I'll look into gcc-testresults for an i386, now that I know it's a requirement
to keep a port live.
I compile, and run, RTEMS for the pc386 RTEMS target regularly, so I know the
4.7 cross-compiler does th
On 14 December 2012 21:58, Jonathan Wakely wrote:
> Gerald did ask me to update the libstdc++ docs but I didn't (and I'm
> still not sure what the consensus was regarding which link to use.)
Actually the right fix for the libstdc++ docs seems pretty obvious,
I'll do it tomorrow.
Snapshot gcc-4.6-20121214 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20121214/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 14 December 2012 21:51, Joe Buck wrote:
> Richard Henderson writes:
>> On
>> http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
>> we have a stale link to
>> http://www.codesourcery.com/public/cxx-abi/abi.html
>
>>What's the new canonical location for this document?
>
> Looks like CodeSou
Richard Henderson writes:
> On
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
> we have a stale link to
> http://www.codesourcery.com/public/cxx-abi/abi.html
>What's the new canonical location for this document?
Looks like CodeSourcery is being assimilated into Mentor. The parent di
On
http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
we have a stale link to
http://www.codesourcery.com/public/cxx-abi/abi.html
What's the new canonical location for this document?
r~
On Fri, Dec 14, 2012 at 9:16 PM, Robert Dewar wrote:
> On 12/14/2012 3:13 PM, Cynthia Rempel wrote:
>>
>> Hi,
>>
>> RTEMS still supports the i386, and there are many i386 machines still
>> in use. Deprecating the i386 will negatively impact RTEMS ability to
>> support the i386. As Steven Bossche
Having read this whole thread, Ivote for deprecating the 386.
People using this ancient architecture can perfectly well use
older versions of gcc that have this support.
On 12/14/2012 3:13 PM, Cynthia Rempel wrote:
Hi,
RTEMS still supports the i386, and there are many i386 machines still
in use. Deprecating the i386 will negatively impact RTEMS ability to
support the i386. As Steven Bosscher said, the "benefits" are small,
and the impact would be serious for R
Hi,
RTEMS still supports the i386, and there are many i386 machines still in use.
Deprecating the i386 will negatively impact RTEMS ability to support the i386.
As Steven Bosscher said, the "benefits" are small, and the impact would be
serious for RTEMS i386 users.
Thanks!
Cynthia Rempel
___
On Fri, 14 Dec 2012, Richard Earnshaw wrote:
Sun/Oracle has never, to my knowledge used GCC as it's primary compiler.
I believe they have (early solaris 10), but that was on x86_64, not sparc
(which is the one in the primary platform list).
--
Marc Glisse
On Fri, Dec 14, 2012 at 12:16 PM, Michael Zolotukhin
wrote:
> Hi,
> I found quite an old bug PR34768 and was thinking of doing what was
> suggested there.
> Particularly, I was wondering about adding new subcodes to gimple and
> rtl for describing operations with rounding.
>
> Currently, I think t
On 13/12/12 11:24, Steven Bosscher wrote:
On Thu, Dec 13, 2012 at 11:43 AM, John Marino wrote:
I don't speak for FreeBSD, but dropping them from Tier 1 support because
they don't use a GPLv3 *BASE* compiler is a bit vindictive.
FreeBSD has dropped GCC for future releases so there's no reason f
On 12/14/2012 10:03 AM, Erik Trulsson wrote:
Well, the Intel 80486sx did not have an FPU either, while the 80486dx
did have one. From the Pentium (i586) onwards all Intel x86 CPUs have
been equipped with an FPU, so not having an FPU would fit in with being
compatible with i486 but not the i586.
Hi Uros,
When we have a code like X++ (either RMW, or a regular increment) it
is enough for asan to instrument it just once (either as a read or a
write, doesn't matter).
LLVM implementation does this optimization for regular increments,
while GCC does not (yet).
% cat inc.cc
void foo(int *a) {
Hello!
c-c++-common/asan/null-deref-1.c test can generate read-modify-write
instruction ("incl 40(%eax)") when compiled with -Os. However,
address-sanitizer only calls __asan_report_load4 in this case. With
-O2, load of value, modification and store are different instructions,
and address-sanitize
Quoting Ralf Corsepius :
On 12/13/2012 04:53 PM, Erik Trulsson wrote:
Quoting Ralf Corsepius :
On 12/12/2012 08:54 PM, 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
20 matches
Mail list logo
