On 26/01/2024 10:39, Tobias Burnus wrote:
Hi all,
Andrew Stubbs wrote:
On 26/01/2024 07:29, Richard Biener wrote:
If you link against prebuilt objects with COV 5 it seems there's no
way to
override the COV version GCC uses? That is, do we want to add
a -mcode-object-version=... option to allow the user to override this
(and ABI_VERSION_SPEC honoring that, if specified and of course
mkoffload following suit)?
For completeness, I added such a feature, see attachment. (Actually,
'=0' could be permitted for mkoffload without "-g" debugging enabled.)
However, the real problem is that one usually also has libraries build
with the default such as libc, libm, libgomp, ... Thus, specifying
anything else but GCC's default is likely to break.
Hence and also because of the following, I think it doesn't make sense
to add:
We don't have a stable ABI, so trying to link against foreign binaries
is already a problem. Most recently, the SIMD clone implementation
required a change to the procedure calling ABI, the reverse-offload
changes reimplemented the stack setup, and the low-latency memory
patches changed the way we use local memories and needed more info
passed into the device runtime. I expect more of this in future.
PS: The original patch has been committed as r14-8449-g4b5650acb31072.
Tobias
Agreed, there's no point in having a knob that only has one valid
setting, especially when we want to be able to change that setting
without breaking third-party scripts that choose to that knob "for
completeness", or something.
The toolchain can have an opinion about which is the correct COV, and I
think not relying on the LLVM default choice makes sense also. I think
COV 5 is only a small update, but there's no reason to imagine that COV6
will Just Work (COV2 to COV3, and COV3 to COV4 required real effort).
We can move on to COV5 for GCC 15, probably. I'm not aware of any great
blocker, but it sets a minimum LLVM.
Andrew
