1.9.0-73 solve

[frederic han]

Bonjour Bernard,
dans fedora giac est compilé avec -Wp,-D_GLIBCXX_ASSERTIONS et j'ai le problème suivant pour

solve(1+2*sin(3*x)) avec 1.9.0-73

Code : Tout sélectionner

0>> solve(1+2*sin(3*x))
[New Thread 0x7fff1ffff6c0 (LWP 447313)]
/usr/include/c++/13/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = long long int; _Alloc = std::allocator<long long int>; reference = long long int&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

Thread 15 "icas" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fff1ffff6c0 (LWP 447313)]
0x00007ffff50b0884 in __pthread_kill_implementation () from /lib64/libc.so.6
...
(gdb) bt
#0  0x00007ffff50b0884 in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x00007ffff505fafe in raise () from /lib64/libc.so.6
#2  0x00007ffff504887f in abort () from /lib64/libc.so.6
#3  0x00007ffff52df1a0 in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) ()
   from /lib64/libstdc++.so.6
#4  0x00007ffff6938fa1 in std::vector<long long, std::allocator<long long> >::operator[] (this=0x7fff1fff1ff0, __n=5)
    at /usr/include/c++/13/bits/stl_vector.h:1125
#5  0x00007ffff6b5a1ab in giac::smallmodrref_upper (N=std::vector of length 4, capacity 4 = {...}, l=0, lmax=4, c=0, 
    cmax=5, modulo=536770933) at vecteur.cc:8345
#6  0x00007ffff6b9a2f7 in giac::mker (res=std::vector of length 4, capacity 4 = {...}, 
    v=std::vector of length 0, capacity 0, modulo=536770933) at vecteur.cc:15241
#7  0x00007ffff6b9ac5d in giac::mker (a=..., v=..., algorithm=1, contextptr=0x0) at vecteur.cc:15302
#8  0x00007ffff6b9b485 in giac::mker (a=..., v=..., contextptr=0x0) at vecteur.cc:15350
#9  0x00007ffff6b9b4d2 in giac::mker (a=..., contextptr=0x0) at vecteur.cc:15355
#10 0x00007ffff645d9ca in giac::minimal_polynomial (pp=..., minonly=false, contextptr=0x0) at sym2poly.cc:2290
#11 0x00007ffff645f2b4 in giac::r2sym (p=..., lt=@0x7fff1fff2860: 0x7fff1fff2c70, 
    ltend=@0x7fff1fff2a40: 0x7fff1fff2c70, contextptr=0x0) at sym2poly.cc:2387
#12 0x00007ffff6460a90 in giac::r2sym (p=..., lt=@0x7fff1fff2a38: 0x7fff1fff2c68, 
    ltend=@0x7fff1fff2a40: 0x7fff1fff2c70, contextptr=0x0) at sym2poly.cc:2512
#13 0x00007ffff6461a94 in giac::r2sym (p=..., l=..., contextptr=0x0) at sym2poly.cc:2540
#14 0x00007ffff645b261 in giac::r2sym (f=..., l=..., contextptr=0x0) at sym2poly.cc:2093
#15 0x00007ffff646a78e in giac::normal (e=..., distribute_div=true, allow_embeded_recursion=true, contextptr=0x0)
    at sym2poly.cc:3182

[parisse]

Depuis un certain temps (je ne sais plus exactement), j'ai ajouté dans configure.ac -U_GLIBCXX_ASSERTIONS dans le CXXFLAGS, justement pour contourner les tests de la libstdc++ qu'il *faut* désactiver (je n'ai pas l'intention de modifier du code qui fonctionne...). Je ne sais pas qui a la priorité entre le -U et le -D, si c'est -D il faudrait que fedora modifie son script de compilation.
Sinon, on peut toujours compiler soi-même et profiter de la version la plus à jour

[frederic han]

pourquoi ne pas changer les &buffer[cmax]-4 en

Code : Tout sélectionner

longlong * ptr= &buffer[C],*ptrend=&buffer[0]+cmax-4;

NB: je pense que les gens evoluent et que ca n'est plus vrai que les gens sont prets à compiler eux meme un logiciel de math.

[parisse]

Parce que ça prend du temps et surtout c'est dangereux de faire ce genre de modifs, il faut le faire à plusieurs endroits sans introduire d'erreurs. C'est beaucoup plus sûr de désactiver un test qui a été rajouté dans la libstc++ (et c'est aussi légèrement plus rapide). Il y a d'autres moyens de tester des erreurs de runtime de ce type qui sont aussi efficaces qu'un abort, un segfault est le plus souvent facile à tracer, et sinon il y a valgrind.
Ensuite compiler giac n'est pas compliqué, il suffit de faire ./configure ; make -j et make install, maintenant giac detécte tout seul si fltk est installé, et l'installe si nécessaire. Et puis je fournis des packages pour debian10 et debian11...

Sinon, tu as fait des modifs récentes dans qcas? Ca pourrait être intéressant de le compiler vers wasm.

[frederic han]

avec le petit patch suivant sur la 1.9.0-91 tous les tests passent ainsi que ceux de giacpy.

[parisse]

Je modifie seulement les pointeurs de fin, ceux de début n'ont pas de raison de l'être, donc avec le diff suivant:

Code : Tout sélectionner

8049c8049
< 	  longlong * bufend=&buffer[0]+cmax-8;
---
> 	  longlong * bufend=&buffer[cmax]-8;
8073c8073
< 	  longlong * bufend=&buffer[0]+cmax-8;
---
> 	  longlong * bufend=&buffer[cmax]-8;
8319c8319
< 	    longlong * ptr= &buffer[C],*ptrend=&buffer[0]+cmax-4;
---
> 	    longlong * ptr= &buffer[C],*ptrend=&buffer[cmax]-4;
8351c8351
< 	    longlong * ptr= &buffer[C],*ptrend=&buffer[0]+cmax-4;
---
> 	    longlong * ptr= &buffer[C],*ptrend=&buffer[cmax]-4;

Mais ça m'étonne que ce soit les seuls endroits où il y ait ce genre de déroulement de boucles, j'ai plutot l'impression que c'est le seul endroit où les tests les ont détectés. Et je ne vois toujours pas en quoi faire ce genre de modifs fiabilise le code par rapport au code initial. Là je viens de passer 1/2h à tout vérifier, tu as du passer au moins autant de temps à tester, alors que ça n'apporte rien.

[parisse]

Bon, je pense que je vais contourner l'ajout de -D_GLIBCXX_ASSERTIONS en ligne de commande, en ajoutant dans first.h:

Code : Tout sélectionner

#ifdef _GLIBCXX_ASSERTIONS
#undef _GLIBCXX_ASSERTIONS
#endif

[frederic han]

merci pour les modifs , modifier les pointeurs de fin suffisaient pour solve(1+2*sin(3*x))
mais pas pour: jordan(companion(x^3-2,x))

où à un moment on finit à la ligne 8353 par avoir C = cmax:

Code : Tout sélectionner

gdb) c
Continuing.
[New Thread 0x7fff1b7fe6c0 (LWP 378627)]
[New Thread 0x7fff1affd6c0 (LWP 378628)]
[Thread 0x7fff1b7fe6c0 (LWP 378627) exited]
[New Thread 0x7fff1a7fc6c0 (LWP 378629)]
[Thread 0x7fff1affd6c0 (LWP 378628) exited]
[Thread 0x7fff1a7fc6c0 (LWP 378629) exited]
[New Thread 0x7fff19ffb6c0 (LWP 378630)]
[Thread 0x7fff19ffb6c0 (LWP 378630) exited]
[New Thread 0x7fff197fa6c0 (LWP 378631)]
[Thread 0x7fff197fa6c0 (LWP 378631) exited]
#Primes 2

Thread 16 "icas" hit Breakpoint 1, giac::smallmodrref_upper (N=std::vector of length 5, capacity 5 = {...}, l=0, lmax=5, c=0, cmax=3, modulo=429396733) at vecteur.cc:8351
8351		    longlong * ptr= &buffer[C],*ptrend=&buffer[0]+cmax-4;
(gdb) p C
$19 = 3
(gdb) p cmax
$20 = 3
(gdb) p buffer
$21 = std::vector of length 3, capacity 3 = {0, 1, 0}

[parisse]

Essaie plutot la modification dans first.h. Sinon, à chaque fois que je lis une adresse, il peut se produire un faux positif. Les assertions glibcxx sont juste incompatibles avec ma façon de coder.