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: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.
>
> Look at libatomic/libatomic.map and how that gets used. It gives you full
> control over the exports.
>
> jeff
