This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix D compilation on Solaris


On Wed, 31 Oct 2018 at 10:40, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>
> 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.
>

The phobos part is largely free of version (CPU), the druntime
bindings are in a little better shape, despite there being a lot of
places dotted around the place that need to be checked.

>   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.
>

You mean a tool such as htod (header to D)?  I don't think that has
ever gained traction in upstream.

The existing C bindings for sure are brittle, and never take into
account changes between versions (FreeBSD comes to mind), but for new
ports, it at least tries to be consistent in that unhandled places
always end with a 'static assert (false)' compiler error.  If I was
just to defend the current status quo a little.

> * 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.
>

In practice however, the 'real' type maps to C 'long double', so you
can safely use real[16] here.

-- 
Iain


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]