Lines Matching +full:gcc +full:- +full:48
26 #include <pcap/pcap-inttypes.h>
27 #include <pcap/compiler-tests.h>
31 * If we have versions of GCC or Clang that support an __attribute__
34 * label these functions with that attribute - we *know* it's undefined
38 * For GCC 4.9.0 and later, we use __attribute__((no_sanitize_undefined));
39 * pre-5.0 GCC doesn't have __has_attribute, and I'm not sure whether
40 * GCC or Clang first had __attribute__((no_sanitize(XXX)).
68 * XXX - are those all the x86 tests we need?
69 * XXX - are those the only 68k tests we need not to generated
71 * XXX - are there any tests we don't need, because some definitions are for
72 * compilers that also predefine the GCC symbols?
73 * XXX - do we need to test for both 32-bit and 64-bit versions of those
121 * loads, and this is GCC 2.0 or later or a compiler that claims to
122 * be GCC 2.0 or later, which we assume that mean we have
128 * the GCC manual doesn't appear to explicitly say that
129 * __attribute__((packed)) causes the compiler to generate unaligned-safe
136 * case on a little-endian platform, such as DEC's MIPS machines and
141 * at least some versions of GCC, when compiling for 64-bit SPARC,
144 * XXX - add other architectures and compilers as possible and
155 * to define unaligned_uint16_t as a 16-bit unaligned data type.
158 * useful only if that compiler could generate better code for PA-RISC
159 * or Itanium than would be generated by a bunch of shifts-and-ORs.
166 * XXX - what if the native C compiler doesn't support
189 return ((uint16_t)ntohs(((const unaligned_uint16_t *)(p))->val)); in EXTRACT_BE_U_2()
195 return ((int16_t)ntohs(((const unaligned_int16_t *)(p))->val)); in EXTRACT_BE_S_2()
201 return ((uint32_t)ntohl(((const unaligned_uint32_t *)(p))->val)); in EXTRACT_BE_U_4()
207 return ((int32_t)ntohl(((const unaligned_int32_t *)(p))->val)); in EXTRACT_BE_S_4()
213 return ((uint64_t)(((uint64_t)ntohl(((const unaligned_uint32_t *)(p) + 0)->val)) << 32 | in EXTRACT_BE_U_8()
214 ((uint64_t)ntohl(((const unaligned_uint32_t *)(p) + 1)->val)) << 0)); in EXTRACT_BE_U_8()
220 return ((int64_t)(((uint64_t)ntohl(((const unaligned_uint32_t *)(p) + 0)->val)) << 32 | in EXTRACT_BE_S_8()
221 ((uint64_t)ntohl(((const unaligned_uint32_t *)(p) + 1)->val)) << 0)); in EXTRACT_BE_S_8()
226 * this isn't a GCC-compatible compiler, we don't have __attribute__,
228 * set to do unaligned loads, so do unaligned loads of big-endian
229 * quantities the hard way - fetch the bytes one at a time and
232 * XXX - ARM is a special case. ARMv1 through ARMv5 didn't suppory
260 ((uint64_t)(*((const uint8_t *)(p) + 1)) << 48) | \
269 ((uint64_t)(*((const uint8_t *)(p) + 1)) << 48) | \
289 * Non-power-of-2 sizes.
352 ((uint64_t)(((uint64_t)(*((const uint8_t *)(p) + 0)) << 48) | \
362 ((int64_t)(((uint64_t)(*((const uint8_t *)(p) + 0)) << 48) | \
370 ((uint64_t)(*((const uint8_t *)(p) + 0)) << 48) | \
379 * Macros to extract possibly-unaligned little-endian integral values.
380 * XXX - do loads on little-endian machines that support unaligned loads?
408 ((uint64_t)(*((const uint8_t *)(p) + 6)) << 48) | \
417 ((uint64_t)(*((const uint8_t *)(p) + 6)) << 48) | \