C99 allows to define arrays as non-overlappiung using the restrict
keyword. This is supported by GCC 3.1 and later, but it's not
allowed in C++.
This is in preparation of fixing a Cygwin build problem introduce by
commit 3c75fac130.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Newlib shares large parts of <sys/cdefs.h> with FreeBSD and received
this bug report:
https://sourceware.org/pipermail/newlib/2023/020400.html
As an extension, GCC and clang offer C99-style restricted pointers in
C++ mode:
https://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html
We notice that this extension is broken when including newlib headers:
restricted pointers are treated as ordinary pointers.
We traced this to the following section of
newlib/libc/include/sys/cdefs.h:
/*
* GCC 2.95 provides `__restrict' as an extension to C90 to support the
* C99-specific `restrict' type qualifier. We happen to use `__restrict' as
* a way to define the `restrict' type qualifier without disturbing older
* software that is unaware of C99 keywords.
*/
#if !(__GNUC__ == 2 && __GNUC_MINOR__ == 95)
#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901
#define __restrict
#else
#define __restrict restrict
#endif
#endif
While the GCC __restrict extension was indeed introduced in GCC 2.95, it
is not limited to this version; the extension is also not limited to
C90:
https://gcc.gnu.org/gcc-2.95/c++features.html
Rewrite the logic in the header so that __restrict is kept alone when
available.
PR: 272723
MFC after: 1 week
version of __generic()
This ensures that __generic() more closely matches _Generic() when
using the fallback version when _Generic() is not available (such as
GCC).
Co-authored by: jrtc27
Reviewed by: jrtc27
Differential Revision: https://reviews.freebsd.org/D38215
This makes roundup2/rounddown2 type- and const-preserving and allows
using it on pointer types without casting to uintptr_t first. Not
performing pointer-to-integer conversions also helps the compiler's
optimization passes and can therefore result in better code generation.
When using it with integer values there should be no change other than
the compiler checking that the alignment value is a valid power-of-two.
I originally implemented these builtins for CHERI a few years ago and
they have been very useful for CheriBSD. However, they are also useful
for non-CHERI code so I was able to upstream them for Clang 10.0.
Rationale from the clang documentation:
Clang provides builtins to support checking and adjusting alignment
of pointers and integers. These builtins can be used to avoid relying
on implementation-defined behavior of arithmetic on integers derived
from pointers. Additionally, these builtins retain type information
and, unlike bitwise arithmetic, they can perform semantic checking on
the alignment value.
There is also a feature request for GCC, so GCC may also support it in
the future: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98641
Reviewed By: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D28332
The age of the intel compiler support is so old as to be
uninteresting. No recent recports of intel compiler support have been
received. Remove all the special case workarounds for the Intel
compiler. Should there be interest in supporting the compiler, contact
me and I'll work with people to make it happen, though I suspect these
instances are more likely to be in the way than to be helpful.
Reviewed by: cem, emaste, vangyzen, dim
Differential Revision: https://reviews.freebsd.org/D26817
For configurations without x2APIC support (guests, older hardware), the global
LAPIC MMIO mapping will trigger false-positive KCSan reports as it will appear
that multiple CPUs are concurrently reading and writing the same address.
This isn't actually true, as the underlying physical access will be performed
on the local CPU's APIC. Additionally, because LAPIC access can happen during
event timer configuration, the resulting KCSan printf can produce a panic due
to attempted recursion on event timer resources.
Add a __nosanitizethread preprocessor define to prevent the compiler from
inserting TSan hooks, and apply it to the x86 LAPIC accessors.
PR: 249149
Reported by: gbe
Reviewed by: andrew, kib
Tested by: gbe
Differential Revision: https://reviews.freebsd.org/D26354
This is an unfortunate instance where the __has_attribute check does
not function usefully. Gcc does have the attribute, but for gcc it only
applies to functions, not variables, and trying to apply it to a
variable generates Wattribute. So far we only apply the attribute to
variables. Only enable the attribute for clang, for now.
Reviewed by: Anton Rang <rang at acm.org>
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D22875
The assumptions of linker_set don't play nicely with
AddressSanitizer. AddressSanitizer adds a 'redzone' of zeros around
globals (including those in named sections), whereas linker_set
assumes they are all packed consecutively like a pointer array. So:
let's annotate linker_set so that AddressSanitizer ignores it.
Submitted by: Matthew Bryan <matthew.bryan@isilon.com>
Reviewed by: kib, rang_acm.org
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D22239
The <sys/cdefs.h> and <stdatomic.h> headers already included support for
C11 atomics via intrinsincs in modern versions of GCC, but these versions
tried to "hide" atomic variables inside a wrapper structure. This wrapper
is not compatible with GCC's internal <stdatomic.h> header, so that if
GCC's <stdatomic.h> was used together with <sys/cdefs.h>, use of C11
atomics would fail to compile. Fix this by not hiding atomic variables
in a structure for modern versions of GCC. The headers already avoid
using a wrapper structure on clang.
Note that this wrapper was only used if C11 was not enabled (e.g.
via -std=c99), so this also fixes compile failures if a modern version
of GCC was used with -std=c11 but with FreeBSD's <stdatomic.h> instead
of GCC's <stdatomic.h> and this change fixes that case as well.
Reported by: Mark Millard
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D16585
Restore FreeBSD compatibility for __alloc_size() and __alloc_align().
This is a follow-up to commit e494b56035.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
At least on GCC7 calling __alloc_size(x) twice is not equivalent to
calling using the attribute once with two arguments. The later is the
documented use in GCC documentation so add a new alloc_size(n, x)
alternative to cover for the few places where it is used: basically:
calloc(3), reallocarray(3) and mallocarray(9).
Submitted by: Mark Millard
MFC after: 3 days
Reference:
http://docs.freebsd.org/cgi/mid.cgi?F227842D-6BE2-4680-82E7-07906AF61CD7
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
GCC only activates C11 keywords in C mode, not C++ mode. This means
that when targeting an older C++ standard, we cannot fall back to using
_Static_assert(). In this case, do define _Static_assert() as a macro
that uses a typedef'ed array.
Discussed in: r322875 commit thread
Reported by: Mark MIllard
MFC after: 1 month
This reverts most of commit 979d467ff6.
We cannot avoid some bareword attributes until clang is fixed to
properly support __-decorated attributes; see this bug:
https://bugs.llvm.org/show_bug.cgi?id=34319
The macros in question expand to the empty string under gcc, so
only compilation under clang is affected, and since clang has the
bug, the obvious solution is to roll back the changes, and document
the issue.
Signed-off-by: Eric Blake <eblake@redhat.com>
Always use the __-decorated form of an attribute name in public
headers, as the bareword form is in the user's namespace, and we
don't want compilation to break just because the user defines the
bareword to mean something else.
Signed-off-by: Eric Blake <eblake@redhat.com>
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
For example, the FreeBSD GCC (4.2.1) has a spotty support for that
feature. If the static keyword is used with an unnamed array parameter
in a function declaration, then the compilation fails with:
error: static or type qualifiers in abstract declarator
The feature does work if the parameter is named.
So, the restriction introduced in this commit can be removed when all
affected function prototypes have the workaround.
MFC after: 1 week
Sponsored by: Panzura
For consistency with the qualifiers added in r310977, define a new
qualifier _Null_unspecified which is also defined in clang 3.7+.
Add two new macros:
__NULLABILITY_PRAGMA_PUSH
__NULLABILITY_PRAGMA_POP
These are for use in headers when we want avoid noisy warnings if
some pointers are left without nullability annotations.
These are added with way ahead of their first use to teach the GCC
ports headers of their existance before their first use.
This was meant to be used by a future FORTIFY_SOURCE implementation.
Probably for good, FORTIFY_SOURCE and this particular GCCism were never
well supported by clang or other compilers. Furthermore, the technology
has long since been replaced by either static checkers, sanitizers, or
even just the strong stack protector that was enabled by default.
Drop __gnu_inline to avoid cluttering the headers.
MFC after: 5 days
Add two new qualifiers for use by the static checkers:
_Nonnull
The _Nonnull nullability qualifier indicates that null is not a meaningful
value for a value of the _Nonnull pointer type.
_Nullable
The _Nullable nullability qualifier indicates that a value of the
_Nullable pointer type can be null.
These were introduced in Clang 3.7. For more information, see:
http://clang.llvm.org/docs/AttributeReference.html#nonnull
We add these now without using them so that the GCC ports have time to
pick up the header change.
Hinted by: Android Bionic libc [1]
Also seen in: Apple's Libc-1158.20.4
[1]
baa2a973bd
C99 allows array function parameters to use the static keyword for their
sizes. This tells the compiler that the parameter will have at least the
specified size, and calling code will fail to compile if that guarantee is
not met. However, this syntax is not legal in C++.
This commit reverts r300824, which worked around the problem for
sys/md5.h only, and introduces a new macro: min_size(). min_size(x) can
be used in headers as a static array size, but will still compile in C++
mode.
Reviewed by: cem, ed
MFC after: 4 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D8277
fix a typo in __STDC_VERSION__ in __min_size requirements
MFC after: 1 week
Sponsored by: Panzura
It clashes with the one in libc++'s <atomic> header.
(Previously, the _Atomic() macro was defined in <stdatomic.h>, which is
only for use with C11, but for various reasons it was moved to its
current location in r251804.)
Discussed with: bdrewery, ed
MFC after: 2 weeks
Non-default visibility attributes are unsupported on PE/COFF, so don't
use in __hidden definition for Cygwin. Add comment.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This is the complete rework of the feature tests macros for better
compatibility with GNU libc, primarily based on the Linux man pages
documentation:
http://man7.org/linux/man-pages/man7/feature_test_macros.7.html
The previous implementation was flawed in its approach that macros were
often used to hide symbols if defined (e.g. !defined __STRICT_ANSI__ or
!defined _POSIX_SOURCE), whereas the approach of glibc is that these macros
make symbols available when defined (e.g. defined _BSD_SOURCE, or as used
internally, #if __BSD_VISIBLE). As much open-source software is written
with glibc in mind, this necessitated patching numerous packages just to
compile.
In particular, __STRICT_ANSI__ (which is defined by gcc -ansi or -std=c*)
was given too much importance. This implementation limits the influence
of __STRICT_ANSI__ to controlling the default when no other feature test
macros are defined, and to the inclusion of <alloca.h> in <stdlib.h> as
documented. These are the only places where __STRICT_ANSI__ should be
tested.
The following macros are now accepted: _ATFILE_SOURCE, _BSD_SOURCE,
_DEFAULT_SOURCE, _ISOC99_SOURCE, _ISOC11_SOURCE, _LARGEFILE_SOURCE,
_SVID_SOURCE, _XOPEN_SOURCE_EXTENDED.
The existing __*_VISIBLE internal macros have been kept mostly
compatible with the original BSD implementation, with some changes to
the criteria which controls them. Several more macros in this style
have been added where needed for concision or accuracy.
Enabling C++11 or newer in the compiler also enables C99 and C11
functions. Doing so should help move away from the need to define
_GNU_SOURCE in g++ for _GLIBCXX_USE_C99 support as on Linux:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749
Signed-off-by: Yaakov Selkowitz <yselkowi@redhat.com>
header includes. Include <sys/features.h> for
__GNUC_PREREQ__().
(__u?int.*_t): Define via GCC provided __U?INT.*_TYPE__ if
available.
(__intptr_t): Define.
(__uintptr_t): Likewise.
* libc/include/stdint.h: Include <machine/_default_types.h>
instead of <_ansi.h>.
(u?int.*_t): Define via __u?int.*_t provided by
<machine/_default_types.h>.
(u?int_fast.*_t): Define via GCC provided
__U?INT_FAST.*_TYPE__ if available.
(U?INT.*(MIN|MAX)): Define via GCC provided __U?INT.*(MIN|MAX)__
if available.
(U?INT.*_C): Define via GCC provided __U?INT.*_C if available.
* libc/include/sys/cdefs.h: Use <machine/_default_types.h>
instead of <stdint.h>.
* libc/sys/rtems/sys/cpuset.h: Likewise.
* libc/sys/rtems/machine/_types.h: Include <stdint.h> for
FreeBSD compatibility.
(__CONCAT): Define.
(__STRING): Define.
(__XSTRING): Define.
(__ASMNAME): Define.
* libc/include/string.h (strerror_r): Use __ASMNAME to take target
specific label prefixes into account.
libc/search/objectlist.awk.in.
* libc/Makefile.am (SUBDIRS): Add search.
(SUBLIBS): Add search/libsearch.la.
* libc/configure.in (AC_OUTPUT): Add search/Makefile.
* libc/search: New directory.
* libc/search/Makefile.am: New file.
* libc/search/extern.h: New file.
* libc/search/hash.c: New file.
* libc/search/hash.h: New file.
* libc/search/hash_bigkey.c: New file.
* libc/search/hash_buf.c: New file.
* libc/search/hash_func.c: New file.
* libc/search/hash_log2.c: New file.
* libc/search/hash_page.c: New file.
* libc/search/hcreate.3: New file.
* libc/search/hcreate.c: New file.
* libc/search/hcreate.c~: New file.
* libc/search/hcreate_r.c: New file.
* libc/search/ndbm.c: New file.
* libc/search/page.h: New file.
* libc/search/tdelete.c: New file.
* libc/search/tdestroy.c: New file.
* libc/search/tfind.c: New file.
* libc/search/tsearch.3: New file.
* libc/search/tsearch.c: New file.
* libc/search/twalk.c: New file.
* libc/include/db.h: New file.
* libc/include/ndbm.h: New file.
* libc/include/search.h: New file.
* libc/include/sys/queue.h: New file.
* libc/include/sys/cdefs.h: New file.
* libc/include/sys/param.h
[__IEEE_LITTLE_ENDIAN,__IEEE_BIG_ENDIAN]: Set BYTE_ORDER to
LITTLE_ENDIAN or BIG_ENDIAN.
* libc/include/sys/errno.h (EFTYPE): New macro.
* libc/search/bsearch.c: Move from libc/stdlib.
* libc/search/qsort.c: Likewise.
* libc/stdlib/Makefile.am (LIB_SOURCES): Remove bsearch.c and
qsort.c.
(CHEWOUT_FILES): Remove bsearch.def and qsort.def.
* libc/stdlib/stdlib.tex: Remove references to bsearch and qsort.
Corinna Vinschen
Sebastian Huber
John Baldwin
Warner Losh
Mark Johnston
Alex Richardson
jah
rlibby
dab
pfg
kib
ed@FreeBSD.org
Yaakov Selkowitz
Eric Blake
avg
asomers
dim
Jeff Johnston
Jon TURNEY
Joel Sherrill
Thomas Fitzsimmons