On 30/01/2020 09:20, Jakub Jelinek wrote:
On Fri, Jan 24, 2020 at 03:59:28PM +0100, Tobias Burnus wrote:
As reported in PR93409, the build of libgomp/plugin/plugin-gcn.c fails with
a bunch of error messages when building with
--with-multilib-list=m32,m64,mx32
The reason is that the GCN plugin assumes 64bit pointers. As with HSA, the
build is only enabled for x86-64 and "-m32" is excluded. — However, it seems
as if it makes sense to exclude also "-mx32".
This patch was tested with -m32/-m64 multilib as I do not have a -mx32
setup.
I don't have any working -mx32 setup around nor any supported GCN offloading
hw around, so can't test anything, thus just a general comment.
In the way LLVM implements offloading, two (or more) separate compilations
starting with preprocessing etc., it is essential to have exactly the same
structure layout in both at least for things, through which the host and
offloading code are interfacing, so one needs say support for offloading
target XYZ do structure layout of ABC host ABI.
The way we implement it in GCC is different, for the structure layout
we perform them pre-IPA in the host compilation, and for offloading
therefore it only matters that the host and offloading target agree on
basics (fundamental types having the same size), the exact structure layout
details shouldn't matter that much. I don't see the gcn target having
ADJUST_FIELD_ALIGN and all the quirks of the ia32 ABI e.g. with alignment of
long long or double in the structures anyway, yet it seems to be supported
for -m32 (ia32) code, right? So, I don't see a fundamental reason why
-mx32, which is an ilp32 target like -m32, shouldn't be supported.
-m32 is not supported. Not in the business sense, anyway. It's never
been tested, no effort has been made to make it work, and "long int" is
always 64-bit (as are pointers).
By "that much", I mean that while the host vs. offloading target interfaces
should be ok due to structure layout done in the host compiler and then
streamed to the offloading compiler, there is the problem when the
offloaded code interfaces using structures with code natively compiled for
the offloading target (newlib), so say calling stat or similar functions
wouldn't work well. I'm afraid it won't work well in either offloading
model though, in the GCC way struct stat in the offloaded code will be
simply the host struct stat with field from there and corresponding
structure layout, while in native offloading code probably both different
fields and different structure layout, while in the LLVM model I'd assume
the offloading code will use the offloading target struct stat, most likely
with structure layout from the host.
Stat is not implemented, nor is any other OS call apart from "write",
and that's only valid for stdout and stderr (aliased to stdout). It's
not that semi-hosting could not be implemented; it just hasn't been and
there's no real use case for it (besides making the testsuite happier).
If it were to be implemented, however, then indeed x86_64 would be
significantly simpler than ia32, in many cases.
But looking at the patch, we already disable the plugin for ia32 (-m32), so
I'm fine with your patch. If it is ever enabled for ia32, it should be
enabled for -mx32 too.
Thus ok for trunk.
Jakub
