[cfe-dev] libcxx and weak attribute

Reid Kleckner rnk at google.com
Fri Sep 13 09:49:01 PDT 2013


ENOPATCH?

On Fri, Sep 13, 2013 at 12:58 AM, G M <gmisocpp at gmail.com> wrote:

> Hi Everyone (particularly Howard and Reid (rnk) and any windows experts
> out there)
>
> I'm trying to hack some more support for libcxx on Windows (for any
> compilers) but cl.exe/visual studio in this case:
>
> One task is I'm trying to find out what the Windows equivalent is to the
> gcc/clang weak attribute.
> (would address sanitizer or other llvm related code bases benefit from any
> solution that can be found here?).
>
> Take code like this, from libcxx:
>
> __attribute__((__weak__, __visibility__("default"))) void * operator
> new(std::size_t size) { ... }
>

Maybe Rui knows more about how Microsoft does this.  He had to implement
some weak symbol fallback stuff in lld to link the Visual C++ runtime.  I
wonder if operator new was the feature that required this functionality.


> While on the topic, it'd be nice to find the correct solution to this
> problem too:
>
> 2>c:/libcxx/include\utility(597): warning C4141: 'inline' : used more than
> once
> It's a warning but it would be nice to find the correct formulation of
> macro's that will solve that warning too.
> When libcxx is compiled with cl.exe this warning appears 1300 times for
> various offending lines
>
> The attached patch demonstrates the first proposal, using libcxx's new.cpp
> as an example. It at least removes some of the compile errors coming from
> cl.exe, but it may still not be right even if it compiles.
>

Timur had to solve this for asan, and he did this in
compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:

#if defined(_MSC_VER)
# define ALWAYS_INLINE __forceinline
...
#else  // _MSC_VER
# define ALWAYS_INLINE inline __attribute__((always_inline))
...
#endif

libc++ should do the same.  gcc requires you to use inline in combination
with always_inline, while MSVC thinks that inline is redundant with
__forceinline.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130913/18982dc0/attachment.html>


More information about the cfe-dev mailing list