[llvm] r259255 - Need #include <cstdint> for uint64_t

Oh I did not know about DataTypes.h. However given that there are already two other files in llvm (in the AMDGPU and Hexagon targets) that #include since 2014, maybe we can loosen the requirement for DataTypes.h nowadays as #include seems to be working everywhere?

  • Matthias

Sounds to me like including DataTypes.h would be the right choice, since it will include stdint.h if it exists - and error if it doesn’t, along with a few other things. And it guarantees that the entire compiler uses the SAME definition, rather than, potentially, using different variants of the “same” type in different places.

I’d argue the other way around, that you probably should fix the other bits that use cstdint to use DataTypes.h.

DataTypes.h is transitively included through a lot of very common includes already. So its entirely possible AMDGPU and Hexagon are really including it.

The point I was trying to make here is that all things that DataTypes.h provides:
intXXX_t, uintXX_t, PRIdXX, INT64_MAX, HUGE_VAL, ssize_t …
are all part of the C++11 standard and can be found in , (except for ssize_t) so I wondered if there is still a need for llvm to provide this header since we require a C++11 compiler anyway nowadays.

In each case I changed my file to use DataTypes.h now.

  • Matthias

The point I was trying to make here is that all things that DataTypes.h
provides:
intXXX_t, uintXX_t, PRIdXX, INT64_MAX, HUGE_VAL, ssize_t ...
are all part of the C++11 standard and can be found in <cstdint>, <cmath>
(except for ssize_t) so I wondered if there is still a need for llvm to
provide this header since we require a C++11 compiler anyway nowadays.

FWIW, I've thought about this too. cstdint and stdint.h are C++11, and I
think that MSVC claims to support them. Maybe the next time that we bump up
MSVC version it will work.

-- Sean Silva

Sean Silva via llvm-commits <llvm-commits@lists.llvm.org> writes:

no-datatypes.patch (78.7 KB)

no-datatypes-clang.patch (8.83 KB)