https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71334
--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> --- For reference, I get this output on x86_64-pc-linux-gnu: underlying size_t: gcc long unsigned int, gccjit unknown underlying uint32_t: gcc unsigned int, gccjit unsigned int underlying uint64_t: gcc long unsigned int, gccjit long long unsigned int What's happening is that: (a) gcc_jit_context_get_type returns pointer values to a type internal to libgccjit (gcc::jit::recording::memento_of_get_type within jit/jit-recording.[ch]). The pointer you get back will be the same within a given gcc_jit_context for a given value of enum gcc_jit_types. (b) gcc_jit_context_get_int_type looks up the appropriate value for enum gcc_jit_types and effectively calls gcc_jit_context_get_type on it, so you get one of the pointer values above. (c) GCC_JIT_TYPE_SIZE_T is its own value within enum gcc_jit_types, hence you get a different pointer back. (d) When the context is compiled, these instances get turned into gcc's "tree" representation (see jit/jit-playback.c:get_tree_node_for_type), and at this point, it will be using the same "tree" pointer internally if it's the same type. This is all opaque from the POV of the libgccjit client code. Hopefully this clarifies things. Is any of this a problem from the point of view of you using the library? I know we do some type-checking at the API boundary using pointer comparisons of gcc_jit_type * (in recording::type::accepts_writes_from, called from libgccjit.c:compatible_types). Hope this is helpful
