_DOUBLE_ est issu d'un enum tout bête, donc a priori un int. Les
opérateurs ne semblent pas surchargés.
Le code assembleur fautif est :
=> 0x0043510c <+44>: ldd [ %o1 ], %g2
avec %o1, un pointeur vers FFFFD974 et %g2, la valeur 0x1. ldd charge un
double mot qui n'est pas aligné sur 64 bits, donc c'est un peu
normal que le processeur râle.
J'ai essayé de forcer l'alignement du champ type de la classe gen
sans succès (parce qu'on compare tout de même un unsigned char à un
enum). Le résultat est le même.
Une idée ?
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Merci, j'ai oublié de dire que c'était la première chose que j'avais testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis "sans succès", cela signifie que le SIGBUS reste (et on peut innocenter la classe gen), ou qu'il disparait ?
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 29-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Le Wed, 29 Jun 2011 13:57:38 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 28-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Bonjour à tous,
J'essaie de compiler giac 0.9.1 sur un serveur sparc et j'ai
quelques minus problèmes d'alignement.
Le programme se vautre sur :
if (e.type>_DOUBLE_ && e.type!=_FLOAT_
#ifndef SMARTPTR64
&& e.type!=_FUNC
#endif
)
Juste pour te montrer que tu es lu: as-tu essayé de décomposer
accès et comparaison:
Merci, j'ai oublié de dire que c'était la première chose que j'avais
testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis
"sans succès", cela signifie que le SIGBUS reste (et on peut innocenter
la classe gen), ou qu'il disparait ?
Marc Boyer
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
Merci, j'ai oublié de dire que c'était la première chose que j'avais testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis "sans succès", cela signifie que le SIGBUS reste (et on peut innocenter la classe gen), ou qu'il disparait ?
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
JKB
Le Wed, 29 Jun 2011 14:51:22 +0000 (UTC), Marc Boyer écrivait :
Le 29-06-2011, JKB a écrit :
Le Wed, 29 Jun 2011 13:57:38 +0000 (UTC), Marc Boyer écrivait :
Le 28-06-2011, JKB a écrit :
Bonjour à tous,
J'essaie de compiler giac 0.9.1 sur un serveur sparc et j'ai quelques minus problèmes d'alignement.
Le programme se vautre sur :
if (e.type>_DOUBLE_ && e.type!=_FLOAT_ #ifndef SMARTPTR64 && e.type!=_FUNC #endif )
Juste pour te montrer que tu es lu: as-tu essayé de décomposer accès et comparaison:
Merci, j'ai oublié de dire que c'était la première chose que j'avais testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis "sans succès", cela signifie que le SIGBUS reste (et on peut innocenter la classe gen), ou qu'il disparait ?
Il reste... En fait, j'ai copié toutes les valeurs dans des variables intermédiaires de même type et le sigbus est levé lors de la première comparaison (de deux variables de même type). Je ne vois vraiment pas où je pourrais avoir un problème d'alignement.
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Wed, 29 Jun 2011 14:51:22 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 29-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Le Wed, 29 Jun 2011 13:57:38 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 28-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Bonjour à tous,
J'essaie de compiler giac 0.9.1 sur un serveur sparc et j'ai
quelques minus problèmes d'alignement.
Le programme se vautre sur :
if (e.type>_DOUBLE_ && e.type!=_FLOAT_
#ifndef SMARTPTR64
&& e.type!=_FUNC
#endif
)
Juste pour te montrer que tu es lu: as-tu essayé de décomposer
accès et comparaison:
Merci, j'ai oublié de dire que c'était la première chose que j'avais
testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis
"sans succès", cela signifie que le SIGBUS reste (et on peut innocenter
la classe gen), ou qu'il disparait ?
Il reste... En fait, j'ai copié toutes les valeurs dans des
variables intermédiaires de même type et le sigbus est levé lors de
la première comparaison (de deux variables de même type). Je ne vois
vraiment pas où je pourrais avoir un problème d'alignement.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Merci, j'ai oublié de dire que c'était la première chose que j'avais testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis "sans succès", cela signifie que le SIGBUS reste (et on peut innocenter la classe gen), ou qu'il disparait ?
Il reste... En fait, j'ai copié toutes les valeurs dans des variables intermédiaires de même type et le sigbus est levé lors de la première comparaison (de deux variables de même type). Je ne vois vraiment pas où je pourrais avoir un problème d'alignement.
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Marc Boyer
Le 29-06-2011, JKB a écrit :
Le Wed, 29 Jun 2011 14:51:22 +0000 (UTC), Marc Boyer écrivait :
Le 29-06-2011, JKB a écrit :
Le Wed, 29 Jun 2011 13:57:38 +0000 (UTC), Marc Boyer écrivait :
Le 28-06-2011, JKB a écrit :
Juste pour te montrer que tu es lu: as-tu essayé de décomposer accès et comparaison:
Merci, j'ai oublié de dire que c'était la première chose que j'avais testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis "sans succès", cela signifie que le SIGBUS reste (et on peut innocenter la classe gen), ou qu'il disparait ?
Il reste... En fait, j'ai copié toutes les valeurs dans des variables intermédiaires de même type et le sigbus est levé lors de la première comparaison (de deux variables de même type). Je ne vois vraiment pas où je pourrais avoir un problème d'alignement.
Et le _DOUBLE_, c'est aussi un unsigned char ? T'as aussi tenté de décomposer le test ? const bool eSupD= etype > _DOUBLE_ ?
Marc boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 29-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Le Wed, 29 Jun 2011 14:51:22 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 29-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Le Wed, 29 Jun 2011 13:57:38 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 28-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Juste pour te montrer que tu es lu: as-tu essayé de décomposer
accès et comparaison:
Merci, j'ai oublié de dire que c'était la première chose que j'avais
testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis
"sans succès", cela signifie que le SIGBUS reste (et on peut innocenter
la classe gen), ou qu'il disparait ?
Il reste... En fait, j'ai copié toutes les valeurs dans des
variables intermédiaires de même type et le sigbus est levé lors de
la première comparaison (de deux variables de même type). Je ne vois
vraiment pas où je pourrais avoir un problème d'alignement.
Et le _DOUBLE_, c'est aussi un unsigned char ?
T'as aussi tenté de décomposer le test ?
const bool eSupD= etype > _DOUBLE_ ?
Marc boyer
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
Merci, j'ai oublié de dire que c'était la première chose que j'avais testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis "sans succès", cela signifie que le SIGBUS reste (et on peut innocenter la classe gen), ou qu'il disparait ?
Il reste... En fait, j'ai copié toutes les valeurs dans des variables intermédiaires de même type et le sigbus est levé lors de la première comparaison (de deux variables de même type). Je ne vois vraiment pas où je pourrais avoir un problème d'alignement.
Et le _DOUBLE_, c'est aussi un unsigned char ? T'as aussi tenté de décomposer le test ? const bool eSupD= etype > _DOUBLE_ ?
Marc boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
JKB
Le Wed, 29 Jun 2011 16:04:04 +0000 (UTC), Marc Boyer écrivait :
Le 29-06-2011, JKB a écrit :
Le Wed, 29 Jun 2011 14:51:22 +0000 (UTC), Marc Boyer écrivait :
Le 29-06-2011, JKB a écrit :
Le Wed, 29 Jun 2011 13:57:38 +0000 (UTC), Marc Boyer écrivait :
Le 28-06-2011, JKB a écrit :
Juste pour te montrer que tu es lu: as-tu essayé de décomposer accès et comparaison:
Merci, j'ai oublié de dire que c'était la première chose que j'avais testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis "sans succès", cela signifie que le SIGBUS reste (et on peut innocenter la classe gen), ou qu'il disparait ?
Il reste... En fait, j'ai copié toutes les valeurs dans des variables intermédiaires de même type et le sigbus est levé lors de la première comparaison (de deux variables de même type). Je ne vois vraiment pas où je pourrais avoir un problème d'alignement.
Et le _DOUBLE_, c'est aussi un unsigned char ? T'as aussi tenté de décomposer le test ? const bool eSupD= etype > _DOUBLE_ ?
Non, le _DOUBLE_, c'est un enum, donc a priori un int. Mais ce n'est pas une histoire de type parce que si je remplace le unsigned char par un int (voir un enum), je récupère toujours mon sigbus.
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Wed, 29 Jun 2011 16:04:04 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 29-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Le Wed, 29 Jun 2011 14:51:22 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 29-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Le Wed, 29 Jun 2011 13:57:38 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 28-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Juste pour te montrer que tu es lu: as-tu essayé de décomposer
accès et comparaison:
Merci, j'ai oublié de dire que c'était la première chose que j'avais
testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis
"sans succès", cela signifie que le SIGBUS reste (et on peut innocenter
la classe gen), ou qu'il disparait ?
Il reste... En fait, j'ai copié toutes les valeurs dans des
variables intermédiaires de même type et le sigbus est levé lors de
la première comparaison (de deux variables de même type). Je ne vois
vraiment pas où je pourrais avoir un problème d'alignement.
Et le _DOUBLE_, c'est aussi un unsigned char ?
T'as aussi tenté de décomposer le test ?
const bool eSupD= etype > _DOUBLE_ ?
Non, le _DOUBLE_, c'est un enum, donc a priori un int. Mais ce
n'est pas une histoire de type parce que si je remplace le unsigned
char par un int (voir un enum), je récupère toujours mon sigbus.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Merci, j'ai oublié de dire que c'était la première chose que j'avais testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis "sans succès", cela signifie que le SIGBUS reste (et on peut innocenter la classe gen), ou qu'il disparait ?
Il reste... En fait, j'ai copié toutes les valeurs dans des variables intermédiaires de même type et le sigbus est levé lors de la première comparaison (de deux variables de même type). Je ne vois vraiment pas où je pourrais avoir un problème d'alignement.
Et le _DOUBLE_, c'est aussi un unsigned char ? T'as aussi tenté de décomposer le test ? const bool eSupD= etype > _DOUBLE_ ?
Non, le _DOUBLE_, c'est un enum, donc a priori un int. Mais ce n'est pas une histoire de type parce que si je remplace le unsigned char par un int (voir un enum), je récupère toujours mon sigbus.
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Lucas Levrel
Le 28 juin 2011, JKB a écrit :
J'ai essayé de forcer l'alignement du champ type de la classe gen
As-tu essayé de forcer l'alignement de e lui-même (si c'est possible) ?
-- LL
Le 28 juin 2011, JKB a écrit :
J'ai essayé de forcer l'alignement du champ type de la classe gen
As-tu essayé de forcer l'alignement de e lui-même (si c'est possible) ?
J'ai essayé de forcer l'alignement du champ type de la classe gen
As-tu essayé de forcer l'alignement de e lui-même (si c'est possible) ?
-- LL
JKB
Le Wed, 29 Jun 2011 21:29:55 +0200, Lucas Levrel écrivait :
Le 28 juin 2011, JKB a écrit :
J'ai essayé de forcer l'alignement du champ type de la classe gen
As-tu essayé de forcer l'alignement de e lui-même (si c'est possible) ?
Non, mais e est aligné. J'ai vérifié. Et si e ne l'était pas, ça coincerait ailleurs que dans la comparaison lorsque l'on passe par des variables intermédiaires.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Wed, 29 Jun 2011 21:29:55 +0200,
Lucas Levrel <lucas.levrel@u-pec.fr> écrivait :
Le 28 juin 2011, JKB a écrit :
J'ai essayé de forcer l'alignement du champ type de la classe gen
As-tu essayé de forcer l'alignement de e lui-même (si c'est possible) ?
Non, mais e est aligné. J'ai vérifié. Et si e ne l'était pas, ça
coincerait ailleurs que dans la comparaison lorsque l'on passe par
des variables intermédiaires.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Wed, 29 Jun 2011 21:29:55 +0200, Lucas Levrel écrivait :
Le 28 juin 2011, JKB a écrit :
J'ai essayé de forcer l'alignement du champ type de la classe gen
As-tu essayé de forcer l'alignement de e lui-même (si c'est possible) ?
Non, mais e est aligné. J'ai vérifié. Et si e ne l'était pas, ça coincerait ailleurs que dans la comparaison lorsque l'on passe par des variables intermédiaires.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Marc Boyer
Le 29-06-2011, JKB a écrit :
Le Wed, 29 Jun 2011 16:04:04 +0000 (UTC), Marc Boyer écrivait :
Le 29-06-2011, JKB a écrit :
Le Wed, 29 Jun 2011 14:51:22 +0000 (UTC), Marc Boyer écrivait :
Le 29-06-2011, JKB a écrit :
Le Wed, 29 Jun 2011 13:57:38 +0000 (UTC), Marc Boyer écrivait :
Le 28-06-2011, JKB a écrit :
Juste pour te montrer que tu es lu: as-tu essayé de décomposer accès et comparaison:
Merci, j'ai oublié de dire que c'était la première chose que j'avais testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis "sans succès", cela signifie que le SIGBUS reste (et on peut innocenter la classe gen), ou qu'il disparait ?
Il reste... En fait, j'ai copié toutes les valeurs dans des variables intermédiaires de même type et le sigbus est levé lors de la première comparaison (de deux variables de même type). Je ne vois vraiment pas où je pourrais avoir un problème d'alignement.
Et le _DOUBLE_, c'est aussi un unsigned char ? T'as aussi tenté de décomposer le test ? const bool eSupD= etype > _DOUBLE_ ?
Non, le _DOUBLE_, c'est un enum, donc a priori un int. Mais ce n'est pas une histoire de type parce que si je remplace le unsigned char par un int (voir un enum), je récupère toujours mon sigbus.
Oui, m'enfin bon, vu le niveau de bizarrerie du bug, je me méfierais de tout. const unsigned char etype= e.type; const int localDouble= _DOUBLE_; const bool eSupD= etype > localDouble ; if ( eSupD ){ const int localFloat= _FLOAT_ ; const bool eDiffF= etype != _FLOAT_ ; if ( eDiffF ) { ... etc } }
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 29-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Le Wed, 29 Jun 2011 16:04:04 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 29-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Le Wed, 29 Jun 2011 14:51:22 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 29-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Le Wed, 29 Jun 2011 13:57:38 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 28-06-2011, JKB <jkb@koenigsberg.invalid> a écrit :
Juste pour te montrer que tu es lu: as-tu essayé de décomposer
accès et comparaison:
Merci, j'ai oublié de dire que c'était la première chose que j'avais
testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis
"sans succès", cela signifie que le SIGBUS reste (et on peut innocenter
la classe gen), ou qu'il disparait ?
Il reste... En fait, j'ai copié toutes les valeurs dans des
variables intermédiaires de même type et le sigbus est levé lors de
la première comparaison (de deux variables de même type). Je ne vois
vraiment pas où je pourrais avoir un problème d'alignement.
Et le _DOUBLE_, c'est aussi un unsigned char ?
T'as aussi tenté de décomposer le test ?
const bool eSupD= etype > _DOUBLE_ ?
Non, le _DOUBLE_, c'est un enum, donc a priori un int. Mais ce
n'est pas une histoire de type parce que si je remplace le unsigned
char par un int (voir un enum), je récupère toujours mon sigbus.
Oui, m'enfin bon, vu le niveau de bizarrerie du bug, je me méfierais de tout.
const unsigned char etype= e.type;
const int localDouble= _DOUBLE_;
const bool eSupD= etype > localDouble ;
if ( eSupD ){
const int localFloat= _FLOAT_ ;
const bool eDiffF= etype != _FLOAT_ ;
if ( eDiffF ) {
... etc
}
}
Marc Boyer
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
Merci, j'ai oublié de dire que c'était la première chose que j'avais testée... Sans succès d'ailleurs.
C'est en effet la première chose qui vient à l'esprit. Quand tu dis "sans succès", cela signifie que le SIGBUS reste (et on peut innocenter la classe gen), ou qu'il disparait ?
Il reste... En fait, j'ai copié toutes les valeurs dans des variables intermédiaires de même type et le sigbus est levé lors de la première comparaison (de deux variables de même type). Je ne vois vraiment pas où je pourrais avoir un problème d'alignement.
Et le _DOUBLE_, c'est aussi un unsigned char ? T'as aussi tenté de décomposer le test ? const bool eSupD= etype > _DOUBLE_ ?
Non, le _DOUBLE_, c'est un enum, donc a priori un int. Mais ce n'est pas une histoire de type parce que si je remplace le unsigned char par un int (voir un enum), je récupère toujours mon sigbus.
Oui, m'enfin bon, vu le niveau de bizarrerie du bug, je me méfierais de tout. const unsigned char etype= e.type; const int localDouble= _DOUBLE_; const bool eSupD= etype > localDouble ; if ( eSupD ){ const int localFloat= _FLOAT_ ; const bool eDiffF= etype != _FLOAT_ ; if ( eDiffF ) { ... etc } }
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
JKB
Le Thu, 30 Jun 2011 08:13:36 +0000 (UTC), Marc Boyer écrivait :
Oui, m'enfin bon, vu le niveau de bizarrerie du bug, je me méfierais de tout. const unsigned char etype= e.type; const int localDouble= _DOUBLE_; const bool eSupD= etype > localDouble ; if ( eSupD ){ const int localFloat= _FLOAT_ ; const bool eDiffF= etype != _FLOAT_ ; if ( eDiffF ) { ... etc } }
Le concepteur du bug est en train de regarder ce qui se passe. Je passerai pas ici avec la solution. Il paraît que c'est une histoire d'optimisation de code. Enfin, des optimisations qui lèvent un SIGBUS, ça ne doit pas être très propre ;-)
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Thu, 30 Jun 2011 08:13:36 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Oui, m'enfin bon, vu le niveau de bizarrerie du bug, je me méfierais de tout.
const unsigned char etype= e.type;
const int localDouble= _DOUBLE_;
const bool eSupD= etype > localDouble ;
if ( eSupD ){
const int localFloat= _FLOAT_ ;
const bool eDiffF= etype != _FLOAT_ ;
if ( eDiffF ) {
... etc
}
}
Le concepteur du bug est en train de regarder ce qui se passe. Je
passerai pas ici avec la solution. Il paraît que c'est une
histoire d'optimisation de code. Enfin, des optimisations qui lèvent
un SIGBUS, ça ne doit pas être très propre ;-)
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Thu, 30 Jun 2011 08:13:36 +0000 (UTC), Marc Boyer écrivait :
Oui, m'enfin bon, vu le niveau de bizarrerie du bug, je me méfierais de tout. const unsigned char etype= e.type; const int localDouble= _DOUBLE_; const bool eSupD= etype > localDouble ; if ( eSupD ){ const int localFloat= _FLOAT_ ; const bool eDiffF= etype != _FLOAT_ ; if ( eDiffF ) { ... etc } }
Le concepteur du bug est en train de regarder ce qui se passe. Je passerai pas ici avec la solution. Il paraît que c'est une histoire d'optimisation de code. Enfin, des optimisations qui lèvent un SIGBUS, ça ne doit pas être très propre ;-)
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
