2016-03-25 2 views
2

lecture d'un rapport de bogue pour clang not supporting FENV_ACCESS pragma Je suis venu à travers un comment:Est-ce que pragma FENV_ACCESS existe en C++ 11 et supérieur?

Réglage du mode d'arrondi sans utiliser un comportement non défini #pragma STDC FENV_ACCESS ON invoque. Voir C11 7.6.1/2. (Ce pragma n'existe pas en C++, donc < cfenv> est inutilisable, mais ce n'est pas notre faute ...)

Est-ce pragma existe vraiment pas en C++, ce qui rend inutilisable <cfenv>? J'ai essayé de le chercher dans la norme C++ 11, mais ce n'est vraiment pas mentionné du tout. Les pragmas sont-ils hérités de C avec les prototypes de fonctions? Ou ne sont-ils pas réellement nécessaires pour éviter l'UB, puisque le standard C++ ne dit rien sur le comportement étant indéfini quand le pragma n'est pas utilisé (du fait de ne pas mentionner le pragma du tout)?

+0

Cela va nécessiter de retrousser vos manches et écrire et soumettre un correctif pour LLVM. Sympa quand l'open source vous permet de réparer ces choses. –

+0

@HansPassant que voulez-vous dire? Comment un correctif pour LLVM peut-il résoudre un problème dans Standard? – Ruslan

Répondre

1

J'ai recherché le projet de texte standard 2015 et n'ai trouvé aucune occurrence de FENV_ACCESS. http://cppreference.com n'a rien à ce sujet.

Cependant, http://cplusplus.com mentionne (puisque ce n'est pas dans la norme, je pense que nous devons supposer que cette information est consultatif au mieux):

http://www.cplusplus.com/reference/cfenv/FENV_ACCESS/

Je cite cplusplus.com: (Souligné par l'auteur Si ce paramètre est activé, le programme informe le compilateur qu'il peut accéder à l'environnement à virgule flottante pour tester ses indicateurs d'état (exceptions) ou s'exécuter sous des modes de contrôle autres que celui par défaut. Si cette option est désactivée, le compilateur peut effectuer certaines optimisations qui peuvent subvertir ces tests et changements de mode, et accéder ainsi à l'environnement à virgule flottante dans les cas décrits ci-dessus, provoque un comportement indéfini. Si l'état de ce pragma est activé ou désactivé par défaut, cela dépend des paramètres du compilateur et de l'implémentation de la bibliothèque. Etant donné le manque de clarté troublant, je voudrais éviter son utilisation si possible.

Comme toujours, si l'utilisation était inévitable, je voudrais l'encapsuler dans une classe que je peux spécialiser et tester pour chaque architecture.

Ensuite, documentez l'existence de cette classe et les problèmes qu'elle peut provoquer si l'implémentation du compilateur, de l'environnement ou de la bibliothèque est mise à niveau.

Mise à jour:

Il y a une très brève mention de l'en-tête dans le C++ standard:

§ 26.3 L'environnement à virgule flottante [cfenv]

...

2 L'en-tête définit toutes les fonctions, tous les types et toutes les macros comme l'article 7.6 de la norme C.

Mise à jour:

Informations complémentaires ici: http://en.cppreference.com/w/cpp/preprocessor/impl

Ma lecture est que le pragma est défini par la norme C11, et non la norme C++ 11. Par conséquent, l'utilisation dans un programme C++ est strictement implémentée/non définie.

+0

[cppreference] (http://en.cppreference.com/w/cpp/preprocessor/impl) le mentionne sous les mots 'Les trois pragmas suivants sont définis par la norme de langage C'. cplusplus.com semble affirmer qu'ils fonctionnent en C++, mais cette affirmation ne semble pas fondée. – Ruslan

+0

@Ruslan peut-être une meilleure formulation serait "peut ou peut ne pas fonctionner en fonction de votre mise en œuvre"? –

+0

Est-ce que tout cela signifie que c'est un défaut de langage qui devrait être signalé et corrigé? – Ruslan