Discussion :

[dourouc05]

GCC vient de sortir sa version majeure annuelle, numérotée 6.1. Elle cumule les développements d’une année entière, avec des évolutions dans tous les domaines  : côté C++, le compilateur se positionnera sur la norme C++14 par défaut, au lieu de C++98 auparavant, quelques fonctionnalités de C++17 ont été implémentées ; pour le domaine HPC, OpenMP 4.5 est complètement implémenté, les calculs peuvent être déportés sur des coprocesseurs Intel Xeon Phi « Knights Landing » et sur du matériel AMD par HSAIL ; l’implémentation de OpenACC 2.0a a été améliorée, avec une possible déportation sur du matériel NVIDIA par PTX. Au niveau matériel, les prochains processeurs d’AMD, basés sur l’architecture Zen, sont déjà pris en charge ; les plateformes ARM ont été le théâtre de bon nombre d’améliorations ; l’architecture PowerPC a reçu la compatibilité avec POWER9, la prochaine itération des processeurs d’IBM.

Côté C++

La précédente version majeure de GCC, numérotée 5.1, apportait les dernières touches à l’implémentation de C++14, en apportant des fonctionnalités comme la désallocation d’une partie d’un tableau, des constexpr plus généraux, des fonctions anonymes génériques.

Cette nouvelle version de GCC s’arme déjà pour C++17, avec par exemple, la définition d’attributs sur les énumérateurs ou encore des expressions utilisant l’opérateur fold (aussi nommé reduce ou autre, selon les modes) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// Cette fonction somme tous ses arguments. 
template<typename... Args>
  bool f(Args... args) { 
    return (true + ... + args);
  }

Plus de détails dans la documentation

Une nouvelle optimisation en C++ casse du code existant

Une nouvelle optimisation fait parler d’elle : la propagation de valeurs considère désormais que le pointeur this en C++ (qui pointe vers l’objet courant) est toujours initialisé (sa valeur n’est jamais nullptr). Ce point particulier n’a jamais été précisé dans une norme, les compilateurs sont donc libres quant à son interprétation — même si Qt 5 ou Chromium exploitaient l’implémentation précédente. Ce cas peut arriver pour des structures, comme un arbre binaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
struct Node {
  Node * left;
  Node * right;
};

Pour traverser cet arbre en C, la manière la plus naturelle d’écrire l’algorithme est récursive. Pour traiter le cas d’une branche absente, la fonction commence par vérifier que le pointeur passé en argument est bien valide :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void in_order(Node* n) {
  if (! n) return;
  in_order(n->left);
  in_order(n->right);
}

En C++, la syntaxe est plus plaisante avec une fonction membre. Dans ce cas, l’argument de la fonction est passé de manière implicite, à travers le pointeur this :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void in_order() {
  if (this == nullptr) return;
  left->in_order();
  right->in_order();
}

Cependant, avec cette optimisation (permise par le standard C++), le premier test sera toujours faux, puisque, par hypothèse, this est toujours un pointeur valide… et ce code plantera lamentablement à l’arrivée d’une feuille. Heureusement, cette optimisation peut être désactivée avec un simple paramètre lors de la compilation (-fno-delete-null-pointer-checks) et l’absence de tel code peut aussi être vérifiée (-fsanitize=undefined).

Bien évidemment, une meilleure manière d'écrire le code vérifie directement chacun des deux pointeurs contenus dans la structure avant de continuer la récursion — ce qui évite en passant les problèmes potentiels avec cette optimisation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void in_order() {
   if (left)   left->in_order();
  if (right) right->in_order();
}

Sources : GCC 6.1 Released, GCC 6 Release Series: Changes, New Features, and Fixes, C++ Standards Support in GCC.
Ce contenu a été publié dans C++, HPC et calcul scientifique par dourouc05.

[athlon64]

pour le domaine HPC, OpenMP 4.5 est complètement implémenté, les calculs peuvent être déportés sur des coprocesseurs Intel Xeon Phi « Knights Landing » et sur du matériel AMD par HSAIL ; l’implémentation de OpenACC 2.0a a été améliorée, avec une possible déportation sur du matériel NVIDIA par PTX. Au niveau matériel, les prochains processeurs d’AMD, basés sur l’architecture Zen, sont déjà pris en charge ; .

Tout bon ça... GPGPU en force.

[foetus]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// Cette fonction somme tous ses arguments. 
template<typename... Args>
  bool f(Args... args) { 
    return (true + ... + args);
  }

Il est bizarre ce code

D'accord je veux bien que je ne sois pas à jour en C++14-17-19-22-XX et le brouillon C++11, mais:

• On fait une somme et on retourne un booléen: il est où le résultat?
• On met un true dans une addition. Il y a de fortes chances que soit le true devient une valeur (si c'est possible) soit la somme est castée en booléen.
• À moins qu'en mettant true dans l'addition on teste si l'addition des paramètres est possible. Mais il est où le résultat?

[mintho carmo]

Il est bizarre ce code

En effet. Il provient directement du draft. Juste apres ce code, il y a un autre code comme exemple faux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
template<typename... Args>
  bool f(Args... args) { 
    return (args && ... && args); // error: both operands contain unexpanded parameter packs
  }

A mon avis, c'est une erreur de frappe (Surtout que true sera traduit pas une valeur non nulle, donc la somme sera une valeur non nulle et le resultat sera non null, donc toujours true. Cela n'aurait pas grand interet). Le code correcte qu'ils voulaient (probablement) mettre est avec des && :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// Cette fonction somme tous ses arguments. 
template<typename... Args>
  bool f(Args... args) { 
    return (true && ... && args);
  }

Cf aussi http://en.cppreference.com/w/cpp/language/fold

[Michael Guilloux]

GCC 6.3 disponible
cette version du système de compilation libre se concentre sur la correction de bogues et de régressions dans GCC 6.2

Sept mois après la sortie de la version majeure annuelle, numérotée 6.1, une deuxième itération du GNU Compiler Collection (GCC) est disponible : GCC 6.3. Pour rappel, GCC est une collection de compilateurs créés par le projet GNU. Il s’agit plus exactement d’un logiciel libre capable de compiler divers langages de programmation, dont C, C++, Objective-C, Java, Ada et Fortran. Il faut également noter qu’il est utilisé pour le développement de la plupart des logiciels libres.

La version 6.1 GCC sortie en avril dernier a introduit d’importants changements et améliorations dans tous les domaines. Côté C++, le compilateur est passé sur la norme C++14 par défaut, au lieu de C++98 auparavant. On a également enregistré l’implémentation de quelques fonctionnalités de C++17. Pour le domaine HPC, OpenMP 4.5 a été complètement implémenté, alors que l’implémentation de OpenACC 2.0a a de son côté été améliorée. Au niveau matériel, GCC 6.1 a embarqué la prise en charge des processeurs AMD Zen et des améliorations pour les plateformes ARM. Il faut encore ajouter que l’architecture PowerPC a reçu la compatibilité avec POWER9, un processeur de la gamme POWER conçu et produit par IBM et annoncé pour l'année 2017.

Comme GCC 6.2 publiée en août dernier, GCC 6.3 est une version corrective pour la branche GCC 6.x. Cette nouvelle itération contient des correctifs pour des régressions et des bogues dans GCC 6.2, avec plus de 79 bogues corrigés depuis la version précédente.

Vous trouverez sur GCC Bugzilla la liste des problèmes rapportés dans le système de suivi des bogues de GCC qui ont été corrigés dans la version 6.3. Il faut toutefois préciser que cette liste peut ne pas être complète, c'est-à-dire qu'il est possible que certains problèmes qui ont été corrigés n'y soient pas répertoriés. Cette version peut être téléchargée à partir du site GNU.org.

Il faut par ailleurs préciser que tous les nouveaux développements autour de la collection de compilateurs GNU sont centrés sur la prochaine version majeure : GCC 7, qui est attendue au début de l’année prochaine.

Sources : GCC 6 Release Series

Voir aussi :

Sortie de GCC 6.1 : cette version du système de compilation libre arrive avec C++14 activé par défaut et l'implémentation complète de OpenMP 4.5
Fedora et GCC 6 montrent de mauvaises pratiques de codage, la nouvelle version du compilateur refuse maintenant des constructions douteuses
Forum GCC

[MikeRowSoft]

[...]Une nouvelle optimisation fait parler d’elle : la propagation de valeurs considère désormais que le pointeur this en C++ (qui pointe vers l’objet courant) est toujours initialisé (sa valeur n’est jamais nullptr).[...]

Il va sûrement falloir que je relise encore, mais c'est plutôt cool pour le destructeur.

[...]Il faut par ailleurs préciser que tous les nouveaux développements autour de la collection de compilateurs GNU sont centrés sur la prochaine version majeure : GCC 7, qui est attendue au début de l’année prochaine.[...]

Cool.

[frfancha]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void in_order() {
  if (this == nullptr) return;
  left->in_order();
  right->in_order();
}

Cependant, avec cette optimisation (permise par le standard C++), le premier test sera toujours faux, puisque, par hypothèse, this est toujours un pointeur valide… et ce code plantera lamentablement à l’arrivée d’une feuille.

Soit je suis très fatigué, soit l'exemple est complètement erroné: de toute façon à l'appel de la méthode (par left->in_order() par exemple) this n'est PAS null et l'élimination du test ne pose aucun problème.
Ce qui pose problème et qui fait que ce code est pourri c'est l'appel left->in_order() sans vérifier que left est null ou pas, et ça n'a rien à voir avec l'optimisation.
Non?

[laerne]

J'aurais cru qu'une fonction non-virtuelle aurait été appelée en poussant `this` sur la stack en copiant directement le pointeur utilisé pour l'appel sans vérifier si c'est nullptr, mais en codant un test compilé avec GCC6.2, ce n'est pas le cas. Donc tu as raison.…