Add a host_build() function, so that it's possible to
check for software being build with USE_HOSTCC without
relying on preprocessor conditions. In other words

 #ifdef USE_HOSTCC
 	host_only_code();
 #endif

can be written like this instead:

 if (host_build())
 	host_only_code();

This improves code readability and test coverage and
compiler will eleminate this unreachable code.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Define this macro always so we don't need the preprocessor to check it.
Convert the users to #if instead of #ifdef.

Note that '#if MEM_SUPPORT_64BIT_DATA' does not give an error if the
macro is not define. It just assumes zero.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

This is not really a CONFIG since it is not intended to be set by boards.
Move it into the compiler header with other similar defines, and rename
it.

Signed-off-by: Simon Glass <sjg@chromium.org>

The build failure was originally reported on arm64-musl
target at https://bugs.gentoo.org/703132. Here is the amd64-musl
variant:

```
$ LANG=C make CROSS_COMPILE=x86_64-gentoo-linux-musl- tools-only_defconfig -j$(nproc)
$ LANG=C make CROSS_COMPILE=x86_64-gentoo-linux-musl- tools-all            -j$(nproc)
...
In file included from tools/env/../../env/flags.c:7,
                 from tools/env/env_flags.c:1:
include/env.h:159:1: error: unknown type name 'ulong'; did you mean 'long'?
  159 | ulong env_get_ulong(const char *name, int base, ulong default_val);
      | ^~~~~
      | long
```

Note: 'ulong' is not defined there.

On glibc 'ulong' comes from <sys/types.h>:

```c
/* Old compatibility names for C types.  */
typedef unsigned long int ulong;
```

On musl it comes from <sys/types.h> as well but from under different guards:

```c
typedef unsigned long u_long, ulong;
```

The change inlines 'ulong' define similar to 'uint' define.

Bug: https://bugs.gentoo.org/703132
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

You do not need to use the typedefs provided by compiler.

Our compilers are either IPL32 or LP64.  Hence, U-Boot can/should
always use int-ll64.h typedefs like Linux kernel, whatever the
typedefs the compiler internally uses.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

FreeBSD, like OpenBSD, uses BIG_ENDIAN, LITTLE_ENDIAN, and BYTE_ORDER,
whereas Linux and compatibles use __-prefixed names.  Define the names
the same as the OpenBSD block below it.

When building u-boot on sparc64 and powerpc hosts it became clear that
u-boot expects endian conversion defines to be macros:

lib/crc32.c:87: error: braced-group within expression allowed only inside a function

For OpenBSD switch from using system definitions equivalent to the u-boot ones
and define glibc __BYTE_ORDER __BIG_ENDIAN __LITTLE_ENDIAN names, as at least
some parts of the non-cross build assumes those names are present (ie crc32.c).

Signed-off-by: Jonathan Gray <jsg@jsg.id.au>

The u-boot endian macros map directly to system endian
macros on OpenBSD.

Signed-off-by: Jonathan Gray <jsg@jsg.id.au>

This reverts commit e8f954a756a825130d11b9c8fca70101dd8b3ac5, which
causes compiling errors on 32-bit hosts.

Acked-by: Aneesh Bansal <aneesh.bansal@freescale.com>
Signed-off-by: York Sun <yorksun@freescale.com>

uintptr_t which is a typdef for unsigned long is needed for creating
pointers (32 or 64 bit depending on Core) from 32 bit variables
storing the address.
If a 32 bit variable (u32) is typecasted to a pointer (void *),
compiler gives a warning in case size of pointer on the core is 64 bit.

The typdef has been moved from include/compiler.h to include/linux/types.h

Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>