Re: Julia on musl libc systems

Re: Julia on musl libc systems

[Szabolcs Nagy]

* Alba Pompeo <albapompeo@gmail.com> [2016-01-30 23:13:48 -0200]:
> Good to know more about the historical development and different
> technical features of both libm implementations. Maybe musl and julia
> developers could set up a discussion in the near future to see how
> they can minimize duplicated efforts.
> 
> Mr. Nagy, we finally came across an issue that may need an experts
> help. Could you have a look at it?

added the musl list into cc, musl specific issues should
be discussed there

> It's one of musl dependencies (suitesparse).
> It's an off-putting issue, but I hope it's fixable. An internal compiler error.
> https://github.com/tkelman/julia-alpine/issues/1#issuecomment-177282137
> The .c file in question is here.
> https://github.com/jluttine/suitesparse/blob/master/CHOLMOD/Modify/t_cholmod_updown_numkr.c
> 

if an unstable version of the clang preprocessor crashes
with ice, it is probably not libc related.

but others who use clang with musl might know about this
(i'd try to reduce the example and report the error
against clang)

> On Sat, Jan 30, 2016 at 11:07 PM, Szabolcs Nagy <nsz@port70.net> wrote:
> > * Alba Pompeo <albapompeo@gmail.com> [2016-01-30 20:08:55 -0200]:
> >> I've been looking more deeply into Julia's dependencies and found this.
> >> https://github.com/JuliaLang/openlibm
> >> Isn't the purpose of openlibm exactly that of musl's libm?
> >
> > i think openlibm got forked off from freebsd libm
> > around the same time as musl libm did.
> >
> > the goals are slightly different i think
> >
> > musl libm cleaned up more historical c programming
> > issues and is tuned for libc use.
> >
> > openlibm probably has more performance/precision
> > tunings and it is for portable behaviour across
> > different platforms.
> >
> >> This seems like a huge duplicated effort in my view.
> >> Couldn't Julia devs simply use musl's libm and be done with it or am I
> >> missing something here?
> >
> > they would have to cut math out of the musl
> > source tree and make some os specific changes
> > (default fenv setup on i386 etc.)
> >
> > it would be nice to work together, most of the
> > code can be shared, but some of the surrounding
> > build system probably not.

Re: Re: Julia on musl libc systems

[Szabolcs Nagy]

* Szabolcs Nagy <nsz@port70.net> [2016-01-31 17:49:56 +0100]:
> * Alba Pompeo <albapompeo@gmail.com> [2016-01-30 23:13:48 -0200]:
> > It's one of musl dependencies (suitesparse).
> > It's an off-putting issue, but I hope it's fixable. An internal compiler error.
> > https://github.com/tkelman/julia-alpine/issues/1#issuecomment-177282137
> > The .c file in question is here.
> > https://github.com/jluttine/suitesparse/blob/master/CHOLMOD/Modify/t_cholmod_updown_numkr.c
> > 
> 
> if an unstable version of the clang preprocessor crashes
> with ice, it is probably not libc related.
> 

sorry, i misunderstood the discussion

i see it is the alpine gcc that crashed on SuiteSparse
and i can reproduce it

Re: Re: Julia on musl libc systems

[Rich Felker]

On Sun, Jan 31, 2016 at 07:00:34PM +0100, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@port70.net> [2016-01-31 17:49:56 +0100]:
> > * Alba Pompeo <albapompeo@gmail.com> [2016-01-30 23:13:48 -0200]:
> > > It's one of musl dependencies (suitesparse).
> > > It's an off-putting issue, but I hope it's fixable. An internal compiler error.
> > > https://github.com/tkelman/julia-alpine/issues/1#issuecomment-177282137
> > > The .c file in question is here.
> > > https://github.com/jluttine/suitesparse/blob/master/CHOLMOD/Modify/t_cholmod_updown_numkr.c
> > > 
> > 
> > if an unstable version of the clang preprocessor crashes
> > with ice, it is probably not libc related.
> > 
> 
> sorry, i misunderstood the discussion
> 
> i see it is the alpine gcc that crashed on SuiteSparse
> and i can reproduce it

Are they perhaps using C++ and precompiled headers? The latter are
silently broken if gcc is built as pie (Alpine builds everything as
pie) and will crash the compiler. If this is the issue, the right fix
is to patch gcc to ignore precompiled headers and always use the
original source ones, but upstream gcc trunk (gcc6) has a (somewhat
buggy) patch to force-disable pie in its build.

Rich

Re: Re: Julia on musl libc systems

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2016-01-31 13:45:50 -0500]:
> On Sun, Jan 31, 2016 at 07:00:34PM +0100, Szabolcs Nagy wrote:
> > * Szabolcs Nagy <nsz@port70.net> [2016-01-31 17:49:56 +0100]:
> > > * Alba Pompeo <albapompeo@gmail.com> [2016-01-30 23:13:48 -0200]:
> > > > It's one of musl dependencies (suitesparse).
> > > > It's an off-putting issue, but I hope it's fixable. An internal compiler error.
> > > > https://github.com/tkelman/julia-alpine/issues/1#issuecomment-177282137
> > > > The .c file in question is here.
> > > > https://github.com/jluttine/suitesparse/blob/master/CHOLMOD/Modify/t_cholmod_updown_numkr.c
> > > > 
> > > 
> > > if an unstable version of the clang preprocessor crashes
> > > with ice, it is probably not libc related.
> > > 
> > 
> > sorry, i misunderstood the discussion
> > 
> > i see it is the alpine gcc that crashed on SuiteSparse
> > and i can reproduce it
> 
> Are they perhaps using C++ and precompiled headers? The latter are

no, a reduced test case is attached

gcc -O3 bug.c

fails, but

gcc -O3 -fno-tree-slp-vectorize bug.c

passes, so CFLAGS+=-fno-tree-slp-vectorize is a
workaround.

probably related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68517
(although i dont see 0 sized structs here),
but i could not reproduce it with another toolchain,
only with the alpine x86_64 gcc-5.3.0 one.

Re: Re: Julia on musl libc systems

[Szabolcs Nagy]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

* Szabolcs Nagy <nsz@port70.net> [2016-01-31 21:40:50 +0100]:
> * Rich Felker <dalias@libc.org> [2016-01-31 13:45:50 -0500]:
> > Are they perhaps using C++ and precompiled headers? The latter are
> 
> no, a reduced test case is attached

now really

> gcc -O3 bug.c
> 
> fails, but
> 
> gcc -O3 -fno-tree-slp-vectorize bug.c
> 
> passes, so CFLAGS+=-fno-tree-slp-vectorize is a
> workaround.
> 
> probably related to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68517
> (although i dont see 0 sized structs here),
> but i could not reproduce it with another toolchain,
> only with the alpine x86_64 gcc-5.3.0 one.

[-- Attachment #2: bug.c --]
[-- Type: text/x-csrc, Size: 2804 bytes --]

typedef unsigned long size_t;
typedef struct cholmod_common_struct {
  struct cholmod_method_struct {
    int a;
  } method[9 + 1];
} cholmod_common;
typedef struct cholmod_sparse_struct {
  int a;
} cholmod_sparse;
typedef struct cholmod_descendant_score_t {
  int a;
} descendantScore;
typedef struct cholmod_factor_struct {
  int a;
} cholmod_factor;
typedef struct cholmod_dense_struct {
  int a;
} cholmod_dense;
typedef struct Path_struct { int rank; } Path_type;
static void updown_8_4(int update, int j, int e, double Alpha[], double W[],
                       cholmod_factor *L, cholmod_common *Common) {
  double G0[4], G1[4], G2[4], G3[4];
  double Z0[4], Z1[4], Z2[4], Z3[4];
  double *W0, *W1, *W2, *W3, *Lx;
  int *Li, *Lp, *Lnz;
  int j1, j2, j3, p0, p1, p2, p3, parent, lnz, pend, k;
  for (; j <= e; j = parent) {
    {
      if ((j2 <= e) && (lnz == Lnz[j3] + 3)) {
        {
          double lx[2][2], w[2], *w0, *w1;
          lx[0][0] = Lx[p0];
          lx[1][0] = Lx[p0 + 1];
          lx[0][1] = Lx[p1];
          lx[1][1] = Lx[p1 + 1];
          lx[1][1] -= G1[1] * w[1];
          w[0] = w0[2] - Z0[2] * lx[0][0];
          w[1] = w1[2] - Z0[2] * lx[1][0];
          lx[0][0] -= G0[2] * w[0];
          lx[1][0] -= G0[2] * w[1];
          w0[2] = w[0] -= Z1[2] * lx[0][1];
          w1[2] = w[1] -= Z1[2] * lx[1][1];
          lx[0][1] -= G1[2] * w[0];
          Lx[p0] = lx[0][0];
          Lx[p0 + 1] = lx[1][0];
          Lx[p1] = lx[0][1];
          Lx[p1 + 1] = lx[1][1];
        }
      }
    }
  }
}
static void updown_8_r(int update, cholmod_sparse *C, int rank,
                       cholmod_factor *L, double W[], Path_type Path[],
                       int npaths, int mask[], int maskmark,
                       cholmod_common *Common) {
  double *Cx, *Wpath, *W1, *a;
  int i, j, p, ccol, pend, wfirst, e, path=0, packed;
  {
    switch (Path[path].rank) {
    case 1:
      updown_8_4(update, j, e, a, W1, L, Common);
    }
  }
}
int cholmod_updown_mask2(int update, cholmod_sparse *C, int *colmark, int *mask,
                         int maskmark, cholmod_factor *L, cholmod_dense *X,
                         cholmod_dense *DeltaB, cholmod_common *Common) {
  double *Lx, *W=0, *Xx, *Nx;
  Path_type OrderedPath[32], Path[32];
  int n, wdim, k1, k2, npaths=0, i, j, row, packed, ccol, p, cncol, do_solve, k=0,
      botrow;
  updown_8_r(update, C, k, L, W, OrderedPath, npaths, mask, maskmark,
             Common);
  return 0;
}
int cholmod_updown_mark(int update, cholmod_sparse *C, int *colmark,
                        cholmod_factor *L, cholmod_dense *X,
                        cholmod_dense *DeltaB, cholmod_common *Common) {
  return (cholmod_updown_mask2(update, C, colmark, ((void *)0), 0, L, X, DeltaB,
                               Common));
}

Re: Re: Julia on musl libc systems

[Alba Pompeo]

Has there been any development on this?
I tried again and it still fails.
$ wget http://faculty.cse.tamu.edu/davis/SuiteSparse/SuiteSparse-4.5.3.tar.gz
$ tar -xzvf SuiteSparse-4.5.3.tar.gz
$ cd SuiteSparse-4.5.3
$ make
In file included from ../Modify/cholmod_updown.c:284:0:
../Modify/t_cholmod_updown_numkr.c: In function 'updown_8_4':
../Modify/t_cholmod_updown.c:47:27: internal compiler error: in
vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
 #define FORM_NAME(k,rank) updown_ ## k ## _ ## rank
                           ^
../Modify/t_cholmod_updown.c:48:25: note: in expansion of macro 'FORM_NAME'
 #define NUMERIC(k,rank) FORM_NAME(k,rank)
                         ^
../Modify/t_cholmod_updown_numkr.c:325:13: note: in expansion of macro 'NUMERIC'
 static void NUMERIC (WDIM, RANK)
             ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Makefile:478: recipe for target 'cholmod_updown.o' failed
make[3]: *** [cholmod_updown.o] Error 1


Can you reproduce the issue?

Ciao.


On Sun, Jan 31, 2016 at 6:42 PM, Szabolcs Nagy <nsz@port70.net> wrote:
> * Szabolcs Nagy <nsz@port70.net> [2016-01-31 21:40:50 +0100]:
>> * Rich Felker <dalias@libc.org> [2016-01-31 13:45:50 -0500]:
>> > Are they perhaps using C++ and precompiled headers? The latter are
>>
>> no, a reduced test case is attached
>
> now really
>
>> gcc -O3 bug.c
>>
>> fails, but
>>
>> gcc -O3 -fno-tree-slp-vectorize bug.c
>>
>> passes, so CFLAGS+=-fno-tree-slp-vectorize is a
>> workaround.
>>
>> probably related to
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68517
>> (although i dont see 0 sized structs here),
>> but i could not reproduce it with another toolchain,
>> only with the alpine x86_64 gcc-5.3.0 one.

Re: Re: Julia on musl libc systems

[Alba Pompeo]

A friend found out that SuiteSparse compiles fine with GCC
Optimization -O2. It only fails with default -O3.
Maybe this helps debug?

Ciao.


On Sat, May 21, 2016 at 10:37 AM, Alba Pompeo <albapompeo@gmail.com> wrote:
> Has there been any development on this?
> I tried again and it still fails.
> $ wget http://faculty.cse.tamu.edu/davis/SuiteSparse/SuiteSparse-4.5.3.tar.gz
> $ tar -xzvf SuiteSparse-4.5.3.tar.gz
> $ cd SuiteSparse-4.5.3
> $ make
> In file included from ../Modify/cholmod_updown.c:284:0:
> ../Modify/t_cholmod_updown_numkr.c: In function 'updown_8_4':
> ../Modify/t_cholmod_updown.c:47:27: internal compiler error: in
> vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
>  #define FORM_NAME(k,rank) updown_ ## k ## _ ## rank
>                            ^
> ../Modify/t_cholmod_updown.c:48:25: note: in expansion of macro 'FORM_NAME'
>  #define NUMERIC(k,rank) FORM_NAME(k,rank)
>                          ^
> ../Modify/t_cholmod_updown_numkr.c:325:13: note: in expansion of macro 'NUMERIC'
>  static void NUMERIC (WDIM, RANK)
>              ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> Makefile:478: recipe for target 'cholmod_updown.o' failed
> make[3]: *** [cholmod_updown.o] Error 1
>
>
> Can you reproduce the issue?
>
> Ciao.
>
>
> On Sun, Jan 31, 2016 at 6:42 PM, Szabolcs Nagy <nsz@port70.net> wrote:
>> * Szabolcs Nagy <nsz@port70.net> [2016-01-31 21:40:50 +0100]:
>>> * Rich Felker <dalias@libc.org> [2016-01-31 13:45:50 -0500]:
>>> > Are they perhaps using C++ and precompiled headers? The latter are
>>>
>>> no, a reduced test case is attached
>>
>> now really
>>
>>> gcc -O3 bug.c
>>>
>>> fails, but
>>>
>>> gcc -O3 -fno-tree-slp-vectorize bug.c
>>>
>>> passes, so CFLAGS+=-fno-tree-slp-vectorize is a
>>> workaround.
>>>
>>> probably related to
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68517
>>> (although i dont see 0 sized structs here),
>>> but i could not reproduce it with another toolchain,
>>> only with the alpine x86_64 gcc-5.3.0 one.

Re: Re: Julia on musl libc systems

[Alexander Monakov]

Hi!

Thanks to the minimized testcase provided by Szabolcs, I've narrowed it down
to a bad qsort call in gcc: the comparator provided to qsort lacks
transitivity in some cases. One doesn't see this on a Glibc-hosted toolchain
because Alpine implicitely enables -fno-strict-overflow, and also
because with Glibc resulting sort order is different, and happens to avoid the
gcc_assert that triggers on Alpine with musl.

I've opened a GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71702

Alexander

Re: Re: Julia on musl libc systems

[Alba Pompeo]

Alexander, great work!
Let's hope GCC developers look at it soon.


On Wed, Jun 29, 2016 at 2:03 PM, Alexander Monakov <amonakov@ispras.ru> wrote:
> Hi!
>
> Thanks to the minimized testcase provided by Szabolcs, I've narrowed it down
> to a bad qsort call in gcc: the comparator provided to qsort lacks
> transitivity in some cases. One doesn't see this on a Glibc-hosted toolchain
> because Alpine implicitely enables -fno-strict-overflow, and also
> because with Glibc resulting sort order is different, and happens to avoid the
> gcc_assert that triggers on Alpine with musl.
>
> I've opened a GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71702
>
> Alexander