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.
