[OpenIndiana-discuss] The Register today

[Toomas Soome]

> On 10. May 2021, at 10:33, Volker A. Brandt <vab at bb-c.de> wrote:
> 
> Toomas Soome via openindiana-discuss writes:
>> Please note that while IPD is filed, there is not yet line drawn, at least I
>> want to get few updates integrated so whoever will decide to create fork,
>> will get those bits too. That includes support for cpio boot archive (needs
>> forth boot code to read cpio), code to recognize T4 cpu properties and
>> perhaps few other bits.
> 
> We appreciate your work, Toomas!
> 
> What I find strange is that "public" reactions (like The Register) all
> mention lack of hardware.  There is a lot of hardware available, and
> hosting has been offered as well.
> 
> IMHO it's not hardware, it's people.
> 
> I would be interested in a description of the compiler problem that
> needs to be fixed to move SPARC forward, preferably in layman's terms.
> :-)  Or is it a number of unrelated issues?
> 
> TBH I never paid much attention because I just assumed that my skillset
> isn't up to understanding the problem anyway, let alone fixing it.
> 
> We are very close to having a self-hosted OpenIndiana for SPARC, and I
> would like to investigate how to leverage that.
> 
> 

The immediate issue is https://www.illumos.org/issues/2757. In core, this issue means that negative 32-bit numbers are not translated to negative 64-bit numbers. Currently used gcc 4.4.4 does implement such translation in compiler, there is no such patch for more recent compilers (firstly, the code path in more recent compilers has changed a lot, and secondly, such translation should be done by OS). This effectively does block switch from gcc 4.4.4. I actually am running gcc 7 built system, knowingly, keeping in mind that I may be bitten by problems cause by this issue.

Secondly, there are SPARC optimizer issues in gcc 7 and gcc 9 (likely with 10 as well), crashing compiler while building specific parts of illumos tree. One example:

    libcurses: gcc 9 bug with -O2
    
    ../screen/tparm.c: In function 'tparm':
    ../screen/tparm.c:727:1: error: insn does not satisfy its constraints:
      727 | }
          | ^
    (insn:TI 66 1769 1770 (set (reg:DI 8 %o0)
            (mem/u/c:DI (plus:DI (reg:DI 13 %o5)
                    (symbol_ref:DI ("result.4619") [flags 0x2] <var_decl fa9e7de8 re
    sult>)) [0  S8 A64])) 125 {*movdi_insn_sp64}
         (expr_list:REG_EQUAL (symbol_ref:DI ("result.4619") [flags 0x2] <var_decl f
    a9e7de8 result>)
            (nil)))
    during RTL pass: final
    ../screen/tparm.c:727:1: internal compiler error: in final_scan_insn_1, at final
    .c:3013
    0x6ba95b _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
            /code/oi-userland/components/developer/gcc-9/gcc-9.3.0/gcc/rtl-error.c:1
    08
    0x6ba997 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
            /code/oi-userland/components/developer/gcc-9/gcc-9.3.0/gcc/rtl-error.c:1
    18
    0x42a623 final_scan_insn_1
            /code/oi-userland/components/developer/gcc-9/gcc-9.3.0/gcc/final.c:3013
    0x42a6bf final_scan_insn(rtx_insn*, __FILE*, int, int, int*)
            /code/oi-userland/components/developer/gcc-9/gcc-9.3.0/gcc/final.c:3153
    0x429fb7 final_scan_insn_1
            /code/oi-userland/components/developer/gcc-9/gcc-9.3.0/gcc/final.c:2759
    0x42a6bf final_scan_insn(rtx_insn*, __FILE*, int, int, int*)
            /code/oi-userland/components/developer/gcc-9/gcc-9.3.0/gcc/final.c:3153
    0x42a943 final_1
            /code/oi-userland/components/developer/gcc-9/gcc-9.3.0/gcc/final.c:2021
    0x42c3cb rest_of_handle_final
            /code/oi-userland/components/developer/gcc-9/gcc-9.3.0/gcc/final.c:4659
    0x42c3cb execute
            /code/oi-userland/components/developer/gcc-9/gcc-9.3.0/gcc/final.c:4737
    Please submit a full bug report,
    with preprocessed source if appropriate.
    Please include the complete backtrace with any bug report.


I haven’t had time to open bugreport with gcc. 

And then there are some other issues related to optimizations/hacks created to support specific network cards, and so on. A lot of work to get those issues fixed, so that we wont be blocking illumos-gate, and unfortunately, very small group of users.

As a side note, it is interesting to see SPARC related discussion in this list; there is no package repository for SPARC by OpenIndiana;)

Considering all the above, I was also one of those asking if it is really good for illumos to keep this baggage. Perhaps it is time to let go.

rgds,
toomas