La démarche est, je pense, un peu différente de celle d'un simple
commentaire comme mis dans un entête. J'imagine (mais je peux me tromper),
qu'avant de considérer qu'un code C devient un code C++, on se renseigne
sur les différences entre les deux langages, et on regarde un peu
son code voire s'il utilise les constructions incriminées. Non ?
> En passant, certains sont en train de faire modifier le code de gcc pour
> qu'il soit compilable en C++ et en C; avec comme effet qu'ils ont ajoute la
> possibilite d'avoir un warning sur certaines differences quand on compile
> en C.
C'est à dire, un message du genre "Warning: this construction has
a different semantics in C and C++" ?
La démarche est, je pense, un peu différente de celle d'un simple
commentaire comme mis dans un entête. J'imagine (mais je peux me tromper),
qu'avant de considérer qu'un code C devient un code C++, on se renseigne
sur les différences entre les deux langages, et on regarde un peu
son code voire s'il utilise les constructions incriminées. Non ?
> En passant, certains sont en train de faire modifier le code de gcc pour
> qu'il soit compilable en C++ et en C; avec comme effet qu'ils ont ajoute la
> possibilite d'avoir un warning sur certaines differences quand on compile
> en C.
C'est à dire, un message du genre "Warning: this construction has
a different semantics in C and C++" ?
La démarche est, je pense, un peu différente de celle d'un simple
commentaire comme mis dans un entête. J'imagine (mais je peux me tromper),
qu'avant de considérer qu'un code C devient un code C++, on se renseigne
sur les différences entre les deux langages, et on regarde un peu
son code voire s'il utilise les constructions incriminées. Non ?
> En passant, certains sont en train de faire modifier le code de gcc pour
> qu'il soit compilable en C++ et en C; avec comme effet qu'ils ont ajoute la
> possibilite d'avoir un warning sur certaines differences quand on compile
> en C.
C'est à dire, un message du genre "Warning: this construction has
a different semantics in C and C++" ?
Donc, je suis bien en 387, pas un iota de SSE*. Avec ou sans
l'option -mfpmath87, même résultat, l'option -ffloat-store
est sans effet. Même code à l'arrivée. J'ai vérifié aussi le
code assembleur généré.
Bref, j'en reviens toujours à la conclusion que c'est un bug
du compulateur.
Donc, je suis bien en 387, pas un iota de SSE*. Avec ou sans
l'option -mfpmath87, même résultat, l'option -ffloat-store
est sans effet. Même code à l'arrivée. J'ai vérifié aussi le
code assembleur généré.
Bref, j'en reviens toujours à la conclusion que c'est un bug
du compulateur.
Donc, je suis bien en 387, pas un iota de SSE*. Avec ou sans
l'option -mfpmath87, même résultat, l'option -ffloat-store
est sans effet. Même code à l'arrivée. J'ai vérifié aussi le
code assembleur généré.
Bref, j'en reviens toujours à la conclusion que c'est un bug
du compulateur.
La démarche est, je pense, un peu différente de celle d'un simple
commentaire comme mis dans un entête. J'imagine (mais je peux me tromper),
qu'avant de considérer qu'un code C devient un code C++, on se renseigne
sur les différences entre les deux langages, et on regarde un peu
son code voire s'il utilise les constructions incriminées. Non ?
La démarche est, je pense, un peu différente de celle d'un simple
commentaire comme mis dans un entête. J'imagine (mais je peux me tromper),
qu'avant de considérer qu'un code C devient un code C++, on se renseigne
sur les différences entre les deux langages, et on regarde un peu
son code voire s'il utilise les constructions incriminées. Non ?
La démarche est, je pense, un peu différente de celle d'un simple
commentaire comme mis dans un entête. J'imagine (mais je peux me tromper),
qu'avant de considérer qu'un code C devient un code C++, on se renseigne
sur les différences entre les deux langages, et on regarde un peu
son code voire s'il utilise les constructions incriminées. Non ?
Dans la pratique, on a les différences de nommages (et il y a export"C"
qui est fait pour), le type de NULL et quelques variations du même
genre, l'histoire du type de 'a' qui d'après ce que j'ai compris, sert
surtout à détecter le langage du compilateur :^), et dans les trucs plus
gênants, les utilisations de malloc() et le destin des const globales.
Dans la pratique, on a les différences de nommages (et il y a export"C"
qui est fait pour), le type de NULL et quelques variations du même
genre, l'histoire du type de 'a' qui d'après ce que j'ai compris, sert
surtout à détecter le langage du compilateur :^), et dans les trucs plus
gênants, les utilisations de malloc() et le destin des const globales.
Dans la pratique, on a les différences de nommages (et il y a export"C"
qui est fait pour), le type de NULL et quelques variations du même
genre, l'histoire du type de 'a' qui d'après ce que j'ai compris, sert
surtout à détecter le langage du compilateur :^), et dans les trucs plus
gênants, les utilisations de malloc() et le destin des const globales.
Dans l'article ,
Kojak écrit:
> [...] Même code à l'arrivée. J'ai vérifié auss i le
> code assembleur généré.
Au contraire, tu montres qu'elle a toujours un effet. Tu disais:
|Et, sauf erreur, j'obtiens toujours, sans '-ffloat-store' :
> Bref, j'en reviens toujours à la conclusion que c'est un bug
> du compulateur.
Le fait que -ffloat-store introduise des load/store sur une expression
(ici, u / v / v / v) n'a pas forcément à être considé ré comme un bug.
Quoique... cela peut contredire FLT_EVAL_METHOD.
Dans l'article <20090330132424.6fdcebc1@thor.janville.org>,
Kojak <nntpspy@janville.borg.invalid> écrit:
> [...] Même code à l'arrivée. J'ai vérifié auss i le
> code assembleur généré.
Au contraire, tu montres qu'elle a toujours un effet. Tu disais:
|Et, sauf erreur, j'obtiens toujours, sans '-ffloat-store' :
> Bref, j'en reviens toujours à la conclusion que c'est un bug
> du compulateur.
Le fait que -ffloat-store introduise des load/store sur une expression
(ici, u / v / v / v) n'a pas forcément à être considé ré comme un bug.
Quoique... cela peut contredire FLT_EVAL_METHOD.
Dans l'article ,
Kojak écrit:
> [...] Même code à l'arrivée. J'ai vérifié auss i le
> code assembleur généré.
Au contraire, tu montres qu'elle a toujours un effet. Tu disais:
|Et, sauf erreur, j'obtiens toujours, sans '-ffloat-store' :
> Bref, j'en reviens toujours à la conclusion que c'est un bug
> du compulateur.
Le fait que -ffloat-store introduise des load/store sur une expression
(ici, u / v / v / v) n'a pas forcément à être considé ré comme un bug.
Quoique... cela peut contredire FLT_EVAL_METHOD.
In article ,
Marc Boyer wrote:La démarche est, je pense, un peu différente de celle d'un simple
commentaire comme mis dans un entête. J'imagine (mais je peux me tromper),
qu'avant de considérer qu'un code C devient un code C++, on se renseigne
sur les différences entre les deux langages, et on regarde un peu
son code voire s'il utilise les constructions incriminées. Non ?
Qu'est-ce qui te fait dire, dans le cas qui nous preoccupait au debut,
que les gens qui ont compile ce driver avec un compilo C++ ne savent
pas exactement ce qu'ils font ?
En particulier, ca n'est pas vraiment complique de trouver toutes les
raisons qui font qu'un programme C valide sera un programme C++ valide
de semantique differente... (le plus gros souci etant effectivement
sizeof('a'), pas exactement la construction qui va poser le plus de
probleme en pratique...)
In article <slrngt1joj.t1m.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
La démarche est, je pense, un peu différente de celle d'un simple
commentaire comme mis dans un entête. J'imagine (mais je peux me tromper),
qu'avant de considérer qu'un code C devient un code C++, on se renseigne
sur les différences entre les deux langages, et on regarde un peu
son code voire s'il utilise les constructions incriminées. Non ?
Qu'est-ce qui te fait dire, dans le cas qui nous preoccupait au debut,
que les gens qui ont compile ce driver avec un compilo C++ ne savent
pas exactement ce qu'ils font ?
En particulier, ca n'est pas vraiment complique de trouver toutes les
raisons qui font qu'un programme C valide sera un programme C++ valide
de semantique differente... (le plus gros souci etant effectivement
sizeof('a'), pas exactement la construction qui va poser le plus de
probleme en pratique...)
In article ,
Marc Boyer wrote:La démarche est, je pense, un peu différente de celle d'un simple
commentaire comme mis dans un entête. J'imagine (mais je peux me tromper),
qu'avant de considérer qu'un code C devient un code C++, on se renseigne
sur les différences entre les deux langages, et on regarde un peu
son code voire s'il utilise les constructions incriminées. Non ?
Qu'est-ce qui te fait dire, dans le cas qui nous preoccupait au debut,
que les gens qui ont compile ce driver avec un compilo C++ ne savent
pas exactement ce qu'ils font ?
En particulier, ca n'est pas vraiment complique de trouver toutes les
raisons qui font qu'un programme C valide sera un programme C++ valide
de semantique differente... (le plus gros souci etant effectivement
sizeof('a'), pas exactement la construction qui va poser le plus de
probleme en pratique...)
Je confirme, avec la version de GCC utilisée (3.4.6) le rajout de
-ffloat-store n'a aucun effet sur le résultat de la compilation.
Un peu comme si l'option avait été prévue dans le parser, mais pas
activée. Un problème spécifique à la version Debian ? Ou est-ce
général à toutes les version de GCC 3 (4.6 et autres) ? Là, je ne
saurais dire.
Bref, aurais-tu un exemple simple où, compilé avec GCC 3 (disons
la version 3.4.6, par exemple) le résultat serait différent avec
et sans -ffloat-store ?
Je confirme, avec la version de GCC utilisée (3.4.6) le rajout de
-ffloat-store n'a aucun effet sur le résultat de la compilation.
Un peu comme si l'option avait été prévue dans le parser, mais pas
activée. Un problème spécifique à la version Debian ? Ou est-ce
général à toutes les version de GCC 3 (4.6 et autres) ? Là, je ne
saurais dire.
Bref, aurais-tu un exemple simple où, compilé avec GCC 3 (disons
la version 3.4.6, par exemple) le résultat serait différent avec
et sans -ffloat-store ?
Je confirme, avec la version de GCC utilisée (3.4.6) le rajout de
-ffloat-store n'a aucun effet sur le résultat de la compilation.
Un peu comme si l'option avait été prévue dans le parser, mais pas
activée. Un problème spécifique à la version Debian ? Ou est-ce
général à toutes les version de GCC 3 (4.6 et autres) ? Là, je ne
saurais dire.
Bref, aurais-tu un exemple simple où, compilé avec GCC 3 (disons
la version 3.4.6, par exemple) le résultat serait différent avec
et sans -ffloat-store ?
A mon sens, le plus pénible, ce serait
const int i=0; // extern en C / static en C++
A mon sens, le plus pénible, ce serait
const int i=0; // extern en C / static en C++
A mon sens, le plus pénible, ce serait
const int i=0; // extern en C / static en C++
Je confirme, avec la version de GCC utilisée (3.4.6) le rajout de
-ffloat-store n'a aucun effet sur le résultat de la compilation.
Un peu comme si l'option avait été prévue dans le parser, mais pas
activée. Un problème spécifique à la version Debian ? Ou est-ce
général à toutes les version de GCC 3 (4.6 et autres) ? Là, je ne
saurais dire.
Bref, aurais-tu un exemple simple où, compilé avec GCC 3 (disons
la version 3.4.6, par exemple) le résultat serait différent avec
et sans -ffloat-store ?
Je confirme, avec la version de GCC utilisée (3.4.6) le rajout de
-ffloat-store n'a aucun effet sur le résultat de la compilation.
Un peu comme si l'option avait été prévue dans le parser, mais pas
activée. Un problème spécifique à la version Debian ? Ou est-ce
général à toutes les version de GCC 3 (4.6 et autres) ? Là, je ne
saurais dire.
Bref, aurais-tu un exemple simple où, compilé avec GCC 3 (disons
la version 3.4.6, par exemple) le résultat serait différent avec
et sans -ffloat-store ?
Je confirme, avec la version de GCC utilisée (3.4.6) le rajout de
-ffloat-store n'a aucun effet sur le résultat de la compilation.
Un peu comme si l'option avait été prévue dans le parser, mais pas
activée. Un problème spécifique à la version Debian ? Ou est-ce
général à toutes les version de GCC 3 (4.6 et autres) ? Là, je ne
saurais dire.
Bref, aurais-tu un exemple simple où, compilé avec GCC 3 (disons
la version 3.4.6, par exemple) le résultat serait différent avec
et sans -ffloat-store ?
Il faut activer les optimisations, mais modifier ton code d'origine
pour que GCC évite de prendre en compte les constantes et de faire
les calculs à la compilation:
float f, x, y, z;
volatile float u = 1.0, v = 0.1;
Attention, le volatile ne doit se trouver que sur u et v, car
on veut toujours les optimisations sur les expressions.
Il faut activer les optimisations, mais modifier ton code d'origine
pour que GCC évite de prendre en compte les constantes et de faire
les calculs à la compilation:
float f, x, y, z;
volatile float u = 1.0, v = 0.1;
Attention, le volatile ne doit se trouver que sur u et v, car
on veut toujours les optimisations sur les expressions.
Il faut activer les optimisations, mais modifier ton code d'origine
pour que GCC évite de prendre en compte les constantes et de faire
les calculs à la compilation:
float f, x, y, z;
volatile float u = 1.0, v = 0.1;
Attention, le volatile ne doit se trouver que sur u et v, car
on veut toujours les optimisations sur les expressions.
