On Thu, Dec 07, 2023 at 11:30:16AM +0100, Iain Buclaw wrote: > Hi, > > Thanks for this. > > Excerpts from Yang Yujie's message of Dezember 1, 2023 11:08 am: > > diff --git a/gcc/d/dmd/cond.d b/gcc/d/dmd/cond.d > > index 568b639e0b6..02af0cc9e29 100644 > > --- a/gcc/d/dmd/cond.d > > +++ b/gcc/d/dmd/cond.d > > @@ -693,10 +693,10 @@ extern (C++) final class VersionCondition : > > DVCondition > > case "LDC": > > case "linux": > > case "LittleEndian": > > - case "LoongArch32": > > case "LoongArch64": > > - case "LoongArch_HardFloat": > > - case "LoongArch_SoftFloat": > > + case "LoongArch_F64": > > + case "LoongArch_F32": > > + case "LoongArch_SF": > > case "MinGW": > > case "MIPS32": > > case "MIPS64": > > Changes to this module should be submitted to github.com/dlang/dmd, > otherwise it'll get overwritten on the next "merge" with upstream. > > What's the rationale for F64 and SF abbreviations? > > Otherwise, looks reasonable. > > Iain.
Hi Iain, Thanks for the review! I will push this to the dmd repo first shortly and then send a v4 here. By definition, LoongArch at the current stage can choose to implement either a 64-bit / 32-bit or no FPU at all, which are represented with target triplets loongarch*-*{f64,f32.sf}. The F64/F32/SF-suffixed version strings represents this distinction, though the support of the "F32" ISA variant is not active upstream. >From what I can see, the current usage of "F64/SF" is only needed for FP context code. I will also push the corresponding change to druntime later. Also If you have the time, does the following patch look OK to you? I couldn't get libphobos to build as a static library and this is the fix I came up with. https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636767.html Thanks, Yujie