Hi,
Excerpts from liushuyu's message of Februar 6, 2025 2:02 am:
From: Zixing Liu <liushuyu...@gmail.com>
This set of patches will add proper IEEE 128 quad precision marking to GDC
compiler, so that it works with the new changes in D standard library
where POWER system can use any math functions inside the standard library
that requires the "real" type.
The patch also adds the ELFv1 and ELFv2 version identifiers to bridge
the gap between LLVM D Compiler (LDC) and GNU D Compiler (GDC) so that
the user can reliably use the "version(...)" syntax to check for which
ABI is currently in use.
Thanks. I wonder if something could be done to predefine ELFv1 for other
targets too. Unconditionally calling add_builtin_version in glibc-d.cc,
freebsd-d.cc, ..., doesn't seem like the best thing to do, but I'm open
for suggestions.
As far as I understand, ELFv1 and ELFv2 concepts are limited to PowerPC
platforms due to the need for compatibility.
No other platform (supported by D) has such a need for defining ELFv1
and ELFv2 version identifiers.
+
+ if (TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128)
+ d_add_builtin_version ("D_PPCUseIEEE128");
It says in the spec that all version identifiers derived from any
predefined versions by appending any character(s) are reserved.
So there's no need for the `D_` prefix, `PPC_UseIEEE128` will suffice.
In the upstream druntime change
(https://github.com/dlang/dmd/pull/20826), I have changed the identifier
to `|PPCUseIEEE128` and instead of letting compilers setting it, I have
changed the druntime so that compiler does not need to explicitly set
this version identifier.
|
||
+
+// { dg-final { scan-assembler "test_version" } }
+extern (C) bool test_version() {
+ // { dg-final { scan-assembler "li 3,1" } }
+ version (D_PPCUseIEEE128) return true;
+ else return false;
+}
+
+// { dg-final { scan-assembler "test_elf_version" } }
+extern (C) bool test_elf_version() {
+ // { dg-final { scan-assembler "li 3,1" } }
+ version (ELFv2) return true;
+ else return false;
+}
These two tests should return a different value, otherwise you could
just end up matching the same function return twice.
I will address this comment in a newer revision of the patch.
A newer revision of the patch will be submitted after the D language
upstream merges the druntime changes.
Kind regards,
Iain.
Thanks,
Zixing
