| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 247498
|
| |
|
|
|
|
|
|
|
|
| |
char-based types from "char" to "signed char". Adjust stdint.h to use
__INTx_TYPE__ directly without prefixing it with signed and to use
__UINTx_TYPE__ for unsigned ones.
The value of __INTx_TYPE__ now matches GCC.
llvm-svn: 214119
|
| |
|
|
|
|
|
| |
This was broken because __has_include_next(...) would not be valid in a
preprocessor condition if __has_include_next is not defined.
llvm-svn: 201731
|
| |
|
|
| |
llvm-svn: 179427
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementation of C99's attempt to control the C++ standard. *sigh*
The C99 standard says that certain macros in <stdint.h>, such as SIZE_MAX,
should not be defined when the header is included in C++ mode, unless
__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS are defined. The C++11 standard
says "Thanks, but no thanks" and C11 removed this rule, but various C library
implementations (such as glibc) follow C99 anyway.
g++ prior to 4.8 worked around the C99 / glibc behavior by defining
__STDC_*_MACROS in <cstdint>, which was incorrect, because <stdint.h> is
supposed to provide these macros too. g++ 4.8 works around it by defining
__STDC_*_MACROS in its builtin <stdint.h> header.
This change makes Clang act like g++ 4.8 in this regard: our <stdint.h> now
countermands any attempt by the C library to implement the undesired C99 rules,
by defining the __STDC_*_MACROS first. Unlike g++, we do this even in C++98
mode, since that was the intent of the C++ committee, matches the behavior
required in C11, and matches our built-in implementation of <stdint.h>.
llvm-svn: 179419
|
| |
|
|
|
|
| |
particular, make sure to handle WCHAR_MIN correctly.
llvm-svn: 130618
|
| |
|
|
| |
llvm-svn: 129907
|
| |
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129559
|
| |
|
|
|
|
| |
instead of intN_t.
llvm-svn: 107254
|
| |
|
|
|
|
|
|
| |
defines, for increased compatibility with Darwin gcc.
- This is a bit of a hack, since platform compatibility issues don't belong
here, but I don't think this hurts anyone either.
llvm-svn: 102264
|
| |
|
|
| |
llvm-svn: 89598
|
| |
|
|
|
|
| |
UINT<n>_C(v) macros.
llvm-svn: 89461
|
| |
|
|
|
|
| |
and UINT<n>_MAX defintions.
llvm-svn: 89460
|
| |
|
|
|
|
| |
uint<n>_t definitions.
llvm-svn: 89459
|
| |
|
|
|
|
| |
other limit macros.
llvm-svn: 89355
|
| |
|
|
|
|
| |
widths. This corrects the values of these definitions for MSP430 and PIC16.
llvm-svn: 89350
|
| |
|
|
|
|
| |
arbitrary widths.
llvm-svn: 89347
|
| |
|
|
| |
llvm-svn: 89343
|
| |
|
|
|
|
| |
macros corresponding to __INTPTR_WIDTH__.
llvm-svn: 89239
|
| |
|
|
| |
llvm-svn: 89237
|
| |
|
|
|
|
| |
INTn_C and UINTn_C macros.
llvm-svn: 89226
|
| |
|
|
|
|
| |
their corresponding exact-width type.
llvm-svn: 89224
|
| |
|
|
|
|
| |
__INTMAX_WIDTH__.
llvm-svn: 89221
|
| |
|
|
|
|
|
| |
INT8_C, with (-INT8_C(127)-1) in the definition of INT8_MIN. Apply similar
changes to the definitions of INT16_MIN and INT24_MIN.
llvm-svn: 89120
|
| |
|
|
|
|
|
| |
suffixes. This corrects the suffixes for the limit constants of the 32-bit
types on MSP430 and PIC16, and the 64-bit types on PPC64, SystemZ, X86_64.
llvm-svn: 89101
|
| |
|
|
|
|
|
| |
requires that their arguments be decimal, hex, octal constants---no signs
allowed---making the parens unnecessary.
llvm-svn: 89095
|
| |
|
|
|
|
|
| |
__INTn_C_SUFFIX__ macros that are defined for types with corresponding
constant suffixes (i.e. long and long long).
llvm-svn: 88914
|
| |
|
|
|
|
|
|
|
|
| |
Ken Dyck!
"This adds definitions for types of 8-bit multiples
from 8 to 64 to stdint.h and rationalizes the selection of types
for the exact-width definitions in InitPreprocessor.cpp."
llvm-svn: 86977
|
| |
|
|
|
|
| |
introduces no new function changes. Patch by Ken Dyck!
llvm-svn: 86062
|
| |
|
|
| |
llvm-svn: 85834
|
| |
|
|
|
|
|
|
| |
stdint.h unless we are freestanding.
Any suggestions here are welcome.
llvm-svn: 70806
|
| |
|
|
|
|
|
|
| |
int8_t and games it with strange *_defined macros. Emulate its weirdness
for better compatibility with linux etc. Problem pointed out by anders
johnson.
llvm-svn: 69458
|
| |
|
|
| |
llvm-svn: 67018
|
| |
|
|
| |
llvm-svn: 65704
|
| |
|
|
|
|
| |
definition of __intptr_t_defined when stdint.h defines intptr_t.
llvm-svn: 64497
|
| |
|
|
|
|
|
|
|
|
| |
a target.
Make Preprocessor.cpp define a new __INTPTR_TYPE__ macro based on this.
On linux/32, set intptr_t to int, instead of long. This fixes PR3563.
llvm-svn: 64495
|
| |
|
|
| |
llvm-svn: 64206
|
| |
|
|
|
|
| |
for pointing this out!
llvm-svn: 64037
|
| |
|
|
|
|
| |
for pointing this out.
llvm-svn: 64011
|
| |
|
|
|
|
| |
Obviously I make a miserable header developer :)
llvm-svn: 64009
|
| |
|
|
|
|
|
| |
uintmax_t is unsigned long long, which is not optimal, but is assumed
elsewhere already.
llvm-svn: 64007
|
| |
|
|
|
|
| |
Thanks to Eli for pointing this out.
llvm-svn: 64006
|
| |
|
|
|
|
|
|
| |
long instead of int. This is because system heaers like to redefine
typedefs and that is an error if they don't exactly match. Use long
for intptr_t on all systems where long is the right size.
llvm-svn: 63984
|
| |
|
|
| |
llvm-svn: 63982
|
|
|
llvm-svn: 63977
|