Compilation de gcc 4.3.1 par Sun Studio 12 (Solaris)

if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;

Est-ce une utilisation standard du préprocesseur ? Et si non,
comment contourner le truc ? J'avoue ne pas savoir ce que fait
'SAT ## NAME ## _type_node'...

Cordialement,

JKB

In article <slrng4veeo.puo.knatschke@rayleigh.systella.fr>,
JKB <wilhelm-siegfried.knatschke-koenigsberg@chezmoi.com> wrote:

if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;

Est-ce une utilisation standard du préprocesseur ? Et si non,
comment contourner le truc ? J'avoue ne pas savoir ce que fait
'SAT ## NAME ## _type_node'...

Cordialement,

JKB

C'est du preprocesseur ANSI un peu tordu... Il doit y avoir un bug d'evaluation
dans ton SunStudio, ou alors c'est un bug dans gcc qui `passe' a travers le
preprocesseur et qui ne se repere pas ailleurs... les regles d'evaluations
sont passablement tordues, et je n'ais pas ma norme sous la main.

Ta meilleure chance, ca serait d'avoir un preprocesseur qui marche, et
de configurer ton build de gcc pour utiliser ton compilateur sunstudio
plus un preprocesseur un peu mieux.

- regarde voir dans ta doc sunstudio s'il n'y a pas des options obscures
de compatibilite.
- tu peux essayer un preproc "standard" comme ucpp, qui devrait compiler
sans probleme (http://pornin.nerim.net/ucpp/)

- tu peux aussi essayer de bootstrapper en passant par un GCC plus ancien.

- tu peux essayer un preproc "standard" comme ucpp, qui devrait compiler
sans probleme (http://pornin.nerim.net/ucpp/)

Site down. Y a-t-il un tarball ailleurs, je n'ai pas trouvé...

C'est dans les ports de la plupart des bsd, on a des miroirs de distfiles

if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;
- tu peux essayer un preproc "standard" comme ucpp, qui devrait

compiler sans probleme

En news:g2oed8$asm$2@biggoron.nerim.net, Marc Espie va escriure:

if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;
- tu peux essayer un preproc "standard" comme ucpp, qui devrait

compiler sans probleme

Cette construction ne plaît pas du tout à ucpp...

C> type paste.c
#define C_COMMON_FIXED_TYPES(SAT,NAME)
if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;
C_COMMON_FIXED_TYPES (, fract);

C> ucpp paste.c
paste.c: warning: line 7: operator '##' produced the invalid token ' fract'
paste.c: warning: line 7: operator '##' produced the invalid token ' u'
paste.c: warning: line 7: operator '##' produced the invalid token ' u'
paste.c: warning: line 7: operator '##' produced the invalid token ' fract'
#line 1 "paste.c"





if (type1 == fract_type_node || type1 == ufract_type_node) return unsignedp
? u
fract_type_node : fract_type_node; ;

1/ Sun Studio est installé correctement puisqu'il m'a permis de
compiler tous les prérequis sans problèmes ;
2/ l'étape de configuration est passée sans souci ;
3/ la compilation plante sur :

C_COMMON_FIXED_TYPES (, fract);

au détail près qu'un argument est nul et qu'il est utilisé dans la
macro comme suit :

if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;

D'après Google tu n'es pas le seul avec ce souci.
cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id3304
htpp://gcc.gnu.org/ml/gcc-bugs/2007-09/msg00258.html
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01137.html
Vu que le problème a (au moins) 9 mois et est correctement reporté pour
autant que je puisse voir, on dirait pas que les mainteneurs de GCC ont
l'intention de faire des efforts supplémentaires pour le corriger.
Surtout qu'il y a un correctif évident, utiliser une version plus ancienne
de GCC pour compiler la bête de course.

En news:slrng4veeo.puo.knatschke@rayleigh.systella.fr, JKB va escriure:

1/ Sun Studio est installé correctement puisqu'il m'a permis de
compiler tous les prérequis sans problèmes ;
2/ l'étape de configuration est passée sans souci ;
3/ la compilation plante sur :

Quelle phase ? Je suppose la première (c'est-à-dire en utilisant les outils
natifs, "bootstrap"), mais bon...

C_COMMON_FIXED_TYPES (, fract);

D'après Google tu n'es pas le seul avec ce souci.
cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id3304
htpp://gcc.gnu.org/ml/gcc-bugs/2007-09/msg00258.html
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01137.html
Vu que le problème a (au moins) 9 mois et est correctement reporté pour
autant que je puisse voir, on dirait pas que les mainteneurs de GCC ont
l'intention de faire des efforts supplémentaires pour le corriger.
Surtout qu'il y a un correctif évident, utiliser une version plus ancienne
de GCC pour compiler la bête de course.

Maintenant, si tu trouves une correction à appliquer au source, peut-être
qu'ils le prendront...

au détail près qu'un argument est nul et qu'il est utilisé dans la
macro comme suit :

Je rajoute devant :

#define C_COMMON_FIXED_TYPES(SAT,NAME)

if (type1 == SAT ## NAME ## _type_node
|| type1 == SAT ## u ## NAME ## _type_node)
return unsignedp ? SAT ## u ## NAME ## _type_node
: SAT ## NAME ## _type_node;

Et il faut donc savoir évaluer
== SAT ## NAME ## _type_node
quand SAT est vide. Si le préprocessur est conforme C99 (donc sait manipuler
les arguments vides, concept de "placeholders" dans la norme), pas de souci
; par contre, s'il est conforme à la norme C90, le SAT compte pour du
beurre, et l'évaluation de
== ## NAME
donne ==NAME, qui n'est pas un élément lexical correct, donc (C90 6.8.3.2p2,
ANSI C 3.8.3.2p2) le comportement est explicitement indéfini.

Évidemment avec la plupart des préprocesseurs (ceux qui font du traitement
de texte pur, et pour qui l'opérateur ## se réduit à ne pas émettre de ' '
dans la sortie quand il y a doute ou ambiguïté), pas de problème, /lib/cpp
émet ==NAME, le compilateur va convertir le truc en deux lexèmes distincts
et roulemapoule ; par contre si le préprocesseur est plus intégré et la
sortie de cpp est passée directement, lexème par lexème, à l'analyse
syntaxique, ou bien si le préprocesseur est plus regardant (genre ucpp),
cela gueule voire cela plante.

Bon, je vais de ce pas chercher un préprocesseur C99...

En news:slrng4vrin.puo.knatschke@rayleigh.systella.fr, JKB va escriure:

Bon, je vais de ce pas chercher un préprocesseur C99...

Euh, si tu peux modifier ta chaîne pour mettre le préprocesseur qui
t'arrange (-Yp,xxx peut être ?), alors une manière plus simple devrait être
de forcer à utiliser le /lib/cpp de ta machine... De cette façon, tu vas
casser le lien direct entre cpp et l'analyseur syntaxique (en forçant à
passer par un fichier .i intermédiaire), et tu devrais de cette façon passer
outre le plantage (OK, peut-être que cpp va râler, mais au point où on
est...)

Évidemment, tu ajustes le chemin pour aller chercher le préprocesseur
attendu (je sais que Sun a/avait la manie de mettre les outils de
développement dans des coins réellement bizarres).

Par ailleurs, en fait quasiment n'importe quel préprocesseur pourrait faire
l'affaire ; et un préprocesseur réellement C99 comme ucpp va accrocher (cf.
mon autre message), alors que d'autres comme les anciennes versions de GCC
(cccp) ou celui de DMR, pour citer deux préprocesseurs courants (= que je
connais), vont digérer probablement sans souci la soupe, écrire un joli .i
sur le disque avec ==frac bien collés ;-), que cc1 va ensuite pouvoir relire
comme deux lexèmes distincts sans voir l'astuce.