> -----Original Message----- > From: Jeff Law [mailto:l...@redhat.com] > Sent: Wednesday, October 23, 2013 1:15 AM > To: Iyer, Balaji V; gcc@gcc.gnu.org > Cc: Aldy Hernandez (al...@redhat.com); r...@redhat.com; Jason Merrill > (ja...@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
