svn commit: r233699 - head/contrib/libstdc++/libsupc++
Author: theraven
Date: Fri Mar 30 12:48:36 2012
New Revision: 233699
URL: http://svn.freebsd.org/changeset/base/233699
Log:
Undo the earlier revert of the ABI change in libsupc++. On further
discussion,
posting an errata notice with 9.1 is the less painful solution.
Approved by: dim (mentor)
Modified:
head/contrib/libstdc++/libsupc++/typeinfo
Modified: head/contrib/libstdc++/libsupc++/typeinfo
==
--- head/contrib/libstdc++/libsupc++/typeinfo Fri Mar 30 12:34:34 2012
(r233698)
+++ head/contrib/libstdc++/libsupc++/typeinfo Fri Mar 30 12:48:36 2012
(r233699)
@@ -100,6 +100,12 @@ namespace std
bool operator!=(const type_info& __arg) const
{ return !operator==(__arg); }
+// Return true if this is a pointer type of some kind
+virtual bool __is_pointer_p() const;
+
+// Return true if this is a function type
+virtual bool __is_function_p() const;
+
// Try and catch a thrown type. Store an adjusted pointer to the
// caught type in THR_OBJ. If THR_TYPE is not a pointer type, then
// THR_OBJ points to the thrown object. If THR_TYPE is a pointer
@@ -113,12 +119,6 @@ namespace std
virtual bool __do_upcast(const __cxxabiv1::__class_type_info *__target,
void **__obj_ptr) const;
-// Return true if this is a pointer type of some kind
-virtual bool __is_pointer_p() const;
-
-// Return true if this is a function type
-virtual bool __is_function_p() const;
-
protected:
const char *__name;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r233749 - in head/gnu/lib: libstdc++ libsupc++
Author: theraven
Date: Sat Mar 31 14:25:12 2012
New Revision: 233749
URL: http://svn.freebsd.org/changeset/base/233749
Log:
Make libsupc++ build as a shared library and make libstdc++ a filter library
for it.
This allows people to swap out libsupc++ for libcxxrt easily, so we can begin
the libstdc++ -> libc++ migration.
Approved by: dim (mentor)
Added:
head/gnu/lib/libsupc++/Version.map
- copied, changed from r232970,
head/contrib/libstdc++/config/abi/pre/gnu.ver
Modified:
head/gnu/lib/libstdc++/Makefile
head/gnu/lib/libsupc++/Makefile
Modified: head/gnu/lib/libstdc++/Makefile
==
--- head/gnu/lib/libstdc++/Makefile Sat Mar 31 14:03:16 2012
(r233748)
+++ head/gnu/lib/libstdc++/Makefile Sat Mar 31 14:25:12 2012
(r233749)
@@ -25,7 +25,7 @@ CXXFLAGS+=-fno-implicit-templates -ffun
PO_CXXFLAGS= ${CXXFLAGS:N-ffunction-sections}
DPADD= ${LIBM}
-LDADD= -lm
+LDADD= -lm -Wl,-f,libsupc++.so.1
# libstdc++ sources
SRCS+= bitmap_allocator.cc pool_allocator.cc \
Modified: head/gnu/lib/libsupc++/Makefile
==
--- head/gnu/lib/libsupc++/Makefile Sat Mar 31 14:03:16 2012
(r233748)
+++ head/gnu/lib/libsupc++/Makefile Sat Mar 31 14:25:12 2012
(r233749)
@@ -7,8 +7,8 @@ SRCDIR= ${.CURDIR}/../../../contrib/libs
.PATH: ${SRCDIR} ${GCCLIB}/libiberty
-# Static only.
LIB= supc++
+SHLIB_MAJOR=1
SRCS+= del_op.cc del_opnt.cc del_opv.cc del_opvnt.cc eh_alloc.cc eh_arm.cc \
eh_aux_runtime.cc eh_call.cc eh_catch.cc eh_exception.cc eh_globals.cc \
eh_personality.cc eh_term_handler.cc eh_terminate.cc eh_throw.cc \
@@ -36,4 +36,9 @@ unwind.h: ${GCCDIR}/unwind-generic.h
SRCS+= unwind.h
CLEANFILES+= unwind.h
+# Symbol versioning
+
+VERSION_MAP= ${.CURDIR}/Version.map
+
+
.include
Copied and modified: head/gnu/lib/libsupc++/Version.map (from r232970,
head/contrib/libstdc++/config/abi/pre/gnu.ver)
==
--- head/contrib/libstdc++/config/abi/pre/gnu.ver Wed Mar 14 14:34:14
2012(r232970, copy source)
+++ head/gnu/lib/libsupc++/Version.map Sat Mar 31 14:25:12 2012
(r233749)
@@ -19,676 +19,7 @@
## Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
## USA.
-GLIBCXX_3.4 {
-
- global:
-
-# Names inside the 'extern' block are demangled names.
-extern "C++"
-{
- std::[A-Za]*;
-# std::ba[a-r]*;
- std::basic_[a-e]*;
- std::basic_f[a-r]*;
-# std::basic_fstream;
- std::basic_f[t-z]*;
- std::basic_[g-h]*;
- std::basic_i[a-e]*;
-# std::basic_ifstream;
- std::basic_i[g-r]*;
- std::basic_istr[a-d]*;
-# std::basic_istream;
- std::basic_istr[f-z]*;
- std::basic_i[t-z]*;
- std::basic_[j-n]*;
- std::basic_o[a-e]*;
-# std::basic_ofstream;
-# std::basic_o[g-z]*;
- std::basic_o[g-r]*;
- std::basic_ostr[a-d]*;
- std::basic_ostr[f-z]*;
- std::basic_[p-r]*;
- std::basic_streambuf*;
-# std::basic_string
-# std::basic_stringbuf
- std::basic_stringstream*;
- std::basic_[t-z]*;
- std::ba[t-z]*;
- std::b[b-z]*;
- std::c[a-g]*;
-# std::char_traits;
- std::c[i-z]*;
- std::[d-h]*;
- std::i[a-n]*;
- std::ios_base::[A-Ha-z]*;
- std::ios_base::_M_grow_words*;
- std::ios_base::_M_init*;
- std::ios_base::Init::[A-Za-z]*;
- std::ios_base::[J-Za-z]*;
- std::i[p-r]*;
-# std::istream
-# std::istreambuf_iterator
- std::istringstream*;
- std::istrstream*;
- std::i[t-z]*;
- std::[A-Zj-k]*;
- std::length_error*;
- std::logic_error*;
- std::locale::[A-Za-e]*;
- std::locale::facet::[A-Za-z]*;
- std::locale::facet::_S_get_c_locale*;
- std::locale::facet::_S_clone_c_locale*;
- std::locale::facet::_S_create_c_locale*;
- std::locale::facet::_S_destroy_c_locale*;
- std::locale::[A-Zg-h]*;
- std::locale::id::[A-Za-z]*;
- std::locale::id::_M_id*;
- std::locale::[A-Zj-z]*;
- std::locale::_[A-Ha-z]*;
- std::locale::_Impl::[A-Za-z]*;
-# std::locale::_Impl::_M_[A-Za-z]*;
- std::locale::_[J-Ra-z]*;
- std::locale::_S_normalize_category*;
- std::locale::_[T-Za-z]*;
-# std::[A-Zm-r]*;
- std::[A-Zm]*;
- std::n[^u]*;
- std::nu[^m]*;
- std::num[^e]*;
- std::[p-r]*;
- std::ostrstream*;
- std::out_of_range*;
- std::overflow_error*;
- std::set_new_handler*;
- std::set_terminate*;
- std::set_unexpected*;
-# std::string
- std::strstream*;
- std::strstreambuf*;
- std::[A-Zt-z]*;
- std::_List_node_base::hook*;
- std::_List_node_base::swap*;
- std::_List_node_base::unhook*;
-
svn commit: r233757 - head/sys/sys
Author: theraven Date: Sun Apr 1 09:35:23 2012 New Revision: 233757 URL: http://svn.freebsd.org/changeset/base/233757 Log: Bump __FreeBSD_version for xlocale cleanup, as requested by ports people. Approved by: dim (mentor) Modified: head/sys/sys/param.h Modified: head/sys/sys/param.h == --- head/sys/sys/param.hSun Apr 1 08:58:21 2012(r233756) +++ head/sys/sys/param.hSun Apr 1 09:35:23 2012(r233757) @@ -58,7 +58,7 @@ * in the range 5 to 9. */ #undef __FreeBSD_version -#define __FreeBSD_version 109 /* Master, propagated to newvers */ +#define __FreeBSD_version 110 /* Master, propagated to newvers */ /* * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD, ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r233749 - in head/gnu/lib: libstdc++ libsupc++
On 2 Apr 2012, at 02:03, Alexander Kabaev wrote: > there are reports of this commit breaking complex C++ binaries such as > build as part of KDE4. This is being looked at. Do you have any more information about what is broken? (Run-time failures, linker failures?) David___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232351 - in head/sys: kern sys ufs/ffs ufs/ufs
On 7 Apr 2012, at 18:10, David Schultz wrote: > The biggest hinderance to using extern inline is that gcc and C99 > disagree about what it means, unless you use a reasonably recent > compiler in C99 mode. I first tried to use extern inline in the > tree several years after I backported gcc's C99 inline support, > and it still turned out to be a headache. You can detect which inlining mode is going to happen by checking the value of __STDC_VERSION__ and the value of __GNUC_GNU_INLINE__. If __STDC_VERSION__ is >= 199901L and __GNUC_GNU_INLINE__ is not defined then you're in C99 inlining mode, otherwise you're in GNU inlining mode. On some projects with headers that need to work in both modes, we've written some INLINE_EXTERN macros that do the right thing in whichever mode we find ourselves compiling. It might be worth putting these in cdefs.h if they're generally useful. David___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r234573 - head/include/xlocale
Author: theraven
Date: Sun Apr 22 16:58:14 2012
New Revision: 234573
URL: http://svn.freebsd.org/changeset/base/234573
Log:
Fix a bug caused by some misplaced brackets.
Reported by: das
Modified:
head/include/xlocale/_ctype.h
Modified: head/include/xlocale/_ctype.h
==
--- head/include/xlocale/_ctype.h Sun Apr 22 16:13:23 2012
(r234572)
+++ head/include/xlocale/_ctype.h Sun Apr 22 16:58:14 2012
(r234573)
@@ -78,8 +78,8 @@ __maskrune_l(__ct_rune_t __c, unsigned l
{
int __limit;
_RuneLocale *runes = __runes_for_locale(__loc, &__limit);
- return (__c < 0 || __c >= _CACHED_RUNES) ? ___runetype_l(__c, __loc) :
- runes->__runetype[__c] & __f;
+ return ((__c < 0 || __c >= _CACHED_RUNES) ? ___runetype_l(__c, __loc) :
+ runes->__runetype[__c]) & __f;
}
_XLOCALE_INLINE int
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r234578 - head/lib/libc/locale
Author: theraven
Date: Sun Apr 22 18:51:38 2012
New Revision: 234578
URL: http://svn.freebsd.org/changeset/base/234578
Log:
Fix some incorrect symbol versions.
Reported by: das
Modified:
head/lib/libc/locale/Symbol.map
Modified: head/lib/libc/locale/Symbol.map
==
--- head/lib/libc/locale/Symbol.map Sun Apr 22 18:18:49 2012
(r234577)
+++ head/lib/libc/locale/Symbol.map Sun Apr 22 18:51:38 2012
(r234578)
@@ -60,13 +60,9 @@ FBSD_1.0 {
nextwctype;
nl_langinfo;
__maskrune;
- __maskrune_l;
__sbmaskrune;
- __sbmaskrune_l;
__istype;
- __istype_l;
__sbistype;
- __sbistype_l;
__isctype;
__toupper;
__sbtoupper;
@@ -197,6 +193,10 @@ FBSD_1.3 {
wcstoul_l;
wcstoull_l;
wcstoumax_l;
+ __sbistype_l;
+ __maskrune_l;
+ __sbmaskrune_l;
+ __istype_l;
__runes_for_locale;
_ThreadRuneLocale;
};
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r234732 - head/usr.sbin/wpa/hostapd
Author: theraven Date: Fri Apr 27 15:35:09 2012 New Revision: 234732 URL: http://svn.freebsd.org/changeset/base/234732 Log: Add a note to hostapd.conf about an unhelpful error message in the hope that it won't confuse anyone else in the future. MFC after:1 week Modified: head/usr.sbin/wpa/hostapd/hostapd.conf.5 Modified: head/usr.sbin/wpa/hostapd/hostapd.conf.5 == --- head/usr.sbin/wpa/hostapd/hostapd.conf.5Fri Apr 27 13:58:09 2012 (r234731) +++ head/usr.sbin/wpa/hostapd/hostapd.conf.5Fri Apr 27 15:35:09 2012 (r234732) @@ -67,7 +67,8 @@ The following parameters are recognized: Interface name. Should be set in .Dq hostap -mode. +mode. Make certain that there are no spaces after the interface name, +or hostapd will complain that the interface does not exist. .It Va debug Debugging mode: 0 = no, 1 = minimal, 2 = verbose, 3 = msg dumps, 4 = excessive. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r234958 - head/include
Author: theraven
Date: Thu May 3 15:54:06 2012
New Revision: 234958
URL: http://svn.freebsd.org/changeset/base/234958
Log:
Fix after clang decided to rename all of its builtins to include
a c11 prefix to disambiguate them from the one provided by GCC.
Note: Clang 3.1 also supports the GCC builtins for libstdc++ 4.7
compatibility,
but I don't recommend using them because they are very poorly designed.
MFC after:2 weeks
Modified:
head/include/stdatomic.h
Modified: head/include/stdatomic.h
==
--- head/include/stdatomic.hThu May 3 15:51:34 2012(r234957)
+++ head/include/stdatomic.hThu May 3 15:54:06 2012(r234958)
@@ -51,7 +51,7 @@
#if defined(__CLANG_ATOMICS)
#defineATOMIC_VAR_INIT(value) (value)
-#defineatomic_init(obj, value) __atomic_init(obj, value)
+#defineatomic_init(obj, value) __c11_atomic_init(obj, value)
#else
#defineATOMIC_VAR_INIT(value) { .__val = (value) }
#defineatomic_init(obj, value) do {
\
@@ -104,7 +104,10 @@ enum memory_order {
* 7.17.4 Fences.
*/
-#if defined(__CLANG_ATOMICS) || defined(__GNUC_ATOMICS)
+#ifdef __CLANG_ATOMICS
+#defineatomic_thread_fence(order) __c11_atomic_thread_fence(order)
+#defineatomic_signal_fence(order) __c11_atomic_signal_fence(order)
+#elif defined(__GNUC_ATOMICS)
#defineatomic_thread_fence(order) __atomic_thread_fence(order)
#defineatomic_signal_fence(order) __atomic_signal_fence(order)
#else
@@ -118,7 +121,7 @@ enum memory_order {
#if defined(__CLANG_ATOMICS)
#defineatomic_is_lock_free(obj) \
- __atomic_is_lock_free(sizeof(obj))
+ __c11_atomic_is_lock_free(sizeof(obj))
#elif defined(__GNUC_ATOMICS)
#defineatomic_is_lock_free(obj) \
__atomic_is_lock_free(sizeof((obj)->__val))
@@ -182,28 +185,28 @@ typedef _Atomic(__uintmax_t) atomic_uin
#if defined(__CLANG_ATOMICS)
#defineatomic_compare_exchange_strong_explicit(object, expected,
\
desired, success, failure) \
- __atomic_compare_exchange_strong(object, expected, desired, \
+ __c11_atomic_compare_exchange_strong(object, expected, desired, \
success, failure)
#defineatomic_compare_exchange_weak_explicit(object, expected,
\
desired, success, failure) \
- __atomic_compare_exchange_weak(object, expected, desired, \
+ __c11_atomic_compare_exchange_weak(object, expected, desired, \
success, failure)
#defineatomic_exchange_explicit(object, desired, order)
\
- __atomic_exchange(object, desired, order)
+ __c11_atomic_exchange(object, desired, order)
#defineatomic_fetch_add_explicit(object, operand, order)
\
- __atomic_fetch_add(object, operand, order)
+ __c11_atomic_fetch_add(object, operand, order)
#defineatomic_fetch_and_explicit(object, operand, order)
\
- __atomic_fetch_and(object, operand, order)
+ __c11_atomic_fetch_and(object, operand, order)
#defineatomic_fetch_or_explicit(object, operand, order)
\
- __atomic_fetch_or(object, operand, order)
+ __c11_atomic_fetch_or(object, operand, order)
#defineatomic_fetch_sub_explicit(object, operand, order)
\
- __atomic_fetch_sub(object, operand, order)
+ __c11_atomic_fetch_sub(object, operand, order)
#defineatomic_fetch_xor_explicit(object, operand, order)
\
- __atomic_fetch_xor(object, operand, order)
+ __c11_atomic_fetch_xor(object, operand, order)
#defineatomic_load_explicit(object, order)
\
- __atomic_load(object, order)
+ __c11_atomic_load(object, order)
#defineatomic_store_explicit(object, desired, order)
\
- __atomic_store(object, desired, order)
+ __c11_atomic_store(object, desired, order)
#elif defined(__GNUC_ATOMICS)
#defineatomic_compare_exchange_strong_explicit(object, expected,
\
desired, success, failure) \
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r234976 - in head/contrib/libc++: include src
Author: theraven
Date: Thu May 3 17:44:07 2012
New Revision: 234976
URL: http://svn.freebsd.org/changeset/base/234976
Log:
Import new version of libc++. Among other improvements, this comes with an
header that works with clang 3.1 (and, importantly, the pre-3.1
snapshot currently in head)
Modified:
head/contrib/libc++/include/__config
head/contrib/libc++/include/__tuple
head/contrib/libc++/include/algorithm
head/contrib/libc++/include/atomic
head/contrib/libc++/include/cmath
head/contrib/libc++/include/limits
head/contrib/libc++/include/memory
head/contrib/libc++/include/random
head/contrib/libc++/include/system_error
head/contrib/libc++/include/tuple
head/contrib/libc++/include/type_traits
head/contrib/libc++/include/utility
head/contrib/libc++/src/iostream.cpp
head/contrib/libc++/src/stdexcept.cpp
head/contrib/libc++/src/utility.cpp
Directory Properties:
head/contrib/libc++/ (props changed)
Modified: head/contrib/libc++/include/__config
==
--- head/contrib/libc++/include/__configThu May 3 17:08:40 2012
(r234975)
+++ head/contrib/libc++/include/__configThu May 3 17:44:07 2012
(r234976)
@@ -384,7 +384,9 @@ template struct __static_asse
#endif
#ifdef _LIBCPP_HAS_NO_CONSTEXPR
-#define constexpr const
+#define _LIBCPP_CONSTEXPR
+#else
+#define _LIBCPP_CONSTEXPR constexpr
#endif
#ifndef __has_feature
Modified: head/contrib/libc++/include/__tuple
==
--- head/contrib/libc++/include/__tuple Thu May 3 17:08:40 2012
(r234975)
+++ head/contrib/libc++/include/__tuple Thu May 3 17:44:07 2012
(r234976)
@@ -216,7 +216,7 @@ struct __tuple_convertible_imp : public
template
struct __tuple_convertible_imp,
__tuple_types<_Up0, _Up...> >
: public integral_constant::value &&
+ is_convertible<_Tp0, _Up0>::value &&
__tuple_convertible_imp, __tuple_types<_Up...> >::value> {};
template <>
@@ -235,6 +235,33 @@ struct __tuple_convertible<_Tp, _Up, tru
typename __make_tuple_types<_Tp>::type, typename
__make_tuple_types<_Up>::type>
{};
+// __tuple_constructible
+
+template
+struct __tuple_constructible_imp : public false_type {};
+
+template
+struct __tuple_constructible_imp,
__tuple_types<_Up0, _Up...> >
+: public integral_constant::value &&
+ __tuple_constructible_imp, __tuple_types<_Up...> >::value> {};
+
+template <>
+struct __tuple_constructible_imp, __tuple_types<> >
+: public true_type {};
+
+template ::type>::value,
+bool = __tuple_like<_Up>::value>
+struct __tuple_constructible
+: public false_type {};
+
+template
+struct __tuple_constructible<_Tp, _Up, true, true>
+: public __tuple_constructible_imp::type>::value ==
+ tuple_size<_Up>::value,
+ typename __make_tuple_types<_Tp>::type, typename
__make_tuple_types<_Up>::type>
+{};
+
// __tuple_assignable
template
Modified: head/contrib/libc++/include/algorithm
==
--- head/contrib/libc++/include/algorithm Thu May 3 17:08:40 2012
(r234975)
+++ head/contrib/libc++/include/algorithm Thu May 3 17:44:07 2012
(r234976)
@@ -2508,11 +2508,16 @@ private:
_Engine_result_type __mask0_;
_Engine_result_type __mask1_;
+#ifdef _LIBCPP_HAS_NO_CONSTEXPR
static const _Working_result_type _Rp = _Engine::_Max - _Engine::_Min
- +
_Working_result_type(1);
-static const size_t __m = __log2<_Working_result_type, _Rp>::value;
-static const size_t _WDt = numeric_limits<_Working_result_type>::digits;
-static const size_t _EDt = numeric_limits<_Engine_result_type>::digits;
+ + _Working_result_type(1);
+#else
+static _LIBCPP_CONSTEXPR const _Working_result_type _Rp = _Engine::max() -
_Engine::min()
+ +
_Working_result_type(1);
+#endif
+static _LIBCPP_CONSTEXPR const size_t __m = __log2<_Working_result_type,
_Rp>::value;
+static _LIBCPP_CONSTEXPR const size_t _WDt =
numeric_limits<_Working_result_type>::digits;
+static _LIBCPP_CONSTEXPR const size_t _EDt =
numeric_limits<_Engine_result_type>::digits;
public:
// constructors and seeding functions
@@ -2712,8 +2717,8 @@ public:
result_type operator()();
-static constexpr result_type min() {return _Min;}
-static constexpr result_type max() {return _Max;}
+static _LIBCPP_CONSTEXPR result_type min() {return _Min;}
+static _LIBCPP_CONSTEXPR result_type max() {return _Max;}
friend __rs_default __rs_get();
};
Modified: head/contrib/libc++/includ
Re: svn commit: r235267 - in head/usr.bin/sort: . nls
On 11 May 2012, at 08:48, Konstantin Belousov wrote: > On Fri, May 11, 2012 at 12:37:16PM +, Gabor Kovesdan wrote: >> Author: gabor >> Date: Fri May 11 12:37:16 2012 >> New Revision: 235267 >> URL: http://svn.freebsd.org/changeset/base/235267 > >> +bool byte_sort = false; >> + >> +static wchar_t **wmonths = NULL; >> +static unsigned char **cmonths = NULL; > > Such initializations are useless. You only increase the size of the binary > on the disk as the consequence. Really? The C specification requires all globals and statics that are not explicitly initialised to be set to their zero value, so this initialisation has no effect on the resulting binary[1]. These are placed in the BSS section, irrespective of whether the initialisation is implicit or explicit and the loader is responsible for allocating space for them - all that is stored in the binary is the size. For local variables, initialisation like this has no effect even at low optimisation levels - dead stores will be removed. It does, however, make it more difficult for the compiler to distinguish between initialised and initialised sensibly in some cases. David [1] In a standards-compliant compiler. Apparently a few shipping compilers for embedded systems fail to respect this, but everything FreeBSD is compiled with does.___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r236148 - head/lib/msun/src
Author: theraven Date: Sun May 27 12:54:41 2012 New Revision: 236148 URL: http://svn.freebsd.org/changeset/base/236148 Log: Allow inclusion of libc++ to work after including math.h Submitted by: Yamaya Takashi Reviewed by: das MFC after:1 week Modified: head/lib/msun/src/math.h Modified: head/lib/msun/src/math.h == --- head/lib/msun/src/math.hSun May 27 12:47:35 2012(r236147) +++ head/lib/msun/src/math.hSun May 27 12:54:41 2012(r236148) @@ -395,35 +395,15 @@ float significandf(float); * long double versions of ISO/POSIX math functions */ #if __ISO_C_VISIBLE >= 1999 -#if _DECLARE_C99_LDBL_MATH -long doubleacoshl(long double); -#endif long doubleacosl(long double); -#if _DECLARE_C99_LDBL_MATH -long doubleasinhl(long double); -#endif long doubleasinl(long double); long doubleatan2l(long double, long double); -#if _DECLARE_C99_LDBL_MATH -long doubleatanhl(long double); -#endif long doubleatanl(long double); long doublecbrtl(long double); long doubleceill(long double); long doublecopysignl(long double, long double) __pure2; -#if _DECLARE_C99_LDBL_MATH -long doublecoshl(long double); -#endif long doublecosl(long double); -#if _DECLARE_C99_LDBL_MATH -long doubleerfcl(long double); -long doubleerfl(long double); -#endif long doubleexp2l(long double); -#if _DECLARE_C99_LDBL_MATH -long doubleexpl(long double); -long doubleexpm1l(long double); -#endif long doublefabsl(long double) __pure2; long doublefdiml(long double, long double); long doublefloorl(long double); @@ -435,20 +415,9 @@ long doublefrexpl(long double value, in long doublehypotl(long double, long double); intilogbl(long double) __pure2; long doubleldexpl(long double, int); -#if _DECLARE_C99_LDBL_MATH -long doublelgammal(long double); -#endif long long llrintl(long double); long long llroundl(long double); -#if _DECLARE_C99_LDBL_MATH -long doublelog10l(long double); -long doublelog1pl(long double); -long doublelog2l(long double); -#endif long doublelogbl(long double); -#if _DECLARE_C99_LDBL_MATH -long doublelogl(long double); -#endif long lrintl(long double); long lroundl(long double); long doublemodfl(long double, long double *); /* fundamentally !__pure2 */ @@ -458,30 +427,54 @@ long double nextafterl(long double, long double nexttoward(double, long double); float nexttowardf(float, long double); long doublenexttowardl(long double, long double); -#if _DECLARE_C99_LDBL_MATH -long doublepowl(long double, long double); -#endif long doubleremainderl(long double, long double); long doubleremquol(long double, long double, int *); long doublerintl(long double); long doubleroundl(long double); long doublescalblnl(long double, long); long doublescalbnl(long double, int); -#if _DECLARE_C99_LDBL_MATH -long doublesinhl(long double); -#endif long doublesinl(long double); long doublesqrtl(long double); -#if _DECLARE_C99_LDBL_MATH -long doubletanhl(long double); -#endif long doubletanl(long double); -#if _DECLARE_C99_LDBL_MATH -long doubletgammal(long double); -#endif long doubletruncl(long double); #endif /* __ISO_C_VISIBLE >= 1999 */ __END_DECLS #endif /* !_MATH_H_ */ + +/* separate header for cmath */ +#ifndef _MATH_EXTRA_H_ +#if __ISO_C_VISIBLE >= 1999 +#if _DECLARE_C99_LDBL_MATH + +#define _MATH_EXTRA_H_ + +/* + * extra long double versions of math functions for C99 and cmath + */ +__BEGIN_DECLS + +long doubleacoshl(long double); +long doubleasinhl(long double); +long doubleatanhl(long double); +long doublecoshl(long double); +long doubleerfcl(long double); +long doubleerfl(long double); +long doubleexpl(long double); +long doubleexpm1l(long double); +long doublelgammal(long double); +long doublelog10l(long double); +long doublelog1pl(long double); +long doublelog2l(long double); +long doublelogl(long double); +long doublepowl(long double, long double); +long doublesinhl(long double); +long doubletanhl(long double); +long doubletgammal(long double); + +__END_DECLS + +#endif /* !_DECLARE_C99_LDBL_MATH */ +#endif /* __ISO_C_VISIBLE >= 1999 */ +#endif /* !_MATH_EXTRA_H_ */ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r236177 - head/gnu/lib/libsupc++
Author: theraven
Date: Mon May 28 12:11:00 2012
New Revision: 236177
URL: http://svn.freebsd.org/changeset/base/236177
Log:
Correctly export operator new / delete for things linking against libsupc++
but
not libstdc++.
Unfortunately, it appears that libsupc++ / libstdc++ have a different idea of
the type of size_t to the rest of the world, which may cause problems later
on...
Reported by: des
MFC after:1 week
Modified:
head/gnu/lib/libsupc++/Version.map
Modified: head/gnu/lib/libsupc++/Version.map
==
--- head/gnu/lib/libsupc++/Version.map Mon May 28 10:45:51 2012
(r236176)
+++ head/gnu/lib/libsupc++/Version.map Mon May 28 12:11:00 2012
(r236177)
@@ -126,6 +126,16 @@ CXXABI_1.3 {
# __gnu_cxx::_verbose_terminate_handler()
_ZN9__gnu_cxx27__verbose_terminate_handlerEv;
+# new / delete operators
+_Znaj;
+_ZnajRKSt9nothrow_t;
+_Znwj;
+_ZnwjRKSt9nothrow_t;
+_ZdaPv;
+_ZdaPvRKSt9nothrow_t;
+_ZdlPv;
+_ZdlPvRKSt9nothrow_t;
+
local:
*;
};
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r236137 - head/contrib/gcc/config/i386
On 28 May 2012, at 20:33, Dimitry Andric wrote: > On the other hand, it's really platform-dependent: I've checked several > Linux distributions, and it is fairly unpredictable whether their gcc > passes --hash-style to the linker, or if they do, which option they use. Can we make it dependent on the triple? i.e. if the triple is arch-whatever-freebsd9 or greater, make it pass the flag, otherwise don't bother? Or is it not worth caring about older FreeBSD? There's no real disadvantage in passing it unconditionally (marginally longer link times) and potentially a big benefit. I don't see a problem with committing it upstream, but it would be nice to pull that change in locally before 9.1 and not have to wait for LLVM 3.2 before we got to make use of it. Misleading and poorly designed benchmarks on Phoronix are at stake! David___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r236137 - head/contrib/gcc/config/i386
On 30 May 2012, at 09:01, Marius Strobl wrote: > Ehm, yes, but given that this wouldn't be the first such flag we have > is avoiding it really worth the link time and run time overheads in > the long term? Given the small overhead of the extra hashes, yes. At some point in the future, we can turn off the older ones and get a tiny reduction in overhead, but doing it now would cause much more pain for users in not being able to copy binaries from slightly newer to slightly older machines than we'd save from a tiny increase in binary size. This is the archetypal change for incremental deployment, let's not make our users' lives difficult just because we can. David Who doesn't want to be woken up by mobs of users with flaming torches and pitchforks.___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r236456 - in head/sys: amd64/include i386/include
On 4 Jun 2012, at 11:00, Tijl Coosemans wrote: > On 02-06-2012 20:10, Konstantin Belousov wrote: >> Author: kib >> Date: Sat Jun 2 18:10:16 2012 >> New Revision: 236456 >> URL: http://svn.freebsd.org/changeset/base/236456 >> >> Log: >> Use plain store for atomic_store_rel on x86, instead of implicitly >> locked xchg instruction. IA32 memory model guarantees that store has >> release semantic, since stores cannot pass loads or stores. > > They can pass non-temporal stores can't they? Now that we have support for C11 atomics via stdatomic.h (in current and stable), it would be nice to compare their performance with the assembly versions. There is the potential for greater optimisation, because the compiler treats any asm block as a full barrier, so only the CPU, not the compiler, can reorder loads and stores across it. With the C11 stuff, on a new compiler (clang or gcc 4.7), the compiler can perform any reordering of loads and stores that does not violate the semantics specified by the atomic operation. David___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r236889 - head/lib/libc/locale
Author: theraven
Date: Mon Jun 11 14:02:02 2012
New Revision: 236889
URL: http://svn.freebsd.org/changeset/base/236889
Log:
Fix a leak when setting the global character locale to "C" from something
else.
Reported by: mm
Modified:
head/lib/libc/locale/setrunelocale.c
Modified: head/lib/libc/locale/setrunelocale.c
==
--- head/lib/libc/locale/setrunelocale.cMon Jun 11 13:17:45 2012
(r236888)
+++ head/lib/libc/locale/setrunelocale.cMon Jun 11 14:02:02 2012
(r236889)
@@ -89,6 +89,17 @@ const _RuneLocale *__getCurrentRuneLocal
return XLOCALE_CTYPE(__get_locale())->runes;
}
+static void free_runes(_RuneLocale *rl)
+{
+ /* FIXME: The "EUC" check here is a hideous abstraction violation. */
+ if ((rl != &_DefaultRuneLocale) && (rl)) {
+ if (strcmp(rl->__encoding, "EUC") == 0) {
+ free(rl->__variable);
+ }
+ free(rl);
+ }
+}
+
static int
__setrunelocale(struct xlocale_ctype *l, const char *encoding)
{
@@ -102,6 +113,7 @@ __setrunelocale(struct xlocale_ctype *l,
* The "C" and "POSIX" locale are always here.
*/
if (strcmp(encoding, "C") == 0 || strcmp(encoding, "POSIX") == 0) {
+ free_runes(saved.runes);
(void) _none_init(l, (_RuneLocale*)&_DefaultRuneLocale);
return (0);
}
@@ -153,13 +165,7 @@ __setrunelocale(struct xlocale_ctype *l,
if (ret == 0) {
/* Free the old runes if it exists. */
- /* FIXME: The "EUC" check here is a hideous abstraction
violation. */
- if ((saved.runes != &_DefaultRuneLocale) && (saved.runes)) {
- if (strcmp(saved.runes->__encoding, "EUC") == 0) {
- free(saved.runes->__variable);
- }
- free(saved.runes);
- }
+ free_runes(saved.runes);
} else {
/* Restore the saved version if this failed. */
memcpy(l, &saved, sizeof(struct xlocale_ctype));
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r236890 - in head: gnu/lib/libsupc++ lib/libcxxrt
Author: theraven
Date: Mon Jun 11 15:40:57 2012
New Revision: 236890
URL: http://svn.freebsd.org/changeset/base/236890
Log:
Clean up some symbol versions for libsupc++ / libcxxrt.
MFC after:1 week
Reviewed by: kan
Modified:
head/gnu/lib/libsupc++/Version.map
head/lib/libcxxrt/Version.map
Modified: head/gnu/lib/libsupc++/Version.map
==
--- head/gnu/lib/libsupc++/Version.map Mon Jun 11 14:02:02 2012
(r236889)
+++ head/gnu/lib/libsupc++/Version.map Mon Jun 11 15:40:57 2012
(r236890)
@@ -126,26 +126,22 @@ CXXABI_1.3 {
# __gnu_cxx::_verbose_terminate_handler()
_ZN9__gnu_cxx27__verbose_terminate_handlerEv;
-# operator new and new[], 32-bit size_t
-_Znaj;
-_ZnajRKSt9nothrow_t;
-_Znwj;
-_ZnwjRKSt9nothrow_t;
-
-# operator new and new[], 64-bit size_t
-_Znam;
-_ZnamRKSt9nothrow_t;
-_Znwm;
-_ZnwmRKSt9nothrow_t;
+ local:
+*;
+};
+
+GLIBCXX_3.4 {
+# operator new and new[]
+_Znai[jm];
+_Zna[jm]RKSt9nothrow_t;
+_Znw[jm];
+_Znw[jm]RKSt9nothrow_t;
# operator delete and delete[]
_ZdaPv;
_ZdaPvRKSt9nothrow_t;
_ZdlPv;
_ZdlPvRKSt9nothrow_t;
-
- local:
-*;
};
CXXABI_1.3.1 {
Modified: head/lib/libcxxrt/Version.map
==
--- head/lib/libcxxrt/Version.map Mon Jun 11 14:02:02 2012
(r236889)
+++ head/lib/libcxxrt/Version.map Mon Jun 11 15:40:57 2012
(r236890)
@@ -306,11 +306,6 @@ CXXRT_1.0 {
"std::type_info::__is_pointer_p() const";
-"operator delete[](void*)";
-"operator delete(void*)";
-"operator new[](unsigned long)";
-"operator new(unsigned long)";
-"operator new(unsigned long, std::nothrow_t const&)";
};
__cxa_allocate_dependent_exception;
@@ -321,3 +316,16 @@ CXXRT_1.0 {
__cxa_rethrow_primary_exception;
} CXXABI_1.3.1;
+
+GLIBCXX_3.4 {
+extern "C++" {
+"operator delete[](void*)";
+"operator delete(void*)";
+"operator new[](unsigned int)";
+"operator new(unsigned int)";
+"operator new(unsigned int, std::nothrow_t const&)";
+"operator new[](unsigned long)";
+"operator new(unsigned long)";
+"operator new(unsigned long, std::nothrow_t const&)";
+};
+};
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286168 - head/sys/net
On 2 Aug 2015, at 17:34, Ian Lepore wrote: > > It generates a compiler error, so the output is going to contain > file-and-line like any other compiler error, as well as the message from > the source code. It will, of course, vary between compilers, but this is what clang generates: $ cat static.c _Static_assert(0, "example assert failed"); $ cc static.c static.c:1:1: error: static_assert failed "example assert failed" _Static_assert(0, "example assert failed"); ^ ~ 1 error generated. GCC 4.8 and later produce very similar output: $ gcc-4.8 static.c static.c:1:1: error: static assertion failed: "example assert failed" _Static_assert(0, "example assert failed"); ^ gcc 4.7 only provides the first line: $ gcc-4.7 static.c static.c:1:1: error: static assertion failed: "example assert failed" David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286715 - head/lib/libc/string
On 13 Aug 2015, at 08:11, Marcelo Araujo wrote: > > The bcopy() was removed in IEEE Std 1003.1-2008 and it is marked as LEGACY in > IEEE Std 1003.1-2004. However, BSD has its implementation before IEEE Std > 1003.1-2001. > > In my understood it is obsolete on POSIX, but not truly obsolete for FreeBSD. > So I believe, this patch now address it in the correct way. Its use should be strongly discouraged in FreeBSD (or, ideally, replaced with the macro from the POSIX man page). LLVM does a load of optimisations for memmove and memcpy - using bcopy is a really good way of bypassing all of these. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286715 - head/lib/libc/string
On 13 Aug 2015, at 08:56, Marcelo Araujo wrote: > > So it means, this commit here was right already: > https://svnweb.freebsd.org/base?view=revision&revision=286651 > > Although I made a mistake with the date. More or less. I partly agree with Bruce that suggesting memcpy is misleading. I’d prefer something like: This function is deprecated (marked as LEGACY in POSIX.1-2001): use .Xr memmove 3 in new programs. If you can guarantee that the input and output buffers do not overlap, then .Xr memcpy 3 may be more efficient. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r287780 - in head: share/man/man9 sys/kern sys/sys
On 17 Sep 2015, at 08:20, Hans Petter Selasky wrote: > > On 09/17/15 00:05, Gleb Smirnoff wrote: >> Weren't you explicitly asked not to touch this system without a proper >> review and discussion? > > Adding a new function is not touching code. Adding a new interface to an existing core subsystem is most definitely touching the system. I would expect *anyone* making a change like this to have both the design and code reviewed for sanity checking. For someone who has already been required to have explicit review of any changes to the subsystem to skip this step shows a flagrant disregard for the project’s policies and best practices. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r274489 - in head/sys/amd64: amd64 include
On 21 Nov 2014, at 23:26, Scott Long wrote: > That’s a good question to look further into. I didn’t see any measurable > differences with this change. I think that the cost of the function call > itself masks the cost of a few extra instructions, but I didn’t test with > switching it on/off for the entire kernel [ Note: The following is not specific to the kernel ] The overhead for preserving / omitting the frame pointer is decidedly nonlinear. On a modern superscalar processor, it will usually be effectively zero, right up until the point that it pushes something out of the instruction cache on a hot path, at which point it jumps to 20-50%, depending on the workload. The performance difference was more pronounced on i386, where having an extra GPR for the register allocator to use could make a 10-20% performance difference on some fairly common code (the two big performance wins for x86-64 over IA32 were the increase in number of GPRs and an FPU ISA that wasn't batshit insane). For ISAs with more GPRs, that's less of an issue, although after inlining being able to use %rbp as a GPR can sometimes make a noticeable difference in performance. In particular, as %rpb is callee-save, it's very useful to be able to use it in non-leaf functions. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom
On 1 Apr 2015, at 18:41, Mateusz Guzik wrote: > > I guess you were right, this was bad. > > I moved the implementation to null.c, I hope this makes everyone happy. > > https://lists.freebsd.org/pipermail/svn-src-all/2015-April/101876.html This almost certainly does not make people happy: - * Copyright (c) 2000 Mark R. V. Murray & Jeroen C. van Gelderen - * Copyright (c) 2001-2004 Mark R. V. Murray - * Copyright (c) 2014 Eitan Adler + * Copyright (c) 2015 Mateusz Guzik * All rights reserved. * + * Some dudes which previously held the copyright: + * Marc V. R. Murray, Jeroen C. van Gelderen, Eytan Adrel + * Please try not to violate copyright in commits to the FreeBSD project. We get cranky when we have to talk to lawyers. This file already had a good example of how you amend existing copyright notices when you make a sufficiently significant change to warrant claiming copyright. Your copyright on your portions does not supersede the copyright held by the other contributors. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom
On 2 Apr 2015, at 11:22, Mateusz Guzik wrote: > > Now one has to wonder how obnoxious one has to get so that people think > "this can't be real". > > I tried really hard. :) Not sure about your locale, but here (where the tradition originated) if you fool someone in the morning then they are an April Fool, if you attempt to fool them in the afternoon then you are the April Fool. Your mail was timestamped 12:36 (ah, the perils of time zones...), though looking back at it I do rather like the commit time: Date: Wed Apr 1 13:37:00 2015 David (Blaming illness for not spotting the joke) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r281721 - head/sys/sys
On 20 Apr 2015, at 17:19, Bruce Evans wrote: > > Enums should never be used in ABIs, since their size can be anything > large enough. The rules for the size of enums also differ between C and C++, though clang (and, I think, gcc) support an attribute for specifying the enum type. > They also cause namespace problems. The whole enum declaration must > be exposed in any header that uses an enum type. Both C and C++ permit forward declarations of enums for use in function prototypes and so on, e.g.: enum foo; void bar(enum foo); David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r281925 - head/lib/libc/locale
Author: theraven Date: Fri Apr 24 10:17:55 2015 New Revision: 281925 URL: https://svnweb.freebsd.org/changeset/base/281925 Log: Small changes to locale-related man pages. Fix a missing .h and change the recommended include for the POSIX2008 functions from xlocale.h to locale.h. Including xlocale.h is for legacy / Darwin compatibility so should not be encouraged. Modified: head/lib/libc/locale/duplocale.3 head/lib/libc/locale/freelocale.3 head/lib/libc/locale/newlocale.3 head/lib/libc/locale/querylocale.3 head/lib/libc/locale/uselocale.3 Modified: head/lib/libc/locale/duplocale.3 == --- head/lib/libc/locale/duplocale.3Fri Apr 24 09:52:41 2015 (r281924) +++ head/lib/libc/locale/duplocale.3Fri Apr 24 10:17:55 2015 (r281925) @@ -36,7 +36,7 @@ .Sh LIBRARY .Lb libc .Sh SYNOPSIS -.In xlocale.h +.In locale.h .Ft locale_t .Fn duplocale "locale_t locale" .Sh DESCRIPTION Modified: head/lib/libc/locale/freelocale.3 == --- head/lib/libc/locale/freelocale.3 Fri Apr 24 09:52:41 2015 (r281924) +++ head/lib/libc/locale/freelocale.3 Fri Apr 24 10:17:55 2015 (r281925) @@ -38,7 +38,7 @@ or .Sh LIBRARY .Lb libc .Sh SYNOPSIS -.In xlocale.h +.In locale.h .Ft int .Fn freelocale "locale_t locale" .Sh DESCRIPTION Modified: head/lib/libc/locale/newlocale.3 == --- head/lib/libc/locale/newlocale.3Fri Apr 24 09:52:41 2015 (r281924) +++ head/lib/libc/locale/newlocale.3Fri Apr 24 10:17:55 2015 (r281925) @@ -35,7 +35,7 @@ .Sh LIBRARY .Lb libc .Sh SYNOPSIS -.In xlocale +.In locale.h .Ft locale_t .Fn newlocale "int mask" "const char * locale" "locale_t base" .Sh DESCRIPTION Modified: head/lib/libc/locale/querylocale.3 == --- head/lib/libc/locale/querylocale.3 Fri Apr 24 09:52:41 2015 (r281924) +++ head/lib/libc/locale/querylocale.3 Fri Apr 24 10:17:55 2015 (r281925) @@ -36,7 +36,7 @@ .Sh LIBRARY .Lb libc .Sh SYNOPSIS -.In xlocale.h +.In locale.h .Ft const char * .Fn querylocale "int mask" "locale_t locale" .Sh DESCRIPTION Modified: head/lib/libc/locale/uselocale.3 == --- head/lib/libc/locale/uselocale.3Fri Apr 24 09:52:41 2015 (r281924) +++ head/lib/libc/locale/uselocale.3Fri Apr 24 10:17:55 2015 (r281925) @@ -36,7 +36,7 @@ .Sh LIBRARY .Lb libc .Sh SYNOPSIS -.In xlocale.h +.In locale.h .Ft locale_t .Fn uselocale "locale_t locale" .Sh DESCRIPTION ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r281927 - head/lib/libc/locale
Author: theraven
Date: Fri Apr 24 10:21:20 2015
New Revision: 281927
URL: https://svnweb.freebsd.org/changeset/base/281927
Log:
__xlocale_C_ctype should not be const. It contains a reference count that is
modified by newlocale / duplocale / freelocale.
MFC after:1 week
Modified:
head/lib/libc/locale/none.c
Modified: head/lib/libc/locale/none.c
==
--- head/lib/libc/locale/none.c Fri Apr 24 10:18:41 2015(r281926)
+++ head/lib/libc/locale/none.c Fri Apr 24 10:21:20 2015(r281927)
@@ -209,7 +209,7 @@ struct xlocale_ctype __xlocale_global_ct
256 /* __mb_sb_limit */
};
-const struct xlocale_ctype __xlocale_C_ctype = {
+struct xlocale_ctype __xlocale_C_ctype = {
{{0}, "C"},
(_RuneLocale*)&_DefaultRuneLocale,
_none_mbrtowc,
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r278479 - in head: etc sys/kern
On 10 Feb 2015, at 18:30, Rui Paulo wrote: > > Another thing I had in mind (which is more work) was to abstract the devctl > kernel code in an API which could make it easy to fan out the notifications > to multiple /dev devices. However, that may be overkill. This kind of notification is something that kdbus is increasingly being used for on Linux. The primitive allows events to originate either in the kernel or in userspace and to be sent either point-to-point or to a bloom filter set of recipients (so you occasionally get some messages you're not expecting, but hopefully don't get too many spurious wakeups). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On 5 Mar 2015, at 12:30, Slawa Olhovchenkov wrote: > > Yes, if ships before (don't break if working). > Some Linux distro remove telnet from default install. > Do you like to remove telnet also? Absolutely, now that netcat is part of the default install. For anything that a sane user might consider telnet for in 2015, netcat is a better option. For insane users, there's always pkg add. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On 5 Mar 2015, at 12:33, Slawa Olhovchenkov wrote: > > And how to test open/listing ports/sockets?! netcat - nc(1) - which can also work in the other direction and is designed specifically for this purpose. > How to connect to mpd control socket?! mpdcon from the command line, MPDroid from my mobile, or nc if you're a masochist. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On 5 Mar 2015, at 12:21, Slawa Olhovchenkov wrote: > >> I guess when they are going to be not precious enough to be removed? :) >> >> In modern world of ssh and https, does any OS require them in base? > > yes. > Some telecom equipment require rlogin. 'Some relatively obscure use case needs them' is not usually the requirement for keeping something in the base system. Presumably people who interact with telecoms equipment are capable of installing packages... David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
> On 5 Mar 2015, at 12:42, Slawa Olhovchenkov wrote: > >> netcat - nc(1) - which can also work in the other direction and is designed >> specifically for this purpose. > > nc(1) don't correctly work. It works for me for everything that I used to use telnet for (connection testing, checking plain-text protocols, although increasingly I have to use openssl s_client because few things speak TCP without SSL), what cases does it not work for you? > nc don't work with unix socket. Okay, now you're changing your requirements - you first spoke of remote equipment and network testing. However, UNIX domain sockets appear as files in the filesystem, and we have a host of utilities that are capable of interacting with files (unless they're message-oriented, but then telnet doesn't help either). >>> How to connect to mpd control socket?! >> >> mpdcon from the command line, MPDroid from my mobile, or nc if you're a >> masochist. > > MPDroid?! wut? Or you just don't know about mpd? The one that I'm familiar with is the music player daemon. The other common use of the initalism is multiple personality disorder. If you mean something else, then you should probably say what it is, rather than rely on other people understanding some obscure term (hint: you're not doing yourself any favours in justifying that this is a widespread requirement if people reading your post can't even tell what the requirement is). If you meant the mpd5 package then... well, if you're installing one thing from packages then installing another is not really likely to be an issue. Anyway, from your follow up to Gleb, it seems that your requirement is a network testing tool for computers that are not connected to a network? That seems like a sufficiently niche use that you don't need to have things in the base system. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On 5 Mar 2015, at 13:14, Slawa Olhovchenkov wrote: > > In previos message -- silently return when telnet speak about used IP > address and diagnostic messages. One simple command do many diagnostic > information. Okay, so check the return code. Or pass -v if you want more verbose information: $ nc -v foo.example.com 80 nc: getaddrinfo: nodename nor servname provided, or not known $ nc -v localhost 80 nc: connectx to localhost port 80 (tcp) failed: Connection refused nc: connectx to localhost port 80 (tcp) failed: Connection refused nc: connectx to localhost port 80 (tcp) failed: Connection refused Or even alias nc -v to telnet if you like typing more... Or add -D, if you want more debugging information. > I am know only about telnet can connect to unix socket. So can cat... Actually, so can nc if you read the man page (which, of course, you did before deciding that it couldn't do what you needed). With -U, it will connect to a UNIX domain socket. Oh, and it can also create UNIX sockets for listening to: $ nc -l -U tmp $ # in another terminal: $ nc -U tmp And now you have two nc instances talking to each other via a UNIX socket. > Why not? And why before this is will be ok? Telnet is in the base system because, back in the 4BSD days, telnet was the recommended way that you logged into remote computers. Now it isn't. For most network diagnostic and simple socket operations, nc is a far more useful tool. Including things that want to talk to UNIX sockets. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On 5 Mar 2015, at 14:04, Dmitry Sivachenko wrote: > It is so nice to have most useful stuff out of the box. The question is whether a tool for logging into remote machines without encryption is 'the most useful stuff'. The tool is also [ab]used for network testing, but we already provide a better tool for that in the form of nc(1). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On 5 Mar 2015, at 14:13, Slawa Olhovchenkov wrote: > > Not better, no. Does telnet support creating server sockets? No. Does telnet support IPsec? No. Does telnet let you specify the tcp window size? No. Does telnet come with a massive selection of options for insecure login / authentication? Yes. Telnet is a tool for insecure remote access. nc is a tool for creating and debugging socket connections. > telnet more verbose (and by default and more). 'nc -v' is less to type than 'telnet' and provides *more* debugging support via -D. > And what about 'tools, not policy'? What about it? We provide a tool that *is designed for creating and debugging sockets*. You instead want a tool for insecure remote login that happens to sort-of work for creating and debugging sockets and your justification for wanting it is that you can use it for debugging sockets. >From your previous posts, you've clearly not read the nc man page and have >absolutely no idea what it is capable of. Why not spent five minutes learning >about the tool that we provide that is *designed specifically for your >requirements* and then suggest places where it could be improved for your >needs, rather than insisting that we provide you with a hammer so that you can >keep bashing screws into walls? David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279764 - head/sys/vm
On 10 Mar 2015, at 10:18, Konstantin Belousov wrote: > > Because you cannot grep for the panic string when __func__ is used. The userspace assert uses __func__, __FILE__ and __LINE__, which means that you never need to grep the source code to find out where the assert came from: the assertion message tells you precisely where to go. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r295768 - head/usr.sbin/iostat
On 19 Feb 2016, at 23:23, Dimitry Andric wrote:
>
> This warning is only produced when you use -Wall -W, and then initialize
> structs partially, i.e. you initialize some fields but not others. I
> think this is a quite reasonable warning for a high warning level.
The warning is annoying in many ways. You ought to be able to zero initialise
any struct with {0}, but clang objects if you do this and requires every field
to be filled in. This warning really shouldn’t be enabled with -Wall, because
it has too hight a false positive rate.
With regard to Bruce’s comment about padding, this is a known issue in C11.
There is an open DR about it and it’s scheduled for discussion at the WG14
meeting in London in April.
David
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r295768 - head/usr.sbin/iostat
On 22 Feb 2016, at 10:15, Kubilay Kocak wrote: > > For the lay persons among us (I'm genuinely interested), what are the > the downsides to requiring initialization of all fields? Explicit initialisation, or initialisation in general? Being able to initialise the entire structure with code that will always initialise everything with zero makes the code less fragile because you can add a field to the structure and not have to find all of the places where it’s initialised. The clang warning makes it easy to find the places you need to change, but now you have code churn for no good reason. Implicit initialisation is often useful for generating more efficient code. If you’re intialising with a bunch of common fields, the compiler will end up creating a static variable and doing a memcpy (which the back end may optimise), which is very cheap. A load of code in libc ends up like this. > And in addition, the upsides, if any, of 'deferred' field initialization? The same as the upsides for deferred variable initialization. Modern compilers are good at tracking intraprocedural data flow. If you don’t initialise a field, then the compiler can typically tell that you’ve read from a field but not written to it. It’s generally good defensive programming for zero to have a well-defined meaning (C codifies this for pointers, Go codifies it for all structure types), but if you haven’t done this then the zero may be a valid but incorrect value and no amount of static analysis can tell you that the programmer did something that is valid but wrong. Some languages with richer type systems explicitly encode the invalidity of the variable in its type and transform it to the valid version once it is initialised (some also provide maybe types as a programmer-level constructs. You can implement them fairly trivially in C++, see for example LLVM’s ErrorOr<> template). Sane coding style for C (not style(9)) typically includes the principle of minimum scope, where variables must be declared as close to possible their initialisation. This helps minimise these problems, because you either declare the variable where it is initialised, or (if initialisation is conditional) right next to it where you can clearly see that it has been initialised on all code paths. Unfortunately, as you can see from the PVS results, style(9) could have been carefully designed to maximise the introduction of accidental bugs. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r289027 - head/contrib/tzcode/stdtime
On 8 Oct 2015, at 13:51, Andriy Gapon wrote: > > What if one day github disappears but FreeBSD is still going? > The full commit message would be lost. That’s not the only thing that is bad about this commit message. Why ‘Assume C89?’ We compile libc as C99 + GNU extensions and are likely to default to C11 + GNU extensions soon. Reading the actual commit, it looks as if it’s changing K&R declarations to ISO C declarations. It’s also introducing an ATTRIBUTE_PURE macro in private.h, which does exactly the same as __pure declared in sys/cdefs.h (which is included by *every single FreeBSD header*. Why this extra spelling? No idea. Is this contrib code (it looks like it)? If so, it should come in via the vendor area (not be directly committed to head), if not then it should have been code reviewed and not include redundant and confusing macro declarations. When merging stuff from GitHub, Alfred has written some good documentation about how to handle them in such a way that we preserve the prior commit history (effectively, checkout the pr branch, rebase it on head, git svn dcommit the result). Please follow this procedure. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r289935 - in head/usr.bin: . dtc
Author: theraven
Date: Sun Oct 25 14:52:16 2015
New Revision: 289935
URL: https://svnweb.freebsd.org/changeset/base/289935
Log:
Lots of improvements to the BSD-licensed dtc
- Various fixes to includes (including recursive includes)
- Lots of testing that the output exactly matches GPL'd dtc
- Lots of bug fixes to merging
- Fix incorrect mmap usage
- Ad-hoc memory management replaced with C++11 unique_ptr and similar
Patrick Wildt has successfully run many (all?) of the GPL dtc test suite.
Modified:
head/usr.bin/Makefile
head/usr.bin/dtc/checking.cc
head/usr.bin/dtc/checking.hh
head/usr.bin/dtc/dtb.cc
head/usr.bin/dtc/dtc.cc
head/usr.bin/dtc/fdt.cc
head/usr.bin/dtc/fdt.hh
head/usr.bin/dtc/input_buffer.cc
head/usr.bin/dtc/input_buffer.hh
head/usr.bin/dtc/string.hh
Modified: head/usr.bin/Makefile
==
--- head/usr.bin/Makefile Sun Oct 25 14:42:56 2015(r289934)
+++ head/usr.bin/Makefile Sun Oct 25 14:52:16 2015(r289935)
@@ -210,8 +210,10 @@ SUBDIR.${MK_GAMES}+= pom
SUBDIR.${MK_GAMES}+= primes
SUBDIR.${MK_GAMES}+= random
.if ${MK_GPL_DTC} != "yes"
+.if ${COMPILER_FEATURES:Mc++11}
SUBDIR+= dtc
.endif
+.endif
SUBDIR.${MK_GROFF}+= vgrind
SUBDIR.${MK_HESIOD}+= hesinfo
SUBDIR.${MK_ICONV}+= iconv
Modified: head/usr.bin/dtc/checking.cc
==
--- head/usr.bin/dtc/checking.ccSun Oct 25 14:42:56 2015
(r289934)
+++ head/usr.bin/dtc/checking.ccSun Oct 25 14:52:16 2015
(r289935)
@@ -51,7 +51,7 @@ namespace
struct address_cells_checker : public checker
{
address_cells_checker(const char *name) : checker(name) {}
- virtual bool check_node(device_tree *tree, node *n)
+ virtual bool check_node(device_tree *tree, const node_ptr &n)
{
// If this has no children, it trivially meets the
// conditions.
@@ -61,8 +61,7 @@ namespace
}
bool found_address = false;
bool found_size = false;
- for (node::property_iterator i=n->property_begin(),
-e=n->property_end() ; i!=e ; ++i)
+ for (auto i=n->property_begin(), e=n->property_end() ;
i!=e ; ++i)
{
if (!found_address)
{
@@ -91,7 +90,7 @@ namespace
} // anonymous namespace
bool
-checker::visit_node(device_tree *tree, node *n)
+checker::visit_node(device_tree *tree, const node_ptr &n)
{
path.push_back(std::make_pair(n->name, n->unit_address));
// Check this node
@@ -100,8 +99,7 @@ checker::visit_node(device_tree *tree, n
return false;
}
// Now check its properties
- for (node::property_iterator i=n->property_begin(), e=n->property_end()
-; i!=e ; ++i)
+ for (auto i=n->property_begin(), e=n->property_end() ; i!=e ; ++i)
{
if (!check_property(tree, n, *i))
{
@@ -125,22 +123,21 @@ void
checker::report_error(const char *errmsg)
{
fprintf(stderr, "Error: %s, while checking node: ", errmsg);
- for (device_tree::node_path::iterator p=path.begin()+1, pe=path.end() ;
-p!=pe ; ++p)
+ for (auto &p : path)
{
putc('/', stderr);
- p->first.dump();
- if (!(p->second.empty()))
+ p.first.dump();
+ if (!(p.second.empty()))
{
putc('@', stderr);
- p->second.dump();
+ p.second.dump();
}
}
fprintf(stderr, " [-W%s]\n", checker_name);
}
bool
-property_checker::check_property(device_tree *tree, node *n, property *p)
+property_checker::check_property(device_tree *tree, const node_ptr &n,
property_ptr p)
{
if (p->get_key() == key)
{
@@ -154,7 +151,7 @@ property_checker::check_property(device_
}
bool
-property_size_checker::check(device_tree *tree, node *n, property *p)
+property_size_checker::check(device_tree *tree, const node_ptr &n,
property_ptr p)
{
uint32_t psize = 0;
for (property::value_iterator i=p->begin(),e=p->end() ; i!=e ; ++i)
@@ -216,10 +213,9 @@ bool
check_manager::run_checks(device_tree *tree, bool keep_going)
{
bool success = true;
- for (std::map::iterator i=checkers.begin(),
-e=checkers.end() ; i!=e ; ++i)
+ for (auto &i : checkers)
{
- success &= i->second->check_tree(tree);
+ success &= i.second->check_tree(tree);
if (!(success || keep_going))
{
break;
@@ -231,7 +227
svn commit: r289995 - head/usr.bin/dtc
Author: theraven Date: Mon Oct 26 10:37:17 2015 New Revision: 289995 URL: https://svnweb.freebsd.org/changeset/base/289995 Log: Ensure that dtc is built in C++11 mode. Reported by: George Abdelmalik Modified: head/usr.bin/dtc/Makefile Modified: head/usr.bin/dtc/Makefile == --- head/usr.bin/dtc/Makefile Mon Oct 26 10:09:08 2015(r289994) +++ head/usr.bin/dtc/Makefile Mon Oct 26 10:37:17 2015(r289995) @@ -6,6 +6,8 @@ MAN=dtc.1 WARNS?=3 +CXXFLAGS+= -std=c++11 + NO_SHARED?=NO .include ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r289995 - head/usr.bin/dtc
On 26 Oct 2015, at 10:48, Baptiste Daroussin wrote: > > Just jumping on that one, you should probably revisit de HACKING files :) Ah, good point. I’ll update them. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r289996 - head/usr.bin/dtc
Author: theraven Date: Mon Oct 26 11:02:57 2015 New Revision: 289996 URL: https://svnweb.freebsd.org/changeset/base/289996 Log: Update some obsolete information in the HACKING document. Reported by: bapt Modified: head/usr.bin/dtc/HACKING Modified: head/usr.bin/dtc/HACKING == --- head/usr.bin/dtc/HACKINGMon Oct 26 10:37:17 2015(r289995) +++ head/usr.bin/dtc/HACKINGMon Oct 26 11:02:57 2015(r289996) @@ -21,19 +21,17 @@ welcome. C++11 - -This project currently aims to compile with g++ 4.2.1 and so doesn't make any -use of C++11 features. It would be a good idea to relax this restriction once -clang is the default compiler for ARM, MIPS and PowerPC. - -This code makes use of a lot of iterator loops, which would be cleaner using -the new syntax in C++11. It also explicitly deletes a lot of objects held in -collections in destructors that have these collections as their members. This -could be simplified by using `shared_ptr`. - -The code does make use of `static_assert()`, but uses a macro in utility.hh to -remove these if they are not supported. The FreeBSD standard headers also -define a compatibility macro the implements static asserts in terms of an array -with 1 element on success and -1 elements on failure. +This project uses C++11, as the goal for FreeBSD 11 is to require C/C++11 as a +minimum, either from clang or an external toolchain. In particular, it uses +`std::unique_ptr` extensively for memory management within the tree. Unique +pointers are also used in several other places to track ownership. + +Most iterator loops use the new loop syntax and the `auto` type for type +deduction. Range-based `for` loops generally improve the readability of the +code, though `auto` should only be used in places where the type can be deduced +as easily by the reader as by the compiler. + +The code also makes use of `static_assert()` to track compile-time invariants. Adding New Checks - ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r273135 - in head/sys: contrib/rdma/krping dev/cxgbe/iw_cxgbe ofed/drivers/infiniband/core ofed/drivers/infiniband/hw/mlx4 ofed/drivers/infiniband/hw/mthca ofed/drivers/infiniband/ulp/
On 16 Oct 2014, at 14:41, Mateusz Guzik wrote: > Well, atomic_set can be as simple as v->counter = i; (which btw will > make it look identical to linux version). This should not give any > measureable effect unless atomic_set on given var is abused quite a lot. v->counter = i does not establish a happens-before relationship and so there is no guarantee that the write will be visible to other threads until something else does establish such a relationship. The compiler and CPU are both free to reorder the store at will, and to elide it. There is a reason that C11 provides atomic_store and atomic_load operations. It sounds like Linux wants the relaxed consistency model here, which *is* equivalent to v->counter = i on x86, but *will not be the same* on any weakly-ordered architecture (e.g. ARM). Given that we have a stdatomic.h in the base system, which works with all of our supported compilers, please consider using the functionality provided by the C standard to solve your exact problem. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r273274 - head/sys/netpfil/ipfw
On 19 Oct 2014, at 13:02, Andriy Gapon wrote: > I think that on platforms where an optimized version of fls() is available > that > would work faster than this cool piece of bit magic. If you're lucky, the compiler's idiom recogniser will spot this. You're generally better off using the builtins though, because then the compiler will expand them to something sensible (hopefully - old versions of gcc did horribly inefficient things for bswap and clz on platforms without native support). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r274086 - head/sbin/route
On 4 Nov 2014, at 10:28, Stefan Farfeleder wrote: > Shouldn't Coverity understand that err doesn't return? err() is marked as __dead2, which expands to __attribute__((__noreturn__)). If Coverity doesn't know that __attribute__((__noreturn__)) functions don't return, then that's a Coverity bug and they should fix it (if we're not expanding __dead3 to __attribute__((__noreturn__)) for Coverity, then that's a sys/cdefs.h bug and should be fixed there). Putting a break after a noreturn function makes the code less readable and will cause errors in non-buggy static analysers (dead code warning - why do you have a break on an unreachable line?). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r273382 - head/contrib/libcxxrt
On 6 Nov 2014, at 01:04, Rui Paulo wrote: > I don't think the non-temporary fix was ever committed. What's the problem? > Is something else defining these methods? Yes, they're defined by libc++ too. The problem is that gcc 4.9 wants to be able to throw bad_array_new_length exceptions when you do new foo[x] and sizeof(foo) * x overflows. It does this by calling a support function defined in the C++ runtime, but that means that the C++ runtime must have the bad_array_new_length class defined there too. Having the methods on those classes defined in libcxxrt and libc++ breaks things. The correct fix was to move a #endif in libc++ so that it didn't compile those functions. There was some discussion about whether we needed to support the case that old libc++ and new libcxxrt were used, but it's probably not required. Bapt was going to check whether there were any symbol versioning issues with code compiled against old libc++/libcxxrt and dynamically linked against the new one. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r274340 - in head/sys: crypto/rijndael dev/random geom/bde
On 11 Nov 2014, at 16:31, Brooks Davis wrote: > In general, we need to fix the C/C++ standard to us express the > things we actually mean when we use const (for example see strchr()'s > use of const). I believe the last issue now being tracked on Google's > internal list of deficiencies in the C++ standard. One of the reviewers for a paper involving this pointed me at Jeffrey Foster's work on qualifier polymorphism for C, which would address these issues. Unfortunately, this work is quite old and didn't make it into the standard. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r290711 - head/sys/ofed/drivers/infiniband/core
On 13 Nov 2015, at 08:35, Konstantin Belousov wrote: > > On Fri, Nov 13, 2015 at 09:18:54AM +0100, Hans Petter Selasky wrote: >> Hi, >> >> On 11/12/15 18:17, Conrad Meyer wrote: >>> These should cast through (u)intptr_t rather than unsigned long. >>> >> >> This is Linux code, and they use "unsigned long" for pointer casts >> everywhere, trying to not break their style. >> >> BTW: I added to linux_compat.c: >> >> CTASSERT(sizeof(unsigned long) == sizeof(uintptr_t)); >> >> And it survived my "tinderbox" build and I was surprised! > > FreeBSD (at least currently) runs on two kinds of ABIs: ILP32 and LP64. > ILP32 means that sizeof(int) == sizeof(long) == sizeof(void *) == 4. > For LP64, sizeof(long) == sizeof(void *) == 8, while sizeof(int) == 4. > We do not support anything else. Note that this is not true of all downstreams. We currently have 128 and 256-bit void*s with 64-bit longs on CHERI, and I believe that bde’s version has 32-bit longs on all platforms. This kind of code *is* broken for us and we’d greatly appreciate people not writing new code that intentionally relies on undefined behaviour (round tripping a pointer via any integer type other than intptr_t is undefined in C), when a well-defined mechanism exists, just because Linux decides to do the wrong thing. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r292876 - head/usr.bin/dtc
Author: theraven
Date: Tue Dec 29 16:29:42 2015
New Revision: 292876
URL: https://svnweb.freebsd.org/changeset/base/292876
Log:
Improvements to BSD-licensed DTC.
- Added an expression parser so that expressions from headers are now working
- Fixed missing null terminators on cross references
- Disabled exceptions / RTTI in the build for smaller binaries
- Changed phandle order generation to be identical to GPL'd dtc
Modified:
head/usr.bin/dtc/Makefile
head/usr.bin/dtc/checking.cc
head/usr.bin/dtc/checking.hh
head/usr.bin/dtc/dtb.hh
head/usr.bin/dtc/fdt.cc
head/usr.bin/dtc/fdt.hh
head/usr.bin/dtc/input_buffer.cc
head/usr.bin/dtc/input_buffer.hh
Modified: head/usr.bin/dtc/Makefile
==
--- head/usr.bin/dtc/Makefile Tue Dec 29 16:11:43 2015(r292875)
+++ head/usr.bin/dtc/Makefile Tue Dec 29 16:29:42 2015(r292876)
@@ -6,7 +6,7 @@ MAN=dtc.1
WARNS?=3
-CXXFLAGS+= -std=c++11
+CXXFLAGS+= -std=c++11 -fno-rtti -fno-exceptions
NO_SHARED?=NO
Modified: head/usr.bin/dtc/checking.cc
==
--- head/usr.bin/dtc/checking.ccTue Dec 29 16:11:43 2015
(r292875)
+++ head/usr.bin/dtc/checking.ccTue Dec 29 16:29:42 2015
(r292876)
@@ -51,7 +51,7 @@ namespace
struct address_cells_checker : public checker
{
address_cells_checker(const char *name) : checker(name) {}
- virtual bool check_node(device_tree *tree, const node_ptr &n)
+ virtual bool check_node(device_tree *, const node_ptr &n)
{
// If this has no children, it trivially meets the
// conditions.
@@ -151,7 +151,7 @@ property_checker::check_property(device_
}
bool
-property_size_checker::check(device_tree *tree, const node_ptr &n,
property_ptr p)
+property_size_checker::check(device_tree *, const node_ptr &, property_ptr p)
{
uint32_t psize = 0;
for (property::value_iterator i=p->begin(),e=p->end() ; i!=e ; ++i)
Modified: head/usr.bin/dtc/checking.hh
==
--- head/usr.bin/dtc/checking.hhTue Dec 29 16:11:43 2015
(r292875)
+++ head/usr.bin/dtc/checking.hhTue Dec 29 16:29:42 2015
(r292876)
@@ -86,7 +86,7 @@ class checker
* Method for checking that a node is valid. The root class version
* does nothing, subclasses should override this.
*/
- virtual bool check_node(device_tree *tree, const node_ptr &n)
+ virtual bool check_node(device_tree *, const node_ptr &)
{
return true;
}
@@ -94,7 +94,7 @@ class checker
* Method for checking that a property is valid. The root class
* version does nothing, subclasses should override this.
*/
- virtual bool check_property(device_tree *tree, const node_ptr &n,
property_ptr p)
+ virtual bool check_property(device_tree *, const node_ptr &,
property_ptr )
{
return true;
}
@@ -160,7 +160,7 @@ struct property_type_checker begin() == p->end();
}
@@ -175,7 +175,7 @@ struct property_type_checker begin() + 1 == p->end()) && p->begin()->is_string();
}
@@ -190,7 +190,7 @@ struct property_type_checker begin(),e=p->end() ; i!=e ;
++i)
@@ -213,7 +213,7 @@ struct property_type_checker begin() + 1 == p->end()) &&
(tree->referenced_node(*p->begin()) != 0);
Modified: head/usr.bin/dtc/dtb.hh
==
--- head/usr.bin/dtc/dtb.hh Tue Dec 29 16:11:43 2015(r292875)
+++ head/usr.bin/dtc/dtb.hh Tue Dec 29 16:29:42 2015(r292876)
@@ -186,11 +186,11 @@ class binary_writer : public output_writ
* The binary format does not support labels, so this method
* does nothing.
*/
- virtual void write_label(string name) {}
+ virtual void write_label(string) {}
/**
* Comments are ignored by the binary writer.
*/
- virtual void write_comment(string name) {}
+ virtual void write_comment(string) {}
virtual void write_string(string name);
virtual void write_data(uint8_t v);
virtual void write_data(uint32_t v);
Modified: head/usr.bin/dtc/fdt.cc
==
--- head/usr.bin/dtc/fdt.cc Tue Dec 29 16:11:43 2015(r292875)
+++ head/usr.bin/dtc/fdt.cc Tue Dec 29 16:29:42 2015(r292876)
@@ -264,24 +264,6 @@ property::parse_string(input_buffer &inp
void
property::parse_cells(input_buffer &input, int cell_size)
{
- unsigned long long cell_max;
- switch (cell_size)
- {
- case 8:
Re: svn commit: r292809 - head/lib/libc/stdio
On 30 Dec 2015, at 00:48, Bruce Evans wrote: > > - C++ apparently spells this as both _Alignof() and alignof() after 2011/03 This is not correct. C++ spells it alignof. C spells it _Alignof, unless you include , in which case C spells it alignof and defines _ _alignof_is_defined. On FreeBSD, we define _Alignof in C++ mode, because it’s in the reserved identifier space and gives us something that works in C and C++. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r310138 - head/lib/libc/stdio
On 16 Dec 2016, at 19:31, Baptiste Daroussin wrote: > > Other than that, it makes more difficult to use vanilla gcc with out userland. > and it is adding more complexity to be able to build freebsd from a non > freebsd > system which some people are working on. Why? You’ll get some spurious warnings about printf, but that’s all. Our printf (like the glibc one) already supports user-defined extensions via register_printf_function (for which, I note, we don’t have a man page), so third-party code also has some of these warnings if they’ve registered other printf handlers. I’d actually consider that to be the biggest argument against adding %b support: we support users adding their own interpretation of %b via register_printf_function and this will break anyone third-party code where people do this. This commit is doubly bad, because not only does it change our ABI, it doesn’t document the fact. The code in this commit is also simply broken. It does not add a corresponding handler in xprintf.c, so as soon as someone calls register_printf_function with *any* argument, printf’s ability to handle %b will be broken in a difficult-to-debug way. David smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r310138 - head/lib/libc/stdio
On 22 Dec 2016, at 23:02, Baptiste Daroussin wrote: > > I think it is pretty clear that there are too many people requesting the > revert > for the revert not to be done. Even if this feature is desired, the implementation in the patch is broken and should be reverted until a correct implementation (one that doesn’t break the first time user code calls register_printf_*) is done. David smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r302252 - head/sys/kern
On 4 Jul 2016, at 21:09, Adrian Chadd wrote: > > Right, so if we're not careful, we could leak bits of kernel memory, > and it can also screw up key cache comparisons. > > (I asked this question because I've been screwed by it recentlyish, > and it looks like the latest C standard didn't fix it..) It was discussed at the WG14 meeting in London in April, but I don’t think that there was a clear consensus. It gets particularly tricky for _Atomic types, and I think that there’s now a clarification (or will be in C2x, if not) that any padding in _Atomic types is zeroed. Generally, compilers will turn this into a bzero and then a set of the remaining fields, so you’re likely to end up with the right thing, but it’s not guaranteed by the standard. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r323277 - head/lib/libc/locale
Author: theraven
Date: Thu Sep 7 17:51:35 2017
New Revision: 323277
URL: https://svnweb.freebsd.org/changeset/base/323277
Log:
Document some invariants for the XLC_ enum.
These can't be reordered without breaking other code. Document that and add
some static asserts to ensure that anyone who tries gets build failures.
Modified:
head/lib/libc/locale/xlocale_private.h
Modified: head/lib/libc/locale/xlocale_private.h
==
--- head/lib/libc/locale/xlocale_private.h Thu Sep 7 17:20:47 2017
(r323276)
+++ head/lib/libc/locale/xlocale_private.h Thu Sep 7 17:51:35 2017
(r323277)
@@ -40,6 +40,14 @@
#include
#include "setlocale.h"
+/**
+ * The XLC_ values are indexes into the components array. They are defined in
+ * the same order as the LC_ values in locale.h, but without the LC_ALL zero
+ * value. Translating from LC_X to XLC_X is done by subtracting one.
+ *
+ * Any reordering of this enum should ensure that these invariants are not
+ * violated.
+ */
enum {
XLC_COLLATE = 0,
XLC_CTYPE,
@@ -50,6 +58,19 @@ enum {
XLC_LAST
};
+_Static_assert(XLC_LAST - XLC_COLLATE == 6, "XLC values should be contiguous");
+_Static_assert(XLC_COLLATE == LC_COLLATE - 1,
+ "XLC_COLLATE doesn't match the LC_COLLATE value.");
+_Static_assert(XLC_CTYPE == LC_CTYPE - 1,
+ "XLC_CTYPE doesn't match the LC_CTYPE value.");
+_Static_assert(XLC_MONETARY == LC_MONETARY - 1,
+ "XLC_MONETARY doesn't match the LC_MONETARY value.");
+_Static_assert(XLC_NUMERIC == LC_NUMERIC - 1,
+ "XLC_NUMERIC doesn't match the LC_NUMERIC value.");
+_Static_assert(XLC_TIME == LC_TIME - 1,
+ "XLC_TIME doesn't match the LC_TIME value.");
+_Static_assert(XLC_MESSAGES == LC_MESSAGES - 1,
+ "XLC_MESSAGES doesn't match the LC_MESSAGES value.");
/**
* Header used for objects that are reference counted. Objects may optionally
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r323329 - head/sys/sys
On 8 Sep 2017, at 21:09, Mateusz Guzik wrote:
>
> Author: mjg
> Date: Fri Sep 8 20:09:14 2017
> New Revision: 323329
> URL: https://svnweb.freebsd.org/changeset/base/323329
>
> Log:
> Allow __builtin_memset instead of bzero for small buffers of known size
This change seems redundant, because modern compilers already do this
optimisation. For example:
#include
char buf[42];
void bz(void)
{
bzero(buf, 42);
}
With clang 4.0 on x86 compiles to:
pushq %rbp
movq%rsp, %rbp
xorps %xmm0, %xmm0
movups %xmm0, buf+26(%rip)
movaps %xmm0, buf+16(%rip)
movaps %xmm0, buf(%rip)
popq%rbp
retq
On AArch64, it compiles to:
adrpx8, buf
add x8, x8, :lo12:buf
strhwzr, [x8, #40]
stp xzr, xzr, [x8, #24]
stp xzr, xzr, [x8, #8]
str xzr, [x8]
ret
Neither contains a call, both have inlined the zeroing. This change is
strictly worse, because the compiler has some carefully tuned heuristics that
are set per target for when to inline the memset / bzero and when to call the
function. These are based on both the size and the alignment, including
whether the target supports misaligned accesses and whether misaligned accesses
are cheap. None of this is captured by this change.
In the kernel, this optimisation is disabled by -ffreestanding, however
__builtin_memset will be turned into a memset call if the size is not constant
or if the memset call would be more efficient (as determined by the
aforementioned heuristics). Simply using __builtin_memset in all cases should
give better code, and is more likely to be forward compatible with future ISAs
where the arbitrary constant picked in this patch may or may not be optimal.
David
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r284198 - head/bin/ls
On 13 Jun 2015, at 11:17, Ian Lepore wrote: > > If you would have told me a year ago that you had a simple scheme that > could make 30 years of experience maintaining code for unix-like systems > completely worthless I would have been skeptical, but it seems we're > well on our way. There is a lot of heckling and unhelpful hyperbole in this thread. Reading the xo_emit format strings takes a little bit of getting used to, but the same is true of printf - it’s just that we’re already used to printf. The structured parts (xo_open_container, xo_close_container and friends) are clear and descriptive. The changes are fairly invasive, but the benefits are also very large for anyone who is wanting to automate administration of FreeBSD systems. If you have suggestions for how the libxo APIs could be improved, then please let us know - Phil is very reception to suggestions but objections along the lines of ‘it’s not what I’m used to and changes sometimes break things so we should never have changes’ are not helpful. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268137 - head/sys/sys
I only just caught this (having seen the fallout from NetBSD doing the same thing in a shipping release and the pain that it’s caused): __weak is a reserved keyword in Objective-C, please pick another name for this. This in cdefs.h makes it impossible to include any FreeBSD standard headers in Objective-C programs (of which we have a couple of hundred in ports) if they use any of the modern Objective-C language modes. David > On 2 Jul 2014, at 09:45, Hans Petter Selasky wrote: > > Author: hselasky > Date: Wed Jul 2 08:45:26 2014 > New Revision: 268137 > URL: http://svnweb.freebsd.org/changeset/base/268137 > > Log: > Define a "__weak" macro for declaring symbols "weak". > > Modified: > head/sys/sys/cdefs.h > > Modified: head/sys/sys/cdefs.h > == > --- head/sys/sys/cdefs.h Wed Jul 2 05:45:40 2014(r268136) > +++ head/sys/sys/cdefs.h Wed Jul 2 08:45:26 2014(r268137) > @@ -210,7 +210,9 @@ > #define __packed > #define __aligned(x) > #define __section(x) > +#define __weak > #else > +#define __weak __attribute__((__weak__)) > #if !__GNUC_PREREQ__(2, 5) && !defined(__INTEL_COMPILER) > #define __dead2 > #define __pure2 > ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268137 - head/sys/sys
On 19 Jun 2015, at 11:45, Hans Petter Selasky wrote:
>
> Appearently this will be fixed in GNUSTEP base:
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/cdefs_elf.h?only_with_tag=MAIN
>
> Is this still an issue?
It is impossible to fix it in GNUstep Base, because we can’t guarantee that
user code doesn’t include system headers after including GNUstep headers (not
to mention the fact that GNUstep is not the only Objective-C standard library
implementation out there). If the user does, for example:
#import
#include
void example()
{
__weak id foo = bar();
baz(foo);
}
Then they will get a compile error no matter what GNUstep’s Foundation.h does.
It can’t prevent cdefs.h from redefining __weak to be something different.
I’ve just looked at the GNUstep base changelog since that NetBSD commit and
there are no relevant changes, so I’ve no idea what the NetBSD people are
thinking there.
David
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268137 - head/sys/sys
On 19 Jun 2015, at 12:57, Hans Petter Selasky wrote: > > Hi, > >> Then they will get a compile error no matter what GNUstep’s Foundation.h >> does. It can’t prevent cdefs.h from redefining __weak to be something >> different. >> > > Except "#undef __weak” Please read the example that I wrote. This will *not* be fixed by #undef __weak. In particular, the __weak keyword is implemented in Clang as a pre-defined macro, so after *any* inclusion of any C standard library header, every program that uses zeroing weak references needs to redefine __weak to whatever (implementation-defined and subject to change thing) that the compiler defines it to. >> I’ve just looked at the GNUstep base changelog since that NetBSD commit and >> there are no relevant changes, so I’ve no idea what the NetBSD people are >> thinking there. >> > > I think we should have a common cross-BSD solution for the proper definition > of __weak, so that user-space applications which use it follow along. Portable code should not rely on anything in cdefs.h. > Is there a procedure for that? Possibly we should do an exp-run after > changing this to ensure that we don't break more than we fix. I’m not sure what we have any code in ports yet that uses ARC or GC in Objective-C, but I definitely know of people building out-of-ports programs on FreeBSD whose code you have just broken (including myself, though I do Objective-C stuff on 10, so haven’t yet encountered the breakage). > I'll ask some GNUstep people I know about this. Taking off my FreeBSD Core Team hat and putting on my GNUstep libobjc maintainer hat: Please fix this and do not define C-family language keywords or compiler reserved words to be incompatible things in cdefs.h. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268137 - head/sys/sys
On 19 Jun 2015, at 14:41, Hans Petter Selasky wrote: > > On 06/19/15 14:54, David Chisnall wrote: >> I definitely know of people building out-of-ports programs on FreeBSD whose >> code you have just broken (including myself, > > though I do Objective-C stuff on 10, so haven’t yet encountered the > > breakage). > > Hi David, > > r268137 has been in 11-current for a long time (11 months) and was MFC'ed to > 10-stable not long ago. We have not yet done a release from 10 with this breakage, so I’ve not yet seen it in the wild. Most people doing Objective-C development do not develop on FreeBSD -HEAD. The majority develop on OS X and port to FreeBSD releases. I am anxious to get this fixed before the next 10.x release is out so that we are not shipping something that is going to force people wanting to ship Objective-C code to have to have FreeBSD-specific work-arounds for the next few years. > I understand that including "sys/cdefs.h" breaks objective C-code in the > kernel, but we don't have any such code, do we? You fundamentally misunderstand what cdefs.h is. It is not a kernel header, it is the header that provides all of the definitions required for all system headers. All libc headers expect cdefs.h to be included (either directly or indirectly) before anything else in the file. > Multiple systems are defining __weak for C and C++ : > > Linux: >> include/linux/compiler-gcc.h: > #define __weak__attribute__((weak)) > > NetBSD: > > sys/cdefs_elf.h > #define __weak __attribute__((__weak__)) > > FreeBSD: > > sys/cdefs.h > #define __weak __attribute__((__weak__)) NetBSD is the only system that I’m aware of that has actually shipped this, and it broke a lot of things. Spot the odd one out: $ cat tmp.m #include __weak id x; # FreeBSD 10.1: $ cc -E tmp.m -fobjc-arc | tail -1 __attribute__((objc_ownership(weak))) id x; # Linux $ clang -E tmp.m -fobjc-runtime=gnustep-1.7 -fobjc-arc | tail -1 __attribute__((objc_ownership(weak))) id x; # FreeBSD Head: $ cc -E tmp.m -fobjc-arc | tail -1 __attribute__((__weak__)) id x; The worst thing about this is that you have broken it so that it silently does the wrong thing, rather than raising a warning with the default warnings enabled. >> Portable code should not rely on anything in cdefs.h. > > Right - can you explain why it is ending up in your ObjC code? Because it’s in cdefs.h, which is included by *every single userspace C header*. cdefs.h must work with all C-family languages. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268137 - head/sys/sys
On 19 Jun 2015, at 15:32, Marcelo Araujo wrote: > > Maybe would be a good idea run an 'exp run' with this patch? Just to double > check if any port will break, although after you rename, I don't believe it > will conflict anymore, however an 'exp run' would show you it. It’s probably worth doing, though unfortunately the failure mode for the previous breakage was to silently generate the wrong code in some cases and so may not have shown up in an exp run. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r285284 - head/lib/liblzma
On 9 Jul 2015, at 03:53, NGie Cooper wrote: > > $ cat ~/has_immintrin.c > #include > > #if __has_include() > #error "I have immintrin.h" > #else > #error "I don't have immintrin.h" > #endif > $ clang -c ~/has_immintrin.c > /home/ngie/has_immintrin.c:4:2: error: "I have immintrin.h" > #error "I have immintrin.h" > ^ > 1 error generated. > $ gcc -c ~/has_immintrin.c > /home/ngie/has_immintrin.c:6:2: error: #error "I don't have immintrin.h" > > Sadly this macro wasn't added until gcc 5.x: > https://gcc.gnu.org/gcc-5/changes.html cdefs.h defines __has_include(x) to 0 if the compiler does not provide __has_include(), so this will also work with gcc in base (always claiming not to have immintrin.h). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r285284 - head/lib/liblzma
On 9 Jul 2015, at 10:19, NGie Cooper wrote: > > Yes, but this case will fail for gcc 4.3 ~ 4.4 through 5.x if you use > my recommended method... I think that’s probably fine. We basically have four cases that we care about: - People who are using clang because it’s the system compiler [works] - People who are using new clang from ports / svn because it’s new and shiny [works] - People who are using gcc from base because it’s the system compiler [works] - People who are using new gcc from ports / svn because it’s new and shiny [works] The only people it doesn’t work for are the ones building FreeBSD using an out-of-tree old GCC. There probably aren’t too many of those… David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r285404 - head/sys/compat/cloudabi
On 11 Jul 2015, at 21:56, Konstantin Belousov wrote: > >> Bucket 2: The system call could also just fail and return an error >> (MSG_NOSIGPIPE). > SIGPIPE exists to ensure that naive programs do something reasonable > when their stdout suddenly goes away. Or, transposing the PoV, it allows > to write useful and well-behaving programs while ignoring complications. > If all programs must be aware of the special error code from write which > indicates that nobody listens to the output anymore, it would cause > unneeded code copy/pasted all over the src. Presumably this could be handled in userspace in the system call wrappers if someone wanted to do it that way - the syscall wrapper would check for the error condition and call the system call handler (though if you wanted the mcontext to be meaningful for the syscall return or support separate signal stacks then this would be fairly complex). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r285552 - head/usr.bin/xargs
On 15 Jul 2015, at 01:02, Xin Li wrote: > > My only concern with strtonum() is that it's English only. Given that strtonum() wraps strtoll, it ought to support whatever the current locale is (assuming that the program calls setlocale() before calling strtonum(), otherwise it will use the C locale[1]). Or do you mean that the error messages are not localised? David [1] I would strongly advise against calling strtonum() or strtoll(), rather than strtoll_l() from a library, as it is impossible to specify in a potentially multi-threaded context whether you’re currently using a human-friendly or a machine-friendly number representation. In a single-threaded application, it’s probably fine as long as *all* of your number parsing is either from a user or from a machine-parsable file (and all of your output is similar, or you’re explicitly setting the locale before each call). Given that strtonum() is non-standard anyway, we should probably add a strtonum_l() that takes a locale_t and a number base. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r313040 - head/sys/mips/include
On 1 Feb 2017, at 08:13, Konstantin Belousov wrote: > > On Wed, Feb 01, 2017 at 10:38:42AM -0500, Alexander Kabaev wrote: >> On Wed, 1 Feb 2017 16:17:21 +0200 >> Konstantin Belousov wrote: >> >>> Please do not retry on sc failure, return the error to upper layer. >>> See also r313007 and preceeding discussion after r312973. >> >> There was not much a discussion there, do you mind expanding a bit on >> why one behavior is more desired than other? I am not against the >> change, but I need to understand the reasoning behind it better. Since >> atomic_cmpset retries too, it will have to be adjusted as well. > > atomic_cmpset() cannot avoid retry on the ll/sc architectures, because > sc might fail even if the old and the new values are same. One of the > points of the fcmpset API design is to avoid nested loops: this is a > microoptimization to put less pressure on the CPUs frontend. The caller > of (f)cmpset must check for failure anyway, so not doing this inside the > function reduces number of branches. Less branches makes code shorter, > and reduces utilization of some CPU resources, like branch predictor > state. C[++]11 addresses this by having a weak and a strong variant of compare and exchange. The strong version may only fail if the comparison fails, we weak version is permitted to fail spuriously. Given that most uses of compare and exchange use a loop, and most ll/sc architectures guarantee forward process after a few attempts, you almost always want to use the weak version. The weak version also has the advantage that the compiler is free to fold the initial load into the load linked, as long as the target architecture would permit it, so you end up with more idiomatic ll, op, sc, branch sequences, rather than l, op, ll, branch, sc, branch sequences. David smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r322875 - head/sys/dev/nvme
On 25 Aug 2017, at 07:32, Mark Millard wrote: > > As I remember _Static_assert is from C11, not > the older C99. In pre-C11 dialects of C, _Static_assert is an identifier reserved for the implementation. sys/cdefs.h defines it to generate a zero-length array if the condition is true or a negative-length array if it is false, emulating the behaviour (though giving less helpful error messages) > > As I understand head/sys/dev/nvme/nvme.h use by > C++ code could now reject attempts to use > _Static_assert . In C++, _Static_assert is an identifier reserved for the implementation, but in C++11 or newer static_assert is a keyword. sys/cdefs.h defines _Static_assert to static_assert for newer versions of C++ and defines it to the C-before-11-compatible version for C++-before-11. TL;DR: We have gone to a lot of effort to ensure that these keywords work in all C/C++ dialects, please use them, please report bugs if you find a case where they don’t work. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
