Re: [WIP v3] Introduce mescc.a for division algorithm and move the latter there.

[Jan Nieuwenhuizen]

Danny Milosavljevic writes:

Hello Danny!

> with WIP v3 I get on armhf:
>
> (1) gcc-lib
>
> Failed tests:
>
>>lib/tests/scaffold/7l-struct-any-size-array-simple.c
>>lib/tests/scaffold/7r-sign-extend.c

Hmm...interesting?

> (2) mescc-lib
>
> # XFAIL:
>
>>lib/tests/scaffold/17-compare-unsigned-short-le.c: XFAIL
>> lib/tests/scaffold/17-compare-unsigned-short-le.c (exit status: 1)
>>lib/tests/scaffold/72-typedef-struct-def-local.c: XFAIL
>> lib/tests/scaffold/72-typedef-struct-def-local.c (exit status: 1)
>>lib/tests/scaffold/17-compare-unsigned-char-le.c: XFAIL
>> lib/tests/scaffold/17-compare-unsigned-char-le.c (exit status: 1)
>>lib/tests/scaffold/66-local-char-array.c: XFAIL 
>>lib/tests/scaffold/66-local-char-array.c (exit status: 1)

(yes, could be "OK")

> # Real ones:
>
>>lib/tests/scaffold/63-struct-cell.c: Timeout
>
> [...]
> t: (functionx) () == foo
> t: foo
> t: foo
> t: foo
> t: foo
> t: foo
> [...]

...so this puzzle remains, right?  Yeah, some assembly things really
require digging into as I'm sure you're all to familiar with.

>>lib/tests/scaffold/7u-struct-func.c: FAIL lib/tests/scaffold/7u-struct-func.c 
>>(exit status: 1)
>
> exit status 1 probably means that f.func (2) != 1;

Yes, probably :-)  Looks somewhat similar to 63-struct-cell; function
pointers in structs; could be related.  This one looks simpler, it's
unfortunate that 63-struct-cell comes first.

I guess many of these tests were written from actual cases that failed;
6x-* being Mes code, 7x- happened to be tcc code.  It would be nice to
move towards more functional tests, instead...oh well...

>>lib/tests/scaffold/44-switch.c: FAIL lib/tests/scaffold/44-switch.c (exit 
>>status: 11)
>
> t: switch 0
> TCHAR
> 0
> t: switch 1
> 1
> 5..1, -1
> t: switch -1
> default
> default
> $ echo $?
> 11

Oh...what a difficult test.

>>lib/tests/stdlib/80-qsort-dupes.c: test-c.sh line 71:  6121 Segmentation fault
>
> ls:
> Segmentation fault (core dumped)

qsort...that doesn't surprise me.  There's a silly switch in
lib/stdlib/qsort.c:

#if 1                           //__x86_64__

...

>>lib/tests/stdlib/80-qsort.c: test-c.sh line 71:  5920 Segmentation fault

[..]

>>lib/tests/setjmp/80-setjmp.c: test-c.sh line 71:  5490 Segmentation fault
>
> second
> Segmentation fault (core dumped)
>
> And that's *after* I implemented setjmp :P

Oh!  Hehe.

> I guess that one doesn't work yet...
>
> Also, on i686-linux with patch applied:
>
> $ guix build  -K -s i686-linux -f guix.scm 
> /gnu/store/3ry6gxn6s5nzjnbs7vlf2q2zvz9zx5ql-mes.git-0.22-0.834e97d

Beautiful!

> I'd say the patch WIP v3 "Introduce mescc.a for division algorithm and
> move the latter there" makes things a lot better and we can use it for
> real.

Yes, great work!

> Note that I didn't test the Hurd (and it probably won't work because
> we don't implement a __raise function for it).

Yes, I'd be happy to look into that later.  As long as it lives on a
wip-* branch (feel free to push to plain "wip" too!) we can always
decide to squash/amend/rewrite that commit witt Hurd support -- or
fix it in a separate commit.

Great work, thank you!!!

Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com