https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97254
Bug ID: 97254 Summary: [nvptx] Define PCC_BITFIELD_TYPE_MATTERS Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- While debugging gcc/testsuite/gcc.dg/pr94600-1.c, I found that nvptx doesn't define PCC_BITFIELD_TYPE_MATTERS. AFAIU, the theory for offloading is that settings that influence abi should be compatible with the host. And in i386.h, we find: ... /* If bit field type is int, don't let it cross an int, and give entire struct the alignment of an int. */ /* Required on the 386 since it doesn't have bit-field insns. */ #define PCC_BITFIELD_TYPE_MATTERS 1 ... OTOH, the value may be different for other hosts. On the llvm side, we find this comment in llvm.git/clang/lib/Basic/Targets/ARM.cpp: ... // Do not respect the alignment of bit-field types when laying out // structures. This corresponds to PCC_BITFIELD_TYPE_MATTERS in gcc. UseBitFieldTypeAlignment = false; ... and in llvm.git/clang/lib/Basic/Targets/NVPTX.cpp: ... UseBitFieldTypeAlignment = HostTarget->useBitFieldTypeAlignment(); ... which seems to confirm that approach. It should be possible to get the host target by looking at the --enable-as-accelerator, and figure out the value from there. OTOH, it's possible that for GCC the nvptx implementation of the hook is moot, given that part of the processing is done in the host compiler. That does not answer the question what to do for the standalone target though. But probably, given that the value is set for both known offloading hosts x86_64 and ppc, it might be a good idea to have the standalone target do the same.