Lapack: Autoriser une installation possible de la bibliothèque index-64 aux côtés de la bibliothèque index-32 standard ?

Salut Aisha, cela me semble tout à fait logique, mais voyons si nous avons des commentaires des autres. Attendons donc quelques jours. J

Très certainement, cela semble être un bon plan.

OMG @langou
tu es si rapide :coeur:

Juste pour être complet, j'écris les choses que nous avons encore à faire :

• Découvrez comment nommer les en-têtes afin que l'API 32 bits puisse coexister avec l'API 64 bits
• Corrigez les instructions printf/fprintf afin qu'elles utilisent le qualificateur correct pour l'impression.

Toutes les suggestions pour résoudre le premier point sont les bienvenues, je n'ai malheureusement pas de solution "propre".

Quelques questions, qui m'aideront à gérer le nommage des fichiers

• Il semble y avoir une tonne de définitions en double entre cblas_f77.h et cblas_test.h . Avons-nous vraiment besoin de ça ?
• cblas_test.h doit-il être installé ? Compte tenu de son nom (et des fichiers dans lesquels il est utilisé), je suppose qu'il ne sera utilisé que pendant la phase de test. Peut-être ne devrions-nous pas installer ce fichier au niveau du système ?

Salut @epsilon-0,

Certaines choses que j'avais en tête pour permettre à cela de coexister avec l'installation standard - nommez les bibliothèques en libblas64.so, libcblas64.so, liblapack64.so, liblapacke64.so, de cette façon il n'y a pas de conflit entre les noms de bibliothèque ( bien sûr, vous ne pouvez pas lier à la fois libblas et libblas64 en même temps).

vous cherchez peut-être le PR #218. L'auteur de ce PR est Björn Esser du projet Fedora.

Salut @epsilon-0. Le #462 a-t-il résolu ce problème ?

@weslleyspereira non, ce n'est pas encore terminé.
Il doit y avoir un peu plus de renommage/gestion des en-têtes.
Je suis occupé pour les prochaines semaines donc je ne pourrai pas le faire bientôt.
Aperçu de base

• les fichiers d'en-tête doivent être appelés cblas.h et cblas64.h , de même pour les autres en-têtes
  
  
  
  • cela signifie que les fichiers *.c auraient besoin d'un léger ajustement pour inclure l'en-tête approprié, mais ce n'est que pendant le temps de construction, il peut donc être piraté.
  
  
• les fichiers cmake doivent être installés sous lapack64 ou cblas64 , etc.

OK je vois. Merci pour le suivi rapide !

J'ai des problèmes similaires en essayant d'emballer des choses avec pkgsrc. J'aimerais avoir une installation complète de la référence, avec cblas et lapacke. Pour différentes implémentations installées en même temps, je me suis contenté de noms de bibliothèques et de sous-répertoires différents pour les en-têtes, donc par exemple

/usr/lib/libopenblas.so
/usr/lib/libopenblas64.so
/usr/lib/libblas.so
/usr/lib/libcblas.so
/usr/lib/libblas64.so
/usr/lib/libcblas64.so
/usr/include/openblas/cblas.h
/usr/include/openblas64/cblas.h
/usr/include/netlib/cblas.h
/usr/include/netlib64/cblas.h
/usr/include/cblas.h -> netlib/cblas.h (for compatibility, having the default)

(et ainsi de suite)

Nous ne considérons pas le changement d'exécution comme les distributions binaires, donc c'est OK si chaque cblas.h (et lapacke.h) est spécifique à sa bibliothèque correspondante, comme avec des noms supplémentaires pour libopenblas. La sélection du temps de construction se fait via

BLAS_INCLUDES=-I/prefix/include/netlib64
BLAS_LIBS=-lblas64
CBLAS_LIBS=-lcblas64

(etc.) C'est ce que les fichiers .pc sont censés dire, et c'est beaucoup plus facile que de communiquer un nom de fichier d'en-tête différent. Ils ne sont pas encore cohérents sur ce point, mais je suis en train de le réparer. Il semble que les gens aient juste piraté cela dans leurs distributions, même s'ils se soucient de toutes les bibliothèques de référence.

J'ai une question sur ces en-têtes, cependant.

Je pirate la version cmake pour que chaque composant soit construit séparément et j'essaie une autre correction (voir https://github.com/Reference-LAPACK/lapack/pull/556). Je reçois les bibliothèques libblas.so et libblas64.so bien construites, je fais configurer les répertoires d'en-tête… mais les cblas.h et lapacke.h installés sont identiques pour les versions d'indexation 32 et 64 bits. C'est en contradiction avec openblas : là, j'ai une différence cruciale que je ne vois pas pour les builds netlib :

diff -ruN /data/pkg/include/openblas/openblas_config.h /data/pkg/include/openblas64/openblas_config.h
--- /data/pkg/include/openblas/openblas_config.h    2021-06-03 19:03:53.000000000 +0200
+++ /data/pkg/include/openblas64/openblas_config.h  2021-06-03 19:13:36.000000000 +0200
@@ -44,6 +44,7 @@
 #define OPENBLAS_DLOCAL_BUFFER_SIZE 32768
 #define OPENBLAS_CLOCAL_BUFFER_SIZE 16384
 #define OPENBLAS_ZLOCAL_BUFFER_SIZE 12288
+#define OPENBLAS_USE64BITINT 
 #define OPENBLAS_GEMM_MULTITHREAD_THRESHOLD 4
 #define OPENBLAS_VERSION " OpenBLAS 0.3.15 "
 /*This is only for "make install" target.*/

Pour les bibliothèques de référence, tous les en-têtes des versions d'index 32 et 64 bits sont identiques et apparemment, les utilisateurs sont censés mettre
-DWeirdNEC dans leurs drapeaux (c'était peut-être drôle il y a 30 ans) pour cblas.h et -DLAPACK_ILP64 -DHAVE_LAPACK_CONFIG_H . Étant donné que les gens utilisent les bibliothèques BLAS optimisées en production, la norme de facto n'est pas de les exposer aux utilisateurs. Ceux-ci renvoient à la référence, à mon humble avis, et aux en-têtes installés à partir d'une version ILP64 ne devraient pas nécessiter d'indicateurs géniaux pour éviter de planter votre application lors de la liaison à la bibliothèque 64 bits.

Sommes-nous d'accord pour dire que c'est la bonne solution pour modifier les en-têtes au moment de la construction pour définir les bons entiers ?

Btw, les fichiers de configuration cblas qui sont installés manquent également de référence aux defs nécessaires, ils sont donc cassés pour les builds d'index 64 bits, comme il semble. Mais en fait, je pense ne pas les installer du tout. Ils sont redondants avec les fichiers .pc et rendent peut-être plus difficile de convaincre les packages dépendants utilisant cmake d'accepter un choix de packager via BLAS_LIBS etal.

PS : Avec Intel MKL, il y a un switch central -DMKL_ILP64 à régler. J'imagine la mise en place triviale
include/intel-mkl64/cblas.h avec

#ifndef MKL_ILP64
#define MKL_ILP64
#endif
#include <mkl_cblas.h>

pour s'adapter au schéma général. Je pourrais également mettre la définition dans BLAS_INCLUDES, idem pour les définitions étranges de netlib. Qu'est-ce qui est mieux? Voulons-nous le faire comme Intel ou comme OpenBLAS ?

Sommes-nous d'accord pour dire que c'est la bonne solution pour modifier les en-têtes au moment de la construction pour définir les bons entiers ?

Oui. Je suis d'accord avec cela et préfère la solution qui ne réplique pas l'intégralité de l'en-tête. Je pense que c'est plus propre.

Btw, les fichiers de configuration cblas qui sont installés manquent également de référence aux defs nécessaires, ils sont donc cassés pour les builds d'index 64 bits, comme il semble.

Droit. Je viens d'installer les bibliothèques 64 bits (BUILD_INDEX64=ON) et je n'ai rien vu me disant d'utiliser WeirdNEC , LAPACK_ILP64 ou HAVE_LAPACK_CONFIG_H . Merci de l'avoir remarqué !

Oui. Je suis d'accord avec cela et préfère la solution qui ne réplique pas l'intégralité de l'en-tête. Je pense que c'est plus propre.

C'est ambigu pour moi. Quelle est la solution la plus propre ? Ce que je prépare maintenant est tel :

#if defined(WeirdNEC) || @HAVE_ILP64@
   #define CBLAS_INDEX long
   #ifndef WeirdNEC
   #define WeirdNEC
   #endif
#else
   #define CBLAS_INDEX int
#endif

Le CMakeFile doit remplacer HAVE_ILP par 1 ou 0, l'en-tête résultant étant installé pour la version actuelle.

(Au fait : long ne fonctionnerait pas sur Windows. C'est long là-bas… ou int64_t sur toutes les plateformes avec stdint.)

Droit. Je viens d'installer les bibliothèques 64 bits (BUILD_INDEX64=ON) et je n'ai rien vu me disant d'utiliser WeirdNEC , LAPACK_ILP64 ou HAVE_LAPACK_CONFIG_H . Merci de l'avoir remarqué !

J'imagine un futur où tu fais

cc -I/foo/include/netlib64 -o bar bar.c -L/foo/lib -lcblas64

Et les choses sont gérées dans foo/include/netlib64/cblas.h, sinon par foo/include/netlib/cblas.h (éventuellement lié à foo/include/cblas.h).

J'ai le soupçon que ce n'est _pas_ ce que vous vouliez dire, mais je veux convaincre que c'est mieux ;-)

Vous pouvez essayer de ne pas dupliquer l'en-tête en plaçant 'l'en-tête' dans /foo/include/cblas.h et en faisant en sorte que /foo/include/netlib64/cblas.h inclue celui-ci uniquement en définissant WeirdNEC, mais cela signifie que le 64 Les packages bit et 32 ​​bits partagent ce fichier d'en-tête commun, ce qui est compliqué pour l'emballage. C'est bien mieux si chacun met son fichier dans des endroits/noms séparés. Le nom doit rester cblas.h car vous ne voulez pas remplacer les lignes #include <cblas.h> .

Edit: De plus, avoir cblas.h inclus ../cblas.h est désordonné en soi. Nous définissons également le répertoire d'installation de l'en-tête _one_ pour cmake. Par défaut, c'est /foo/include, pas /foo/netlib64/include. Je ne vais pas changer cette valeur par défaut. Les conditionneurs devront spécifier le sous-répertoire comme ceci (BSD make in pkgsrc) :

.if !empty(LAPACK_COMPONENT:M*64)
.  if empty(MACHINE_ARCH:M*64)
PKG_FAIL_REASON+=       "${LAPACK_COMPONENT} incompatible with non-64-bit platform"
.  endif
HEADERDIR=netlib64
.else
HEADERDIR=netlib
.endif

# Note: We patch the build to install both static and
# shared libraries.
CMAKE_ARGS=     -DBUILD_DEPRECATED=ON \
                -DBUILD_SHARED_LIBS=ON \
                -DBUILD_STATIC_LIBS=ON \
                -DCMAKE_INSTALL_INCLUDEDIR=${PREFIX}/include/${HEADERDIR} \
                ${LAPACK_COMPONENT_CMAKE_ARGS}

Un bel aspect de l'expédition / de l'installation du cblas.h 32 bits avec cette modification de l'emplacement habituel est que la mécanique d'origine fonctionne toujours. Seule la variante 64 bits appliquera WeirdNEC. Vous pouvez décider d'installer uniquement le 64 bits dans un préfixe et de ne pas toucher aux autres parties de l'écosystème.

Oh, allez… le CBLAS/cmake/cblas-config-install.cmake.in semble oublier -DCMAKE_INSTALL_INCLUDEDIR, n'est-ce pas ?

# Report lapacke header search locations.
set(CBLAS_INCLUDE_DIRS ${_CBLAS_PREFIX}/include)

(Le commentaire est du sucre sur le dessus.)

J'ai l'impression que la version CMake est beaucoup moins mature qu'on pourrait le penser. Le projet est-il sérieux d'avoir cela comme construction principale ou s'agit-il simplement d'une contribution d'entraînement ? Je suis vraiment tenté de plutôt réparer le Makefile à l'ancienne, moins de tracas tout autour. Mais j'ai maintenant passé tellement de temps à réparer les trucs CMake, que je déteste de toute façon. J'aimerais donc en finir.

Je dois abandonner maintenant… J'ai réussi à déplacer cblas.h vers cblas.h.in comme indiqué ci-dessus, et j'ai ajouté

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/cblas.h.in cblas.h @ONLY)
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/cblas_f77.h.in cblas_f77.h @ONLY)

à CBLAS/include/CMakeLists.txt, ayant également défini @HAVE_ILP64@ à 1 ou 0 dans le CMakeLists.txt de niveau supérieur. Mais pour ma vie, je ne peux pas comprendre comment faire en sorte que les éléments d'installation qui se trouvent dans un fichier CMakeLists.txt de niveau supérieur installent les en-têtes générés, ou la copie étrange de la même chose à partir de ${LAPACK_BINARY_DIR}/include (vraiment ? Un copier dans l'arborescence des sources ?)

Qu'est-ce que la macro append_subdir_files est censée faire ? Il semble ajouter une copie du préfixe aux chemins d'en-tête. Je n'ai pas assez ou trop de chemin vers les fichiers d'en-tête source. Je veux juste installer les fichiers d'en-tête d'ICI à LÀ, bon sang.

Quelqu'un de bien informé peut-il aider ici? Je suppose que je pourrais le comprendre demain, mais je ne suis pas sûr que ce soit sans briser quelque chose dans le monde réel pour un soulagement émotionnel.

Oui. Je suis d'accord avec cela et préfère la solution qui ne réplique pas l'intégralité de l'en-tête. Je pense que c'est plus propre.

C'est ambigu pour moi. Quelle est la solution la plus propre ? Ce que je prépare maintenant est tel :

#if defined(WeirdNEC) || @HAVE_ILP64@
   #define CBLAS_INDEX long
   #ifndef WeirdNEC
   #define WeirdNEC
   #endif
#else
   #define CBLAS_INDEX int
#endif

Le CMakeFile doit remplacer HAVE_ILP par 1 ou 0, l'en-tête résultant étant installé pour la version actuelle.

(Au fait : long ne fonctionnerait pas sur Windows. C'est long là-bas… ou int64_t sur toutes les plateformes avec stdint.)

Droit. Je viens d'installer les bibliothèques 64 bits (BUILD_INDEX64=ON) et je n'ai rien vu me disant d'utiliser WeirdNEC , LAPACK_ILP64 ou HAVE_LAPACK_CONFIG_H . Merci de l'avoir remarqué !

J'imagine un futur où tu fais

cc -I/foo/include/netlib64 -o bar bar.c -L/foo/lib -lcblas64

Et les choses sont gérées dans foo/include/netlib64/cblas.h, sinon par foo/include/netlib/cblas.h (éventuellement lié à foo/include/cblas.h).

J'ai le soupçon que ce n'est _pas_ ce que vous vouliez dire, mais je veux convaincre que c'est mieux ;-)

Désolé, laissez-moi vous expliquer. Au début, j'aimais l'idée de conserver l'en-tête d'origine cblas.h et de créer include/netlib64/cblas.h et include/netlib/cblas.h avec quelque chose comme

#if defined(WeirdNEC)
   #define WeirdNEC
#endif
#include <cblas.h>

Vous pouvez essayer de ne pas dupliquer l'en-tête en plaçant 'l'en-tête' dans /foo/include/cblas.h et en faisant en sorte que /foo/include/netlib64/cblas.h inclue celui-ci uniquement en définissant WeirdNEC, mais cela signifie que le 64 Les packages bit et 32 ​​bits partagent ce fichier d'en-tête commun, ce qui est compliqué pour l'emballage. C'est bien mieux si chacun met son fichier dans des endroits/noms séparés. Le nom doit rester cblas.h car vous ne voulez pas remplacer les lignes #include <cblas.h> .

Edit: De plus, avoir cblas.h inclus ../cblas.h est désordonné en soi. Nous définissons également le répertoire d'installation de l'en-tête _one_ pour cmake.

mais oui, nous devrions utiliser include/netlib64 et include dans les répertoires d'inclusion si un en-tête inclut l'autre.

Par défaut, c'est /foo/include, pas /foo/netlib64/include. Je ne vais pas changer cette valeur par défaut. Les conditionneurs devront spécifier le sous-répertoire comme ceci (BSD make in pkgsrc) :

.if !empty(LAPACK_COMPONENT:M*64)
.  if empty(MACHINE_ARCH:M*64)
PKG_FAIL_REASON+=       "${LAPACK_COMPONENT} incompatible with non-64-bit platform"
.  endif
HEADERDIR=netlib64
.else
HEADERDIR=netlib
.endif

# Note: We patch the build to install both static and
# shared libraries.
CMAKE_ARGS=     -DBUILD_DEPRECATED=ON \
                -DBUILD_SHARED_LIBS=ON \
                -DBUILD_STATIC_LIBS=ON \
                -DCMAKE_INSTALL_INCLUDEDIR=${PREFIX}/include/${HEADERDIR} \
                ${LAPACK_COMPONENT_CMAKE_ARGS}

Cela me semble bon. Ainsi, vous n'ajouteriez qu'une alternative pour compiler LAPACK sans avoir à _deviner_ les drapeaux du compilateur. Mais la méthode actuelle fonctionnerait aussi.

(Au fait : long ne fonctionnerait pas sur Windows. C'est long là-bas… ou int64_t sur toutes les plateformes avec stdint.)

Bon à savoir. BLAS++ et LAPACK++ utilisent int64_t au lieu de long long.

@weslleyspereira Donc vous avez d'abord aimé cette idée :

#if defined(WeirdNEC)
   #define WeirdNEC
#endif
#include "../cblas.h"

avec /prefix/include/cblas.h et /prefix/include/netlib64/cblas.h, ce dernier localisant le premier ? Mais êtes-vous d'accord maintenant qu'il s'agit d'une solution plus robuste pour installer un en-tête qui ressemble à ceci pour une version 64 bits ?

#if defined(WeirdNEC) || @HAVE_ILP64@
   #define CBLAS_INDEX long
   #ifndef WeirdNEC
   #define WeirdNEC
   #endif
#else
   #define CBLAS_INDEX int
#endif

(long vs. int64 est une autre affaire, mais je suis tout à fait pour faire ce changement, tout comme BLAS++)

Zut, je ne suis même pas sûr s'il est sûr de supposer que `#include ".../cblas.h" ne trouvera que l'autre en-tête indenté. La norme C semble dire que l'ordre de recherche est défini par l'implémentation, pas nécessairement par rapport à l'en-tête actuel. Mon principal problème en tant que packager est que j'aurais besoin d'un package séparé pour cet en-tête commun ou que le package 64 bits dépende du package 32 bits uniquement pour cela. Ce serait nul.

J'aimerais vraiment aller de l'avant avec un tel changement pour pkgsrc, pour régler un changement pour le code en amont plus tard. Nous pourrions discuter d'un nouveau symbole pour forcer les indices 32 bits ou 64 bits explicitement avec l'un des en-têtes ( -DNETLIB_INDEX_BITS=64 ?), en utilisant par défaut ce avec quoi la bibliothèque a été construite.

Puis-je me mettre d'accord sur la solution que nous envisageons ?

lib/libcblas64.so
include/optional_subdir64/cblas.h

et

lib/libcblas.so
include/optional_subdir/cblas.h

Chaque version du code LAPACK génère des en-têtes qui, au moins par défaut, correspondent aux bibliothèques installées sans que l'utilisateur ne définisse quoi que ce soit. D'ACCORD?

Je pourrais alors le glisser avant la prochaine version de pkgsrc (la date limite approche) et nous pourrons discuter davantage des détails de cette implémentation afin que je puisse supprimer les correctifs après avoir fusionné quelque chose ici, avec une nouvelle version de LAPACK. Avec ce changement, la version simple de Makefile doit également être corrigée, mais je n'en ai pas encore besoin pour les correctifs _my_ lorsque j'utilise simplement la version CMake.

(J'ai juste besoin de vérifier mon tempérament lorsque j'essaie de battre cette étrange construction CMake dans la soumission, où il mélange les copies d'en-tête dans les répertoires de construction et ne peut ensuite pas les trouver pour l'installation. Ou décider si ces fichiers .cmake cassés ont une utilité pour nous, peut-être qu'il suffit de les supprimer de l'installation… nous avons pkg-config !)

N'importe quoi? Je dois admettre que je ne vois pas beaucoup de chance pour une solution différente dans la pratique, car c'est l'exemple donné par openblas, la principale implémentation que nous utilisons. Je peux imaginer convaincre Intel d'avoir également un sous-répertoire pour les en-têtes d'index 64 bits/32 bits, recouvrant leurs mkl_cblas.h et mkl_lapacke.h. Sinon, je construis un package simple qui ne fournit que ceux-ci.

include/mkl-blas/cblas.h
include/mkl-blas64/cblas.h

Actuellement, j'ai ajouté des machines à pkgsrc pour fournir des builds avec la drôle de ligne -DWeirdNEC -DHAVE_LAPACK_CONFIG_H -DLAPACK_ILP64 , avec cblas et cblas64 installant des en-têtes identiques. Cela pourrait rester ainsi, mais je pense toujours qu'il est logique que l'en-tête soit configuré pour correspondre à l'ABI de construction.

@weslleyspereira Donc vous avez d'abord aimé cette idée :

#if defined(WeirdNEC)
   #define WeirdNEC
#endif
#include "../cblas.h"

avec /prefix/include/cblas.h et /prefix/include/netlib64/cblas.h, ce dernier localisant le premier ? Mais êtes-vous d'accord maintenant qu'il s'agit d'une solution plus robuste pour installer un en-tête qui ressemble à ceci pour une version 64 bits ?

#if defined(WeirdNEC) || @HAVE_ILP64@
   #define CBLAS_INDEX long
   #ifndef WeirdNEC
   #define WeirdNEC
   #endif
#else
   #define CBLAS_INDEX int
#endif

Oui c'est ça. Je suis d'accord avec votre solution d'avoir des sous-dossiers pour les en-têtes 32 et 64 bits. J'en ai discuté avec @langou , et il était également convaincu que ce serait une bonne solution.

(long vs. int64 est une autre affaire, mais je suis tout à fait pour faire ce changement, tout comme BLAS++)

Droit. Cela devrait être traité dans un autre numéro.

J'aimerais vraiment aller de l'avant avec un tel changement pour pkgsrc, pour régler un changement pour le code en amont plus tard. Nous pourrions discuter d'un nouveau symbole pour forcer les indices 32 bits ou 64 bits explicitement avec l'un des en-têtes ( -DNETLIB_INDEX_BITS=64 ?), en utilisant par défaut ce avec quoi la bibliothèque a été construite.

Puis-je me mettre d'accord sur la solution que nous envisageons ?

lib/libcblas64.so
include/optional_subdir64/cblas.h

et

lib/libcblas.so
include/optional_subdir/cblas.h

Oui. Je pense que vous pouvez aller de l'avant et proposer un PR à l'avenir, merci ! Personnellement, je pense qu'un nouveau symbole comme NETLIB_INDEX_BITS est tout à fait logique. Je voudrais juste m'assurer que la valeur par défaut reste 32, et que -DWeirdNEC implique -DNETLIB_INDEX_BITS=64 .

Chaque version du code LAPACK génère des en-têtes qui, au moins par défaut, correspondent aux bibliothèques installées sans que l'utilisateur ne définisse quoi que ce soit. D'ACCORD?

Cela me semble bien.

Je pourrais alors le glisser avant la prochaine version de pkgsrc (la date limite approche) et nous pourrons discuter davantage des détails de cette implémentation afin que je puisse supprimer les correctifs après avoir fusionné quelque chose ici, avec une nouvelle version de LAPACK. Avec ce changement, la version simple de Makefile doit également être corrigée, mais je n'en ai pas encore besoin pour les correctifs _my_ lorsque j'utilise simplement la version CMake.

D'accord! Nous aurons probablement une version LAPACK au deuxième semestre 2021. Et oui, le Makefile devrait être ajusté en conséquence, et je suis prêt à vous aider.

C'est un peu lié. Il ne faut pas oublier que les en-têtes pour netlib CBLAS ne sont pas uniquement fournis par netlib… NumPy utilise toujours son propre en-tête :

https://github.com/numpy/numpy/blob/main/numpy/core/src/common/npy_cblas.h

Et dans cet en-tête, il définit CBLAS_INDEX=size_t , différent du type entier utilisé pour spécifier les indices. Il est utilisé uniquement pour les valeurs de retour de certaines fonctions :

$ grep CBLAS_INDEX ./numpy/core/src/common/npy_cblas_base.h                                                                                                                                  
CBLAS_INDEX BLASNAME(cblas_isamax)(const BLASINT N, const float  *X, const BLASINT incX);
CBLAS_INDEX BLASNAME(cblas_idamax)(const BLASINT N, const double *X, const BLASINT incX);
CBLAS_INDEX BLASNAME(cblas_icamax)(const BLASINT N, const void   *X, const BLASINT incX);
CBLAS_INDEX BLASNAME(cblas_izamax)(const BLASINT N, const void   *X, const BLASINT incX);

La différence:

$ grep cblas_isamax ./numpy/core/src/common/npy_cblas_base.h  /data/pkg/include/cblas.h                                                                                                      
./numpy/core/src/common/npy_cblas_base.h:CBLAS_INDEX BLASNAME(cblas_isamax)(const BLASINT N, const float  *X, const BLASINT incX);
/data/pkg/include/cblas.h:CBLAS_INDEX cblas_isamax(const CBLAS_INDEX N, const float  *X, const CBLAS_INDEX incX);

Je me demande si cela peut causer des problèmes. Pour Netlib, il n'y a qu'un seul type d'index, tandis que d'autres implémentations utilisent un type de valeur de retour différent pour les fonctions d'index. OpenBLAS donne l'exemple. Ils disent qu'isamax renvoie size_t non signé, mais le wrapper C appelle en fait une fonction Fortran qui renvoie un entier signé systèmes de bits).

L'implémentation de référence a-t-elle un avis à ce sujet ? Je _devine_ qu'il n'y a pas vraiment de problème, car une valeur size_t pourra toujours contenir tout retour non négatif d'isamax(). Mais ça sent mauvais. (Edit : vous pouvez construire avec des index 64 bits sur un système 32 bits où size_t est de 32 bits, non ? Ensuite, vous avez un débordement. En plus de la difficulté de convertir size_t * en int * .)

Étant donné que les implémentations optimisées semblent avoir décidé de size_t là-bas, la référence devrait-elle accepter ce fait et suivre ?

Et à quel point est-il dangereux, en fait, de lier numpy avec la référence cblas ?

OpenBLAS donne l'exemple. (...)
Étant donné que les implémentations optimisées semblent avoir décidé de size_t là-bas, la référence devrait-elle accepter ce fait et suivre ?

Je ne peux certainement pas parler pour numpy (ou mkl, etc. d'ailleurs), mais j'hésiterais à prétendre qu'OpenBLAS est normatif sous quelque forme que ce soit, encore moins par rapport à ce qui est (je crois) généralement considéré comme __the__ implémentation de référence .. .

Sûr. C'est juste que les gens utilisent OpenBLAS ou MKL dans la pratique et les deux semblent s'être installés sur

#define CBLAS_INDEX size_t  /* this may vary between platforms */
#ifdef MKL_ILP64
#define MKL_INT MKL_INT64
#else
#define MKL_INT int
#endif
CBLAS_INDEX cblas_isamax(const MKL_INT N, const float  *X, const MKL_INT incX);

ou similaire

#ifdef OPENBLAS_USE64BITINT
typedef BLASLONG blasint;
#else
typedef int blasint;
#endif
#define CBLAS_INDEX size_t
CBLAS_INDEX cblas_isamax(OPENBLAS_CONST blasint n, OPENBLAS_CONST float  *x, OPENBLAS_CONST blasint incx);

vs la référence

#ifdef WeirdNEC
   #define CBLAS_INDEX long
#else
   #define CBLAS_INDEX int
#endif
CBLAS_INDEX cblas_isamax(const CBLAS_INDEX N, const float  *X, const CBLAS_INDEX incX);

Comment se fait-il qu'ils s'écartent de la référence ici ? Y a-t-il eu une communication à ce sujet ? Aussi… je vois MKL et OpenBLAS définir une foule de fonctions qui ne font même pas partie de la référence CBLAS :

CBLAS_INDEX cblas_isamin(const MKL_INT N, const float  *X, const MKL_INT incX);
CBLAS_INDEX cblas_idamin(const MKL_INT N, const double *X, const MKL_INT incX);
CBLAS_INDEX cblas_icamin(const MKL_INT N, const void   *X, const MKL_INT incX);
CBLAS_INDEX cblas_izamin(const MKL_INT N, const void   *X, const MKL_INT incX);

CBLAS_INDEX cblas_isamin(OPENBLAS_CONST blasint n, OPENBLAS_CONST float  *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_idamin(OPENBLAS_CONST blasint n, OPENBLAS_CONST double *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_icamin(OPENBLAS_CONST blasint n, OPENBLAS_CONST void  *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_izamin(OPENBLAS_CONST blasint n, OPENBLAS_CONST void *x, OPENBLAS_CONST blasint incx);

CBLAS_INDEX cblas_ismax(OPENBLAS_CONST blasint n, OPENBLAS_CONST float  *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_idmax(OPENBLAS_CONST blasint n, OPENBLAS_CONST double *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_icmax(OPENBLAS_CONST blasint n, OPENBLAS_CONST void  *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_izmax(OPENBLAS_CONST blasint n, OPENBLAS_CONST void *x, OPENBLAS_CONST blasint incx);

CBLAS_INDEX cblas_ismin(OPENBLAS_CONST blasint n, OPENBLAS_CONST float  *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_idmin(OPENBLAS_CONST blasint n, OPENBLAS_CONST double *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_icmin(OPENBLAS_CONST blasint n, OPENBLAS_CONST void  *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_izmin(OPENBLAS_CONST blasint n, OPENBLAS_CONST void *x, OPENBLAS_CONST blasint incx);

Donc, étendre la norme est une chose, mais size_t vs int semble être un problème sérieux sur les systèmes 64 bits. Cela devrait être réglé d'une manière ou d'une autre. Il me semble que la méthode Netlib est sensée : Même type que celui qui est utilisé pour les index. Comme tous appellent des routines Fortran comme celle-ci à la fin

c     isamaxsub.f
c
c     The program is a fortran wrapper for isamax.
c     Witten by Keita Teranishi.  2/11/1998
c
      subroutine isamaxsub(n,x,incx,iamax)
c
      external isamax
      integer  isamax,iamax
      integer n,incx
      real x(*)
c
      iamax=isamax(n,x,incx)
      return
      end

… remettre une adresse de size_t pour iamax, cela semble tout simplement faux. Je n'ai pas trouvé d'autre implémentation que celle de référence dans les sources OpenBLAS. Sont-ils juste stupides de changer le type externe comme ça ou est-ce que je néglige quelque chose de très basique ? Est-ce que quelqu'un utilise réellement ces fonctions ?

Salut à tous, Référence BLAS, référence CBLAS, référence LAPACK, deux des axes principaux de ces projets sont (1) les algorithmes numériques et (2) la définition d'interfaces communes, une implémentation de référence et une suite de tests qui va de pair. Je pense que toutes les personnes impliquées dans ces projets sont heureuses de regarder et d'apprendre d'autres projets (OpenBLAS, MKL, etc.) sur l'ingénierie logicielle, les meilleures pratiques pour déployer le logiciel, etc. Nous avons beaucoup à apprendre de ces projets. (Et nous apprenons aussi beaucoup d'autres projets d'algèbre linéaire numérique !) Quoi qu'il en soit : la référence BLAS, CBLAS, LAPACK peut utiliser certaines améliorations dans son emballage CMake, ses interfaces, et si OpenBLAS (par exemple) a un meilleur processus, c'est bien adapté pour nous, eh bien, je suis tout à fait favorable à l'évolution vers ce modèle.

Pour ajouter un peu de contexte, le CBLAS est né d'un comité (le Forum technique des sous-programmes d'algèbre linéaire de base) qui a travaillé de 1996 à 2000 sur la révision du BLAS, dans le cadre de laquelle ils ont défini une interface C pour le BLAS. Voir:
http://www.netlib.org/blas/blast-forum/
Voir notamment :
http://www.netlib.org/blas/blast-forum/cinterface.pdf
Je pense que le CBLAS proposé par LAPACK est une implémentation de l'interface telle que définie par le Forum technique des sous-programmes d'algèbre linéaire de base il y a 25 ans.

S'il y a des suggestions pour améliorer CBLAS, envoyez-les. Je peux essayer de transmettre cela aux différentes parties prenantes.

Merci pour le pointeur. La partie pertinente semble donc être B.2.2 dans cette spécification, qui dit que BLAS_INDEX est généralement size_t , mais peut également être choisi pour être identique au type entier Fortran (signé) utilisé pour indexage. C'est à la mise en œuvre.

Il semble donc que les implémentations optimisées populaires aient choisi size_t et que la référence Netlib ait choisi le même entier qu'elle utilise pour Fortran. Je vois des copies de cblas.h partout dans divers projets qui utilisent la lib (comme numpy, envoyant un en-tête pour une lib externe), avec cette ligne

#define CBLAS_INDEX size_t  /* this may vary between platforms */

Dans https://github.com/LuaDist/gsl/blob/master/cblas/gsl_cblas.h , cela est accompagné de

/* This is a copy of the CBLAS standard header.
 * We carry this around so we do not have to
 * break our model for flexible BLAS functionality.
 */

Cela semble provenir de l'implémentation de référence, mais a-t-il changé depuis ? En regardant 41779680d1f233928b67f5f66c0b239aecb42774 … je vois que le commutateur CBLAS_INDEX avec WeirdNEC était là avant la version 64 bits. Wow, ce commit est-il récent. Maintenant, je vois que size_t était dans la référence cblas.h jusqu'en 2015, 83fc0b48afd1f9a6d6f8dddb16e69ed7ed0e7242 l'ayant modifié et introduit la définition WeirdNEC. Je n'imaginais pas que ce soit si récent ! Sauvagement déroutant.

Je vois aussi que la version précédente de cblas.h a remis un int à l'appel fortran, maintenant CBLAS_INDEX . Cela semble être correct maintenant, avec une utilisation cohérente de CBLAS_INDEX comme type entier et le commutateur pour 32 ou 64 bits dans la partie Fortran.

Mais se pourrait-il que les bibliothèques optimisées qui ont hérité d'une ancienne version de cblas.h avec size_t mais qui synchronisent les sources avec le code CBLAS actuel de la référence aient un joli bug ? Ne font-ils pas quelque chose comme ça pour le cas 32 bits sur un système 64 bits ?

#include <stdio.h>
#include <stdlib.h>


void ia_max(int a, void *b)
{
    int *ib = (int*)b;
    *ib = a*2;
}


int main(int argc, char **argv)
{
    int i = atoi(argv[1]);
    size_t maxi;
    ia_max(i, &maxi);
    printf("in %d out %ld\n", i, (long)maxi);
    return 0;
}

Cela se traduit par

$ gcc -O -o t t.c
$ ./t 42
in 42 out 140724603453524

L'initialisation de la size_t à zéro aide, mais probablement uniquement dans le cas du petit boutien. Personne n'a d'ennuis pour ça ? Je dois manquer quelque chose.

De conclure:

1. La référence CBLAS avait le size_t comme valeur de retour en premier.
2. Il a utilisé int dans l'appel réel à Fortran, cependant.
3. En aval (utilisateurs BLAS optimisés, CBLAS) s'exécutent avec l'ancienne version de l'en-tête.
4. La référence CBLAS introduit le hack WeirdNEC pour un système spécifique, remplaçant size_t par int ou long (correspondant au côté Fortran ?!)
5. L'interface CBLAS de référence 64 bits est construite par-dessus, en utilisant CBLAS_INDEX partout pour l'entier par défaut Fortran.
6. Les avals ont fait leur propre chose avec le support 64 bits, mais en le séparant de CBLAS_INDEX , qui est toujours size_t.
7. Les avals héritent des wrappers CBLAS qui utilisent CBLAS_INDEX pour appeler Fortran qui attend l'entier par défaut.

Cela ressemble à une merveilleuse casse en conséquence. Les en-têtes et le code ont divergé. Comment se fait-il que personne n'ait encore remarqué de problèmes ? Ou ai-je raté la partie où le code d'emballage de référence CBLAS pour isamax et ses amis n'est pas réellement utilisé ?

OpenBLAS au moins n'utilise pas le code wrapper CBLAS de Reference-LAPACK (et ne l'a jamais fait, la source est là mais n'est pas construite)

@martin-frbg Bon à savoir. Pouvez-vous indiquer un chemin de code pour, disons, x86-64 qui montre comment le size_t est transmis au calcul réel pour cblas_isamax() ? J'ai trouvé une implémentation spécifique du noyau mais je ne suis pas sûr du cas général.

Il serait bon de savoir que personne ne passe réellement un (size_t*) à l'interface Fortran.

C'est sûr que ce n'est pas bien que les projets supposent juste

size_t cblas_isamax(…)

lorsque la bibliothèque réelle peut offrir un int ou long (ou int64_t) comme valeur de retour. Peut fonctionner la plupart du temps avec des valeurs dans des registres 64 bits, mais ce n'est pas agréable. Pouvons-nous rectifier cela dans les implémentations ? Les gens n'ont pas repris l'exemple de Netlib au cours des 5 dernières années à propos de l'utilisation constante de CBLAS_INDEX .

le code pertinent se trouve dans OpenBLAS/interface, par exemple interface/imax.c est compilé en cblas_isamax() lorsque CBLAS est défini, aucun code Fortran n'est impliqué dans son graphe d'appels.

Ah bien. Ainsi, le seul cas qui pose problème est celui des projets dépendants utilisant une copie de cblas.h qui ne correspond pas à la bibliothèque.

Je ne trouve pas d'utilisation réelle de cblas_isamax() et d'amis dans NumPy (et SciPy), donc ce n'est peut-être qu'un problème théorique. Il devrait être corrigé quand même. Donc:

1. D'autres suivent l'exemple de Netlib en utilisant int32_t/int64_t (soyons explicites ;-) BLAS_INDEX pour les retours de taille et les arguments d'index.
2. Netlib s'effondre et revient à size_t pour ces retours comme les autres.

Est-ce une question distincte à discuter ? Cela concerne cependant le choix d'une bibliothèque 32 ou 64 bits.

PS: je ne sais toujours pas si les énumérations dans l'API sont une bonne idée (en tant que type de données réel pour les arguments de fonction et les membres de structure), car il existe des options de compilateur pour modifier l'entier utilisé en dessous. Pas si pertinent dans la pratique, mais me met quand même mal à l'aise.

Plus j'y pense, plus je penche pour l'option 2 : Nous avions size_t dans l'API depuis très longtemps. Ensuite, Netlib a changé ce size_t en int ou long. Indépendamment de ce qui correspond le mieux au code Fortran ou pourrait être plus cohérent, l'API size_t a été établie et la référence Netlib a cassé cela.

Dois-je ouvrir un PR pour changer les choses pour

size_t cblas_isamax(const CBLAS_INDEX N, const float  *X, const CBLAS_INDEX incX);
size_t cblas_idamax(const CBLAS_INDEX N, const double *X, const CBLAS_INDEX incX);
size_t cblas_icamax(const CBLAS_INDEX N, const void   *X, const CBLAS_INDEX incX);
size_t cblas_izamax(const CBLAS_INDEX N, const void   *X, const CBLAS_INDEX incX);

de nouveau? Il ne devrait plus y avoir de macro à cette position pour souligner que c'est toujours size_t, partout, passé et futur.

Dans https://github.com/numpy/numpy/issues/19243, nous en sommes maintenant essentiellement arrivés à : « Screw Netlib, size_t fonctionne pour tout le monde ».

Il y a trois raisons d'utiliser size_t :

1. Toutes les fonctions de bibliothèque standard C et C++ acceptent et renvoient cette valeur, par exemple, void* malloc(size_t) , size_t strlen() ou std::size_t std::vector<T>::size() (C++). L'utilisation de size_t évite de tronquer les valeurs et les conversions signées/non signées.
2. size_t est souvent utilisé pour exprimer des quantités qui ne peuvent pas être négatives, par exemple des dimensions matricielles.
3. Les standards C et C++ garantissent que vous pouvez stocker la taille de n'importe quel tableau dans un size_t et que vous pouvez indexer tous les éléments avec size_t , cf. cppference.com : size_t .

Edit : Vous pouvez construire avec des index 64 bits sur un système 32 bits où size_t est de 32 bits, n'est-ce pas ? Ensuite, vous avez un débordement.

Non car un système 32 bits peut avoir plus de 4 Go de mémoire virtuelle (Linux le supporte) mais un seul processus 32 bits ne peut jamais accéder à plus de 4 Go. C'est-à-dire que les 32 bits supérieurs des index 64 bits ne sont jamais utilisés.

_Limite de mémoire à un processus 32 bits s'exécutant sur un système d'exploitation Linux 64 bits_

Je pense également que garder size_t est la bonne chose à faire, car le changement a été la rupture ABI et a désynchronisé Netlib avec le reste du monde.

Mais je me sens obligé de pinailler sur vos arguments ;-)

1. All of the C and C++ standard library functions accept and return this value

Lorsque j'ai fait des recherches à ce sujet, je suis tombé sur l'aveu que c'était une erreur historique d'utiliser un type non signé pour les index de conteneur C++, et probablement même le type de retour de la méthode size(), car vous finissez rapidement par mélanger des nombres signés et non signés dans d'une certaine manière. L'état actuel de Netlib serait cohérent avec lui-même, utilisant toujours des types signés pour la taille et les indices, mais bien sûr incohérent avec malloc() , qui nécessite une taille non signée pour pouvoir réellement adresser toute la mémoire qui tient dans 32 bits (ou 64 bits, en théorie).

Je me demande bien à ce sujet dans le code que j'ai écrit où j'ai finalement remis un index comme décalage à un appel de fonction. L'index est non signé, l'offset signé. En dehors des compilateurs (MSVC) confondus par -unsigned_value , cela signifierait que je dois toujours m'inquiéter d'un éventuel débordement lors de la conversion.

Mais de toute façon, s'il ne s'agit que de calculer les tailles de mémoire à remettre à malloc() et à ses amis, size_t est la chose naturelle, et cela a déjà été là dans CBLAS.

Sur les problèmes possibles avec l'état actuel du code, non-concordance avec les cblas.h vendeur dans les builds :

Non car un système 32 bits peut avoir plus de 4 Go de mémoire virtuelle (Linux le supporte) mais un seul processus 32 bits ne peut jamais accéder à plus de 4 Go. C'est-à-dire que les 32 bits supérieurs des index 64 bits ne sont jamais utilisés.

Bon, size_t reste 32 bits. Lorsque vous (aussi idiot que cela puisse être) construit cblas_isamax() pour renvoyer un entier de 64 bits, après avoir piraté la compilation pour ne pas utiliser long , mais int64_t , bien sûr, qu'est-ce qui va vraiment arriver dans une telle utilisation?

size_t cblas_isamax(); // really int64_t cblas_isamax()!
size_t value = cblas_isamax(…);

La convention d'appel x86 peut mettre la valeur 64 bits dans EAX et EDX. Ou cela pourrait fonctionner avec un retour de pointeur et un tampon. Mais que feraient les autres architectures ? Donc, vous n'obtiendrez peut-être pas de corruption, mais à coup sûr une mauvaise valeur. Dans le meilleur des cas, les 32 bits supérieurs sont ignorés.

Imaginez maintenant un système 32 bits big-endian (une certaine forme d'ARM)… vous obtiendrez même la moitié souhaitée de la valeur renvoyée ?

Vous ne pouvez pas vraiment travailler avec des données non éparses qui nécessitent des index 64 bits dans le programme 32 bits, bien sûr. Mais le simple fait de pouvoir faire un appel de fonction non correspondant qui _au_moins_ donne des résultats erronés semble malsain.

J'ai fait quelques tests rapides… sur Linux x86 ( gcc -m32 sur un système x86-64), il suffit de supprimer les 32 bits supérieurs.

Le cas le plus intéressant … 64 bits size_t :

size_t cblas_isamax(); // really int32_t cblas_isamax()!
size_t value = cblas_isamax(…);

Encore une fois, sur x86-64, la relation particulière entre RAX 64 bits et EAX 32 bits rend les choses quelque peu bien définies pour également mettre à zéro silencieusement les 32 bits supérieurs une fois que vous effectuez une opération 32 bits sur le registre partagé. Mais il y a du plaisir à avoir avec une définition de fonction un peu bizarre :

$ cat ret32.c 
#include <stdint.h>

int32_t ret64(int64_t a)
{
    a += 1LL<<32;
    return a;
}
$ gcc -m64  -g -c -o ret32.o ret32.c 
$ LANG=C objdump -S ret32.o 
[…]
   8:   48 89 7d f8             mov    %rdi,-0x8(%rbp)
    a += 1LL<<32;
   c:   48 b8 00 00 00 00 01    movabs $0x100000000,%rax
  13:   00 00 00 
  16:   48 01 45 f8             add    %rax,-0x8(%rbp)
    return a;
  1a:   48 8b 45 f8             mov    -0x8(%rbp),%rax

Vous pourriez discuter s'il est intelligent pour le compilateur de travailler sur le registre 64 bits complet et de laisser les 32 bits supérieurs non effacés pour une fonction qui devrait renvoyer une valeur de 32 bits, mais c'est parfaitement légal si vous comptez uniquement sur l'appelant en utilisant les 32 bits inférieurs, je suppose.

$ cat call.c 
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

INDEX ret64(int64_t);

int main(int argc, char **argv)
{
    if(argc < 2)
        return 1;
    int64_t a = (int64_t)strtoll(argv[1], NULL, 10);
    INDEX  s = ret64(a);
    printf("%lld\n", (long long)s);
    return 0;
}
$ gcc -m64 -g -DINDEX=int32_t -c -o call32_64.o call.c
$ gcc -m64 -g -DINDEX=size_t -c -o call64_64.o call.c
$ ./call32_64 1
1
$ ./call64_64 1
4294967297

Amusant. Une valeur de retour 32 bits qui donne plus que ce qui est possible en 32 bits. C'est ce qui peut arriver (en principe) avec l'état actuel de Netlib CBLAS lié à du code qui attend size_t. Je suppose cependant que les 32 bits supérieurs de RAX seront zéro dans le code réel en pratique. Mais qui sait… le compilateur s'attend à ce que l'appelant n'utilise pas plus que les 32 bits inférieurs sur n'importe quelle plate-forme… pourrait aussi bien y stocker des déchets.

Alors… sommes-nous d'accord pour ramener Netlib à size_t comme valeur de retour ?

Merci pour tous ces précieux commentaires !

J'ai discuté un peu de ce sujet avec @langou. Sur la base de la discussion ici, ma proposition est:

Dans un PR séparé :

1. Nous revenons à un cblas.h qui utilise deux définitions entières, disons CBLAS_INDEX et CBLAS_INT. C'est ce qui se passe dans MKL (CBLAS_INDEX et MKL_INT) et OpenBLAS (CBLAS_INDEX et blasint). CBLAS_INDEX ne sera utilisé que dans le retour de i*amax . Avec cela, nous restaurons une ABI compatible avec les autres BLAS.
2. De plus, nous choisissons la valeur par défaut de CBLAS_INDEX pour être size_t et collectons les opinions de la communauté.

Je pense que c'est aligné (ou peut-être la même) idée derrière les récentes discussions dans ce fil.
Comme @drhpc l'a souligné,
https://github.com/Reference-LAPACK/lapack/commit/83fc0b48afd1f9a6d6f8dddb16e69ed7ed0e7242 a changé la valeur par défaut de CBLAS_INDEX, et
https://github.com/Reference-LAPACK/lapack/commit/41779680d1f233928b67f5f66c0b239aecb42774 a modifié l'utilisation de CBLAS_INDEX.

Juste pour renforcer :

• OpenBLAS, MKL, GNU Scientific Library et Numpy utilisent tous size_t par défaut.
• L'interface C pour BLAS (https://www.netlib.org/blas/blast-forum/cinterface.pdf) indique que, généralement, CBLAS_INDEX = size_t .

Êtes-vous d'accord? Si vous le faites, je peux ouvrir le PR. Ou peut-être que @drhpc aimerait le faire.

Je suis d'accord. Et s'il vous plaît, continuez avec le PR.

@mgates3 m'a mentionné la discussion sur le groupe Google Slate :
https://groups.google.com/a/icl.utk.edu/g/slate-user/c/f5y6gt0aoLs/m/oQyyhikwCgAJ
La discussion ne porte pas sur ce que devrait être « CBLAS_INDEX », mais plutôt sur ce que devrait être « CBLAS_INT ». CBLAS_INT doit-il être size_t ou un entier signé ou etc. ? Je pense que les participants font de bons points, donc je passe.

S'il vous plaît, voir #588.

Bon, size_t reste 32 bits. Lorsque vous (aussi idiot que cela puisse être) construit cblas_isamax() pour retourner un entier 64 bits, après avoir piraté la construction pour ne pas utiliser long , mais int64_t , bien sûr, qu'est-ce qui va vraiment arriver dans une telle utilisation?

size_t cblas_isamax(); // really int64_t cblas_isamax()!
size_t value = cblas_isamax(…);

La convention d'appel x86 peut mettre la valeur 64 bits dans EAX et EDX. Ou cela pourrait fonctionner avec un retour de pointeur et un tampon. Mais que feraient les autres architectures ? Donc, vous n'obtiendrez peut-être pas de corruption, mais à coup sûr une mauvaise valeur. Dans le meilleur des cas, les 32 bits supérieurs sont ignorés.

Imaginez maintenant un système 32 bits big-endian (une certaine forme d'ARM)… vous obtiendrez même la moitié souhaitée de la valeur renvoyée ?

C'est la fin du jeu. Sur les processeurs Arm 32 bits, quatre valeurs 32 bits peuvent être transmises et renvoyées dans des registres, les valeurs 64 bits occupent deux registres consécutifs, voir Section 6.1.1.1 dans _Procedure Call Standard for the Arm Architecture_ . Au lieu d'écrire dans un registre, l'appelé encombrera deux registres avec ses entiers de 64 bits ; c'est évidemment un problème. Dès que l'appelant n'a plus de registres pour les paramètres, la pile est utilisée. L'alignement de la pile est de 32 bits mais au lieu de lire ou d'écrire sur 32 bits, l'appelé écrit sur 64 bits ; encore une fois, c'est la fin du jeu et ce problème (inadéquation des tailles de lecture/écriture de la pile) devrait causer des problèmes sur toutes les architectures de jeux d'instructions à un moment donné.

• Armer la documentation ABI

Je me demande bien à ce sujet dans le code que j'ai écrit où j'ai finalement remis un index comme décalage à un appel de fonction. L'index est non signé, l'offset signé. En dehors des compilateurs (MSVC) confondus par -unsigned_value, cela signifierait que je dois toujours m'inquiéter d'un éventuel débordement lors de la conversion.

Non, les comités standard derrière C et C++ font que votre code se comporte de la manière évidente dans ce cas : si u est une valeur non signée et s est une valeur signée, où u a au moins autant de bits que s , alors u + s donnera le résultat mathématiquement correct à moins que u + s déborde ou déborde. S'il déborde/dépasse, le résultat s'enroulera, c'est-à-dire (u + s) mod 2^b , où b est le nombre de bits dans u et s . D'un autre côté, si le type signé peut représenter toutes les valeurs du type non signé, alors la valeur non signée sera convertie en type non signé.

Les clauses pertinentes du projet de norme C11 sont les suivantes :

• 6.2.5.9 : Les opérations binaires avec uniquement des opérandes non signés ne peuvent pas déborder ; le résultat est pris modulo MAX + 1 , où MAX est la plus grande valeur représentable.
• 6.3.1.3 : Étant donné une valeur signée s , elle est convertie en la valeur non signée s si s >= 0 , sinon elle est convertie en s + MAX + 1 .
• 6.3.1.8 : Les opérandes signés et non signés [de même taille] sont convertis en non signés ; un opérande non signé est converti en un type signé si le type signé peut représenter toutes les valeurs du type non signé

Par conséquent, u + s (syntaxe C) sera évalué à

• (u + s) mod (M + 1) si s >= 0 ,
• (u + s + M + 1) mod (M + 1) sinon.

En l'absence de dépassement ou de dépassement, cette expression sera évaluée à u + s qui est le résultat intuitivement souhaité.

Lorsque j'ai fait des recherches à ce sujet, je suis tombé sur l'aveu que c'était une erreur historique d'utiliser un type non signé pour les index de conteneur C++, et probablement même le type de retour de la méthode size(), car vous finissez rapidement par mélanger des nombres signés et non signés dans d'une certaine manière.

Il y a des programmeurs C++ (y compris l'inventeur du C++) qui proposent d'utiliser des entiers signés partout, voir les C++ Core Guidelines mais je n'appellerais pas cela un aveu. Le problème avec la politique « entiers signés partout » est

• vérification des valeurs minimales : avec un entier non signé, il est dans de nombreux cas superflu de vérifier la valeur minimale, avec un entier signé, c'est obligatoire ; ceci est sujet aux erreurs et peut causer des problèmes de sécurité, voir par exemple CWE-839 _Comparaison de plage numérique sans contrôle minimum_ .
• débordements : un débordement non signé a un résultat bien défini alors qu'un débordement d'entier signé constitue un comportement indéfini.

Vous pouvez essayer de vérifier un débordement signé avec l'expression a + b < a mais le compilateur peut l'optimiser sans avertissement, voir par exemple le bogue GCC 30475 _assert(int+100 > int) optimisé away_ à partir de 2007. Cela fonctionnerait avec des entiers non signés ( a non signé, b éventuellement signé et b ayant au plus autant de bits que a ). En voyant l'article _OptOut - Compiler Undefined Behavior Optimizations_ de 2020, le comportement de GCC n'a apparemment pas changé.