[cxx-mem-model] Use __atomic builtins for OpenMP

I do realize that there's technically a regression for i486,
since we'll no longer look for xadd without the i586 cmpxchg.
I really can't imagine that anyone cares.

Tested on x86_64-linux.

r~

Use __atomic builtins for #pragma omp atomic.

        * omp-low.c (expand_omp_atomic_fetch_op): Don't test individual
        fetch_op optabs, only test can_compare_and_swap_p.  Use __atomic
        builtins instead of __sync builtins.
        * optabs.h (get_atomic_op_for_code): Remove decl.
        (struct atomic_op_functions): Move to...
        * optabs.c: ... here.
        (get_atomic_op_for_code): Make static.
    
testsuite/
        * lib/target-supports.exp (check_effective_target_cas_char): New.
        (check_effective_target_cas_int): New.
        * c-c++-common/gomp/atomic-10.c: Use cas_int; match __atomic builtin.
        * c-c++-common/gomp/atomic-3.c: Likewise.
        * c-c++-common/gomp/atomic-9.c: Likewise.
    
        * gcc.dg/gomp/atomic-1.c, gcc.dg/gomp/atomic-2.c,
        gcc.dg/gomp/atomic-3.c, gcc.dg/gomp/atomic-4.c, gcc.dg/gomp/atomic-7.c,
        gcc.dg/gomp/atomic-8.c, gcc.dg/gomp/atomic-9.c,
        gcc.dg/gomp/atomic-10.c, gcc.dg/gomp/atomic-12.c,

[google] Enable loop unroll/peel notes under -fopt-info

This patch is for google-main only.

Tested with bootstrap and regression tests.

Print unroll and peel factors along with loop source position under -fopt-info.

Teresa

2011-10-31   Teresa Johnson  <tejohnson <at> google.com>

        * common.opt (fopt-info): Disable -fopt-info by default.
        * loop-unroll.c (report_unroll_peel): New function.
        (unroll_and_peel_loops): Call record_loop_exits for later use.
        (peel_loops_completely): Print the loop source position in dump
        info and emit note under -fopt-info.
        (decide_unroll_and_peeling): Ditto.
        (decide_peel_once_rolling): Record peel factor for use in note
        emission.
        (decide_peel_completely): Ditto.
        * cfgloop.c (get_loop_location): New function.
        * cfgloop.h (get_loop_location): Ditto.
        * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Emit note
        under -fopt-info.

Index: tree-ssa-loop-ivcanon.c
===================================================================
--- tree-ssa-loop-ivcanon.c	(revision 180437)
+++ tree-ssa-loop-ivcanon.c	(working copy)
 <at>  <at>  -52,6 +52,7  <at>  <at> 
 #include "flags.h"

Re: C++ PATCH to add -std=c++11 ??

On 10/31/2011 01:57 PM, Jason Merrill wrote:
> On 10/31/2011 06:39 AM, Paolo Carlini wrote:
>> Great. When you commit it, you can as well add 'PR c++/50920' to the
>> ChangeLog!
>
> OK, here's what I'm checking in. There are a lot more instances of C++0x
> in comments and cxx_dialect checks, but I'm not going to worry about
> those now.

And some doc changes:

Re: RFA: libstdc++ PATCH to initializer_list to #error in C++98 mode

Here's what I'm checking in:

C++ PATCH to disable -fdeduce-init-list by default

In my implementation of the C++11 list-initialization proposal, I also 
implemented an extension that allowed for deduction of 
std::initializer_list<...> for a template type parameter, so that people 
could try it out and see what they thought.  This extension didn't make 
it into C++11, so I'm switching its flag to be off by default.

Tested x86_64-pc-linux-gnu, applying to trunk.

Re: [go]: Port to ALPHA arch - epoll problems

Uros Bizjak <ubizjak <at> gmail.com> writes:

> It turned out that the EpollEvent definition in
> libgo/syscalls/epoll/socket_epoll.go is non-portable (if not outright
> dangerous...). The definition does have a FIXME comment, but does not
> take into account the effects of __attribute__((__packed__)) from
> system headers. Contrary to alpha header, x86 has
> __attribute__((__packed__)) added to struct epoll_event definition in
> sys/epoll.h header.

I couldn't work out a way to handle this correctly in mksysinfo.sh or
-fdump-go-spec, so I did it in configure instead.  Bootstrapped and
tested on x86_64-unknown-linux-gnu.  Committed to mainline.  Let me know
if it seems to do the right sort of thing on Alpha GNU/Linux--see if the
generated file TARGET/libgo/epoll.h looks OK.

Ian

[PATCH] Fix errors in expand_atomic_store.

        * optabs.c (expand_atomic_store): Use create_fixed_operand for
        atomic_store optab.  Don't try to fall back to sync_lock_release.

---
The create_fixed_operand thinko is obvious.  The sync_lock_release is
more subtle.  The target is allowed to support only storing 0/1 with
the test_and_set/lock_release pair, and it's allowed to support that
in non-obvious ways.  We don't want to get involved in that.

r~

---
 gcc/ChangeLog.mm |    5 +++++
 gcc/optabs.c     |   21 +--------------------
 2 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/gcc/optabs.c b/gcc/optabs.c
index 1ecab53..d8ab97e 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
 <at>  <at>  -7118,32 +7118,13  <at>  <at>  expand_atomic_store (rtx mem, rtx val, enum memmodel model)
   icode = direct_optab_handler (atomic_store_optab, mode);
   if (icode != CODE_FOR_nothing)
     {
-
-      create_output_operand (&ops[0], mem, mode);
+      create_fixed_operand (&ops[0], mem);
       create_input_operand (&ops[1], val, mode);
       create_integer_operand (&ops[2], model);
       if (maybe_expand_insn (icode, 3, ops))

[cxx-mem-model] i386 atomic load/store

I'm considering the following.  Does anyone believe this i386/i486 decision
re DImode is a mistake?  Should I limit that to Pentium by checking cmpxchg?

r~

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 7ce57d8..7d28e43 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
 <at>  <at>  -248,6 +248,9  <at>  <at> 
   ;; For BMI2 support
   UNSPEC_PDEP
   UNSPEC_PEXT
+
+  ;; For __atomic support
+  UNSPEC_MOVA
 ])

 (define_c_enum "unspecv" [
diff --git a/gcc/config/i386/sync.md b/gcc/config/i386/sync.md
index e5579b1..da08e92 100644
--- a/gcc/config/i386/sync.md
+++ b/gcc/config/i386/sync.md
 <at>  <at>  -46,6 +46,88  <at>  <at> 
   "lock{%;} or{l}\t{$0, (%%esp)|DWORD PTR [esp], 0}"
   [(set_attr "memory" "unknown")])

+;; ??? From volume 3 section 7.1.1 Guaranteed Atomic Operations,
+;; Only beginning at Pentium family processors do we get any guarantee of

Re: Go patch committed: Update Go library

Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE> writes:

> * The message points to the wrong line due to a broken test: malloc.goc
>   has:
>
> 		p = runtime_SysReserve((void*)(0x00f8ULL<<32), bitmap_size + arena_size);
> 		if(p == nil)
> 			runtime_throw("runtime: cannot reserve arena virtual address space");
>
>   On failure, p will be MAP_FAILED ((void *)-1), not nil, so the wrong
>   assertion it thrown.

I fixed this particular issue as follows, copying the code from the
other Go library.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian

Re: [RFC PATCH] Gather vectorization (PR tree-optimization/50789)

On 10/31/2011 03:23 PM, Jakub Jelinek wrote:

> On Sat, Oct 29, 2011 at 03:53:37PM +0200, Toon Moene wrote:

>> I wonder whether it will work with the attached Fortran routine - it
>> sure would mean a boost to the 18%+ heaviest CPU user in our code.

> Would be nice to cut down slightly this testcase into just one or two loops
> that are vectorized and turn it into a runtime testcase which verifies
> the vectorization was correct.

This is not a verifiable routine yet, but as the linear interpolation 
part already has all the juicy indirection necessary to test this 
vectorization, most of the routine can be thrown away, to leave the 
attached as essential.

--

-- 
Toon Moene - e-mail: toon <at> moene.org - phone: +31 346 214290  | 4 more
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands       | 4 44
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news