public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Cilk Library
@ 2013-10-02 19:40 Iyer, Balaji V
  2013-10-03  4:45 ` Jeff Law
  2013-10-08 19:44 ` Jeff Law
  0 siblings, 2 replies; 19+ messages in thread
From: Iyer, Balaji V @ 2013-10-02 19:40 UTC (permalink / raw)
  To: gcc
  Cc: Jeff Law, Aldy Hernandez (aldyh@redhat.com),
	rth, Jason Merrill (jason@redhat.com)

[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]

Dear steering committee,
	To support the _Cilk_spawn, and _Cilk_sync implementation in GCC (patch submitted link: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00859.html), we need to add a foreign library (Cilk Runtime Library) into the gcc repository. With this email, I am attaching the README file that will accompany Cilk Runtime Library (libcilkrts). I am also copy-pasting the header comment from one of the libcilkrts files. The header shown below will be in all the source files in libcilkrts. Does this look OK?

Thanks,

Balaji V. Iyer.


/* cilk_api.c                  -*-C-*-
 *
 *************************************************************************
 *
 *  @copyright
 *  Copyright (C) 2009-2013, Intel Corporation
 *  All rights reserved.
 *
 *  @copyright
 *  Redistribution and use in source and binary forms, with or without
 *  modification, are permitted provided that the following conditions
 *  are met:
 *
 *    * Redistributions of source code must retain the above copyright
 *      notice, this list of conditions and the following disclaimer.
 *    * Redistributions in binary form must reproduce the above copyright
 *      notice, this list of conditions and the following disclaimer in
 *      the documentation and/or other materials provided with the
 *      distribution.
 *    * Neither the name of Intel Corporation nor the names of its
 *      contributors may be used to endorse or promote products derived
 *      from this software without specific prior written permission.
 *
 *  @copyright
 *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 *  HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
 *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
 *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
 *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
 *  AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 *  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
 *  WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 *  POSSIBILITY OF SUCH DAMAGE.
 **************************************************************************/

[-- Attachment #2: README --]
[-- Type: application/octet-stream, Size: 2275 bytes --]

Intel(R) Cilk(TM) Plus runtime library

Index:
1. BUILDING
2. USING
3. DOXYGEN DOCUMENTATION
4. QUESTIONS OR BUGS
5. CONTRIBUTIONS

#
#  1. BUILDING:
#

To distribute applications that use the Intel Cilk Plus language
extensions to non-development systems, you need to build the Intel
Cilk Plus runtime library and distribute it with your application.

To build the libcilkrts.so runtime library component, you need the
autoconf and automake packages, which are available through your
favorite package manager.  You also need a C/C++ compiler that
supports the Intel Cilk Plus language extensions, since the runtime
uses Intel Cilk Plus features internally.  Use either the Intel(R)
C++ Compiler (icc command) v12.1 or later, or the "cilkplus" branch
in GCC (gcc command).

Once you have the necessary prerequisites installed, you can use the
following commands to create the library:

% libtoolize
% aclocal
% automake --add-missing
% autoconf
% ./configure
% make
% make install

This will produce the libcilkrts.so shared object.  To install the
library in a custom location, set the prefix while running the
configure script:

% ./configure --prefix=/your/path/to/lib

#
#  2. USING:
#

The Intel(R) C++ Compiler will automatically try to bring in the
Intel Cilk Plus runtime in any program that uses the relevant
features.  GCC requires explicit linking of both the library and
its dependencies (libpthread, libdl).  For example:

% gcc foo.c -lcilkrts -lpthread -ldl

#
#  3. DOXYGEN DOCUMENTATION:
#

The library source has Doxygen markup.  Generate HTML documentation
based on the markup by changing directory into runtime and running:

% doxygen doxygen.cfg

#
#  4. QUESTIONS OR BUGS:
#

Issues with the Intel Cilk Plus runtime can be addressed in the Intel
Cilk Plus forums:
http://software.intel.com/en-us/forums/intel-cilk-plus/

#
#  5. CONTRIBUTIONS:
#

The Intel Cilk Plus runtime library is dual licensed. The upstream copy
of the library is maintained via the BSD-licensed version available at:
http://cilkplus.org/

Changes to the Intel Cilk Plus runtime are welcome and should be
contributed to the upstream version via http://cilkplus.org/.

------------------------
Intel and Cilk are trademarks of Intel Corporation in the U.S. and/or
other countries.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Cilk Library
  2013-10-02 19:40 Cilk Library Iyer, Balaji V
@ 2013-10-03  4:45 ` Jeff Law
  2013-10-08 19:44 ` Jeff Law
  1 sibling, 0 replies; 19+ messages in thread
From: Jeff Law @ 2013-10-03  4:45 UTC (permalink / raw)
  To: Iyer, Balaji V
  Cc: gcc, Aldy Hernandez (aldyh@redhat.com),
	rth, Jason Merrill (jason@redhat.com)

On 10/02/13 13:40, Iyer, Balaji V wrote:
> Dear steering committee, To support the _Cilk_spawn, and _Cilk_sync
> implementation in GCC (patch submitted link:
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00859.html), we need to
> add a foreign library (Cilk Runtime Library) into the gcc repository.
> With this email, I am attaching the README file that will accompany
> Cilk Runtime Library (libcilkrts). I am also copy-pasting the header
> comment from one of the libcilkrts files. The header shown below will
> be in all the source files in libcilkrts. Does this look OK?
I've forwarded this to the steering committee.

jeff

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Cilk Library
  2013-10-02 19:40 Cilk Library Iyer, Balaji V
  2013-10-03  4:45 ` Jeff Law
@ 2013-10-08 19:44 ` Jeff Law
  2013-10-09 18:32   ` Iyer, Balaji V
  1 sibling, 1 reply; 19+ messages in thread
From: Jeff Law @ 2013-10-08 19:44 UTC (permalink / raw)
  To: Iyer, Balaji V, gcc
  Cc: Aldy Hernandez (aldyh@redhat.com), rth, Jason Merrill (jason@redhat.com)

On 10/02/13 13:40, Iyer, Balaji V wrote:
> Dear steering committee, To support the _Cilk_spawn, and _Cilk_sync
> implementation in GCC (patch submitted link:
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00859.html), we need to
> add a foreign library (Cilk Runtime Library) into the gcc repository.
> With this email, I am attaching the README file that will accompany
> Cilk Runtime Library (libcilkrts). I am also copy-pasting the header
> comment from one of the libcilkrts files. The header shown below will
> be in all the source files in libcilkrts. Does this look OK?
>

I'm pleased to announce the steering committee approves the license 
terms for the Cilk+ runtime system as well as the plan to have the Cilk+ 
runtime maintained upstream by Intel and copied into the GCC repository.

Given the runtime system will be maintained upstream by Intel, only a 
cursory review of the runtime system should be necessary -- basically 
stuff like ensuring it integrates into our build system, copyrights are 
in place and the like.


Jeff

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: Cilk Library
  2013-10-08 19:44 ` Jeff Law
@ 2013-10-09 18:32   ` Iyer, Balaji V
  2013-10-09 20:22     ` Joseph S. Myers
                       ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Iyer, Balaji V @ 2013-10-09 18:32 UTC (permalink / raw)
  To: Jeff Law, gcc
  Cc: Aldy Hernandez (aldyh@redhat.com), rth, Jason Merrill (jason@redhat.com)

Dear Jeff and the rest of Steering committee members,
     Thank you very much for approving the license terms of the Cilk Library. I couldn't attach the zipped copy of the patch due to its size, so here is a link to the Cilk library patch that can be applied to the trunk: (https://docs.google.com/file/d/0BzEpbbnrYKsSWjBWSkNrVS1SaGs/edit?usp=sharing).

     Is it OK for trunk?

Here are the ChangeLog entries:

ChangeLog:
2013-10-09  Balaji V. Iyer  <balaji.v.iyer@intel.com>

        * Makefile.def: Add libcilkrts to target_modules.  Make libcilkrts
        depend on libstdc++ and libgcc.
        * configure.ac: Added libcilkrts to target binaries.
        * configure: Likewise.
        * Makefile.in: Added libcilkrts related fields to support building it.

libcilkrts/ChangeLog:
2013-10-09  Balaji V. Iyer  <balaji.v.iyer@intel.com>

	* libcilkrts/Makefile.am: New file.  Libcilkrts version 3613.
	* libcilkrts/Makefile.in: Likewise.
	* libcilkrts/README: Likewise.
	* libcilkrts/aclocal.m4: Likewise.
	* libcilkrts/configure: Likewise.
	* libcilkrts/configure.ac: Likewise.
	* libcilkrts/include/cilk/cilk.h: Likewise.
	* libcilkrts/include/cilk/cilk_api.h: Likewise.
	* libcilkrts/include/cilk/cilk_api_linux.h: Likewise.
	* libcilkrts/include/cilk/cilk_stub.h: Likewise.
	* libcilkrts/include/cilk/cilk_undocumented.h: Likewise.
	* libcilkrts/include/cilk/common.h: Likewise.
	* libcilkrts/include/cilk/holder.h: Likewise.
	* libcilkrts/include/cilk/hyperobject_base.h: Likewise.
	* libcilkrts/include/cilk/metaprogramming.h: Likewise.
	* libcilkrts/include/cilk/reducer.h: Likewise.
	* libcilkrts/include/cilk/reducer_file.h: Likewise.
	* libcilkrts/include/cilk/reducer_list.h: Likewise.
	* libcilkrts/include/cilk/reducer_max.h: Likewise.
	* libcilkrts/include/cilk/reducer_min.h: Likewise.
	* libcilkrts/include/cilk/reducer_min_max.h: Likewise.
	* libcilkrts/include/cilk/reducer_opadd.h: Likewise.
	* libcilkrts/include/cilk/reducer_opand.h: Likewise.
	* libcilkrts/include/cilk/reducer_opmul.h: Likewise.
	* libcilkrts/include/cilk/reducer_opor.h: Likewise.
	* libcilkrts/include/cilk/reducer_opxor.h: Likewise.
	* libcilkrts/include/cilk/reducer_ostream.h: Likewise.
	* libcilkrts/include/cilk/reducer_string.h: Likewise.
	* libcilkrts/include/cilktools/cilkscreen.h: Likewise.
	* libcilkrts/include/cilktools/cilkview.h: Likewise.
	* libcilkrts/include/cilktools/fake_mutex.h: Likewise.
	* libcilkrts/include/cilktools/lock_guard.h: Likewise.
	* libcilkrts/include/internal/abi.h: Likewise.
	* libcilkrts/include/internal/cilk_fake.h: Likewise.
	* libcilkrts/include/internal/cilk_version.h: Likewise.
	* libcilkrts/include/internal/inspector-abi.h: Likewise.
	* libcilkrts/include/internal/metacall.h: Likewise.
	* libcilkrts/include/internal/rev.mk: Likewise.
	* libcilkrts/mk/cilk-version.mk: Likewise.
	* libcilkrts/mk/unix-common.mk: Likewise.
	* libcilkrts/runtime/acknowledgements.dox: Likewise.
	* libcilkrts/runtime/bug.cpp: Likewise.
	* libcilkrts/runtime/bug.h: Likewise.
	* libcilkrts/runtime/c_reducers.c: Likewise.
	* libcilkrts/runtime/cilk-abi-cilk-for.cpp: Likewise.
	* libcilkrts/runtime/cilk-abi-vla-internal.c: Likewise.
	* libcilkrts/runtime/cilk-abi-vla-internal.h: Likewise.
	* libcilkrts/runtime/cilk-abi-vla.c: Likewise.
	* libcilkrts/runtime/cilk-abi.c: Likewise.
	* libcilkrts/runtime/cilk-ittnotify.h: Likewise.
	* libcilkrts/runtime/cilk-tbb-interop.h: Likewise.
	* libcilkrts/runtime/cilk_api.c: Likewise.
	* libcilkrts/runtime/cilk_fiber-unix.cpp: Likewise.
	* libcilkrts/runtime/cilk_fiber-unix.h: Likewise.
	* libcilkrts/runtime/cilk_fiber.cpp: Likewise.
	* libcilkrts/runtime/cilk_fiber.h: Likewise.
	* libcilkrts/runtime/cilk_malloc.c: Likewise.
	* libcilkrts/runtime/cilk_malloc.h: Likewise.
	* libcilkrts/runtime/component.h: Likewise.
	* libcilkrts/runtime/doxygen-layout.xml: Likewise.
	* libcilkrts/runtime/doxygen.cfg: Likewise.
	* libcilkrts/runtime/except-gcc.cpp: Likewise.
	* libcilkrts/runtime/except-gcc.h: Likewise.
	* libcilkrts/runtime/except.h: Likewise.
	* libcilkrts/runtime/frame_malloc.c: Likewise.
	* libcilkrts/runtime/frame_malloc.h: Likewise.
	* libcilkrts/runtime/full_frame.c: Likewise.
	* libcilkrts/runtime/full_frame.h: Likewise.
	* libcilkrts/runtime/global_state.cpp: Likewise.
	* libcilkrts/runtime/global_state.h: Likewise.
	* libcilkrts/runtime/jmpbuf.c: Likewise.
	* libcilkrts/runtime/jmpbuf.h: Likewise.
	* libcilkrts/runtime/local_state.c: Likewise.
	* libcilkrts/runtime/local_state.h: Likewise.
	* libcilkrts/runtime/metacall_impl.c: Likewise.
	* libcilkrts/runtime/metacall_impl.h: Likewise.
	* libcilkrts/runtime/os-unix.c: Likewise.
	* libcilkrts/runtime/os.h: Likewise.
	* libcilkrts/runtime/os_mutex-unix.c: Likewise.
	* libcilkrts/runtime/os_mutex.h: Likewise.
	* libcilkrts/runtime/pedigrees.c: Likewise.
	* libcilkrts/runtime/pedigrees.h: Likewise.
	* libcilkrts/runtime/record-replay.cpp: Likewise.
	* libcilkrts/runtime/record-replay.h: Likewise.
	* libcilkrts/runtime/reducer_impl.cpp: Likewise.
	* libcilkrts/runtime/reducer_impl.h: Likewise.
	* libcilkrts/runtime/rts-common.h: Likewise.
	* libcilkrts/runtime/scheduler.c: Likewise.
	* libcilkrts/runtime/scheduler.h: Likewise.
	* libcilkrts/runtime/signal_node.c: Likewise.
	* libcilkrts/runtime/signal_node.h: Likewise.
	* libcilkrts/runtime/spin_mutex.c: Likewise.
	* libcilkrts/runtime/spin_mutex.h: Likewise.
	* libcilkrts/runtime/stacks.h: Likewise.
	* libcilkrts/runtime/stats.c: Likewise.
	* libcilkrts/runtime/stats.h: Likewise.
	* libcilkrts/runtime/symbol_test.c: Likewise.
	* libcilkrts/runtime/sysdep-unix.c: Likewise.
	* libcilkrts/runtime/sysdep.h: Likewise.
	* libcilkrts/runtime/unix_symbols.t: Likewise.
	* libcilkrts/runtime/worker_mutex.c: Likewise.
	* libcilkrts/runtime/worker_mutex.h: Likewise.

Thanks,

Balaji V. Iyer.
   

> -----Original Message-----
> From: Jeff Law [mailto:law@redhat.com]
> Sent: Tuesday, October 08, 2013 3:45 PM
> To: Iyer, Balaji V; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (aldyh@redhat.com); rth@redhat.com; Jason Merrill
> (jason@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/02/13 13:40, Iyer, Balaji V wrote:
> > Dear steering committee, To support the _Cilk_spawn, and _Cilk_sync
> > implementation in GCC (patch submitted link:
> > http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00859.html), we need to
> > add a foreign library (Cilk Runtime Library) into the gcc repository.
> > With this email, I am attaching the README file that will accompany
> > Cilk Runtime Library (libcilkrts). I am also copy-pasting the header
> > comment from one of the libcilkrts files. The header shown below will
> > be in all the source files in libcilkrts. Does this look OK?
> >
> 
> I'm pleased to announce the steering committee approves the license terms for
> the Cilk+ runtime system as well as the plan to have the Cilk+ runtime
> maintained upstream by Intel and copied into the GCC repository.
> 
> Given the runtime system will be maintained upstream by Intel, only a cursory
> review of the runtime system should be necessary -- basically stuff like ensuring
> it integrates into our build system, copyrights are in place and the like.
> 
> 
> Jeff

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: Cilk Library
  2013-10-09 18:32   ` Iyer, Balaji V
@ 2013-10-09 20:22     ` Joseph S. Myers
  2013-10-10 13:19     ` Aldy Hernandez
  2013-10-15 20:14     ` Jeff Law
  2 siblings, 0 replies; 19+ messages in thread
From: Joseph S. Myers @ 2013-10-09 20:22 UTC (permalink / raw)
  To: Iyer, Balaji V
  Cc: Jeff Law, gcc, Aldy Hernandez (aldyh@redhat.com),
	rth, Jason Merrill (jason@redhat.com)

Some observations:

* Various source files include x86-specific asm.  At some point it will 
need restructuring so that the architecture-specific parts go in 
architecture-specific files and it's clear what to do to add support for 
another architecture.

* Given that architecture dependency, the toplevel configure.ac needs to 
take care to disable building this library for unsupported targets.  See 
what's done for libatomic, libitm, libsanitizer or libvtv, using a 
configure.tgt file in the library's subdirectory to avoid toplevel 
configure.ac needing to hardcode such target information directly.

* In fact, I think the dependency is not just x86, but hosted POSIX system 
on x86, given the use of -lpthread -ldl.

* You have:

+GENERAL_FLAGS += -DBUILD_USER=\"$(USER)\"
+GENERAL_FLAGS += -DBUILD_HOST=\"`hostname`\"

Please remove this, and the uses of __DATE__ and __TIME__.  It is becoming 
increasingly clear that it would be desirable for free software binaries, 
including complete GNU/Linux distributions, to be bit-for-bit reproducible 
from sources when bootstrapped by different people on different systems 
from different starting points.  So nothing should end up in the binaries 
that would depend unnecessarily on the build system.

* You have, in libcilkrts/mk/unix-common.mk, code setting a variable OUT, 
determining (I think) the configuration in some way, based on running 
"uname".  This is obviously inappropriate for cross-compilation.  You need 
to ensure that when building in the GCC source tree, this variable (if it 
matters at all) is set based on the host triplet for which the library is 
configured (host for a target library = target for toplevel configure).  
Or, if this file is unused (and I don't see anything obvious using it), it 
could just be removed from the source tree in GCC.

* Could you confirm whether the library uses symbol versioning, defaults 
to hidden visibility or otherwise ensures that only those symbols 
specifically intended to be part of the public interface get exported from 
the shared library?  If not, it would be a very good idea to make it do so 
(see libgomp for example).

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Cilk Library
  2013-10-09 18:32   ` Iyer, Balaji V
  2013-10-09 20:22     ` Joseph S. Myers
@ 2013-10-10 13:19     ` Aldy Hernandez
  2013-10-10 13:35       ` Iyer, Balaji V
  2013-10-15 20:14     ` Jeff Law
  2 siblings, 1 reply; 19+ messages in thread
From: Aldy Hernandez @ 2013-10-10 13:19 UTC (permalink / raw)
  To: Iyer, Balaji V; +Cc: Jeff Law, gcc, rth, Jason Merrill (jason@redhat.com)

On 10/09/13 13:32, Iyer, Balaji V wrote:

>       Is it OK for trunk?
>

I would prefer that a consumer of this library be in place before you 
commit.  That is, until cilk_spawn/sync/etc go in.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: Cilk Library
  2013-10-10 13:19     ` Aldy Hernandez
@ 2013-10-10 13:35       ` Iyer, Balaji V
  0 siblings, 0 replies; 19+ messages in thread
From: Iyer, Balaji V @ 2013-10-10 13:35 UTC (permalink / raw)
  To: Aldy Hernandez; +Cc: Jeff Law, gcc, rth, Jason Merrill (jason@redhat.com)



> -----Original Message-----
> From: Aldy Hernandez [mailto:aldyh@redhat.com]
> Sent: Thursday, October 10, 2013 9:19 AM
> To: Iyer, Balaji V
> Cc: Jeff Law; gcc@gcc.gnu.org; rth@redhat.com; Jason Merrill
> (jason@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/09/13 13:32, Iyer, Balaji V wrote:
> 
> >       Is it OK for trunk?
> >
> 
> I would prefer that a consumer of this library be in place before you commit.
> That is, until cilk_spawn/sync/etc go in.

Yup that's the plan.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Cilk Library
  2013-10-09 18:32   ` Iyer, Balaji V
  2013-10-09 20:22     ` Joseph S. Myers
  2013-10-10 13:19     ` Aldy Hernandez
@ 2013-10-15 20:14     ` Jeff Law
  2013-10-16  8:26       ` Richard Biener
  2013-10-16 19:30       ` Iyer, Balaji V
  2 siblings, 2 replies; 19+ messages in thread
From: Jeff Law @ 2013-10-15 20:14 UTC (permalink / raw)
  To: Iyer, Balaji V, gcc
  Cc: Aldy Hernandez (aldyh@redhat.com), rth, Jason Merrill (jason@redhat.com)

On 10/09/13 12:32, Iyer, Balaji V wrote:
> Dear Jeff and the rest of Steering committee members,
>       Thank you very much for approving the license terms of the Cilk Library. I couldn't attach the zipped copy of the patch due to its size, so here is a link to the Cilk library patch that can be applied to the trunk: (https://docs.google.com/file/d/0BzEpbbnrYKsSWjBWSkNrVS1SaGs/edit?usp=sharing).
>
>       Is it OK for trunk?
>
> Here are the ChangeLog entries:
>
> ChangeLog:
> 2013-10-09  Balaji V. Iyer  <balaji.v.iyer@intel.com>
>
>          * Makefile.def: Add libcilkrts to target_modules.  Make libcilkrts
>          depend on libstdc++ and libgcc.
>          * configure.ac: Added libcilkrts to target binaries.
>          * configure: Likewise.
>          * Makefile.in: Added libcilkrts related fields to support building it.
>
> libcilkrts/ChangeLog:
> 2013-10-09  Balaji V. Iyer  <balaji.v.iyer@intel.com>
>
> 	* libcilkrts/Makefile.am: New file.  Libcilkrts version 3613.
> 	* libcilkrts/Makefile.in: Likewise.
> 	* libcilkrts/README: Likewise.
> 	* libcilkrts/aclocal.m4: Likewise.
> 	* libcilkrts/configure: Likewise.
> 	* libcilkrts/configure.ac: Likewise.
> 	* libcilkrts/include/cilk/cilk.h: Likewise.
> 	* libcilkrts/include/cilk/cilk_api.h: Likewise.
> 	* libcilkrts/include/cilk/cilk_api_linux.h: Likewise.
> 	* libcilkrts/include/cilk/cilk_stub.h: Likewise.
> 	* libcilkrts/include/cilk/cilk_undocumented.h: Likewise.
> 	* libcilkrts/include/cilk/common.h: Likewise.
> 	* libcilkrts/include/cilk/holder.h: Likewise.
> 	* libcilkrts/include/cilk/hyperobject_base.h: Likewise.
> 	* libcilkrts/include/cilk/metaprogramming.h: Likewise.
> 	* libcilkrts/include/cilk/reducer.h: Likewise.
> 	* libcilkrts/include/cilk/reducer_file.h: Likewise.
> 	* libcilkrts/include/cilk/reducer_list.h: Likewise.
> 	* libcilkrts/include/cilk/reducer_max.h: Likewise.
> 	* libcilkrts/include/cilk/reducer_min.h: Likewise.
> 	* libcilkrts/include/cilk/reducer_min_max.h: Likewise.
> 	* libcilkrts/include/cilk/reducer_opadd.h: Likewise.
> 	* libcilkrts/include/cilk/reducer_opand.h: Likewise.
> 	* libcilkrts/include/cilk/reducer_opmul.h: Likewise.
> 	* libcilkrts/include/cilk/reducer_opor.h: Likewise.
> 	* libcilkrts/include/cilk/reducer_opxor.h: Likewise.
> 	* libcilkrts/include/cilk/reducer_ostream.h: Likewise.
> 	* libcilkrts/include/cilk/reducer_string.h: Likewise.
> 	* libcilkrts/include/cilktools/cilkscreen.h: Likewise.
> 	* libcilkrts/include/cilktools/cilkview.h: Likewise.
> 	* libcilkrts/include/cilktools/fake_mutex.h: Likewise.
> 	* libcilkrts/include/cilktools/lock_guard.h: Likewise.
> 	* libcilkrts/include/internal/abi.h: Likewise.
> 	* libcilkrts/include/internal/cilk_fake.h: Likewise.
> 	* libcilkrts/include/internal/cilk_version.h: Likewise.
> 	* libcilkrts/include/internal/inspector-abi.h: Likewise.
> 	* libcilkrts/include/internal/metacall.h: Likewise.
> 	* libcilkrts/include/internal/rev.mk: Likewise.
> 	* libcilkrts/mk/cilk-version.mk: Likewise.
> 	* libcilkrts/mk/unix-common.mk: Likewise.
> 	* libcilkrts/runtime/acknowledgements.dox: Likewise.
> 	* libcilkrts/runtime/bug.cpp: Likewise.
> 	* libcilkrts/runtime/bug.h: Likewise.
> 	* libcilkrts/runtime/c_reducers.c: Likewise.
> 	* libcilkrts/runtime/cilk-abi-cilk-for.cpp: Likewise.
> 	* libcilkrts/runtime/cilk-abi-vla-internal.c: Likewise.
> 	* libcilkrts/runtime/cilk-abi-vla-internal.h: Likewise.
> 	* libcilkrts/runtime/cilk-abi-vla.c: Likewise.
> 	* libcilkrts/runtime/cilk-abi.c: Likewise.
> 	* libcilkrts/runtime/cilk-ittnotify.h: Likewise.
> 	* libcilkrts/runtime/cilk-tbb-interop.h: Likewise.
> 	* libcilkrts/runtime/cilk_api.c: Likewise.
> 	* libcilkrts/runtime/cilk_fiber-unix.cpp: Likewise.
> 	* libcilkrts/runtime/cilk_fiber-unix.h: Likewise.
> 	* libcilkrts/runtime/cilk_fiber.cpp: Likewise.
> 	* libcilkrts/runtime/cilk_fiber.h: Likewise.
> 	* libcilkrts/runtime/cilk_malloc.c: Likewise.
> 	* libcilkrts/runtime/cilk_malloc.h: Likewise.
> 	* libcilkrts/runtime/component.h: Likewise.
> 	* libcilkrts/runtime/doxygen-layout.xml: Likewise.
> 	* libcilkrts/runtime/doxygen.cfg: Likewise.
> 	* libcilkrts/runtime/except-gcc.cpp: Likewise.
> 	* libcilkrts/runtime/except-gcc.h: Likewise.
> 	* libcilkrts/runtime/except.h: Likewise.
> 	* libcilkrts/runtime/frame_malloc.c: Likewise.
> 	* libcilkrts/runtime/frame_malloc.h: Likewise.
> 	* libcilkrts/runtime/full_frame.c: Likewise.
> 	* libcilkrts/runtime/full_frame.h: Likewise.
> 	* libcilkrts/runtime/global_state.cpp: Likewise.
> 	* libcilkrts/runtime/global_state.h: Likewise.
> 	* libcilkrts/runtime/jmpbuf.c: Likewise.
> 	* libcilkrts/runtime/jmpbuf.h: Likewise.
> 	* libcilkrts/runtime/local_state.c: Likewise.
> 	* libcilkrts/runtime/local_state.h: Likewise.
> 	* libcilkrts/runtime/metacall_impl.c: Likewise.
> 	* libcilkrts/runtime/metacall_impl.h: Likewise.
> 	* libcilkrts/runtime/os-unix.c: Likewise.
> 	* libcilkrts/runtime/os.h: Likewise.
> 	* libcilkrts/runtime/os_mutex-unix.c: Likewise.
> 	* libcilkrts/runtime/os_mutex.h: Likewise.
> 	* libcilkrts/runtime/pedigrees.c: Likewise.
> 	* libcilkrts/runtime/pedigrees.h: Likewise.
> 	* libcilkrts/runtime/record-replay.cpp: Likewise.
> 	* libcilkrts/runtime/record-replay.h: Likewise.
> 	* libcilkrts/runtime/reducer_impl.cpp: Likewise.
> 	* libcilkrts/runtime/reducer_impl.h: Likewise.
> 	* libcilkrts/runtime/rts-common.h: Likewise.
> 	* libcilkrts/runtime/scheduler.c: Likewise.
> 	* libcilkrts/runtime/scheduler.h: Likewise.
> 	* libcilkrts/runtime/signal_node.c: Likewise.
> 	* libcilkrts/runtime/signal_node.h: Likewise.
> 	* libcilkrts/runtime/spin_mutex.c: Likewise.
> 	* libcilkrts/runtime/spin_mutex.h: Likewise.
> 	* libcilkrts/runtime/stacks.h: Likewise.
> 	* libcilkrts/runtime/stats.c: Likewise.
> 	* libcilkrts/runtime/stats.h: Likewise.
> 	* libcilkrts/runtime/symbol_test.c: Likewise.
> 	* libcilkrts/runtime/sysdep-unix.c: Likewise.
> 	* libcilkrts/runtime/sysdep.h: Likewise.
> 	* libcilkrts/runtime/unix_symbols.t: Likewise.
> 	* libcilkrts/runtime/worker_mutex.c: Likewise.
> 	* libcilkrts/runtime/worker_mutex.h: Likewise.
>
> Thanks,
First, the all issues Joseph mentioned need to be addressed.  So first, 
you need to ensure it's only being built on x86/x86_64 given the asms 
and bring together some documentation as to what's needed to port the 
runtime system to other architectures.   Closely related, I think you 
initially need to ensure it only builds on x86-linux platforms -- unless 
you've already verified it works properly on one or more of the bsd 
platforms, solaris, windows, etc.

In the README, you'll want to update the reference to the cilkplus 
branch to something like GCC 4.9 or later since presumably the cilkplus 
branch will be retired once all the bits are in place.  It also mentions 
the GPL, so those bits are probably out of date given the plan to use 
the 3-clause BSD license, similarly for various other files.  A grep for 
GPL might be in order.

I didn't look at the make/configury closely.  It just makes my head 
hurt.  I'm going to assume nothing is terribly busted in there other 
than the need conditionalize properly per Joseph's comments, avoidance 
of DATE, TIME, and the like.

I would strongly echo Joseph's recommendation to ensure that only those 
symbols specifically intended to be part of the public interface are 
exported from the shared library. How stable has the exported API/ABI 
for Cilk+ been?    Related: how clean is the RTS from a compile-time 
namespace pollution standpoint.  For C++ is everything in a namespace, 
for C is everything prefixed appropriately?

Does this runtime include the complete cilkscreen race detector?  Was 
that intentional?

As I mentioned, we're not going to nitpick on the actual source of the 
runtime system because it's being maintained upstream by Intel.  So all 
the things which hurt my eyes when I scanned the library code, I'll just 
ignore.

Since this is being maintained upstream, a notice where to send any 
contributions would be wise.  Look at libsanitizer/README.gcc.

I'm assuming the multilib stuff works... :-0

Is this make -j clean to the best of your knowledge?


Jeff

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Cilk Library
  2013-10-15 20:14     ` Jeff Law
@ 2013-10-16  8:26       ` Richard Biener
  2013-10-16 19:30       ` Iyer, Balaji V
  1 sibling, 0 replies; 19+ messages in thread
From: Richard Biener @ 2013-10-16  8:26 UTC (permalink / raw)
  To: Jeff Law
  Cc: Iyer, Balaji V, gcc, Aldy Hernandez (aldyh@redhat.com),
	rth, Jason Merrill (jason@redhat.com)

On Tue, Oct 15, 2013 at 10:14 PM, Jeff Law <law@redhat.com> wrote:
> On 10/09/13 12:32, Iyer, Balaji V wrote:
>>
>> Dear Jeff and the rest of Steering committee members,
>>       Thank you very much for approving the license terms of the Cilk
>> Library. I couldn't attach the zipped copy of the patch due to its size, so
>> here is a link to the Cilk library patch that can be applied to the trunk:
>> (https://docs.google.com/file/d/0BzEpbbnrYKsSWjBWSkNrVS1SaGs/edit?usp=sharing).
>>
>>       Is it OK for trunk?
>>
>> Here are the ChangeLog entries:
>>
>> ChangeLog:
>> 2013-10-09  Balaji V. Iyer  <balaji.v.iyer@intel.com>
>>
>>          * Makefile.def: Add libcilkrts to target_modules.  Make
>> libcilkrts
>>          depend on libstdc++ and libgcc.
>>          * configure.ac: Added libcilkrts to target binaries.
>>          * configure: Likewise.
>>          * Makefile.in: Added libcilkrts related fields to support
>> building it.
>>
>> libcilkrts/ChangeLog:
>> 2013-10-09  Balaji V. Iyer  <balaji.v.iyer@intel.com>
>>
>>         * libcilkrts/Makefile.am: New file.  Libcilkrts version 3613.
>>         * libcilkrts/Makefile.in: Likewise.
>>         * libcilkrts/README: Likewise.
>>         * libcilkrts/aclocal.m4: Likewise.
>>         * libcilkrts/configure: Likewise.
>>         * libcilkrts/configure.ac: Likewise.
>>         * libcilkrts/include/cilk/cilk.h: Likewise.
>>         * libcilkrts/include/cilk/cilk_api.h: Likewise.
>>         * libcilkrts/include/cilk/cilk_api_linux.h: Likewise.
>>         * libcilkrts/include/cilk/cilk_stub.h: Likewise.
>>         * libcilkrts/include/cilk/cilk_undocumented.h: Likewise.
>>         * libcilkrts/include/cilk/common.h: Likewise.
>>         * libcilkrts/include/cilk/holder.h: Likewise.
>>         * libcilkrts/include/cilk/hyperobject_base.h: Likewise.
>>         * libcilkrts/include/cilk/metaprogramming.h: Likewise.
>>         * libcilkrts/include/cilk/reducer.h: Likewise.
>>         * libcilkrts/include/cilk/reducer_file.h: Likewise.
>>         * libcilkrts/include/cilk/reducer_list.h: Likewise.
>>         * libcilkrts/include/cilk/reducer_max.h: Likewise.
>>         * libcilkrts/include/cilk/reducer_min.h: Likewise.
>>         * libcilkrts/include/cilk/reducer_min_max.h: Likewise.
>>         * libcilkrts/include/cilk/reducer_opadd.h: Likewise.
>>         * libcilkrts/include/cilk/reducer_opand.h: Likewise.
>>         * libcilkrts/include/cilk/reducer_opmul.h: Likewise.
>>         * libcilkrts/include/cilk/reducer_opor.h: Likewise.
>>         * libcilkrts/include/cilk/reducer_opxor.h: Likewise.
>>         * libcilkrts/include/cilk/reducer_ostream.h: Likewise.
>>         * libcilkrts/include/cilk/reducer_string.h: Likewise.
>>         * libcilkrts/include/cilktools/cilkscreen.h: Likewise.
>>         * libcilkrts/include/cilktools/cilkview.h: Likewise.
>>         * libcilkrts/include/cilktools/fake_mutex.h: Likewise.
>>         * libcilkrts/include/cilktools/lock_guard.h: Likewise.
>>         * libcilkrts/include/internal/abi.h: Likewise.
>>         * libcilkrts/include/internal/cilk_fake.h: Likewise.
>>         * libcilkrts/include/internal/cilk_version.h: Likewise.
>>         * libcilkrts/include/internal/inspector-abi.h: Likewise.
>>         * libcilkrts/include/internal/metacall.h: Likewise.
>>         * libcilkrts/include/internal/rev.mk: Likewise.
>>         * libcilkrts/mk/cilk-version.mk: Likewise.
>>         * libcilkrts/mk/unix-common.mk: Likewise.
>>         * libcilkrts/runtime/acknowledgements.dox: Likewise.
>>         * libcilkrts/runtime/bug.cpp: Likewise.
>>         * libcilkrts/runtime/bug.h: Likewise.
>>         * libcilkrts/runtime/c_reducers.c: Likewise.
>>         * libcilkrts/runtime/cilk-abi-cilk-for.cpp: Likewise.
>>         * libcilkrts/runtime/cilk-abi-vla-internal.c: Likewise.
>>         * libcilkrts/runtime/cilk-abi-vla-internal.h: Likewise.
>>         * libcilkrts/runtime/cilk-abi-vla.c: Likewise.
>>         * libcilkrts/runtime/cilk-abi.c: Likewise.
>>         * libcilkrts/runtime/cilk-ittnotify.h: Likewise.
>>         * libcilkrts/runtime/cilk-tbb-interop.h: Likewise.
>>         * libcilkrts/runtime/cilk_api.c: Likewise.
>>         * libcilkrts/runtime/cilk_fiber-unix.cpp: Likewise.
>>         * libcilkrts/runtime/cilk_fiber-unix.h: Likewise.
>>         * libcilkrts/runtime/cilk_fiber.cpp: Likewise.
>>         * libcilkrts/runtime/cilk_fiber.h: Likewise.
>>         * libcilkrts/runtime/cilk_malloc.c: Likewise.
>>         * libcilkrts/runtime/cilk_malloc.h: Likewise.
>>         * libcilkrts/runtime/component.h: Likewise.
>>         * libcilkrts/runtime/doxygen-layout.xml: Likewise.
>>         * libcilkrts/runtime/doxygen.cfg: Likewise.
>>         * libcilkrts/runtime/except-gcc.cpp: Likewise.
>>         * libcilkrts/runtime/except-gcc.h: Likewise.
>>         * libcilkrts/runtime/except.h: Likewise.
>>         * libcilkrts/runtime/frame_malloc.c: Likewise.
>>         * libcilkrts/runtime/frame_malloc.h: Likewise.
>>         * libcilkrts/runtime/full_frame.c: Likewise.
>>         * libcilkrts/runtime/full_frame.h: Likewise.
>>         * libcilkrts/runtime/global_state.cpp: Likewise.
>>         * libcilkrts/runtime/global_state.h: Likewise.
>>         * libcilkrts/runtime/jmpbuf.c: Likewise.
>>         * libcilkrts/runtime/jmpbuf.h: Likewise.
>>         * libcilkrts/runtime/local_state.c: Likewise.
>>         * libcilkrts/runtime/local_state.h: Likewise.
>>         * libcilkrts/runtime/metacall_impl.c: Likewise.
>>         * libcilkrts/runtime/metacall_impl.h: Likewise.
>>         * libcilkrts/runtime/os-unix.c: Likewise.
>>         * libcilkrts/runtime/os.h: Likewise.
>>         * libcilkrts/runtime/os_mutex-unix.c: Likewise.
>>         * libcilkrts/runtime/os_mutex.h: Likewise.
>>         * libcilkrts/runtime/pedigrees.c: Likewise.
>>         * libcilkrts/runtime/pedigrees.h: Likewise.
>>         * libcilkrts/runtime/record-replay.cpp: Likewise.
>>         * libcilkrts/runtime/record-replay.h: Likewise.
>>         * libcilkrts/runtime/reducer_impl.cpp: Likewise.
>>         * libcilkrts/runtime/reducer_impl.h: Likewise.
>>         * libcilkrts/runtime/rts-common.h: Likewise.
>>         * libcilkrts/runtime/scheduler.c: Likewise.
>>         * libcilkrts/runtime/scheduler.h: Likewise.
>>         * libcilkrts/runtime/signal_node.c: Likewise.
>>         * libcilkrts/runtime/signal_node.h: Likewise.
>>         * libcilkrts/runtime/spin_mutex.c: Likewise.
>>         * libcilkrts/runtime/spin_mutex.h: Likewise.
>>         * libcilkrts/runtime/stacks.h: Likewise.
>>         * libcilkrts/runtime/stats.c: Likewise.
>>         * libcilkrts/runtime/stats.h: Likewise.
>>         * libcilkrts/runtime/symbol_test.c: Likewise.
>>         * libcilkrts/runtime/sysdep-unix.c: Likewise.
>>         * libcilkrts/runtime/sysdep.h: Likewise.
>>         * libcilkrts/runtime/unix_symbols.t: Likewise.
>>         * libcilkrts/runtime/worker_mutex.c: Likewise.
>>         * libcilkrts/runtime/worker_mutex.h: Likewise.
>>
>> Thanks,
>
> First, the all issues Joseph mentioned need to be addressed.  So first, you
> need to ensure it's only being built on x86/x86_64 given the asms and bring
> together some documentation as to what's needed to port the runtime system
> to other architectures.   Closely related, I think you initially need to
> ensure it only builds on x86-linux platforms -- unless you've already
> verified it works properly on one or more of the bsd platforms, solaris,
> windows, etc.
>
> In the README, you'll want to update the reference to the cilkplus branch to
> something like GCC 4.9 or later since presumably the cilkplus branch will be
> retired once all the bits are in place.  It also mentions the GPL, so those
> bits are probably out of date given the plan to use the 3-clause BSD
> license, similarly for various other files.  A grep for GPL might be in
> order.
>
> I didn't look at the make/configury closely.  It just makes my head hurt.
> I'm going to assume nothing is terribly busted in there other than the need
> conditionalize properly per Joseph's comments, avoidance of DATE, TIME, and
> the like.
>
> I would strongly echo Joseph's recommendation to ensure that only those
> symbols specifically intended to be part of the public interface are
> exported from the shared library.

As RM I strongly object to adding a runtime library that does not apply
basic symbol export control and versioning.  If you are restricting yourselves
to x86-linux for now anyway it should be pretty easy to setup a linker
version script for this.

Richard.

> How stable has the exported API/ABI for
> Cilk+ been?    Related: how clean is the RTS from a compile-time namespace
> pollution standpoint.  For C++ is everything in a namespace, for C is
> everything prefixed appropriately?
>
> Does this runtime include the complete cilkscreen race detector?  Was that
> intentional?
>
> As I mentioned, we're not going to nitpick on the actual source of the
> runtime system because it's being maintained upstream by Intel.  So all the
> things which hurt my eyes when I scanned the library code, I'll just ignore.
>
> Since this is being maintained upstream, a notice where to send any
> contributions would be wise.  Look at libsanitizer/README.gcc.
>
> I'm assuming the multilib stuff works... :-0
>
> Is this make -j clean to the best of your knowledge?
>
>
> Jeff

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: Cilk Library
  2013-10-15 20:14     ` Jeff Law
  2013-10-16  8:26       ` Richard Biener
@ 2013-10-16 19:30       ` Iyer, Balaji V
  2013-10-23  5:14         ` Jeff Law
  1 sibling, 1 reply; 19+ messages in thread
From: Iyer, Balaji V @ 2013-10-16 19:30 UTC (permalink / raw)
  To: Jeff Law, gcc
  Cc: Aldy Hernandez (aldyh@redhat.com), rth, Jason Merrill (jason@redhat.com)

Hello Jeff,	
	Please see my comments below:

Thanks,

Balaji V. Iyer.


> -----Original Message-----
> From: Jeff Law [mailto:law@redhat.com]
> Sent: Tuesday, October 15, 2013 4:14 PM
> To: Iyer, Balaji V; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (aldyh@redhat.com); rth@redhat.com; Jason Merrill
> (jason@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/09/13 12:32, Iyer, Balaji V wrote:
> > Dear Jeff and the rest of Steering committee members,
> >       Thank you very much for approving the license terms of the Cilk Library. I
> couldn't attach the zipped copy of the patch due to its size, so here is a link to
> the Cilk library patch that can be applied to the trunk:
> (https://docs.google.com/file/d/0BzEpbbnrYKsSWjBWSkNrVS1SaGs/edit?usp=sh
> aring).
> >
> >       Is it OK for trunk?
> >
> > Here are the ChangeLog entries:
> >
> > ChangeLog:
> > 2013-10-09  Balaji V. Iyer  <balaji.v.iyer@intel.com>
> >
> >          * Makefile.def: Add libcilkrts to target_modules.  Make libcilkrts
> >          depend on libstdc++ and libgcc.
> >          * configure.ac: Added libcilkrts to target binaries.
> >          * configure: Likewise.
> >          * Makefile.in: Added libcilkrts related fields to support building it.
> >
> > libcilkrts/ChangeLog:
> > 2013-10-09  Balaji V. Iyer  <balaji.v.iyer@intel.com>
> >
> > 	* libcilkrts/Makefile.am: New file.  Libcilkrts version 3613.
> > 	* libcilkrts/Makefile.in: Likewise.
> > 	* libcilkrts/README: Likewise.
> > 	* libcilkrts/aclocal.m4: Likewise.
> > 	* libcilkrts/configure: Likewise.
> > 	* libcilkrts/configure.ac: Likewise.
> > 	* libcilkrts/include/cilk/cilk.h: Likewise.
> > 	* libcilkrts/include/cilk/cilk_api.h: Likewise.
> > 	* libcilkrts/include/cilk/cilk_api_linux.h: Likewise.
> > 	* libcilkrts/include/cilk/cilk_stub.h: Likewise.
> > 	* libcilkrts/include/cilk/cilk_undocumented.h: Likewise.
> > 	* libcilkrts/include/cilk/common.h: Likewise.
> > 	* libcilkrts/include/cilk/holder.h: Likewise.
> > 	* libcilkrts/include/cilk/hyperobject_base.h: Likewise.
> > 	* libcilkrts/include/cilk/metaprogramming.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer_file.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer_list.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer_max.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer_min.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer_min_max.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer_opadd.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer_opand.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer_opmul.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer_opor.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer_opxor.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer_ostream.h: Likewise.
> > 	* libcilkrts/include/cilk/reducer_string.h: Likewise.
> > 	* libcilkrts/include/cilktools/cilkscreen.h: Likewise.
> > 	* libcilkrts/include/cilktools/cilkview.h: Likewise.
> > 	* libcilkrts/include/cilktools/fake_mutex.h: Likewise.
> > 	* libcilkrts/include/cilktools/lock_guard.h: Likewise.
> > 	* libcilkrts/include/internal/abi.h: Likewise.
> > 	* libcilkrts/include/internal/cilk_fake.h: Likewise.
> > 	* libcilkrts/include/internal/cilk_version.h: Likewise.
> > 	* libcilkrts/include/internal/inspector-abi.h: Likewise.
> > 	* libcilkrts/include/internal/metacall.h: Likewise.
> > 	* libcilkrts/include/internal/rev.mk: Likewise.
> > 	* libcilkrts/mk/cilk-version.mk: Likewise.
> > 	* libcilkrts/mk/unix-common.mk: Likewise.
> > 	* libcilkrts/runtime/acknowledgements.dox: Likewise.
> > 	* libcilkrts/runtime/bug.cpp: Likewise.
> > 	* libcilkrts/runtime/bug.h: Likewise.
> > 	* libcilkrts/runtime/c_reducers.c: Likewise.
> > 	* libcilkrts/runtime/cilk-abi-cilk-for.cpp: Likewise.
> > 	* libcilkrts/runtime/cilk-abi-vla-internal.c: Likewise.
> > 	* libcilkrts/runtime/cilk-abi-vla-internal.h: Likewise.
> > 	* libcilkrts/runtime/cilk-abi-vla.c: Likewise.
> > 	* libcilkrts/runtime/cilk-abi.c: Likewise.
> > 	* libcilkrts/runtime/cilk-ittnotify.h: Likewise.
> > 	* libcilkrts/runtime/cilk-tbb-interop.h: Likewise.
> > 	* libcilkrts/runtime/cilk_api.c: Likewise.
> > 	* libcilkrts/runtime/cilk_fiber-unix.cpp: Likewise.
> > 	* libcilkrts/runtime/cilk_fiber-unix.h: Likewise.
> > 	* libcilkrts/runtime/cilk_fiber.cpp: Likewise.
> > 	* libcilkrts/runtime/cilk_fiber.h: Likewise.
> > 	* libcilkrts/runtime/cilk_malloc.c: Likewise.
> > 	* libcilkrts/runtime/cilk_malloc.h: Likewise.
> > 	* libcilkrts/runtime/component.h: Likewise.
> > 	* libcilkrts/runtime/doxygen-layout.xml: Likewise.
> > 	* libcilkrts/runtime/doxygen.cfg: Likewise.
> > 	* libcilkrts/runtime/except-gcc.cpp: Likewise.
> > 	* libcilkrts/runtime/except-gcc.h: Likewise.
> > 	* libcilkrts/runtime/except.h: Likewise.
> > 	* libcilkrts/runtime/frame_malloc.c: Likewise.
> > 	* libcilkrts/runtime/frame_malloc.h: Likewise.
> > 	* libcilkrts/runtime/full_frame.c: Likewise.
> > 	* libcilkrts/runtime/full_frame.h: Likewise.
> > 	* libcilkrts/runtime/global_state.cpp: Likewise.
> > 	* libcilkrts/runtime/global_state.h: Likewise.
> > 	* libcilkrts/runtime/jmpbuf.c: Likewise.
> > 	* libcilkrts/runtime/jmpbuf.h: Likewise.
> > 	* libcilkrts/runtime/local_state.c: Likewise.
> > 	* libcilkrts/runtime/local_state.h: Likewise.
> > 	* libcilkrts/runtime/metacall_impl.c: Likewise.
> > 	* libcilkrts/runtime/metacall_impl.h: Likewise.
> > 	* libcilkrts/runtime/os-unix.c: Likewise.
> > 	* libcilkrts/runtime/os.h: Likewise.
> > 	* libcilkrts/runtime/os_mutex-unix.c: Likewise.
> > 	* libcilkrts/runtime/os_mutex.h: Likewise.
> > 	* libcilkrts/runtime/pedigrees.c: Likewise.
> > 	* libcilkrts/runtime/pedigrees.h: Likewise.
> > 	* libcilkrts/runtime/record-replay.cpp: Likewise.
> > 	* libcilkrts/runtime/record-replay.h: Likewise.
> > 	* libcilkrts/runtime/reducer_impl.cpp: Likewise.
> > 	* libcilkrts/runtime/reducer_impl.h: Likewise.
> > 	* libcilkrts/runtime/rts-common.h: Likewise.
> > 	* libcilkrts/runtime/scheduler.c: Likewise.
> > 	* libcilkrts/runtime/scheduler.h: Likewise.
> > 	* libcilkrts/runtime/signal_node.c: Likewise.
> > 	* libcilkrts/runtime/signal_node.h: Likewise.
> > 	* libcilkrts/runtime/spin_mutex.c: Likewise.
> > 	* libcilkrts/runtime/spin_mutex.h: Likewise.
> > 	* libcilkrts/runtime/stacks.h: Likewise.
> > 	* libcilkrts/runtime/stats.c: Likewise.
> > 	* libcilkrts/runtime/stats.h: Likewise.
> > 	* libcilkrts/runtime/symbol_test.c: Likewise.
> > 	* libcilkrts/runtime/sysdep-unix.c: Likewise.
> > 	* libcilkrts/runtime/sysdep.h: Likewise.
> > 	* libcilkrts/runtime/unix_symbols.t: Likewise.
> > 	* libcilkrts/runtime/worker_mutex.c: Likewise.
> > 	* libcilkrts/runtime/worker_mutex.h: Likewise.
> >
> > Thanks,
> First, the all issues Joseph mentioned need to be addressed.  So first, you need
> to ensure it's only being built on x86/x86_64 given the asms and bring together
> some documentation as to what's needed to port the
> runtime system to other architectures.   Closely related, I think you
> initially need to ensure it only builds on x86-linux platforms -- unless you've
> already verified it works properly on one or more of the bsd platforms, solaris,
> windows, etc.
> 

We are in the process of addressing all these. I will send out an email with the fixed runtime as soon as I can.

> In the README, you'll want to update the reference to the cilkplus branch to
> something like GCC 4.9 or later since presumably the cilkplus branch will be
> retired once all the bits are in place.  It also mentions the GPL, so those bits are
> probably out of date given the plan to use the 3-clause BSD license, similarly for
> various other files.  A grep for GPL might be in order.
> 

Yup, this is caught and fixed in the Readme. The newer one that we will send shortly should reflect this.

> I didn't look at the make/configury closely.  It just makes my head hurt.  I'm
> going to assume nothing is terribly busted in there other than the need
> conditionalize properly per Joseph's comments, avoidance of DATE, TIME, and
> the like.
> 
> I would strongly echo Joseph's recommendation to ensure that only those
> symbols specifically intended to be part of the public interface are exported
> from the shared library. How stable has the exported API/ABI
> for Cilk+ been?    Related: how clean is the RTS from a compile-time
> namespace pollution standpoint.  For C++ is everything in a namespace, for C is
> everything prefixed appropriately?
> 

We are currently verifying those and making sure only the required symbols are exported.

> Does this runtime include the complete cilkscreen race detector?  Was that
> intentional?
> 

Cilkscreen binaries are available for free from our website (www.cilkplus.org). To use Cilkscreen, compiler must insert some information about location of Spawn, continuation, sync points, etc. into the executable. I am hoping to submit those changes as a separate patch after I submit all the Cilk Plus features.

> As I mentioned, we're not going to nitpick on the actual source of the runtime
> system because it's being maintained upstream by Intel.  So all the things which
> hurt my eyes when I scanned the library code, I'll just ignore.
> 
> Since this is being maintained upstream, a notice where to send any
> contributions would be wise.  Look at libsanitizer/README.gcc.
> 
> I'm assuming the multilib stuff works... :-0
> 

Yes, multilib works correctly. 


> Is this make -j clean to the best of your knowledge?
> 
> 

Yes, make -j8 seem to work well for me when I use it in the Cilkplus branch.

> Jeff

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Cilk Library
  2013-10-16 19:30       ` Iyer, Balaji V
@ 2013-10-23  5:14         ` Jeff Law
  2013-10-23 14:10           ` Iyer, Balaji V
  2013-10-23 19:30           ` Iyer, Balaji V
  0 siblings, 2 replies; 19+ messages in thread
From: Jeff Law @ 2013-10-23  5:14 UTC (permalink / raw)
  To: Iyer, Balaji V, gcc
  Cc: Aldy Hernandez (aldyh@redhat.com), rth, Jason Merrill (jason@redhat.com)

On 10/16/13 13:30, Iyer, Balaji V wrote:
>> First, the all issues Joseph mentioned need to be addressed.  So first, you need
>> to ensure it's only being built on x86/x86_64 given the asms and bring together
>> some documentation as to what's needed to port the
>> runtime system to other architectures.   Closely related, I think you
>> initially need to ensure it only builds on x86-linux platforms -- unless you've
>> already verified it works properly on one or more of the bsd platforms, solaris,
>> windows, etc.
>>
>
> We are in the process of addressing all these. I will send out an email with the fixed runtime as soon as I can.
Excellent.  THanks.


>> I would strongly echo Joseph's recommendation to ensure that only those
>> symbols specifically intended to be part of the public interface are exported
>> from the shared library. How stable has the exported API/ABI
>> for Cilk+ been?    Related: how clean is the RTS from a compile-time
>> namespace pollution standpoint.  For C++ is everything in a namespace, for C is
>> everything prefixed appropriately?
>>
>
> We are currently verifying those and making sure only the required symbols are exported.
IMHO, the best way to do this is with linker scripts and it's an 
excellent time ot drop in versioning information.  I'd think this would 
be useful for ICC as well.  This is probably the biggest issue.  I'll 
note Richi chimed in on this as well.

Look at libatomic/libatomic.map and how that gets used.  It gives you 
full control over the exports.

jeff

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: Cilk Library
  2013-10-23  5:14         ` Jeff Law
@ 2013-10-23 14:10           ` Iyer, Balaji V
  2013-10-23 19:30           ` Iyer, Balaji V
  1 sibling, 0 replies; 19+ messages in thread
From: Iyer, Balaji V @ 2013-10-23 14:10 UTC (permalink / raw)
  To: Jeff Law, gcc
  Cc: Aldy Hernandez (aldyh@redhat.com), rth, Jason Merrill (jason@redhat.com)



> -----Original Message-----
> From: Jeff Law [mailto:law@redhat.com]
> Sent: Wednesday, October 23, 2013 1:15 AM
> To: Iyer, Balaji V; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (aldyh@redhat.com); rth@redhat.com; Jason Merrill
> (jason@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/16/13 13:30, Iyer, Balaji V wrote:
> >> First, the all issues Joseph mentioned need to be addressed.  So
> >> first, you need to ensure it's only being built on x86/x86_64 given
> >> the asms and bring together some documentation as to what's needed to
> port the
> >> runtime system to other architectures.   Closely related, I think you
> >> initially need to ensure it only builds on x86-linux platforms --
> >> unless you've already verified it works properly on one or more of
> >> the bsd platforms, solaris, windows, etc.
> >>
> >
> > We are in the process of addressing all these. I will send out an email with the
> fixed runtime as soon as I can.
> Excellent.  THanks.
> 
> 
> >> I would strongly echo Joseph's recommendation to ensure that only
> >> those symbols specifically intended to be part of the public
> >> interface are exported from the shared library. How stable has the exported
> API/ABI
> >> for Cilk+ been?    Related: how clean is the RTS from a compile-time
> >> namespace pollution standpoint.  For C++ is everything in a
> >> namespace, for C is everything prefixed appropriately?
> >>
> >
> > We are currently verifying those and making sure only the required symbols
> are exported.
> IMHO, the best way to do this is with linker scripts and it's an excellent time ot
> drop in versioning information.  I'd think this would be useful for ICC as well.
> This is probably the biggest issue.  I'll note Richi chimed in on this as well.
> 
Yup we have implemented versioning. Also, we have just completed all the things that Joseph Myers mentioned and are in the process of testing it. I will send out a revised patch this week itself.

> Look at libatomic/libatomic.map and how that gets used.  It gives you full
> control over the exports.
> 
> jeff

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: Cilk Library
  2013-10-23  5:14         ` Jeff Law
  2013-10-23 14:10           ` Iyer, Balaji V
@ 2013-10-23 19:30           ` Iyer, Balaji V
  2013-10-23 20:22             ` Joseph S. Myers
  2013-10-24 16:14             ` Richard Henderson
  1 sibling, 2 replies; 19+ messages in thread
From: Iyer, Balaji V @ 2013-10-23 19:30 UTC (permalink / raw)
  To: Jeff Law, gcc
  Cc: Aldy Hernandez (aldyh@redhat.com),
	rth, Jason Merrill (jason@redhat.com),
	Joseph S. Myers

Hi Jeff et al.,
	Here is a link to the updated patch (https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=sharing). We have fixed all the issues that Joseph pointed out in http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html. We have also added symbol versioning and have double-checked (using nm) that all symbols are hidden unless we have explicitly allowed them to be public.

Thanks,

Balaji V. Iyer.

> -----Original Message-----
> From: Jeff Law [mailto:law@redhat.com]
> Sent: Wednesday, October 23, 2013 1:15 AM
> To: Iyer, Balaji V; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (aldyh@redhat.com); rth@redhat.com; Jason Merrill
> (jason@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/16/13 13:30, Iyer, Balaji V wrote:
> >> First, the all issues Joseph mentioned need to be addressed.  So
> >> first, you need to ensure it's only being built on x86/x86_64 given
> >> the asms and bring together some documentation as to what's needed to
> port the
> >> runtime system to other architectures.   Closely related, I think you
> >> initially need to ensure it only builds on x86-linux platforms --
> >> unless you've already verified it works properly on one or more of
> >> the bsd platforms, solaris, windows, etc.
> >>
> >
> > We are in the process of addressing all these. I will send out an email with the
> fixed runtime as soon as I can.
> Excellent.  THanks.
> 
> 
> >> I would strongly echo Joseph's recommendation to ensure that only
> >> those symbols specifically intended to be part of the public
> >> interface are exported from the shared library. How stable has the exported
> API/ABI
> >> for Cilk+ been?    Related: how clean is the RTS from a compile-time
> >> namespace pollution standpoint.  For C++ is everything in a
> >> namespace, for C is everything prefixed appropriately?
> >>
> >
> > We are currently verifying those and making sure only the required symbols
> are exported.
> IMHO, the best way to do this is with linker scripts and it's an excellent time ot
> drop in versioning information.  I'd think this would be useful for ICC as well.
> This is probably the biggest issue.  I'll note Richi chimed in on this as well.
> 
> Look at libatomic/libatomic.map and how that gets used.  It gives you full
> control over the exports.
> 
> jeff

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: Cilk Library
  2013-10-23 19:30           ` Iyer, Balaji V
@ 2013-10-23 20:22             ` Joseph S. Myers
  2013-10-23 20:32               ` Jeff Law
  2013-10-24 16:14             ` Richard Henderson
  1 sibling, 1 reply; 19+ messages in thread
From: Joseph S. Myers @ 2013-10-23 20:22 UTC (permalink / raw)
  To: Iyer, Balaji V
  Cc: Jeff Law, gcc, Aldy Hernandez (aldyh@redhat.com),
	rth, Jason Merrill (jason@redhat.com)

On Wed, 23 Oct 2013, Iyer, Balaji V wrote:

> Hi Jeff et al.,
> 	Here is a link to the updated patch 
> (https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=sharing). 
> We have fixed all the issues that Joseph pointed out in 
> http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html. We have also added 
> symbol versioning and have double-checked (using nm) that all symbols 
> are hidden unless we have explicitly allowed them to be public.

As I said in my previous comments, please follow libatomic, libitm, 
libsanitizer or libvtv in using a configure.tgt file in the library's 
subdirectory to describe what systems are supported.  This is especially 
important now that all toplevel patches need applying to three rather than 
two repositories (GCC SVN, src CVS, binutils-gdb git) - anything logically 
specific to one of those three should go in an appropriate subdirectory 
whenever possible, to reduce the number of changes needing syncing to 
multiple places.

(Yes, there's lots of configuration specific to newlib/libgloss, binutils, 
gdb or individual GCC libraries that's still hardcoded in the toplevel 
configure.ac and should move to such configure.tgt or similar files in 
subdirectories.  Patches moving it to such files are certainly welcome.  
But at least we shouldn't add new directories with details at toplevel of 
what targets they support.)

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Cilk Library
  2013-10-23 20:22             ` Joseph S. Myers
@ 2013-10-23 20:32               ` Jeff Law
  2013-10-24 15:46                 ` Iyer, Balaji V
  0 siblings, 1 reply; 19+ messages in thread
From: Jeff Law @ 2013-10-23 20:32 UTC (permalink / raw)
  To: Joseph S. Myers, Iyer, Balaji V
  Cc: gcc, Aldy Hernandez (aldyh@redhat.com),
	rth, Jason Merrill (jason@redhat.com)

On 10/23/13 14:22, Joseph S. Myers wrote:
> On Wed, 23 Oct 2013, Iyer, Balaji V wrote:
>
>> Hi Jeff et al.,
>> 	Here is a link to the updated patch
>> (https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=sharing).
>> We have fixed all the issues that Joseph pointed out in
>> http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html. We have also added
>> symbol versioning and have double-checked (using nm) that all symbols
>> are hidden unless we have explicitly allowed them to be public.
>
> As I said in my previous comments, please follow libatomic, libitm,
> libsanitizer or libvtv in using a configure.tgt file in the library's
> subdirectory to describe what systems are supported.  This is especially
> important now that all toplevel patches need applying to three rather than
> two repositories (GCC SVN, src CVS, binutils-gdb git) - anything logically
> specific to one of those three should go in an appropriate subdirectory
> whenever possible, to reduce the number of changes needing syncing to
> multiple places.
It also just makes sense from a modularity point of view.  Whether or 
not cilkrts is supported is a property of cilkrts and thus code to 
detect that and "do the right thing" should live within the cilkrts 
directory.


> (Yes, there's lots of configuration specific to newlib/libgloss, binutils,
> gdb or individual GCC libraries that's still hardcoded in the toplevel
> configure.ac and should move to such configure.tgt or similar files in
> subdirectories.  Patches moving it to such files are certainly welcome.
> But at least we shouldn't add new directories with details at toplevel of
> what targets they support.)
Agreed.  There's a lot of cruft up there that needs to move down into 
the subdirectories.  Unfortunately there's not many people actively 
working to address these maintenance issues.


I didn't see anything else grossly wrong.  I think once the 
configure.tgt stuff is addressed, this patch is good to go.   As 
previously discussed, don't actually check it in until the final 
approval is in place for the keywords.

jeff

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: Cilk Library
  2013-10-23 20:32               ` Jeff Law
@ 2013-10-24 15:46                 ` Iyer, Balaji V
  0 siblings, 0 replies; 19+ messages in thread
From: Iyer, Balaji V @ 2013-10-24 15:46 UTC (permalink / raw)
  To: Jeff Law, Joseph S. Myers
  Cc: gcc, Aldy Hernandez (aldyh@redhat.com),
	rth, Jason Merrill (jason@redhat.com)

Hi Joseph and Jeff,
	The issue you mentioned below is fixed. I added a configure.tgt file in libcilkrts and modified configure.ac (both libcilkrts and the toplevel gcc one) accordingly. Here is a link for the patch (https://drive.google.com/file/d/0BzEpbbnrYKsSZFR6cktQQWtXQms/edit?usp=sharing).

Thanks,

Balaji V. Iyer.

> -----Original Message-----
> From: Jeff Law [mailto:law@redhat.com]
> Sent: Wednesday, October 23, 2013 4:33 PM
> To: Joseph S. Myers; Iyer, Balaji V
> Cc: gcc@gcc.gnu.org; Aldy Hernandez (aldyh@redhat.com); rth@redhat.com;
> Jason Merrill (jason@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/23/13 14:22, Joseph S. Myers wrote:
> > On Wed, 23 Oct 2013, Iyer, Balaji V wrote:
> >
> >> Hi Jeff et al.,
> >> 	Here is a link to the updated patch
> >>
> (https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=s
> haring).
> >> We have fixed all the issues that Joseph pointed out in
> >> http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html. We have also added
> >> symbol versioning and have double-checked (using nm) that all symbols
> >> are hidden unless we have explicitly allowed them to be public.
> >
> > As I said in my previous comments, please follow libatomic, libitm,
> > libsanitizer or libvtv in using a configure.tgt file in the library's
> > subdirectory to describe what systems are supported.  This is
> > especially important now that all toplevel patches need applying to
> > three rather than two repositories (GCC SVN, src CVS, binutils-gdb
> > git) - anything logically specific to one of those three should go in
> > an appropriate subdirectory whenever possible, to reduce the number of
> > changes needing syncing to multiple places.
> It also just makes sense from a modularity point of view.  Whether or not cilkrts
> is supported is a property of cilkrts and thus code to detect that and "do the
> right thing" should live within the cilkrts directory.
> 
> 
> > (Yes, there's lots of configuration specific to newlib/libgloss,
> > binutils, gdb or individual GCC libraries that's still hardcoded in
> > the toplevel configure.ac and should move to such configure.tgt or
> > similar files in subdirectories.  Patches moving it to such files are certainly
> welcome.
> > But at least we shouldn't add new directories with details at toplevel
> > of what targets they support.)
> Agreed.  There's a lot of cruft up there that needs to move down into the
> subdirectories.  Unfortunately there's not many people actively working to
> address these maintenance issues.
> 
> 
> I didn't see anything else grossly wrong.  I think once the
> configure.tgt stuff is addressed, this patch is good to go.   As
> previously discussed, don't actually check it in until the final approval is in place
> for the keywords.
> 

> jeff

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Cilk Library
  2013-10-23 19:30           ` Iyer, Balaji V
  2013-10-23 20:22             ` Joseph S. Myers
@ 2013-10-24 16:14             ` Richard Henderson
  2013-10-24 20:43               ` Iyer, Balaji V
  1 sibling, 1 reply; 19+ messages in thread
From: Richard Henderson @ 2013-10-24 16:14 UTC (permalink / raw)
  To: Iyer, Balaji V, Jeff Law, gcc
  Cc: Aldy Hernandez (aldyh@redhat.com),
	Jason Merrill (jason@redhat.com),
	Joseph S. Myers

On 10/23/2013 12:30 PM, Iyer, Balaji V wrote:
> Hi Jeff et al.,
> 	Here is a link to the updated patch (https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=sharing). We have fixed all the issues that Joseph pointed out in http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html. We have also added symbol versioning and have double-checked (using nm) that all symbols are hidden unless we have explicitly allowed them to be public.
> 


In file included from ../../../git-master/libcilkrts/runtime/cilk-abi.c:52:0:
../../../git-master/libcilkrts/include/cilk/cilk_api.h:59:9: warning: #warning
Cilk API is being used with non-Cilk compiler (or Cilk is disabled) [-Wcpp]
 #       warning Cilk API is being used with non-Cilk compiler (or Cilk is
disabled)

and similar for

 ../../../git-master/libcilkrts/runtime/global_state.cpp:44
 ../../../git-master/libcilkrts/runtime/reducer_impl.cpp:59
 ../../../git-master/libcilkrts/runtime/scheduler.c:74:0:

> CILKABI1
> {
>   global:
>     __cilkrts_bind_thread_1;
>     __cilkrts_bump_loop_rank;
>     __cilkrts_bump_loop_rank_internal;
>     __cilkrts_bump_worker_rank;
>     __cilkrts_bump_worker_rank_internal;
>     __cilkrts_enter_frame_1;
>     __cilkrts_enter_frame_fast_1;
>     __cilkrts_get_pedigree_info;
>     __cilkrts_get_pedigree_internal;
>     __cilkrts_get_sf;
>     __cilkrts_get_stack_size;
>     __cilkrts_get_worker_rank;
>     __cilkrts_save_fp_ctrl_state;
>     __cilkrts_stack_alloc;
>     __cilkrts_stack_free;
>     __cilkrts_watch_stack;
> };

You probably want CILKABI1 to inherit from CILKABI0.  E.g.

  } CLKABI0;

Is there any relation between these and CILKLIB1.02?


r~

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: Cilk Library
  2013-10-24 16:14             ` Richard Henderson
@ 2013-10-24 20:43               ` Iyer, Balaji V
  2013-10-24 21:06                 ` Richard Henderson
  0 siblings, 1 reply; 19+ messages in thread
From: Iyer, Balaji V @ 2013-10-24 20:43 UTC (permalink / raw)
  To: Richard Henderson, Jeff Law, gcc
  Cc: Aldy Hernandez (aldyh@redhat.com),
	Jason Merrill (jason@redhat.com),
	Joseph S. Myers

Hi Richard,
	Here is the link to the fixed patch (https://drive.google.com/file/d/0BzEpbbnrYKsSNmpmM3NlRThfcWc/edit?usp=sharing). Answers to your questions are given below.

Thanks,

Balaji V. Iyer.

> -----Original Message-----
> From: Richard Henderson [mailto:rth@redhat.com]
> Sent: Thursday, October 24, 2013 12:15 PM
> To: Iyer, Balaji V; Jeff Law; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (aldyh@redhat.com); Jason Merrill (jason@redhat.com);
> Joseph S. Myers
> Subject: Re: Cilk Library
> 
> On 10/23/2013 12:30 PM, Iyer, Balaji V wrote:
> > Hi Jeff et al.,
> > 	Here is a link to the updated patch
> (https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=s
> haring). We have fixed all the issues that Joseph pointed out in
> http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html. We have also added
> symbol versioning and have double-checked (using nm) that all symbols are
> hidden unless we have explicitly allowed them to be public.
> >
> 
> 
> In file included from ../../../git-master/libcilkrts/runtime/cilk-abi.c:52:0:
> ../../../git-master/libcilkrts/include/cilk/cilk_api.h:59:9: warning: #warning Cilk
> API is being used with non-Cilk compiler (or Cilk is disabled) [-Wcpp]
>  #       warning Cilk API is being used with non-Cilk compiler (or Cilk is
> disabled)
> 
> and similar for
> 
>  ../../../git-master/libcilkrts/runtime/global_state.cpp:44
>  ../../../git-master/libcilkrts/runtime/reducer_impl.cpp:59
>  ../../../git-master/libcilkrts/runtime/scheduler.c:74:0:

To compile Cilk Library (libcilkrts), the compiler must have _Cilk_spawn and _Cilk_sync support. For this patch, I have defined (please see Makefile.am under GENERAL_FLAGS) the cilk-keywords to NULL to make this patch compile. When I commit this patch, I will commit the patches in the following order (after everything is approved that is):

1. Commit the _Cilk_spawn and _Cilk_sync for C and C++
2. Remove the -D_Cilk_spawn="" and -D_Cilk_sync="" and -D_Cilk_for=for from the Makefile.am
3. Commit the Cilk library patch

If we do it in the above order, you won't see those warnings.

> 
> > CILKABI1
> > {
> >   global:
> >     __cilkrts_bind_thread_1;
> >     __cilkrts_bump_loop_rank;
> >     __cilkrts_bump_loop_rank_internal;
> >     __cilkrts_bump_worker_rank;
> >     __cilkrts_bump_worker_rank_internal;
> >     __cilkrts_enter_frame_1;
> >     __cilkrts_enter_frame_fast_1;
> >     __cilkrts_get_pedigree_info;
> >     __cilkrts_get_pedigree_internal;
> >     __cilkrts_get_sf;
> >     __cilkrts_get_stack_size;
> >     __cilkrts_get_worker_rank;
> >     __cilkrts_save_fp_ctrl_state;
> >     __cilkrts_stack_alloc;
> >     __cilkrts_stack_free;
> >     __cilkrts_watch_stack;
> > };
> 
> You probably want CILKABI1 to inherit from CILKABI0.  E.g.

The inheritance is added.

> 
>   } CLKABI0;
> 
> Is there any relation between these and CILKLIB1.02?
> 

There is no relation. They simply are exported by the same shared object.

> 
> r~

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Cilk Library
  2013-10-24 20:43               ` Iyer, Balaji V
@ 2013-10-24 21:06                 ` Richard Henderson
  0 siblings, 0 replies; 19+ messages in thread
From: Richard Henderson @ 2013-10-24 21:06 UTC (permalink / raw)
  To: Iyer, Balaji V, Jeff Law, gcc
  Cc: Aldy Hernandez (aldyh@redhat.com),
	Jason Merrill (jason@redhat.com),
	Joseph S. Myers

On 10/24/2013 01:43 PM, Iyer, Balaji V wrote:
>> In file included from ../../../git-master/libcilkrts/runtime/cilk-abi.c:52:0:
>> ../../../git-master/libcilkrts/include/cilk/cilk_api.h:59:9: warning: #warning Cilk
>> API is being used with non-Cilk compiler (or Cilk is disabled) [-Wcpp]
>>  #       warning Cilk API is being used with non-Cilk compiler (or Cilk is
>> disabled)
>>
>> and similar for
>>
>>  ../../../git-master/libcilkrts/runtime/global_state.cpp:44
>>  ../../../git-master/libcilkrts/runtime/reducer_impl.cpp:59
>>  ../../../git-master/libcilkrts/runtime/scheduler.c:74:0:
> 
> To compile Cilk Library (libcilkrts), the compiler must have _Cilk_spawn and _Cilk_sync support. For this patch, I have defined (please see Makefile.am under GENERAL_FLAGS) the cilk-keywords to NULL to make this patch compile. When I commit this patch, I will commit the patches in the following order (after everything is approved that is):
> 
> 1. Commit the _Cilk_spawn and _Cilk_sync for C and C++
> 2. Remove the -D_Cilk_spawn="" and -D_Cilk_sync="" and -D_Cilk_for=for from the Makefile.am
> 3. Commit the Cilk library patch
> 
> If we do it in the above order, you won't see those warnings.

Fair enough.  I just didn't know what the warnings meant.


r~

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2013-10-24 21:06 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-02 19:40 Cilk Library Iyer, Balaji V
2013-10-03  4:45 ` Jeff Law
2013-10-08 19:44 ` Jeff Law
2013-10-09 18:32   ` Iyer, Balaji V
2013-10-09 20:22     ` Joseph S. Myers
2013-10-10 13:19     ` Aldy Hernandez
2013-10-10 13:35       ` Iyer, Balaji V
2013-10-15 20:14     ` Jeff Law
2013-10-16  8:26       ` Richard Biener
2013-10-16 19:30       ` Iyer, Balaji V
2013-10-23  5:14         ` Jeff Law
2013-10-23 14:10           ` Iyer, Balaji V
2013-10-23 19:30           ` Iyer, Balaji V
2013-10-23 20:22             ` Joseph S. Myers
2013-10-23 20:32               ` Jeff Law
2013-10-24 15:46                 ` Iyer, Balaji V
2013-10-24 16:14             ` Richard Henderson
2013-10-24 20:43               ` Iyer, Balaji V
2013-10-24 21:06                 ` Richard Henderson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).