On 10/02/2012 05:45 AM, Richard Guenther wrote:
I expect stage1 to close mid to end of October (after which it lasted
for more than 7 months).
Btw, I realize that the aarch64 port probably also wants to merge even if
I didn't see a merge proposal or know whether they have patches to
generic
On 11/15/2012 07:59 PM, Diego Novillo wrote:
At this point, we are trying to reach consensus on the general
direction that we should take. Given how intertwined GC and PCH
are, the choices we make for one affect the other.
We don't have a strong preference at the moment, but we are
leaning in
On 11/19/2012 08:24 PM, Lawrence Crowl wrote:
On 11/16/12, Diego Novillo dnovi...@google.com wrote:
On Nov 16, 2012 Basile Starynkevitch bas...@starynkevitch.net wrote:
I actually disagree with the Get rid of GC idea, but I am not
sure that we all understand the same thing about it (and I have
On 11/14/2012 08:13 PM, Lawrence Crowl wrote:
Diego and I seek your comments on the following (loose) proposal.
We propose a simplified form using new build helper classes ssa_seq
and ssa_stmt that would allow the above code to be written as
follows.
ssa_seq q;
ssa_stmt t = q.stmt (NE_EXPR,
On 11/14/2012 08:12 PM, Lawrence Crowl wrote:
Diego and I seek your comments on the following (loose) proposal.
We propose to provide several function overload sets, as below.
dump_pretty
This function overload set provides the bulk of the printing.
They will use the existing
On 11/22/2012 01:18 PM, Lawrence Crowl wrote:
I have found that tree-flow.h implements iteration over htab_t,
while there is no current facility to do that with hash_table.
Unfortunately, the specific form does not match the standard C++
approach to iterators. We have several choices.
(1)
[ I foolishly sent this with the document as an attachment... hopefully
it gets rejected and anyone interested can simply download the document
from the wiki..]
Over the past couple of months, I've slowly been putting together an
action plan to help modernize GCC's source base. We've had
On 06/21/2013 11:27 AM, Andrew MacLeod wrote:
I hope this link will work :-)...
http://gcc.gnu.org/wiki/AndrewMacLeod?action=AttachFiledo=viewtarget=gccrestructureplan2.1.odt
Highlander
or you can use this PDF file...
http://gcc.gnu.org/wiki/AndrewMacLeod?action=AttachFiledo=viewtarget
On 06/21/2013 12:16 PM, Joseph S. Myers wrote:
A few observations:
* You don't mention anything about separating host-side and target-side
configuration, which are also entangled. A slightly out-of-date list of
target macros used in target-side code is at
In case anyone is planning to attend the BOF on Sunday and missed the
proposal document posted last month, it can be found here:
http://gcc.gnu.org/wiki/AndrewMacLeod?action=AttachFiledo=viewtarget=gccrestructureplan2.1.pdf
Andrew
On 07/30/2013 08:27 AM, Marek Polacek wrote:
On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek pola...@redhat.com wrote:
On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
I do not care very much but I disagree. Having
On 08/09/2013 12:59 PM, Joe Buck wrote:
On Fri, Aug 09, 2013 at 11:23:51AM -0500, Joel Sherrill wrote:
On 8/9/2013 11:05 AM, Deng Hengyi wrote:
Hi Joel,
I have done a test, it seems that '-march=i386' does not provide
__atomic_compare_exchange_n libs. And '-march=i486' or '-march=pentium'
A number of header files have inline functions declared in them. Some of
these functions are actually quite large, and I doubt that inlining them
is the right thing. For instance, tree-flow-inline.h has some quite
large functions. Many of the op_iter* functions are 30-40 lines long,
and
On 09/10/2013 04:44 AM, Richard Biener wrote:
On Tue, Sep 10, 2013 at 10:11 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote:
This last point is crucial. I haven't looked at the code in question,
but one point to check is how the functions
I don't have the time to finish pushing through the C11 atomic work for
this release. Much of the remaining parts are in the parser, which I
know very little about, and I won't be able to do a sufficient job in
the time remaining, so I am switching my focus to the interface work and
getting
On 10/02/2013 03:29 PM, Paolo Carlini wrote:
Hi,
currently bootstrap is broken for me with errors of this kind:
/scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c: In function
‘void canonicalize_loop_closed_ssa(loop_p)’:
On 10/02/2013 03:33 PM, Andrew MacLeod wrote:
On 10/02/2013 03:29 PM, Paolo Carlini wrote:
Hi,
currently bootstrap is broken for me with errors of this kind:
/scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c: In
function ‘void canonicalize_loop_closed_ssa(loop_p)’:
/scratch/Gcc/svn
On 10/02/2013 03:55 PM, Paolo Carlini wrote:
.. patchlet worked for me. Thanks again!
NP.. , all checked in.
thanks for testing it.
Andrew
The tree-flow.h restructuring now brings us to the larger question of
exactly how we want includes organized. All the remaining includes in
tree-ssa.h are required by numerous other .c files. The actual number of
.c files which will need to #include any given file is:
(roughly calculated by
On 10/18/2013 12:55 PM, Jeff Law wrote:
On 10/18/13 08:00, Andrew MacLeod wrote:
The question is... Do we allow a .h file like this to be an aggregator,
meaning a file can just include tree-ssa.h and get all this, or do we
push it all down to the .c file, and actually include what each one
On 10/22/2013 08:27 AM, Joern Rennecke wrote:
On 18 October 2013 19:16, Andrew MacLeod amacl...@redhat.com wrote:
So I think I am in favour of no includes in .h files... It may make it more
obvious when a file is using some other inappropriate file for something,
and it is easier for my simple
on a related note, is there something I have to do to make the compiler
bootstrap on x86_64?
on x86_64 I checked out a fresh branch this morning, and my bootstrap
fails trying to configure cilk runtime. It was doing it yesterday to me
when I updated, so I tried a fresh checkout this
On 10/31/2013 12:05 PM, Iyer, Balaji V wrote:
-Original Message-
From: Andrew MacLeod [mailto:amacl...@redhat.com]
Sent: Thursday, October 31, 2013 11:44 AM
To: Iyer, Balaji V
Cc: 'gcc@gcc.gnu.org'; Jeff Law
Subject: Re: Question about a fix for PR 58925
on a related note
On 10/31/2013 12:13 PM, Andrew MacLeod wrote:
On 10/31/2013 12:05 PM, Iyer, Balaji V wrote:
-Original Message-
From: Andrew MacLeod [mailto:amacl...@redhat.com]
Sent: Thursday, October 31, 2013 11:44 AM
To: Iyer, Balaji V
Cc: 'gcc@gcc.gnu.org'; Jeff Law
Subject: Re: Question about
On 10/31/2013 01:02 PM, Andrew MacLeod wrote:
On 10/31/2013 12:13 PM, Andrew MacLeod wrote:
There isnt much difference in the log or status files... nothing real
obvious. ie, no fails or anything... still looking... I *hate*
configuration crud. sigh.
Andrew
OK, hacking around
On 10/31/2013 03:31 PM, Andrew MacLeod wrote:
On 10/31/2013 01:02 PM, Andrew MacLeod wrote:
On 10/31/2013 12:13 PM, Andrew MacLeod wrote:
but the file is in the correct directory:
/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so
- libstdc++.so.6.0.19
/gcc
On 11/01/2013 10:45 AM, Diego Novillo wrote:
On Wed, Oct 30, 2013 at 10:26 PM, Andrew MacLeod amacl...@redhat.com wrote:
I've made 4 attempts now to split gimple.[ch] into reasonable component
parts, and I've finally found something that I can make work and fits my
plans.
I've attached
On 11/01/2013 10:59 AM, Diego Novillo wrote:
On Fri, Nov 1, 2013 at 10:56 AM, Andrew MacLeod amacl...@redhat.com wrote:
Isnt gimplify clear to everyone? :-) I've even been referring to an
interface to the backend target info for the front end as targetify lately
:-)
Yes, but only when we
On 11/01/2013 11:17 AM, Diego Novillo wrote:
On Fri, Nov 1, 2013 at 11:11 AM, Andrew MacLeod amacl...@redhat.com wrote:
Longer term... the BE will not be calling into gimplify at all.. it will be
purely a front end thing. As direct tree access vanishes, the optimizers
will be forced
On 12/18/2013 08:08 AM, Diego Novillo wrote:
On Wed, Dec 18, 2013 at 6:57 AM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
Would it be better to include tree.h instead of tree-core.h (tree.h
includes tree-core.h anyway), or shall I leave these macros untouched
?
Better leave these
On 03/19/2014 05:08 AM, Richard Biener wrote:
On Tue, Mar 18, 2014 at 5:34 PM, Diego Novillo dnovi...@google.com wrote:
On Tue, Mar 18, 2014 at 10:19 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Jun 21, 2013 at 5:27 PM, Andrew MacLeod amacl...@redhat.com wrote:
[ I foolishly
On 06/18/2014 12:59 PM, Basile Starynkevitch wrote:
Hello All,
The following code:
#include stdlib.h
struct s1_st {
char* i_name;
struct s1_st* i_foo;
};
void clear_s1 (struct s1_st*s)
{
__atomic_store(s-i_name, NULL, __ATOMIC_SEQ_CST);
}
gives an
On 07/09/2014 02:17 AM, Tobias Burnus wrote:
Hello all,
I am trying to use BUILT_IN_ATOMIC_..., but it does not quite work. I
am calling them as:
tmp = builtin_decl_explicit (BUILT_IN_ATOMIC_LOAD_4);
tmp = build_call_expr_loc (input_location, tmp, 2, atom.expr, ...
That gives the
On 08/05/2014 10:21 AM, Prathamesh Kulkarni wrote:
Hi,
I have written notes on GCC re-architecture BOF
presented at the Cauldron. I would be grateful if you would
review it for me.
Seems to cover the core parts well... all subject to change as we go
tho :-)
initial focus wlll be the
During the re-architecture session at Cauldron, I mentioned the
possibility of introducing a plugin-headers.h.
This would be a file which plugins could use which would protect them
somewhat from header file restructuring. The idea is that it includes
all the common things plugins need, (like
On 09/15/2014 02:18 PM, Andrew MacLeod wrote:
During the re-architecture session at Cauldron, I mentioned the
possibility of introducing a plugin-headers.h.
This would be a file which plugins could use which would protect them
somewhat from header file restructuring. The idea
On 11/13/2014 05:45 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm dmalc...@redhat.com wrote:
On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 10, 2014 at 05:27:50PM -0500,
On 11/13/2014 09:34 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 3:24 PM, Andrew MacLeod amacl...@redhat.com wrote:
On 11/13/2014 05:45 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm dmalc...@redhat.com
wrote:
On Tue, 2014-11-11 at 11:43 +0100, Richard Biener
I was poking around attribs.c while trial running my tree-type-safety
stuff, and it triggered something in decl_attributes() that seems fishy
to me. It looks like it was part of the fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315
decl_attributes() can be passed a tree node which
On 11/18/2014 09:52 AM, Andrew MacLeod wrote:
On 11/18/2014 09:40 AM, Jason Merrill wrote:
On 11/18/2014 09:26 AM, Andrew MacLeod wrote:
I was poking around attribs.c while trial running my tree-type-safety
stuff, and it triggered something in decl_attributes() that seems fishy
to me
On 11/18/2014 01:36 PM, Jeff Law wrote:
On 11/18/14 09:30, Andrew MacLeod wrote:
I tried doing the if before chaning to TREE_TYPE... absolutely no
effect on the testsuite or anything else :-)
What do you think, should I check this in? What is there is clearly
incorrect.we could also
On Wed, 2007-06-20 at 14:19 -0400, Diego Novillo wrote:
gs_assign_unary_rhs (gs) - Access the only operand on RHS
gs_assign_binary_rhs1 (gs)- Access the 1st RHS operand
gs_assign_binary_rhs2 (gs)- Access the 2nd RHS operand
And the corresponding _set functions.
I then
On Fri, 2007-08-17 at 12:01 -0400, Kenneth Zadeck wrote:
In any case IRA can not use UREC because UREC is needed before IRA
calculates reg class info and the reg class info is needed for
calculation of UREC. If you manage to use LIVE instead of UREC, it
would permit to use LIVE also in
Pranav Bhandarkar wrote:
Hi,
In the attached testcase due to an ivopts modification, while
rewriting the uses the compiler crashes in tree-ssa-operands.c because
the number of virtual operands of the modified stmt is much greater
than the thresholds controlled by OP_SIZE_{1,2,3} in
Now that GCC is in stage 4.3, I think we'd all be in agreement that it
would be nice to keep this stage short and get a release out.
We are interested in using 4.3 as the system compiler in Fedora 9, and
as such, we'd like to nail down some time lines and requirements with
release
Richard Guenther wrote:
On 10/26/07, Andrew MacLeod [EMAIL PROTECTED] wrote:
Now that GCC is in stage 4.3, I think we'd all be in agreement that it
would be nice to keep this stage short and get a release out.
We are interested in using 4.3 as the system compiler in Fedora 9
Mark Mitchell wrote:
Andrew MacLeod wrote:
we can at least make projected dates known so we have something firmer
than at some point in the future :-)
As RM, I try to take into account what I know about when distributors
will be applying effort, but I must absolutely avoid in any way
Benjamin Kosnik wrote:
I'd rather take the make the dot-zero release approach while branching
and count on interested people fixing bugs on the branch after the
dot-zero release. This way if nobody is interested on a particular
release series then we can declare the dot-zero release final -
Jason Merrill wrote:
Andrew MacLeod wrote:
But yes, Id still be in favour of trying this or anything else which
might help. Cut a release branch, and simply refuse to open stage 1
until we release.
I think I prefer Richard's suggestion of not branching until we're
ready to make the .0
Richard Guenther wrote:
Sure, I think it boils down to the same thing from a conceptual point of
view, but perhaps the nitty gritty details are easier if you keep it as
mainline so we dont have to check everything into 2 branches. Bottom
line is you freeze development until its time to release.
Gerald Pfeifer wrote:
On Mon, 29 Oct 2007, Jason Merrill wrote:
I think I prefer Richard's suggestion of not branching until we're ready to
make the .0 release. The effect should be the same except that people don't
have to deal with checking patches in on the branch vs. the trunk until
Andrew Pinski wrote:
On 10/26/07, Andrew MacLeod [EMAIL PROTECTED] wrote:
Now that GCC is in stage 4.3, I think we'd all be in agreement that it
would be nice to keep this stage short and get a release out.
Let me suggest something which is going sound a little crazy.
Create a beta
Jack Lloyd wrote:
On Thu, Nov 01, 2007 at 09:50:00AM -0700, Andrew Pinski wrote:
Create a beta that is released now and then release one once (or
twice) a month until we release 4.3. This is seperate from a release
candidate and the snapshot. The beta is get attention from some folks
that
Zdenek Dvorak wrote:
Hello,
during a recent discussion, it was pointed to my attention that
update_stmt is performance critical. I wondered why; this is the number
of update_stmt calls for combine.i (all the other passes have less then
1000 calls):
...
I have a patch that decreases
Daniel Berlin wrote:
Here is the easy one:
z_5 = a_3 + b_3
x_4 = z_5 + c_3
DEBUG(x, x_4)
Reassoc may transform this into:
z_5 = c_3 + b_3
x_4 = z_5 + a_3
DEBUG(x, x_4)
Now x has the wrong value.
??
x_4 looks like it has the value 'a_3 + b_3 + c_3' in both examples to
me, although
It gets worse, however
c_3 = a_1 + b_2
z_5 = c_3 + d_9
x_4 = z_5 + e_10
DEBUG(x, x_4)
y_7 = x_4 + f_11
z_8 = y_7 + g_12
-
c_3 = a_1 + b_2
z_5 = c_3 + g_12
x_4 = z_5 + e_10
DEBUG(x, x_4)
y_7 = x_4 + f_11
z_8 = y_7 + d_9
x_4 now no longer represents the value of x, but we haven't directly
There are a few things that I'm considering working on for the 4.4
release, and I figured I'd see what others thought. Is anyone
considering/doing similar or related work?
I'll summarize each, and then go into more details.
1 - Pass cleanup. There have been rumblings about this, but I
Diego Novillo wrote:
On Fri, Feb 1, 2008 at 3:55 PM, Andrew MacLeod [EMAIL PROTECTED] wrote:
1 - Pass cleanup. There have been rumblings about this, but I haven't
Yes, this is an area that is in desperate need of TLC. Your plan
looks good to me. We need to have a mechanism
Kenneth Zadeck wrote:
Birthpoints are not nearly as useful as phi-functions because the
algorithms that use birthpoints do not generally leave the birthpoints
in the right places when they are finished. There is a lot of value
added by the operand of phi-functions. But they do solve the n**2
On 09/09/2011 03:09 AM, Jakub Jelinek wrote:
In particular, is transactional-memory branch mergeable within
a month and half, at least some parts of cxx-mem-model branch,
There will certainly be some parts of the branch which would be
appropriate for merging with mainline in october. We
On 09/09/2011 04:17 AM, Jakub Jelinek wrote:
On Fri, Sep 09, 2011 at 10:07:30AM +0200, Paolo Bonzini wrote:
sync builtins are described in the documentations as being full
memory barriers, with the possible exception of
__sync_lock_test_and_set. However, GCC is not enforcing the fact
that they
On 09/09/2011 09:09 PM, Geert Bosch wrote:
For the C++0x atomic types there are:
void A::store(C desired, memory_order order = memory_order_seq_cst) volatile;
void A::store(C desired, memory_order order = memory_order_seq_cst);
where the first variant (with order = memory_order_relaxed)
would
On 09/11/2011 02:22 PM, Paolo Bonzini wrote:
On 09/11/2011 04:12 PM, Andrew MacLeod wrote:
tail-value = othervalue // global variable write
atomic_exchange (var, tail) // acquire operation
although the optimizer moving the store of tail-value to AFTER the
exchange
On 09/12/2011 02:40 PM, Geert Bosch wrote:
thread 1 thread 2 thread 3 thread 4
x=1; r1=x x=3; r3=x;
x=2; r2=x x=4; r4=x;
Even with relaxed memory ordering, all modifications to x have to occur in some
particular
On 09/12/2011 09:52 PM, Geert Bosch wrote:
No that's false. Even on systems with nice memory models, such as x86 and SPARC
with a TSO model, you need a fence to avoid that a write-load of the same
location is forced to make it all the way to coherent memory and not forwarded
directly from
On 09/13/2011 10:58 AM, Geert Bosch wrote:
On Sep 13, 2011, at 08:08, Andrew MacLeod wrote:
On 09/12/2011 09:52 PM, Geert Bosch wrote:
No that's false. Even on systems with nice memory models, such as x86 and SPARC
with a TSO model, you need a fence to avoid that a write-load of the same
Hi,
On Tue, 13 Sep 2011, Andrew MacLeod wrote:
Your example was not about regular stores, it used atomic variables.
This reads as if there exists non-atomic variables in the new C++
mem-model. Assuming that this is so, why do those ugly requirements of
not introducing new data races also
On 09/26/2011 01:31 PM, James Dennett wrote:
On Mon, Sep 26, 2011 at 9:57 AM, Andrew MacLeodamacl...@redhat.com wrote:
The C++11 memory model asserts that a program containing data races
involving *non-atomic* variables has undefined semantics. The compiler is
not allowed to introduce any
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,
On 10/01/2011 02:55 AM, Marc Glisse wrote:
The compiler must ensure that for any given object, it either ALWAYS
inlines lock free routines, OR calls the external routines. For any
given object, these cannot be intermixed.
Why? You give an example explaining why it is fine to link 386 and
On Sat, 1 Oct 2011, Andrew MacLeod wrote:
Ah ok, I had understood:
* if __atomic_store_8 is inlined on line 18, it should also be inlined
on line 42
when instead it is:
* we can't have a locked addition and a lock-free subtraction (hence
the __atomic_is_lock_free which only takes a size
On 10/03/2011 01:31 PM, Richard Henderson wrote:
On 09/30/2011 01:36 PM, Andrew MacLeod wrote:
http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
__atomic_store (size_t obj_size, T *mem, T val, enum memory_model model)
I don't like this. I really cannot imagine any situation for which
On 10/05/2011 12:14 AM, Jeffrey Yasskin wrote:
If, as the document proposes, 16 byte volatile will have to call the
external rotines, but 16 byte non-volatiles would be lock-free., and
the external routines use locked accesses for 16-byte volatile
atomics, then this makes the concurrent
On 10/05/2011 10:44 AM, Jeffrey Yasskin wrote:
Yes, that's what I'm suggesting. The rule for 'volatile' from the
language is just that Accesses to volatile objects are evaluated
strictly according to the rules of the abstract machine. If the
instruction-level implementation for a 16-byte atomic
After some discussions and further coding, the external library has been
refined.
I've updated the document at http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
In a nutshell, the changes are:
1 - generic routines
=
The generic version routines for arbitrary sized objects were
I'd like to have the cxx-mem-model branch considered for merging with
mainline before we end stage 1 for GCC 4.7.
What it is
==
GCC has had the __sync built-ins for atomic operations for a number of
years now. They implement a sequential consistent (AKA seq-cst)
synchronization
On 10/27/2011 04:55 AM, Richard Guenther wrote:
I am really expecting this branch to be merged for 4.7. The current
status is very presentable IMHO.
If you get (or already got) ack from maintainers covering the areas you
touch then I am fine with merging this branch for 4.7 from a RM point
of
Libstdc++-v3 use to provide a locked implementation of classes for sizes
which didn't have lock-free support. That was removed for this release
as it caused a program compiled with a specific version of GCC to be
locked into that implementation. The design criteria for the new
__atomic
On 12/02/2011 06:59 PM, Diego Novillo wrote:
I just merged from trunk and several of my C++ tests are failing with
the error:
In file included from .../libstdc++-v3/libsupc++/new:42:0,
from
And I assume that since the compiler does them, that would now make it
impossible for us to gather a list of all the 'lock' prefixes so that
we can undo them if it turns out that we are running on a UP machine.
When we do SMP operations, we don't just add a lock prefix to it. We do this:
On 02/03/2012 12:16 PM, Linus Torvalds wrote:
So we have several atomics we use in the kernel, with the more common being
- add (and subtract) and cmpchg of both 'int' and 'long'
This would be __atomic_fetch_add, __atomic_fetch_sub, and
__atomic_compare_exchange.
For 4.8
On 02/08/2012 05:54 AM, Richard Guenther wrote:
On Wed, Feb 8, 2012 at 10:59 AM, Jonathan Wakelyjwakely@gmail.com wrote:
Should they be?
Yes. Esp. also the deprecation of the __sync builtins.
Yes, I meant to do that last week, but instead it's this week :-P
Gerald had pinged me
On 02/08/2012 10:23 AM, Jonathan Wakely wrote:
On 8 February 2012 13:06, Andrew MacLeodamacl...@redhat.com wrote:
On 02/08/2012 05:54 AM, Richard Guenther wrote:
On Wed, Feb 8, 2012 at 10:59 AM, Jonathan Wakelyjwakely@gmail.com
wrote:
Should they be?
Yes. Esp. also the deprecation of
On 02/08/2012 10:23 AM, Jonathan Wakely wrote:
On 8 February 2012 13:06, Andrew MacLeodamacl...@redhat.com wrote:
Yes, I meant to do that last week, but instead it's this week :-P Gerald
had pinged me about it a while ago.
Great, thanks - I was thinking about adding a line to the C++11
On 02/08/2012 10:38 AM, Andrew MacLeod wrote:
OSure. There are 2 benefits for c++ now
- We can compile atomic objects of any arbitrary size/type now.
Previously there was a compiler error if it was not an integer class
that mapped to a supported size of lock-free __sync call. Now a user
On 02/08/2012 04:59 AM, Jonathan Wakely wrote:
Should they be?
How's this look for a news item and the changes file? Formatting seems
fine.
Is there no changelog for docs?
Andrew
Index: index.html
===
RCS file:
On 02/08/2012 04:30 PM, Jonathan Wakely wrote:
On 08/02/2012, Andrew MacLeod wrote:
On 02/08/2012 04:59 AM, Jonathan Wakely wrote:
Should they be?
How's this look for a news item and the changes file? Formatting seems
fine.
The news item is missing a + in C++
It's not critical
On 02/08/2012 06:19 PM, Gerald Pfeifer wrote:
This news item on the main page is quite long if you compare it with
the others and probably fills most of that column on page 1; could you
cut this signficantly and instead link to the gcc-4.7/changes.html and
have
some of the good general
On 03/07/2012 10:11 AM, Sebastian Huber wrote:
Hello,
I run the GCC testsuite for GCC 4.7.0 20120307
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00782.html
I got a lot of errors like this:
FAIL: g++.dg/simulate-thread/atomics-1.C -O0 -g (test for excess
errors)
148796 Excess errors:
On 03/10/2012 09:17 AM, Joe Gottman wrote:
According to the news on the front page, the C++11 memory model
has been added to gcc. But C++11 status page
(http://gcc.gnu.org/projects/cxx0x.html) says that it hasn't. Is this
an oversight?
Atomic support with memory model parameters have
gcc.gnu.org bounced the previous email for some reason...
On 03/12/2012 06:51 PM, Joe Gottman wrote:
On 3/12/2012 8:44 AM, Andrew MacLeod wrote:
On 03/10/2012 09:17 AM, Joe Gottman wrote:
According to the news on the front page, the C++11 memory model
has been added to gcc. But C++11
On 03/13/2012 08:02 PM, Richard Henderson wrote:
So, I've got something put together. I think it should be fairly scalable.
As a test I've thrown in some ARM overrides.
See
git://repo.or.cz/gcc/rth.git rth/libatomic
which is a gcc tree with a libatomic subdir.
Comments welcome. Andrew,
One of the things I want to make sure is that the library can be easily
extended in a generic way (ie not target dependant) as needs change.
Ie, initiually we are simply guaranteeing atomic operations and fall
back to a lock.
I expect in the not too distant future other sorts of guarantees
Stupid evolution and autodetection of html format emails..., gcc bounced
the reply...
On 03/14/2012 02:54 PM, Paweł Sikora wrote:
On Tuesday 13 of March 2012 17:02:01 Richard Henderson wrote:
So, I've got something put together. I think it should be fairly scalable.
As a test I've thrown in
On 03/14/2012 03:06 PM, Andrew MacLeod wrote:
No comment on whether its better or worse than any other library, but
once we have one in place in the toolchain, everyone is welcome to
enhance it with a better implementation.
Heh, not to say that rth's implementation isn't a good one
On 03/15/2012 07:52 PM, Richard Henderson wrote:
On 03/14/12 11:31, Richard Henderson wrote:
For my next trick: figuring out an Easy Way of utilizing IFUNCs,
so that we automatically make use of new cpu features without
recompilation...
Dunno about easy, but I can now generate a shared library
On 03/29/2012 12:52 PM, Basile Starynkevitch wrote:
They blame nobody if their plugins break from one release to the next. They
take this
incompatibility of GCC as part of their plugins developer's work.
Again, a plugin writer by definition uses whatever interface is given to him.
Cheers.
On 06/11/2012 06:27 AM, Dodji Seketeli wrote:
Richard Guentherrichard.guent...@gmail.com a écrit:
Eh - why not give them names with an actual meaning? Development Stage
and Stabilizing Stage? I realize those are rather long names, but you
can always put short forms in tables, like Dev Stage
I punted on determinig what to do with alignment issues when
implementing atomics for 4.7. The time has come however to address what
is to be done. I've put together a wiki page and discussed its contents
with a few people to get this cut. Hopefully it seems reasonably sane. :-)
I've added
I'm not sure when this happened, but I noticed on the weekend that there
has been an explosion in the time spent during the alias analysis phase.
using cplusplus-grammer.ii, it use to compile on my machine in about 55
seconds, and its now up to about 150 seconds.
A quick gprof indicated about 60%
1 - 100 of 1605 matches
Mail list logo
