search for: _libcpp_inline_visibility

...d abs(long double __lcpp_x) _NOEXCEPT {return ::fabsl(__lcpp_x);} ^~ ../projects/libcxx/include/math.h: In function 'long double acos(long double)': ../projects/libcxx/include/math.h:749:91: error: '::acosl' has not been declared inline _LIBCPP_INLINE_VISIBILITY long double acos(long double __lcpp_x) _NOEXCEPT {return ::acosl(__lcpp_x);} ^~ ../projects/libcxx/include/math.h: In function 'long double asin(long double)': ../projects/libcxx/include/math.h:761:91: error: '::asinl' has not been declared inline _LIBCPP_INLINE_VISIBILITY long do...

..._lcpp_x) _NOEXCEPT {return ::fabsl(__lcpp_x);} > ^~ > ../projects/libcxx/include/math.h: In function 'long double acos(long double)': > ../projects/libcxx/include/math.h:749:91: error: '::acosl' has not been declared > inline _LIBCPP_INLINE_VISIBILITY long double acos(long double __lcpp_x) _NOEXCEPT {return ::acosl(__lcpp_x);} > ^~ > ../projects/libcxx/include/math.h: In function 'long double asin(long double)': > ../projects/libcxx/includ...

...absl(__lcpp_x);} > > ^~ > > ../projects/libcxx/include/math.h: In function 'long double acos(long > double)': > > ../projects/libcxx/include/math.h:749:91: error: '::acosl' has not been > declared > > inline _LIBCPP_INLINE_VISIBILITY long double acos(long double __lcpp_x) > _NOEXCEPT {return ::acosl(__lcpp_x);} > > > ^~ > > ../projects/libcxx/include/math.h: In function 'long double asin(long > double)': > > ../projects/libcxx/include/math.h:761:91: error: '::asinl' h...

...d abs(long double __lcpp_x) _NOEXCEPT {return ::fabsl(__lcpp_x);} ^~ ../projects/libcxx/include/math.h: In function 'long double acos(long double)': ../projects/libcxx/include/math.h:749:91: error: '::acosl' has not been declared inline _LIBCPP_INLINE_VISIBILITY long double acos(long double __lcpp_x) _NOEXCEPT {return ::acosl(__lcpp_x);} ^~ ../projects/libcxx/include/math.h: In function 'long double asin(long double)': ../projects/libcxx/include/math.h:761:91: error: '::asinl' has not been declared inline _LIBCPP_INLINE_VISIBILITY long do...

...on not viable: no known conversion from 'pair<typename __make_pair_return<void *>::type, typename __make_pair_return<DIType &>::type>' to 'const value_type' (aka 'const std::__1::pair<void *, llvm::WeakVH>') for 1st argument; _LIBCPP_INLINE_VISIBILITY void push_back(const_reference __x); ^ /usr/include/c++/v1/vector:678:36: note: candidate function not viable: no known conversion from 'pair<typename __make_pair_return<void *>::type, typename __make_pair_return<DIType &>::type&...

...and libc++ would import that into namespace std, and we'd be golden. But we don't have a C library - we use whatever is provided by the system we're running on, so that's not really an option. For my testing, I changed libc++'s <cstring> header: -using ::memcpy; +inline _LIBCPP_INLINE_VISIBILITY +void* memcpy(void* __s1, const void* __s2, size_t __n) __attribute__((nonnull(1, 2))) +{ return ::memcpy(__s1, __s2, __n); } (similarly for memmove and memcmp), and I found several cases of simple code that now UBSAN fires off on: such as: std::vector<int> v; v.push_back(1); and :...

...[RFC] __attribute__((internal_linkage)) > > Hi Stewart, > > I saw this get brought up at the LLVM devmtg in the context of improving > the stack size of libc++ frames. > > Have you guys considered a different approach to solving this problem? In > the case of libc++, the _LIBCPP_INLINE_VISIBILITY macro currently expands > out to "__attribute__ ((__always_inline__))”. It seems reasonable to me > to have it also add the “nodebug” attribute as well. This should allow > the allocas generated by inlining lots of frames to be promoted to > registers (because there is no debug i...

Hi, I'm part of an engineering team doing research on persistent memory support and we have stumbled upon an interesting problem. The issue is, we would like to be able to use the standard library containers in a persistent memory context (think NVDIMM-N). What I mean is that you allocate a container from said memory, use it like you normally would. After the application terminates, expectedly

I haven't been able to figure out from this thread why this attribute is necessary at all. Anonymous or unnamed namespaces were added to C++ for this very purpose, but the ISO C++ Standard does not discuss "linkage" per-se because it is outside the scope of the language specification. But it does describes it in terms of having a hidden name which is "unique" to the

...inkage)) >> >> Hi Stewart, >> >> I saw this get brought up at the LLVM devmtg in the context of >> improving the stack size of libc++ frames. >> >> Have you guys considered a different approach to solving this >> problem? In the case of libc++, the _LIBCPP_INLINE_VISIBILITY macro >> currently expands out to "__attribute__ ((__always_inline__))”. It >> seems reasonable to me to have it also add the “nodebug” attribute as >> well. This should allow the allocas generated by inlining lots of >> frames to be promoted to registers (because...

...> > >>> I saw this get brought up at the LLVM devmtg in the context of > >>> improving the stack size of libc++ frames. > >>> > >>> Have you guys considered a different approach to solving this > >>> problem? In the case of libc++, the _LIBCPP_INLINE_VISIBILITY macro > >>> currently expands out to "__attribute__ ((__always_inline__))”. It > >>> seems reasonable to me to have it also add the “nodebug” attribute as > >>> well. This should allow the allocas generated by inlining lots of > >>> frames to b...

...this get brought up at the LLVM devmtg in the context of >>>>>> improving the stack size of libc++ frames. >>>>>> >>>>>> Have you guys considered a different approach to solving this >>>>>> problem? In the case of libc++, the _LIBCPP_INLINE_VISIBILITY macro >>>>>> currently expands out to "__attribute__ ((__always_inline__))”. It >>>>>> seems reasonable to me to have it also add the “nodebug” attribute as >>>>>> well. This should allow the allocas generated by inlining lots of >>...