Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000106OCamlOCaml generalpublic2000-05-09 17:132000-05-15 14:09
Reporteradministrator 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000106: Bug OCaml sur linuxPPC
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 [^]

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0002108)
administrator (administrator)
2000-05-15 14:06

> 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

(0002109)
administrator (administrator)
2000-05-15 14:09

It's an overflow in a relative branch. There's nothing that ocamlopt can
reasonably do about it.
(0002110)
administrator (administrator)
2001-11-21 13:19

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 !"

(0002111)
administrator (administrator)
2001-11-23 14:14

> - 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


- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker