Hi Iain,

> My first suspect here would be 'struct UnionExp', see d/dmd/expression.h
>
> Upstream dmd use a poor man's alignment, from what I recall to be
> compatible with the dmc compiler.
>
>         // Ensure that the union is suitably aligned.
>         real_t for_alignment_only;
>
> What happens if you were to replace that with marking the type as
> __attribute__ ((aligned (8))) ?

thanks for the suggestion: this worked just fine.  After a couple more
libphobos adjustments (described below), I was able to finish the build
on both sparc-sun-solaris2.11 and i386-pc-solaris2.11.

The link tests still all fail as before, but sparc and x86 are now on
par here :-)

Here are the new issues I saw while completing the sparc build:

* math.d has two problems on 32-bit sparc:

/vol/gcc/src/hg/trunk/local/libphobos/src/std/math.d:5278:18: error: undefined 
identifier 'ControlState'
 5278 |     ControlState savedState;
      |                  ^
/vol/gcc/src/hg/trunk/local/libphobos/src/std/math.d:5325:25: error: undefined 
identifier 'ControlState'
 5325 |     static ControlState getControlState() @trusted nothrow @nogc
      |                         ^
/vol/gcc/src/hg/trunk/local/libphobos/src/std/math.d:5390:17: error: undefined 
identifier 'ControlState'
 5390 |     static void setControlState(ControlState newState) @trusted nothrow 
@nogc
      |                 ^

  Fixed by using the ControlState alias on both SPARC64 and SPARC.

/vol/gcc/src/hg/trunk/local/libphobos/src/std/math.d:5211:9: error: static 
assert  "Not implemented for this architecture"
 5211 |         static assert(false, "Not implemented for this architecture");
      |         ^

  Similarly, ExceptionMask was only defined for SPARC64.  However,
  looking closer it seems that the current definition only matches Linux
  resp. Glibc fenv.h (FE_*).  The Solaris values are different on sparc.

  This seems to be a recurring theme, unfortunately: definitions guarded
  by version ($CPU) are really CRuntime_Glibc && $CPU.  I fear libphobos
  has to be way more careful to distinguish between definitions that
  only depend on the target cpu and those that are (also) OS-dependent.

  Instead of hardcoding all this, it may be worth having a look at how
  Go handles this: they dump the definitions with gcc
  -fdump-go-spec=tmp-gen-sysinfo.go and postprocess them in
  libgo/mksysinfo.sh.  This way, such errors and potential
  inconsistencies are avoided from the start.  This would also massivly
  simplify work for potential porters.

* My previous patch had a typo, now also fixed:

/vol/gcc/src/hg/trunk/local/libphobos/libdruntime/core/sys/posix/ucontext.d:984:20:
 error: undefined identifier 'uint32_t'
  984 |       uint32_t[32] fpu_regs;
      |                    ^

While those were enough to finish the build, I noticed a couple of
additional issues:

* During make check, part (or all) of libphobos was rebuilt.  I strongly
  suspect that this happens because contrib/gcc_update doesn't handle
  libphobos yet: it needs to touch generated files to avoid exactly this
  sort of problem.  I'll post a separate patch once tested.

* Unlike the gdc.dg tests, many gdc.test tests appear as UNRESOLVED like
  this:

UNRESOLVED: runnable/A16.d   compilation failed to produce executable

  There's no preceding FAIL for the link failure itself.  Besides, the
  testname needs to include the gdc.test prefix.

* One issue I forgot last time: when defining the SPARC64 struct
  fpregset_t in libdruntime/core/sys/posix/ucontext.d, one field
  couldn't be represented: the structure contains a union

            union fpu_fr
            {
                uint[32]        fpu_regs;
                double[32]      fpu_dregs;
                /* long double[16]      fpu_qregs; */

  but there's no D type corresponding to long double: the D real type
  represents the biggest floating-point type implemented in hardware,
  and AFAIK no SPARC CPU ever implemented 128-bit floating point.
  Still, with this missing the alignment of the union is wrong.

        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Reply via email to