GCC 5.2 Second Release Candidate available from gcc.gnu.org
A second release candidate for GCC 5.2 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/5.2.0-RC-20150712 and shortly its mirrors. It has been generated from SVN revision 225717. I have sofar bootstrapped the release candidate on x86_64-suse-linux-gnu. Please test the release candidate and report any issues to bugzilla. If all goes well I'd like to release GCC 5.2 at the end of this week.
Re: %fs and %gs segments on x86/x86-64
On Thu, Jul 9, 2015 at 8:02 PM, Armin Rigo wrote: > Hi all, > > Here is an updated patch (attached) for __seg_fs and __seg_gs: > > * added a target hook "default_pointer_address_modes" to avoid > disabling a few gcc optimizations which, according to my reading of > the documentation, should continue to work even in the presence of > multiple address spaces as long as they all use the same mode for > pointers. > > * account for the extra byte in "%gs:(...)" addresses. > > * added one test case (better than none!) using "scan-assembler". If > people agree that this is the style of test that we need here, then I > could add more of them. > > The diff is against trunk. The tests don't all pass; the failures > really seem unrelated, but I guess I should grab the same revision > without the patch, compile it, try to run all the tests on the same > machine, and compare the list of failures... it just takes a serious > amount of time to do so... > > I also reported the bug I got previously > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768) and it seems to > occur already in other targets with address spaces. For this issue, I will work out a patch for it. Thanks, bin > > > A bientôt, > > Armin.
Re: Compilers and RCU readers: Once more unto the breach!
On Tue, May 19, 2015 at 05:55:10PM -0700, Paul E. McKenney wrote: > Hello! > > Following up on last year's discussion (https://lwn.net/Articles/586838/, > https://lwn.net/Articles/588300/), I believe that we have a solution. If > I am wrong, I am sure you all will let me know, and in great detail. ;-) > > The key simplification is to "just say no" to RCU-protected array indexes: > https://lkml.org/lkml/2015/5/12/827, as was suggested by several people. > This simplification means that rcu_dereference (AKA memory_order_consume) > need only return pointers. This in ture avoids things like (x-x), > (x*0), and (x%1) because if "x" is a pointer, these expressions either > return non-pointers are compilation errors. With a very few exceptions, > dependency chains can lead -to- non-pointers, but cannot pass -through- > them. > > The result is that dependencies are carried only by operations for > which the compiler cannot easily optimize the away those dependencies, > these operations including simple assignment, integer offset (including > indexing), dereferencing, casts, passing as a function argument, return > values from functions and so on. A complete list with commentary starts > on page 28 of: > > http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf And an update is available here: http://www.rdrop.com/users/paulmck/RCU/consume.2015.07.13a.pdf Among other things, this update addresses the points about equality comparisons introduced by the compiler, and outlines some of the issues head-/tail-marked alternatives face with respect to abstraction. The updated "Restricted Dependency Chains" section starts on page 28. Thoughts? Thanx, Paul
