Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug OCaml sur linuxPPC #2444

Closed
vicuna opened this issue May 9, 2000 · 4 comments
Closed

Bug OCaml sur linuxPPC #2444

vicuna opened this issue May 9, 2000 · 4 comments
Labels

Comments

@vicuna
Copy link

vicuna commented May 9, 2000

Original bug ID: 106
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

J'ai obtenu l'erreur suivante en compilant un fichier en Ocaml 3.0 sous
LinuxPPC.

L'archive avec le programme est à
ftp://www.lama.univ-savoie.fr/pub/af2/0.5.3/

Il faut aller dans le dossier af2 et faire make (en modifiant
éventuellement le fichier config)

/tmp/camlasm1.s: Assembler messages:
/tmp/camlasm1.s:3750: Error: operand out of range (33360 not between
-32768 and 32767)
/tmp/camlasm1.s:3775: Error: operand out of range (33272 not between
-32768 and 32767)
/tmp/camlasm1.s:3867: Error: operand out of range (32936 not between
-32768 and 32767)
Assembler error, input left in file /tmp/camlasm1.s

--
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI

@vicuna
Copy link
Author

vicuna commented May 15, 2000

Comment author: administrator

J'ai obtenu l'erreur suivante en compilant un fichier en Ocaml 3.0 sous
LinuxPPC.
/tmp/camlasm1.s: Assembler messages:
/tmp/camlasm1.s:3750: Error: operand out of range (33360 not between
-32768 and 32767)

J'ai pu reproduire le problème. C'est un branchement relatif qui
déborde dans une des fonctions de parsing (la plus grosse!). Suivant
les jeux d'instructions, il y a plus ou moins de bits dans les
instructions de branchement pour stocker un déplacement relatif,
e.g. 16 bits sur le PPC, et de très grosses fonctions Caml peuvent
causer un débordement de ce nombre de bits.

La seule parade connue est de couper les fonctions trop grosses en
plusieurs fonctions plus petites.

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented May 15, 2000

Comment author: administrator

It's an overflow in a relative branch. There's nothing that ocamlopt can
reasonably do about it.

@vicuna vicuna closed this as completed May 15, 2000
@vicuna
Copy link
Author

vicuna commented Nov 21, 2001

Comment author: administrator

Bonjour,

Juste quelques remarques à ce sujet :

  • On m'a signalé que le problème se produit également pour (le package
    debian de) Coq, V7.0 (cf PS)

  • Il me semble qu'au minimum le message pourrait venir de Caml lui-même,
    et être plus informatif

  • Avoir un compilateur qui parfois produit des programmes assembleur non
    valides me semble être une grosse contre-publicité pour Caml (Theory:
    "Well typed programs do not go wrong." Practical instance of the previous
    claim: "In some cases they do not go anywhere.")

  • Ce problème met à mal la portabilité des programmes Caml, ou du moins
    l'installation automatique des programmes. Quand on propose un script
    d'installation pour un programme tel que Coq, on peut sans problème
    détecter qu'ocamlopt existe ou qu'il n'existe pas. En revanche, pour
    tester que le programme fait des sauts trops longs pour le jeu
    d'instruction du processeur, il n'y a pas grand-chose d'autre à faire que
    commencer par essayer de compiler en natif pour ensuite tenter la
    compilation en bytecode si celle-ci a échoué et cette solution n'est quand
    même pas très satisfaisante.

  • Il est dommage d'être obligé de compiler en bytecode une application
    parce qu'un tout petit bout de code ne passe pas en natif...

  • J'ai du mal à croire qu'il n'y ait rien à faire... Par exemple la
    solution de découpage que tu proposes ne pourrait-elle pas être faite par
    le compilateur lui-même ? (si je ne dis pas de bêtises, dans
    l'optimisation du code, ocamlopt engendre déjà toute une floppée de
    fonctions auxiliaires) Je t'accorde que ce n'est sans doute pas du code
    très amusant à écrire mais il me semble que l'enjeu en vaudrait la
    peine...

Judicaël.

PS :

coq doesn't build from source on powerpc. Here's an excerpt from the
build log.

ocamlopt -rectypes -I config -I tools -I scripts -I lib -I kernel -I
library -I proofs -I tactics -I pretyping -I parsing -I toplevel -I
contrib/omega -I contrib/ring -I contrib/xml -I contrib/extraction -I
contrib/correctness -I contrib/interface -I contrib/fourier -I
/usr/lib/camlp4 -pp "camlp4o -I . pa_extend.cmo q_MLast.cmo sed -n -e 's|^(\*.*camlp4deps: "\(.*\)".*\*)$|\1|p' parsing/g_tactic.ml4 -impl"
-c -impl parsing/g_tactic.ml4
/tmp/camlasm0.s: Assembler messages:
/tmp/camlasm0.s:15413: Error: operand out of range (32876 not between
-32768 and 32767)
Assembler error, input left in file /tmp/camlasm0.s
make[1]: *** [parsing/g_tactic.cmx] Error 2

A full build log is available from
http://marenka.net/buildd/coq_7.0-1.build.log.

--
Judicael.Courant@lri.fr, http://www.lri.fr/~jcourant/
(+33) (0)1 69 15 64 85
"Heureux ceux qui savent rire d'eux-mêmes :
ils n'ont pas fini de s'amuser !"

@vicuna
Copy link
Author

vicuna commented Nov 23, 2001

Comment author: administrator

  • Il me semble qu'au minimum le message pourrait venir de Caml lui-même,
    et être plus informatif

Voir ci-dessous.

  • Avoir un compilateur qui parfois produit des programmes assembleur non
    valides me semble être une grosse contre-publicité pour Caml (Theory:
    "Well typed programs do not go wrong." Practical instance of the previous
    claim: "In some cases they do not go anywhere.")

C'est un argument de mauvaise foi. Tu obtiens une erreur à la
compilation, pas un plantage à l'exécution. Exactement comme pour
le programme "let x = 1 2". Où est le problème?

  • Ce problème met à mal la portabilité des programmes Caml, ou du moins
    l'installation automatique des programmes. Quand on propose un script
    d'installation pour un programme tel que Coq, on peut sans problème
    détecter qu'ocamlopt existe ou qu'il n'existe pas. En revanche, pour
    tester que le programme fait des sauts trops longs pour le jeu
    d'instruction du processeur, il n'y a pas grand-chose d'autre à faire que
    commencer par essayer de compiler en natif pour ensuite tenter la
    compilation en bytecode si celle-ci a échoué et cette solution n'est quand
    même pas très satisfaisante.

Il n'est pas particulièrement difficile de détecter à la configuration
que l'architecture est un PowerPC, et qu'il faut donc désactiver la
compilation en natif. À vue de nez, c'est 5 minutes de travail pour
implémenter ça.

  • Il est dommage d'être obligé de compiler en bytecode une application
    parce qu'un tout petit bout de code ne passe pas en natif...

  • J'ai du mal à croire qu'il n'y ait rien à faire... Par exemple la
    solution de découpage que tu proposes ne pourrait-elle pas être faite par
    le compilateur lui-même ? (si je ne dis pas de bêtises, dans
    l'optimisation du code, ocamlopt engendre déjà toute une floppée de
    fonctions auxiliaires) Je t'accorde que ce n'est sans doute pas du code
    très amusant à écrire mais il me semble que l'enjeu en vaudrait la
    peine...

On peut détecter et contourner le problème lors de la génération de
code, mais c'est un travail considérable; essentiellement, cela
revient à ajouter une passe à ocamlopt, soit après la génération de
code (dur, dur!), soit avant (un peu plus facile, mais moins précis).

  • Xavier

@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant