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

ocaml build failure on ia64 with gcc4 #3749

Closed
vicuna opened this issue Aug 10, 2005 · 1 comment
Closed

ocaml build failure on ia64 with gcc4 #3749

vicuna opened this issue Aug 10, 2005 · 1 comment
Labels

Comments

@vicuna
Copy link

vicuna commented Aug 10, 2005

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

Bug description

Hi,

the ocaml debian package fails to build on ia64 with the new gcc, with
errors in byterun/interp.c:
gcc -DCAML_NAME_SPACE -O -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o interp.o interp.c
interp.c: In function 'caml_interprete':
interp.c:297: error: invalid lvalue in increment
interp.c:299: error: invalid lvalue in increment
interp.c:301: error: invalid lvalue in increment
interp.c:303: error: invalid lvalue in increment
...

(A full build log is available at
http://buildd.debian.org/fetch.php?&pkg=ocaml&ver=3.08.3-6&arch=ia64&stamp=1123386582&file=log&as=raw)

The problem seems to be the "Next" macro, which is different on ia64
than on other archs:

ifdef DEBUG

define Next goto next_instr

else

ifdef ia64

define Next goto *(void *)(jumptbl_base + *((uint32 *) pc)++)

else

define Next goto *(void *)(jumptbl_base + *pc++)

endif

endif

I believe that using the following on ia64 instead should work, but
since I am no expert, I'd like to get the caml team's advice :)
(I don't really understand why this cast is there, and why it's there
only on ia64, but it has been added in 2000, as part of the ia64 port)
#define Next goto (void)(jumptbl_base + (uint32)*pc++)

Alternately, I wonder if opcode_t could be defined as uint32 instead of
int32, which would probably solve this problem (assuming it doesn't need
to be signed).

Thanks,
Julien Cristau


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+jWpmEvTgKxfcAwRAmoVAKCOWaKIRZsFQs6LXgti6/UDc53amwCfTK/k
BBksmfa4nFX8sb6/0+sJBwU=
=1cgl
-----END PGP SIGNATURE-----



@vicuna
Copy link
Author

vicuna commented Sep 24, 2005

Comment author: administrator

see also #3750, #3751. Fixed in 3.09 by XL, 2005-09-24

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