(struct_matrice **) &((*s_objet_resultat_1).objet)
(struct_matrice **) &((*s_objet_resultat_1).objet)
(struct_matrice **) &((*s_objet_resultat_1).objet)
(struct_matrice **) &((*s_objet_resultat_1).objet)
Pourquoi avoir besoin de caster en "struct_matrice **" ? Sur quelle
ligne exactement le warning est levé ?
(Accessoirement le membre "objet" est bien de type struct_matrice * ?)
(struct_matrice **) &((*s_objet_resultat_1).objet)
Pourquoi avoir besoin de caster en "struct_matrice **" ? Sur quelle
ligne exactement le warning est levé ?
(Accessoirement le membre "objet" est bien de type struct_matrice * ?)
(struct_matrice **) &((*s_objet_resultat_1).objet)
Pourquoi avoir besoin de caster en "struct_matrice **" ? Sur quelle
ligne exactement le warning est levé ?
(Accessoirement le membre "objet" est bien de type struct_matrice * ?)
Bonjour à tous,
J'ai lors de la compilation d'un programme plusieurs warnings que je
ne comprends pas.
Exemple minimal :
factorisation_lu((*s_objet_argument).objet, (struct_matrice **)
&((*s_objet_resultat_1).objet), &ios);
me renvoie lors de la compilation (avec gcc-4.2 comme compilo) :
instructions_l4.conv.c: In function librpl_instruction_lu:
instructions_l4.conv.c:149: warning: dereferencing type-punned pointer
will break strict-aliasing rules.
Le prototype de la fonction (écrite en Fortran90) est le suivant :
void factorisation_lu(struct_matrice *s_matrice,
struct_matrice **s_permutation, long *ios);
et le type struct_matrice est :
typedef struct matrice
{
unsigned long nombre_lignes;
unsigned long nombre_colonnes;
unsigned char type;
void **tableau;
} struct_matrice;
Comment faire pour supprimer ce warning ? Je ne vois pas vraiment ce
que j'ai fait de mail (si tant est que j'ai écrit quelque chose
d'incorrect...).
Bonjour à tous,
J'ai lors de la compilation d'un programme plusieurs warnings que je
ne comprends pas.
Exemple minimal :
factorisation_lu((*s_objet_argument).objet, (struct_matrice **)
&((*s_objet_resultat_1).objet), &ios);
me renvoie lors de la compilation (avec gcc-4.2 comme compilo) :
instructions_l4.conv.c: In function librpl_instruction_lu:
instructions_l4.conv.c:149: warning: dereferencing type-punned pointer
will break strict-aliasing rules.
Le prototype de la fonction (écrite en Fortran90) est le suivant :
void factorisation_lu(struct_matrice *s_matrice,
struct_matrice **s_permutation, long *ios);
et le type struct_matrice est :
typedef struct matrice
{
unsigned long nombre_lignes;
unsigned long nombre_colonnes;
unsigned char type;
void **tableau;
} struct_matrice;
Comment faire pour supprimer ce warning ? Je ne vois pas vraiment ce
que j'ai fait de mail (si tant est que j'ai écrit quelque chose
d'incorrect...).
Bonjour à tous,
J'ai lors de la compilation d'un programme plusieurs warnings que je
ne comprends pas.
Exemple minimal :
factorisation_lu((*s_objet_argument).objet, (struct_matrice **)
&((*s_objet_resultat_1).objet), &ios);
me renvoie lors de la compilation (avec gcc-4.2 comme compilo) :
instructions_l4.conv.c: In function librpl_instruction_lu:
instructions_l4.conv.c:149: warning: dereferencing type-punned pointer
will break strict-aliasing rules.
Le prototype de la fonction (écrite en Fortran90) est le suivant :
void factorisation_lu(struct_matrice *s_matrice,
struct_matrice **s_permutation, long *ios);
et le type struct_matrice est :
typedef struct matrice
{
unsigned long nombre_lignes;
unsigned long nombre_colonnes;
unsigned char type;
void **tableau;
} struct_matrice;
Comment faire pour supprimer ce warning ? Je ne vois pas vraiment ce
que j'ai fait de mail (si tant est que j'ai écrit quelque chose
d'incorrect...).
car le champ objet est un pointeur sur un void. Ce champ peut
pointer sur des entiers, des réels, des complexes, des vecteurs, des
matrices, enfin sur tout un tas d'objets mathématiques.
car le champ objet est un pointeur sur un void. Ce champ peut
pointer sur des entiers, des réels, des complexes, des vecteurs, des
matrices, enfin sur tout un tas d'objets mathématiques.
car le champ objet est un pointeur sur un void. Ce champ peut
pointer sur des entiers, des réels, des complexes, des vecteurs, des
matrices, enfin sur tout un tas d'objets mathématiques.
car le champ objet est un pointeur sur un void. Ce champ peut
pointer sur des entiers, des réels, des complexes, des vecteurs, des
matrices, enfin sur tout un tas d'objets mathématiques.
Ah, l'erreur est là: vous avez un pointeur casté dans un autre type et
immédiatement déréférencé ( *( (struct_matrice **) &foo ), ce qui pose
problème au compilateur car deux pointeurs quasi-identiques mais de
types différents vont exister au même moment ("quasi-identiques" ==
identiques au signe près, en gros).
Au lieu d'un void*, vous pouvez (devriez) utilier une union "propre" du
type:
typedef union opaque
{
struct_matrice *mat;
char *string;
float *flt;
void *data;
} opaque_data;
Dans ce cas, il suffit d'utiliser "&foo.opaque.mat" sans aucun cast.
Aucun autre cast ne devrait être nécessaire, au passage, après ça.
Sinon je conseille vivement cette excellente page d'une clarté
exceptionnelle sur l'aliasing, qui est un poil technique mais qui
explique non seulement ce qu'est l'aliasing, mais également l'interêt de
s'y conformer pour le compilateur:
<http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html>
car le champ objet est un pointeur sur un void. Ce champ peut
pointer sur des entiers, des réels, des complexes, des vecteurs, des
matrices, enfin sur tout un tas d'objets mathématiques.
Ah, l'erreur est là: vous avez un pointeur casté dans un autre type et
immédiatement déréférencé ( *( (struct_matrice **) &foo ), ce qui pose
problème au compilateur car deux pointeurs quasi-identiques mais de
types différents vont exister au même moment ("quasi-identiques" ==
identiques au signe près, en gros).
Au lieu d'un void*, vous pouvez (devriez) utilier une union "propre" du
type:
typedef union opaque
{
struct_matrice *mat;
char *string;
float *flt;
void *data;
} opaque_data;
Dans ce cas, il suffit d'utiliser "&foo.opaque.mat" sans aucun cast.
Aucun autre cast ne devrait être nécessaire, au passage, après ça.
Sinon je conseille vivement cette excellente page d'une clarté
exceptionnelle sur l'aliasing, qui est un poil technique mais qui
explique non seulement ce qu'est l'aliasing, mais également l'interêt de
s'y conformer pour le compilateur:
<http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html>
car le champ objet est un pointeur sur un void. Ce champ peut
pointer sur des entiers, des réels, des complexes, des vecteurs, des
matrices, enfin sur tout un tas d'objets mathématiques.
Ah, l'erreur est là: vous avez un pointeur casté dans un autre type et
immédiatement déréférencé ( *( (struct_matrice **) &foo ), ce qui pose
problème au compilateur car deux pointeurs quasi-identiques mais de
types différents vont exister au même moment ("quasi-identiques" ==
identiques au signe près, en gros).
Au lieu d'un void*, vous pouvez (devriez) utilier une union "propre" du
type:
typedef union opaque
{
struct_matrice *mat;
char *string;
float *flt;
void *data;
} opaque_data;
Dans ce cas, il suffit d'utiliser "&foo.opaque.mat" sans aucun cast.
Aucun autre cast ne devrait être nécessaire, au passage, après ça.
Sinon je conseille vivement cette excellente page d'une clarté
exceptionnelle sur l'aliasing, qui est un poil technique mais qui
explique non seulement ce qu'est l'aliasing, mais également l'interêt de
s'y conformer pour le compilateur:
<http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html>
Après autre investigation, le warning n'apparaît qu'à partir de
l'optimisation -O2.
je viens de m'en tirer en écrivant :
s_matrice= (struct_matrice *) (*s_objet_resultat_1).objet;
factorisation_lu((*s_objet_argument).objet, &s_matrice, &ios);
Mais je reste ouvert à toute forme d'explication.
Après autre investigation, le warning n'apparaît qu'à partir de
l'optimisation -O2.
je viens de m'en tirer en écrivant :
s_matrice= (struct_matrice *) (*s_objet_resultat_1).objet;
factorisation_lu((*s_objet_argument).objet, &s_matrice, &ios);
Mais je reste ouvert à toute forme d'explication.
Après autre investigation, le warning n'apparaît qu'à partir de
l'optimisation -O2.
je viens de m'en tirer en écrivant :
s_matrice= (struct_matrice *) (*s_objet_resultat_1).objet;
factorisation_lu((*s_objet_argument).objet, &s_matrice, &ios);
Mais je reste ouvert à toute forme d'explication.
Après autre investigation, le warning n'apparaît qu'à partir de
l'optimisation -O2.
-fstrict-aliasing est activé avec -O2, -O3, et -Os (man gcc)je viens de m'en tirer en écrivant :
s_matrice= (struct_matrice *) (*s_objet_resultat_1).objet;
factorisation_lu((*s_objet_argument).objet, &s_matrice, &ios);
Humm, ça devrait marcher, mais c'est moins propre qu'une union.
Mais je reste ouvert à toute forme d'explication.
La page de Mike Acton est à lire, mais en gros le compilateur se permet,
lorsqu'il optimise sérieusement, de considérer qu'une adresse est unique à
un moment donné pour un type donné. Cela permet notamment d'_aliaser_ des
pointeurs déréférencés en un registre, en isolant chaque adresse et en
considérant que personne ne peut avoir d'effet de bord dessus à cause d'un
cast mal placé.
Après autre investigation, le warning n'apparaît qu'à partir de
l'optimisation -O2.
-fstrict-aliasing est activé avec -O2, -O3, et -Os (man gcc)
je viens de m'en tirer en écrivant :
s_matrice= (struct_matrice *) (*s_objet_resultat_1).objet;
factorisation_lu((*s_objet_argument).objet, &s_matrice, &ios);
Humm, ça devrait marcher, mais c'est moins propre qu'une union.
Mais je reste ouvert à toute forme d'explication.
La page de Mike Acton est à lire, mais en gros le compilateur se permet,
lorsqu'il optimise sérieusement, de considérer qu'une adresse est unique à
un moment donné pour un type donné. Cela permet notamment d'_aliaser_ des
pointeurs déréférencés en un registre, en isolant chaque adresse et en
considérant que personne ne peut avoir d'effet de bord dessus à cause d'un
cast mal placé.
Après autre investigation, le warning n'apparaît qu'à partir de
l'optimisation -O2.
-fstrict-aliasing est activé avec -O2, -O3, et -Os (man gcc)je viens de m'en tirer en écrivant :
s_matrice= (struct_matrice *) (*s_objet_resultat_1).objet;
factorisation_lu((*s_objet_argument).objet, &s_matrice, &ios);
Humm, ça devrait marcher, mais c'est moins propre qu'une union.
Mais je reste ouvert à toute forme d'explication.
La page de Mike Acton est à lire, mais en gros le compilateur se permet,
lorsqu'il optimise sérieusement, de considérer qu'une adresse est unique à
un moment donné pour un type donné. Cela permet notamment d'_aliaser_ des
pointeurs déréférencés en un registre, en isolant chaque adresse et en
considérant que personne ne peut avoir d'effet de bord dessus à cause d'un
cast mal placé.
"Xavier Roche" a écrit dans le message de
news: fr89nm$prl$Après autre investigation, le warning n'apparaît qu'à partir de
l'optimisation -O2.
-fstrict-aliasing est activé avec -O2, -O3, et -Os (man gcc)je viens de m'en tirer en écrivant :
s_matrice= (struct_matrice *) (*s_objet_resultat_1).objet;
factorisation_lu((*s_objet_argument).objet, &s_matrice, &ios);
Humm, ça devrait marcher, mais c'est moins propre qu'une union.
Tu peux simplifier le code ci-dessus en C, sans cast inutile et avec la
syntaxe des pointeurs :
struct_matrice *s_matrice;
...
s_matrice = s_objet_resultat_l->objet;
factorisation_lu(s_objet_argument->objet, &s_matrice, &ios);
De plus, s'il est possible que la fonction FORTRAN factorisation_lu realloue
la matrice, il faudrait recopier la nouvelle valeur du pointeur dans objet
après l'appel :
s_objet_resultat_l->objet = s_matrice;
Enfin tu passes la meme matrice en entree et sortie de la fonction
factorisation_lu : l'implementation doit permettre cela ou le resultat sera
completement indefini.
Mais je reste ouvert à toute forme d'explication.
La page de Mike Acton est à lire, mais en gros le compilateur se permet,
lorsqu'il optimise sérieusement, de considérer qu'une adresse est unique à
un moment donné pour un type donné. Cela permet notamment d'_aliaser_ des
pointeurs déréférencés en un registre, en isolant chaque adresse et en
considérant que personne ne peut avoir d'effet de bord dessus à cause d'un
cast mal placé.
En résumé : les cast explicites, c'est mal ;-)
"Xavier Roche" <xroche@free.fr.NOSPAM.invalid> a écrit dans le message de
news: fr89nm$prl$3@news.httrack.net...
Après autre investigation, le warning n'apparaît qu'à partir de
l'optimisation -O2.
-fstrict-aliasing est activé avec -O2, -O3, et -Os (man gcc)
je viens de m'en tirer en écrivant :
s_matrice= (struct_matrice *) (*s_objet_resultat_1).objet;
factorisation_lu((*s_objet_argument).objet, &s_matrice, &ios);
Humm, ça devrait marcher, mais c'est moins propre qu'une union.
Tu peux simplifier le code ci-dessus en C, sans cast inutile et avec la
syntaxe des pointeurs :
struct_matrice *s_matrice;
...
s_matrice = s_objet_resultat_l->objet;
factorisation_lu(s_objet_argument->objet, &s_matrice, &ios);
De plus, s'il est possible que la fonction FORTRAN factorisation_lu realloue
la matrice, il faudrait recopier la nouvelle valeur du pointeur dans objet
après l'appel :
s_objet_resultat_l->objet = s_matrice;
Enfin tu passes la meme matrice en entree et sortie de la fonction
factorisation_lu : l'implementation doit permettre cela ou le resultat sera
completement indefini.
Mais je reste ouvert à toute forme d'explication.
La page de Mike Acton est à lire, mais en gros le compilateur se permet,
lorsqu'il optimise sérieusement, de considérer qu'une adresse est unique à
un moment donné pour un type donné. Cela permet notamment d'_aliaser_ des
pointeurs déréférencés en un registre, en isolant chaque adresse et en
considérant que personne ne peut avoir d'effet de bord dessus à cause d'un
cast mal placé.
En résumé : les cast explicites, c'est mal ;-)
"Xavier Roche" a écrit dans le message de
news: fr89nm$prl$Après autre investigation, le warning n'apparaît qu'à partir de
l'optimisation -O2.
-fstrict-aliasing est activé avec -O2, -O3, et -Os (man gcc)je viens de m'en tirer en écrivant :
s_matrice= (struct_matrice *) (*s_objet_resultat_1).objet;
factorisation_lu((*s_objet_argument).objet, &s_matrice, &ios);
Humm, ça devrait marcher, mais c'est moins propre qu'une union.
Tu peux simplifier le code ci-dessus en C, sans cast inutile et avec la
syntaxe des pointeurs :
struct_matrice *s_matrice;
...
s_matrice = s_objet_resultat_l->objet;
factorisation_lu(s_objet_argument->objet, &s_matrice, &ios);
De plus, s'il est possible que la fonction FORTRAN factorisation_lu realloue
la matrice, il faudrait recopier la nouvelle valeur du pointeur dans objet
après l'appel :
s_objet_resultat_l->objet = s_matrice;
Enfin tu passes la meme matrice en entree et sortie de la fonction
factorisation_lu : l'implementation doit permettre cela ou le resultat sera
completement indefini.
Mais je reste ouvert à toute forme d'explication.
La page de Mike Acton est à lire, mais en gros le compilateur se permet,
lorsqu'il optimise sérieusement, de considérer qu'une adresse est unique à
un moment donné pour un type donné. Cela permet notamment d'_aliaser_ des
pointeurs déréférencés en un registre, en isolant chaque adresse et en
considérant que personne ne peut avoir d'effet de bord dessus à cause d'un
cast mal placé.
En résumé : les cast explicites, c'est mal ;-)