On Fri, 30 Sep 2011, Andrew MacLeod wrote:
I've been working on GCC's C++11 atomic implementation.
Cool!
In discussions with
Lawrence, I've recently discovered a fundamental change in what libstdc++-v3
is likely to provide as far as an implementation.
Previously, header files provided a c
> Hi,
>
> I was having a look to this long standing, and unconfirmed, PR:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36778
>
> and the rationale makes sense to me. What do you think, shall we have
> -Wfatal-warnings too, together with -Wfatal-errors?
>
> AFAICS, the patch would be rat
Hi,
I was having a look to this long standing, and unconfirmed, PR:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36778
and the rationale makes sense to me. What do you think, shall we have
-Wfatal-warnings too, together with -Wfatal-errors?
AFAICS, the patch would be rather trivial, littl
I'm planning to support some new instructions found in recent sparc
cpus, specifically VIS 3.0 adds a series of "X and halve"
floating-point instructions where X is one of "add" or "subtract".
There are variants which negate the result as well.
They operate similar to FMA in that all the operati
Snapshot gcc-4.6-20110930 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110930/
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
I've been working on GCC's C++11 atomic implementation. In discussions
with Lawrence, I've recently discovered a fundamental change in what
libstdc++-v3 is likely to provide as far as an implementation.
Previously, header files provided a choice between a locked or a
lock-free implementation,
Paolo Bonzini schrieb:
> On 09/28/2011 02:14 PM, Georg-Johann Lay wrote:
>> This leads to unpleasant code. The machine can access all RAM
>> locations by
>> direct addressing. However, the resulting code is:
>>
>> foo:
>> ldi r24,lo8(-86) ; 6*movqi/2[length = 1]
>> ldi r30,lo8(
On 09/28/2011 02:14 PM, Georg-Johann Lay wrote:
This leads to unpleasant code. The machine can access all RAM locations by
direct addressing. However, the resulting code is:
foo:
ldi r24,lo8(-86) ; 6 *movqi/2[length = 1]
ldi r30,lo8(-64) ; 34 *movhi/5
Art Haas writes:
> I've had no success lately getting GCC to bootstrap successfully. My
> last successful bootstrap was on September 6; my builds on September
> 7 through today all end with a comparison failure. Here's the end
> of my build log:
>
> gmake[2]: Entering directory `/export/home/arth
