Decalages d'un nombre de bits pouvant etre >= a la taille du type
134 réponses
Vincent Lefevre
J'ai besoin de faire un décalage vers la droite sur un type entier
(disons non signé) générique (i.e. défini par typedef) d'un certain
nombre constant de bits. Le problème est que ce nombre de bits peut
être supérieur ou égal à la taille du type en question. Une idée
sur la façon de faire ça efficacement sans obtenir de comportement
indéfini et sans passer par un outil du style "configure"?
| Pour moi, le fait que gcc ignore FP_CONTRACT OFF devrait l'obliger à ne | jamais faire de contraction (ce qu'il fait manifestement ici). Mais la norme
Il faudrait d'abord que GCC implémente les expressions constantes correctement :-)
-- Gaby
"Antoine Leca" <root@localhost.gov> writes:
| Pour moi, le fait que gcc ignore FP_CONTRACT OFF devrait l'obliger à ne
| jamais faire de contraction (ce qu'il fait manifestement ici). Mais la norme
Il faudrait d'abord que GCC implémente les expressions constantes
correctement :-)
| Pour moi, le fait que gcc ignore FP_CONTRACT OFF devrait l'obliger à ne | jamais faire de contraction (ce qu'il fait manifestement ici). Mais la norme
Il faudrait d'abord que GCC implémente les expressions constantes correctement :-)
-- Gaby
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Dans l'article <ckvupk$8hp$, | Antoine Leca écrit: | | > En 20041015190901$, Vincent Lefevre va escriure: | > > J'ai toujours vu les compilateurs évaluer des choses constantes à | > > la compilation, même si la grammaire n'attend pas une expression | > > constante. | | > La raison à cela est que l'évaluation à la compilation des expressions | > constantes est une optimisation (payante et sans grand risque, sauf cas | > particuliers comme les compilateurs croisés) qui est peu difficile à | > implanter puisque la grammaire oblige de toute manière le compilateur à | > savoir réduire une expression constante, dans les cas où on attends une | > constante (taille de tableau, initialisation, etc.) | | Sauf qu'une optimisation ne devrait pas rendre quelque chose non | conforme à la norme. J'avais pris cette contraction comme une | application du 6.6. D'ailleurs on peut voir dans le K&R: "Une | /expression constante/ est une expression qui ne comporte que des | constantes." (sans faire référence à ce qu'attend la grammaire). | Je crois que ce bouquin est définitivement à jeter.
Et tu proposes un patch pour la FAQ ? ;-p
| > ÀMHA on sort de la discussion précédente : de tous temps les | > flottants ont été une bête à part. | | > En supposant que tu as utilisé FP_CONTRACT OFF... | | De toute façon, comme tu le dis plus loin, c'est ignoré: | | tst.c:6: warning: ignoring #pragma STDC FP_CONTRACT | | > Je dirais que oui. Je pense que c'est un sujet que tu devrais ouvrir | > sur la liste de gcc, et attendre l'avis de Joseph Myers... | | ... en espérant qu'ils veuillent bien corriger. J'avais vu dans | les archives une discussion à propos d'un autre bug de gcc et les | flottants (les résultats en précision étendue ne sont pas convertis | en double précision lorsqu'on fait un cast en double ou qu'on fait | une affectation), et ça m'a donné l'impression qu'ils ne voulaient | rien changer. :(
« Rien » est définitevement excessif et ne correspond pas à la réalité. De fait, il y a des projets pour améliorer l'évaluation des expressions constantes -- regarde les derniers messages de JSM sur ce sujet.
| > Pour moi, le fait que gcc ignore FP_CONTRACT OFF devrait l'obliger à | > ne jamais faire de contraction (ce qu'il fait manifestement ici). | > Mais la norme est assez floue sur le sujet, il y a bien une | > recommendation (F.6) qui va dans ce sens, mais comme c'est une | > recommendation on peut également s'en servir pour dire que le | > comportement inverse est conforme ! | | Est-ce que la norme autorise les implémentations à ne pas reconnaître | les pragmas qu'elle définit? Si ce n'est pas autorisé, alors on n'a | même pas besoin de cette recommandation.
si une implémentation ne comprend pas un pragma, elle l'ignore. D'où l'utilité de la chose. <g>
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <ckvupk$8hp$1@shakotay.alphanet.ch>,
| Antoine Leca <root@localhost.gov> écrit:
|
| > En 20041015190901$6139@vinc17.org, Vincent Lefevre va escriure:
| > > J'ai toujours vu les compilateurs évaluer des choses constantes à
| > > la compilation, même si la grammaire n'attend pas une expression
| > > constante.
|
| > La raison à cela est que l'évaluation à la compilation des expressions
| > constantes est une optimisation (payante et sans grand risque, sauf cas
| > particuliers comme les compilateurs croisés) qui est peu difficile à
| > implanter puisque la grammaire oblige de toute manière le compilateur à
| > savoir réduire une expression constante, dans les cas où on attends une
| > constante (taille de tableau, initialisation, etc.)
|
| Sauf qu'une optimisation ne devrait pas rendre quelque chose non
| conforme à la norme. J'avais pris cette contraction comme une
| application du 6.6. D'ailleurs on peut voir dans le K&R: "Une
| /expression constante/ est une expression qui ne comporte que des
| constantes." (sans faire référence à ce qu'attend la grammaire).
| Je crois que ce bouquin est définitivement à jeter.
Et tu proposes un patch pour la FAQ ? ;-p
| > ÀMHA on sort de la discussion précédente : de tous temps les
| > flottants ont été une bête à part.
|
| > En supposant que tu as utilisé FP_CONTRACT OFF...
|
| De toute façon, comme tu le dis plus loin, c'est ignoré:
|
| tst.c:6: warning: ignoring #pragma STDC FP_CONTRACT
|
| > Je dirais que oui. Je pense que c'est un sujet que tu devrais ouvrir
| > sur la liste de gcc, et attendre l'avis de Joseph Myers...
|
| ... en espérant qu'ils veuillent bien corriger. J'avais vu dans
| les archives une discussion à propos d'un autre bug de gcc et les
| flottants (les résultats en précision étendue ne sont pas convertis
| en double précision lorsqu'on fait un cast en double ou qu'on fait
| une affectation), et ça m'a donné l'impression qu'ils ne voulaient
| rien changer. :(
« Rien » est définitevement excessif et ne correspond pas à la
réalité. De fait, il y a des projets pour améliorer l'évaluation des
expressions constantes -- regarde les derniers messages de JSM sur ce
sujet.
| > Pour moi, le fait que gcc ignore FP_CONTRACT OFF devrait l'obliger à
| > ne jamais faire de contraction (ce qu'il fait manifestement ici).
| > Mais la norme est assez floue sur le sujet, il y a bien une
| > recommendation (F.6) qui va dans ce sens, mais comme c'est une
| > recommendation on peut également s'en servir pour dire que le
| > comportement inverse est conforme !
|
| Est-ce que la norme autorise les implémentations à ne pas reconnaître
| les pragmas qu'elle définit? Si ce n'est pas autorisé, alors on n'a
| même pas besoin de cette recommandation.
si une implémentation ne comprend pas un pragma, elle l'ignore. D'où
l'utilité de la chose. <g>
| Dans l'article <ckvupk$8hp$, | Antoine Leca écrit: | | > En 20041015190901$, Vincent Lefevre va escriure: | > > J'ai toujours vu les compilateurs évaluer des choses constantes à | > > la compilation, même si la grammaire n'attend pas une expression | > > constante. | | > La raison à cela est que l'évaluation à la compilation des expressions | > constantes est une optimisation (payante et sans grand risque, sauf cas | > particuliers comme les compilateurs croisés) qui est peu difficile à | > implanter puisque la grammaire oblige de toute manière le compilateur à | > savoir réduire une expression constante, dans les cas où on attends une | > constante (taille de tableau, initialisation, etc.) | | Sauf qu'une optimisation ne devrait pas rendre quelque chose non | conforme à la norme. J'avais pris cette contraction comme une | application du 6.6. D'ailleurs on peut voir dans le K&R: "Une | /expression constante/ est une expression qui ne comporte que des | constantes." (sans faire référence à ce qu'attend la grammaire). | Je crois que ce bouquin est définitivement à jeter.
Et tu proposes un patch pour la FAQ ? ;-p
| > ÀMHA on sort de la discussion précédente : de tous temps les | > flottants ont été une bête à part. | | > En supposant que tu as utilisé FP_CONTRACT OFF... | | De toute façon, comme tu le dis plus loin, c'est ignoré: | | tst.c:6: warning: ignoring #pragma STDC FP_CONTRACT | | > Je dirais que oui. Je pense que c'est un sujet que tu devrais ouvrir | > sur la liste de gcc, et attendre l'avis de Joseph Myers... | | ... en espérant qu'ils veuillent bien corriger. J'avais vu dans | les archives une discussion à propos d'un autre bug de gcc et les | flottants (les résultats en précision étendue ne sont pas convertis | en double précision lorsqu'on fait un cast en double ou qu'on fait | une affectation), et ça m'a donné l'impression qu'ils ne voulaient | rien changer. :(
« Rien » est définitevement excessif et ne correspond pas à la réalité. De fait, il y a des projets pour améliorer l'évaluation des expressions constantes -- regarde les derniers messages de JSM sur ce sujet.
| > Pour moi, le fait que gcc ignore FP_CONTRACT OFF devrait l'obliger à | > ne jamais faire de contraction (ce qu'il fait manifestement ici). | > Mais la norme est assez floue sur le sujet, il y a bien une | > recommendation (F.6) qui va dans ce sens, mais comme c'est une | > recommendation on peut également s'en servir pour dire que le | > comportement inverse est conforme ! | | Est-ce que la norme autorise les implémentations à ne pas reconnaître | les pragmas qu'elle définit? Si ce n'est pas autorisé, alors on n'a | même pas besoin de cette recommandation.
si une implémentation ne comprend pas un pragma, elle l'ignore. D'où l'utilité de la chose. <g>
-- Gaby
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Les programmeurs qui ont besoin d'un contrôle sur la contraction des | expressions flottantes doivent de toute façon savoir ce qu'ils font; | ils préfèrent certainement une baisse de performance (probablement | pas énorme) qu'un comportement incorrect.
ça, c'est pas ici qu'il le faut le dire. C'est sûr J'ai plus ou moins perdu cette bataille ; mais si tu as de nouveaux arguments et de nouveaux faits, il serit productif que tu les envoies sur la liste mentionnée ci-dessus.
Il y a beaucoup de gens sur la liste qui pensent que l'avenir de la programmation en C, c'est dans les jeux videos et que là, ils ont plus besoin de vitesse que de résultats corrects. Ils font plus de bruit, ils les gens les entendent plus.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Les programmeurs qui ont besoin d'un contrôle sur la contraction des
| expressions flottantes doivent de toute façon savoir ce qu'ils font;
| ils préfèrent certainement une baisse de performance (probablement
| pas énorme) qu'un comportement incorrect.
ça, c'est pas ici qu'il le faut le dire. C'est sûr gcc@gcc.gnu.org.
J'ai plus ou moins perdu cette bataille ; mais si tu as de nouveaux
arguments et de nouveaux faits, il serit productif que tu les envoies
sur la liste mentionnée ci-dessus.
Il y a beaucoup de gens sur la liste qui pensent que l'avenir de la
programmation en C, c'est dans les jeux videos et que là, ils ont plus
besoin de vitesse que de résultats corrects. Ils font plus de bruit,
ils les gens les entendent plus.
| Les programmeurs qui ont besoin d'un contrôle sur la contraction des | expressions flottantes doivent de toute façon savoir ce qu'ils font; | ils préfèrent certainement une baisse de performance (probablement | pas énorme) qu'un comportement incorrect.
ça, c'est pas ici qu'il le faut le dire. C'est sûr J'ai plus ou moins perdu cette bataille ; mais si tu as de nouveaux arguments et de nouveaux faits, il serit productif que tu les envoies sur la liste mentionnée ci-dessus.
Il y a beaucoup de gens sur la liste qui pensent que l'avenir de la programmation en C, c'est dans les jeux videos et que là, ils ont plus besoin de vitesse que de résultats corrects. Ils font plus de bruit, ils les gens les entendent plus.
-- Gaby
Vincent Lefevre
Dans l'article , Gabriel Dos Reis écrit:
si une implémentation ne comprend pas un pragma, elle l'ignore. D'où l'utilité de la chose. <g>
Mais là, il s'agissait d'un pragma défini par la norme.
