[Bug jit/71334] gccjit's sized integers have different underlying types than stdint.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71334 --- Comment #3 from Ben Longbons --- What I'm trying to do is: * parse some source code from a new language I'm developing. * Emit that to machine code via some backend (C, GCCJIT, LLVM, firm, etc.) * Also emit a header file so that the library is callable from C code. Doing this requires knowing what the underlying type was, in order to have compatible function declarations. In future I suspect it will also be useful for C++-compatible mangling, which is also used for __attribute__((overloaded)). Functions to get the size/align of any given primitive type would also be very useful. Dealing with all the edge-cases with cross-compiling is hard, especially when the target supports multilib ... even if target-gcc exists, it might not be the same version, and in general (if the preprocessor doesn't have a way to emit that info) you can only get 1 bit of information out per fork+exec. Enumerating possible target info is already way too hard in general, e.g. I can't even find a way to get the current -m32 or -mx32 target names ... with clang at least I can inspect the output of `clang -m32 -x c - -S -emit-llvm -o - <<< ''`
[Bug jit/71334] gccjit's sized integers have different underlying types than stdint.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71334 --- Comment #2 from David Malcolm --- 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
[Bug jit/71334] gccjit's sized integers have different underlying types than stdint.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71334 --- Comment #1 from Andrew Pinski --- I don't see why this is an issue. for LP64 targets, long unsigned int and long long unsigned int are the same size. For gccjit, just uses the GCC internal definition of compatible. That is long unsigned int and long long unsigned int are compatible types. Internally GCC there is a size_t type which is distant from the underlying type but is compatible with that type. Why do you think they should be the same? Remember GCCJIT is not about C language specifications but rather a GCC internal representation.
