This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Cilk Library


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]