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

ocamlopt generates incorrect code on arm #7642

Closed
vicuna opened this issue Sep 27, 2017 · 32 comments
Closed

ocamlopt generates incorrect code on arm #7642

vicuna opened this issue Sep 27, 2017 · 32 comments

Comments

@vicuna
Copy link

vicuna commented Sep 27, 2017

Original bug ID: 7642
Reporter: @glondu
Assigned to: @xavierleroy
Status: resolved (set by @xavierleroy on 2017-10-07T09:46:55Z)
Resolution: fixed
Priority: urgent
Severity: block
Version: 4.05.0
Target version: 4.06.0 +dev/beta1/beta2/rc1
Fixed in version: 4.06.0 +dev/beta1/beta2/rc1
Category: back end (clambda to assembly)
Monitored by: @gasche @yallop

Bug description

In Debian, with OCaml 4.05.0, (at least) menhir, extlib, coq, ocamlrss mysteriously fail to build on armel. While investigating the failure for ocamlrss, I discovered that the following program:

let a = int_of_string Sys.argv.(1);;
Printf.eprintf "%d / 10 = %d\n%!" a (a/10);;

when compiled with ocamlopt, prints "10 / 10 = 0". With ocamlc, the result is correct.

File attachments

@vicuna
Copy link
Author

vicuna commented Sep 27, 2017

Comment author: @mshinwell

I will look at this now.

@vicuna
Copy link
Author

vicuna commented Sep 27, 2017

Comment author: @mshinwell

@glondu: I couldn't reproduce this on an armhf system. Please would you provide:

  1. The output of "configure" when you built the OCaml compiler
  2. The hardware / virtualization environment and exact operating system version
  3. The output of "gcc -v" (or equivalent if you are using a different compiler)
  4. The .s file produced by adding -S to the ocamlopt command line
  5. The output produced on stderr when "-dcmm -dsel -dlinear" is added to the ocamlopt command line
  6. The output of the program if you use ocamlopt.opt AND ocamlopt.byte in the following situations:
    (a) Providing the argument 10
    (b) Providing the argument 20
  7. Swap "a" and "(a / 10)" and repeat number 6 above.

Can you confirm whether OCaml 4.04 operates correctly on this system?

Thanks in advance.

@vicuna
Copy link
Author

vicuna commented Sep 27, 2017

Comment author: @glondu

This happens on "armel" (not "armhf").

1: attached

2: I don't know the hardware / virtualization environment: what command should I run to figure it out? (Note: I am not root on this machine). This bug occurs in an up-to-date Debian unstable chroot running on a Debian 9.1 system.

3: gcc -v output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/7/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-7' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=arm-linux-gnueabi- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv4t --with-float=soft --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 7.2.0 (Debian 7.2.0-7)

I will provide the other requested information soon.

@vicuna
Copy link
Author

vicuna commented Sep 27, 2017

Comment author: @glondu

4: attached

5: attached

6:
abel% ocamlopt.opt ocamlopt_bug.ml
abel% ./a.out 10
10 / 10 = 0
abel% ./a.out 20
20 / 10 = 0
abel% ocamlopt.byte ocamlopt_bug.ml
abel% ./a.out 10
10 / 10 = 1
abel% ./a.out 20
20 / 10 = 2

7:
abel% ocamlopt.opt ocamlopt_bug.ml
abel% ./a.out 10
0 / 10 = 10
abel% ./a.out 20
0 / 10 = 20
abel% ocamlopt.byte ocamlopt_bug.ml
abel% ./a.out 10
1 / 10 = 10
abel% ./a.out 20
2 / 10 = 20

OCaml 4.02.3 operates correctly on this system (4.04 has not been tried).

@vicuna
Copy link
Author

vicuna commented Sep 27, 2017

Comment author: @glondu

Hardware is Marvell Armada 370/XP CPU @ 1.6GHz on a Marvell MV78460 SoC Development Board (ARM v7).

Cf. https://db.debian.org/machines.cgi?host=abel

@vicuna
Copy link
Author

vicuna commented Sep 27, 2017

Comment author: @mshinwell

It looks like the native code version of ocamlopt has been miscompiled and is giving the wrong factor for the magic division-by-constant algorithm. This is presumably either due to a code generation error in the OCaml arm backend or possibly miscompilation by GCC in the nativeint stubs.

Is it possible to get access to the machine in question? (I can provide a reference from a well-known Debian developer if required.)

@vicuna
Copy link
Author

vicuna commented Sep 27, 2017

Comment author: @mshinwell

One other thing: is it possible to repeat the test on the same hardware but running a stable version of Debian? (If so please provide the gcc version as well as the answers.)

@vicuna
Copy link
Author

vicuna commented Sep 27, 2017

Comment author: @glondu

Regarding access: if possible, the procedure is at https://dsa.debian.org/doc/guest-account/ . However it says that "People requesting access should already have a track record of working on Debian for some time." Is it your case? Which "well-known Debian developer" are you thinking of?

Regarding testing on stable: I will try in a stretch chroot.

@vicuna
Copy link
Author

vicuna commented Sep 28, 2017

Comment author: @mshinwell

Yeah, let's try the test with a more likely known-good version of GCC first (i.e. on Debian stable). It would be nice to rule that out.

@vicuna
Copy link
Author

vicuna commented Sep 28, 2017

Comment author: @glondu

On Debian stable, the bug disappears!

gcc -v output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/6/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=arm-linux-gnueabi- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armel/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armel --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armel --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv4t --with-float=soft --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18)

@vicuna
Copy link
Author

vicuna commented Sep 28, 2017

Comment author: @mshinwell

So it seems reasonably likely that this is either a GCC bug or some accidental use of undefined behaviour in the runtime which is causing a new, more clever version of GCC to delete more code.

Could you just try the following:

  • Build the compiler manually on both Debian stable and unstable
  • Take the file asmrun/ints.o built on Debian stable and copy it to your compiler tree on Debian unstable, replacing the file asmrun/ints.o

Then on the Debian unstable compiler tree:

  • Delete asmrun/libasmrun.a just to be sure
  • cd into the asmrun directory
  • Run "make" (this should produce libasmrun.a)
  • Go up one level and run "make install"
  • Delete ocamlopt.opt
  • Run "make opt", which should produce a new ocamlopt.opt
  • "make install"

Now use the new ocamlopt.opt to compile the original test case. What does it print?

@vicuna
Copy link
Author

vicuna commented Sep 28, 2017

Comment author: @mshinwell

Sorry, that should have said: run "make opt.opt", not "make opt".

@vicuna
Copy link
Author

vicuna commented Sep 29, 2017

Comment author: @glondu

Actually, the bug is caused by a Debian-specific patch that forces PIC (attached).

Contrarily to what I said before, ocamlopt.opt compiled with this patch produces incorrect code on unstable as well as on stable.

@vicuna
Copy link
Author

vicuna commented Sep 29, 2017

Comment author: infinity0

I can confirm that removing my patch causes the basic test case above ("10 / 10 = ") to work again. However that just raises more questions. All my patch does is make ARM default to generating PIC code, which shouldn't affect its correctness.

without my patch: $ ./ocaml/ocamlopt.opt -I ocaml/stdlib/ -fno-PIC test.ml && ./a.out 10
10 / 10 = 1
without my patch: $ ./ocaml/ocamlopt.opt -I ocaml/stdlib/ -fPIC test.ml && ./a.out 10
10 / 10 = 1

with my patch: $ ./ocaml/ocamlopt.opt -I ocaml/stdlib/ -fno-PIC test.ml && ./a.out 10
10 / 10 = 0
with my patch: $ ./ocaml/ocamlopt.opt -I ocaml/stdlib/ -fPIC test.ml && ./a.out 10
10 / 10 = 0

ocamlopt(.byte) is fine in all cases, it is compiled using ocamlc and not ocamlopt.

So there is probably still a bug in ocamlopt somewhere, that when used to compile itself, produces a compiler that miscompiles the basic test case given above.

@vicuna
Copy link
Author

vicuna commented Sep 29, 2017

Comment author: infinity0

The original reason for the arm-PIC patch is documented here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837359#80

Basically movw/movt instruction pairs causes problems when GCC defaults to -fPIE as is the case on Debian. OCaml generates these for > ARMv6. The arm-PIC patch works around this by generating PIC code by default, but it looks like it's causing problems here.

I've attached an alternate patch armhf-movw-movt.patch which has been reported to also fix the OCaml testsuite on armhf with a -fPIE GCC, but I don't know if it's the best thing to do, and we haven't yet tested it further (by compiling other packages with it). There is also one further movw/movt pair further up in the file, in emit_intconst, which may or may not cause problems further down the line.

@vicuna
Copy link
Author

vicuna commented Sep 29, 2017

Comment author: @xavierleroy

There is perhaps a lack of synchronization between Clflags.dlcode and Clflags.pic_code. Alternatively, the branch that generates movw/movt should be guarded by "not !Clflags.dlcode && not !Clflags.pic_code".

Yet, I see no connection between this use of movw/movt to load symbol addresses and the magic multiplicative constants for division by a constant. Can someone elaborate?

Also, I am surprised -- and irritated actually -- by the amount of patching done in Debian without even notifying the original "upstream" authors.

@vicuna
Copy link
Author

vicuna commented Sep 29, 2017

Comment author: infinity0

the branch that generates movw/movt should be guarded by "not !Clflags.dlcode && not !Clflags.pic_code".

That branch already is the else-branch of a "if !Clflags.pic_code" sibling branch, so I think the extra "&& not" would be redundant.

I think there may be two separate bugs here - (1) the movw/movt bug and (2) the fact that when ocamlopt.byte compiles ocamlopt with -fPIC, the resulting ocamlopt.opt generates bad code. That is, we uncovered (2) because of the arm-PIC patch for (1), but I don't know what the deeper cause of (2) is.

A slightly older version of the arm-PIC patch worked without problems on ocaml 4.02.3, here it is compiling coq successfully. [1] The -10th Debian revision was used, which already applies the patch [2]. Between 4.02.3 and 4.05.0 there was a minor change, the pic_code variable was dropped from arm/arch.ml and the one from Clflags was used directly instead. So the patch was updated to reflect that.

I'm sorry for the amount of patches, mostly it is a volume issue - with all the other packages that maintainers have to take care of, sometimes we forget to upstream things like this one, especially on "less important" architectures like ARM. I did send various other patches upstream before, to OCaml.

As for the arm-PIC patch specifically, I felt it was safer to switch a flag than to mess with the code generation. Nothing broke for that version (4.02.3) so I then forgot about it.

[1] https://buildd.debian.org/status/fetch.php?pkg=coq&arch=armel&ver=8.6-4%2Bb1&stamp=1500572004&raw=0
[2] https://sources.debian.net/src/ocaml/4.02.3-10/debian/patches/0012-arm-default-PIC.patch/

@vicuna
Copy link
Author

vicuna commented Sep 30, 2017

Comment author: @xavierleroy

Also: from the discussion it's unclear to me whether the problem is specific to "armel" or whether "armhf" is affected as well. My ARM test machines (two RPis, a CubieTruck, and a Scaleway VM) are all "armhf", and "armel" is so obsolete these days that I'd suggest removing ocamlopt support for it entirely.

@vicuna
Copy link
Author

vicuna commented Oct 1, 2017

Comment author: bunk

There are two problems:

(1) link failure originating from emit_load_symbol_addr with -nodynlink on arch > ARMv6 when gcc defaults to PIE

This is the problem on the Debian armhf port (EABI_HF, ARMv7).

Ports with a lower baseline (e.g. Debian armel, Raspbian armhf) are not affected by this problem.

This problem is present in both OCaml 4.02.3 and 4.05.0.

This problem was workarounded in Debian by enabling pic_code when building OCaml on armel/armhf after the Debian gcc stated to default to PIE a year ago.

(2) 10 / 10 = 0 on the Debian armel port when OCaml is built as pic_code with a Debian-specific change to workaroud (1)

This problem has so far only been observed on the Debian armel port (EABI, ARMv4).

This problem is a regression in OCaml 4.02.3 -> 4.05.0.

The more interesting general problem is (1), so lets's focus on that:

The link errors in the tests are triggered by:
testsuite/tests/asmcomp/main.ml: Clflags.dlcode := false;

Removing this line makes the tests link and pass, but how is in general -nodynlink supposed to work on distributions where gcc defaults to PIE (including -pie, which passes -pie to ld)?

@vicuna
Copy link
Author

vicuna commented Oct 1, 2017

Comment author: bunk

To avoid misunderstandings, I am not claiming that -nodynlink would be completely broken when gcc defaults to PIE.

But -nodynlink currently results in the movw/movt branch being used in emit_load_symbol_addr, and this cannot be used in a PIE executable.

Perhaps a configure check based on something like "gcc -dM -E - < /dev/null | grep PIE" is the way forward for a proper solution?

@vicuna
Copy link
Author

vicuna commented Oct 2, 2017

Comment author: @xavierleroy

Yes, of course, PIE mode calls for different code generation schemas than non-PIE mode. I recently worked on the 64-bit ports of OCaml to improve support for PIE (#1323); more work remains for the 32-bit ports.

What irritates me is that distributions switch to PIE mode by default without even notifying upstream compiler developers.

@vicuna
Copy link
Author

vicuna commented Oct 2, 2017

Comment author: infinity0

It's possible to setup an armel chroot inside an armhf or arm64 system. That is in fact what I've been doing - using the Debian arm64 porterbox but with armhf and armel chroots, since the actual armel and armhf Debian porterboxes are very slow. Both bugs reproduce in these chroots OK for me.

If you'd like to try this yourself on a Debian system, you can follow the instructions at [1] but instead use sbuild-createchroot --arch=armel and s/amd64/armel in the rest of the instructions.

Using armhf-movw-movt.patch instead of 0010-arm-default-PIC.patch seems like an adequate solution for the time being - both of these fix (1) on armhf - i.e. ocaml test suite runs successfully - and the replacement patch avoids (2) on armel - my armel coq build is still running but it has already gotten past the previous failure, and the basic "10 / 10" test case works.

So I'll upload that to Debian unstable at the next opportunity, unless someone sees a reason for me not to.

I can see the argument that armel could just be dropped from Debian, and it would make maintainers' lives easier TBH, but that would be a decision for someone else. How would you like to be notified about future flag changes - is it possible for me to send caml-list@inria.fr without subscribing to it, or shall I post somewhere else, etc?

For completeness, we also compile with other flags that change infrequently, at the moment they are:

CFLAGS=-g -O2 -fdebug-prefix-map=$PWD=. -fstack-protector-strong -Wformat -Werror=format-security
CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -fdebug-prefix-map=$PWD=. -fstack-protector-strong -Wformat -Werror=format-security
LDFLAGS=-Wl,-z,relro

(The PIE change was a source-level change by the GCC maintainer rather than to CFLAGS etc, it was a non-standard decision and I don't know it sufficiently-well to go into the details right now.)

[1] https://wiki.debian.org/sbuild#Create_the_chroot

@vicuna
Copy link
Author

vicuna commented Oct 2, 2017

Comment author: bunk

This was not a change in the Debian package of OCaml that would pass -pie to gcc.

This is a change in the gcc in Debian/Ubuntu that makes gcc compile and link all code as PIE unless -no-pie is explicitly passed to gcc.

This gcc change was made in Debian unstable one year ago, and is already included in Debian 9 released in June.

amd64 (upstream) and armel/armhf (Debian-specific as discussed above) enable pic_code in Debian 9, -nodynlink might be broken on arm64 and i386 if that's breakage not covered by the testsuite.

@vicuna
Copy link
Author

vicuna commented Oct 2, 2017

Comment author: @gasche

I can see the argument that armel could just
be dropped from Debian, and it would make
maintainers' lives easier TBH, but that
would be a decision for someone else.

I think Xavier's suggestion was not to remove the armel port from Debian (or the OCaml packages there), but to configure OCaml (under Debian+armel) with bytecode compilation only, and no native compilation. (I believe that several Debian-supported architectures are already configured in this way.)

@vicuna
Copy link
Author

vicuna commented Oct 2, 2017

Comment author: infinity0

OK, I'll consider that. Hopefully the change will not involve much extra work in terms of Debian infrastructure.

What do you advise for the armhf issue? There are three options for Debian:

  1. Keep the existing PIC patch for armhf.
  2. Replace it with the proposed replacement that removes the movw/movt optimisation.
  3. Disable ocamlopt for armhf as well. (Because, essentially the same code is used for both armel and armhf, and we have already seen that the armel version is dodgy.)

With (2) there is the option of keeping armel ocamlopt support, which was my preferred choice in the previous post.

@vicuna
Copy link
Author

vicuna commented Oct 3, 2017

Comment author: @xavierleroy

Here is what you should do for armhf to support PIE:

  • Remove your 0010-arm-default-PIC.patch
  • Don't include your movw-movt patch
  • Do apply the patch I just added to this PR: XL-001-tests-asmcomp.diff

What my patch does is just to fix the failing test in testsuite/tests/asmcomp by removing the "dlcode := false" line mentioned earlier. This line looks like an experiment that I committed by mistake.

With this fix, OCaml 4.05 compiles and passes its tests on armhf with PIE mode manually turned on (i.e. with configure -cc "gcc -pie -fpie").

Some additional explanations:

Q: How can the "asmcomp" test fail with wrong code being produced, yet no change is required in the main compiler sources?
A: The asmcomp test is peculiar in that it tests the back-end of the OCaml native-code compiler independently of the rest of the OCaml compiler, by linking the back-end with a homemade front-end for the C-- intermediate language. So, it is possible for the two compilers (the real compiler "ocamlopt" and the mock compiler in "tests/asmcomp") to disagree by mistake, e.g. on default values for flags. And the 0010-arm-default-PIC.patch was the wrong answer to the problem reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837359#80. Problem that SHOULD HAVE BEEN REPORTED UPSTREAM to begin with.

Q: Why not activate PIC mode by default?
A: Code that is fully Position Independent is often less efficient. Hence on several ports OCaml shoots for Dynamically Loadable code (DL code) by default. DL code can still be relocated by a dynamic loader but perhaps less efficiently than full PIC code.

Q: What about PIE?
A: We're working on it. On several platforms DL code is PIE. On other, uncooperative platforms such as i386, we may end up not supporting PIE at all (by linking with -no-pie).

Q: Back to the armhf port, what happens with ocamlopt -nodynlink ?
A: Code that is neither DL nor PIC is generated. On a platform where PIE is on by default, such code can only be linked with ocamlopt -ccopt -no-pie. This is what the user asked for.

@vicuna
Copy link
Author

vicuna commented Oct 3, 2017

Comment author: infinity0

Thanks for the patch and explanations, I will go ahead and apply that, and disable armel ocamlopt on Debian.

I agree and already knew I should have reported that original bug upstream - that is what the "Forwarded: TODO" line means in the patch in Debian jargon. Everyone forgets about things, there is no need to continue biting my head off. I apologised already and tried to explain the context.

As a reminder, (2) still exists, and it would not have been discovered (yet) if my patch hadn't been used. Now, I know that ocamlopt.opt is not compiled with -fPIC by default, but it means there is some issue with the arm codegen on armel, which may or may not also affect armhf PIC code in ways that we haven't discovered yet.

@vicuna
Copy link
Author

vicuna commented Oct 3, 2017

Comment author: @xavierleroy

You're right, one more problem to go (strange division on armel). I'm trying to build an "armel" environment to reproduce it, without success so far.

I tried the "sbuild" trick on my ARMv8 Debian Jessie machine but it fails with
chroot: failed to run command ‘mount’: Exec format error

As concerns real hardware, early Raspbian for Raspberry Pi model 1 was armel, but it's all armhf now. Debian's page https://wiki.debian.org/ArmEabiPort lists dead hardware only, and manages to never mention Raspberry Pi, as if the page was written in 2011.

My conclusion is that armel is dead and not worth the maintenance hassle. I'll change my mind if someone tells me how to boot the latest Debian armel on one of my Raspberry Pi (model 1, 2 or 3).

@vicuna
Copy link
Author

vicuna commented Oct 5, 2017

Comment author: @xavierleroy

Eventually the "sbuild" trick worked, on a ARMv7 Ubuntu 16.04 host machine. That's a crazy hybrid (Debian armel unstable running within Ubuntu armhf LTS) but it was enough to reproduce the division problem. The repro uses pristine 4.05.0 sources plus the 0010-arm-default-PIC.patch.

The problem shows up when the repro case is compiled with ocamlopt.opt but not with ocamlopt (.byte). This points to a miscompilation of ocamlopt by itself. Great. To be continued.

@vicuna
Copy link
Author

vicuna commented Oct 5, 2017

Comment author: @xavierleroy

Below is a small repro case, excerpted from the ocamlopt sources. It prints the wrong results when compiled with ocamlopt or ocamlopt.opt. The source of the problem is the way ocamlopt treats multiplication for ARM versions < ARMv6, see asmcomp/arm/selection.ml line 59. Reloading post register allocation invalidates the hypothesis that "rm" as pseudo-result is the same physical register as "rm" as argument. The easiest fix is probably to say that ARM version < ARMv6 are not supported by ocamlopt.

let ucompare x y = Nativeint.(compare (add x min_int) (add y min_int))

let udivmod n d = Nativeint.(
if d < 0n then
if ucompare n d < 0 then (0n, n) else (1n, sub n d)
else begin
let q = shift_left (div (shift_right_logical n 1) d) 1 in
let r = sub n (mul q d) in
if ucompare r d >= 0 then (succ q, sub r d) else (q, r)
end)

let _ =
let n = Nativeint.min_int in
let d = 10n in
let (q, r) = udivmod n d in
Printf.printf "%nd %nd = %nd, %nd\n" n d q r

@vicuna
Copy link
Author

vicuna commented Oct 6, 2017

Comment author: infinity0

Thanks for taking a closer look! I asked some other Debian people and apparently not all ARMv8 chips support the older 32-bit instructions, so this might explain your earlier "exec format error".

I've disabled ocamlopt on Debian armel, I think this is sufficient for now - and good to hear that the underlying cause does not affect armhf.

@vicuna
Copy link
Author

vicuna commented Oct 7, 2017

Comment author: @xavierleroy

Fix submitted here: #1411

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants