Je pense que l'amgiuité viens de la manière d'interpréter "remplacer".
L'objectif de clang++llvm me semble quand même de faire un compilateur C et dérivés au moins aussi bon que gcc et même meilleur grâce à toutes les possibilités offertes par llvm.
Par contre, l'objectif, et c'est relativement clair dans les propos des dévellopeurs, n'est pas de faire un remplacant direct de gcc, dans le sens un compilateur qui accepte les mêmes sources et donne les même binnaires.
Un programme écrit en respectant les standards devrait être accepté par les deux sans problèmes, mais tout ce qui touche aux extentions des standards ne sera pas forcément géré de la même manière.
Les extentions spécifiques à gcc ne seront pas forcément gérées de la même manière.
L'objectif de clang est quand même de faire un compilateur propre en partant sur des bases saines. Dans ce cadre, il y a des choses relativement dégueulasse faites par gcc qui ne peuvent pas être supportées.
Donc ici, il faut clairement prendre "remplacant" comme "alternative", c'est-à-dire un compilateur aussi bon (voir meilleur) mais pas forcément compatible à 100% si tu utilise des trucs spécifiques à gcc. Tout comme gcc est une alternative à icc ou visual-c mais pas 100% compatible.
Pour ce qui est de la non-compatibilité avec l'ABI de linux, si j'ai bien compris elle n'est que temporaire. Une grosse partie du dévellopement ce fait sous darwin qui n'a pas la même ABI d'ou cette incompatibilité, mais à terme les deux devrait être supportées.
[^] # Re: ffmpeg
Posté par beagf . En réponse au journal test de llvm. Évalué à 5.
L'objectif de clang++llvm me semble quand même de faire un compilateur C et dérivés au moins aussi bon que gcc et même meilleur grâce à toutes les possibilités offertes par llvm.
Par contre, l'objectif, et c'est relativement clair dans les propos des dévellopeurs, n'est pas de faire un remplacant direct de gcc, dans le sens un compilateur qui accepte les mêmes sources et donne les même binnaires.
Un programme écrit en respectant les standards devrait être accepté par les deux sans problèmes, mais tout ce qui touche aux extentions des standards ne sera pas forcément géré de la même manière.
Les extentions spécifiques à gcc ne seront pas forcément gérées de la même manière.
L'objectif de clang est quand même de faire un compilateur propre en partant sur des bases saines. Dans ce cadre, il y a des choses relativement dégueulasse faites par gcc qui ne peuvent pas être supportées.
Donc ici, il faut clairement prendre "remplacant" comme "alternative", c'est-à-dire un compilateur aussi bon (voir meilleur) mais pas forcément compatible à 100% si tu utilise des trucs spécifiques à gcc. Tout comme gcc est une alternative à icc ou visual-c mais pas 100% compatible.
Pour ce qui est de la non-compatibilité avec l'ABI de linux, si j'ai bien compris elle n'est que temporaire. Une grosse partie du dévellopement ce fait sous darwin qui n'a pas la même ABI d'ou cette incompatibilité, mais à terme les deux devrait être supportées.