Indeed, libgomp fails to build:
configure: error: unsupported system, cannot find Fortran int kind=16,
needed for omp_depend_kind
I've reverted the patch for now. We'll just have to put up with a lot of
new test failures in the stand-alone toolchain so that the offload
toolchain will at least build.
I suspect we'll see some real failures here soon though.
Andrew
On 07/05/2021 23:45, Andrew Stubbs wrote:
On 07/05/2021 18:11, Tobias Burnus wrote:
On 07.05.21 18:35, Andrew Stubbs wrote:
TImode has always been a problem on amdgcn, and now it is causing many
new test failures, so I'm disabling it.
Does still still work with libgomp?
The patch sounds as if it might cause problems, but on the other hand,
I assume you did test it? To recall:
>
The problem is that OpenMP's depobj as implemented in GCC has
sizeof() = 2*sizeof(void*) and is implemented as a two-element struct
in C/C++.
But the OpenMP spec mandates that it is an integer type in Fortran, i.e.
integer(kind=omp_depend_kind).
I was focussing on getting the raw amdgcn toolchain toolchain to work
again. I had forgotten about that little detail with Fortran. :-(
Is there another way we can fix this without implementing all of TImode
support or tracking down every place in the middle-end that wants to use
TImode without checking the optab?
Combining the impl choice and the type requirements that means that
on 64bit systems, this requires __int128 support, cf. commit
https://gcc.gnu.org/g:8d0b2b33748014ee57973c1d7bc9fd7706bb3da9
and https://gcc.gnu.org/PR96306
(Side note: The definition in OpenMP is bad - it should have been
some opaque derived type but that's a mistake done in OpenMP 5.0.)
:-(
Andrew
