Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007642OCamlback end (clambda to assembly)public2017-09-27 10:502017-10-07 11:46
Assigned Toxleroy 
PlatformOSOS Version
Product Version4.05.0 
Target Version4.06.0 +dev/beta1/beta2/rc1Fixed in Version4.06.0 +dev/beta1/beta2/rc1 
Summary0007642: ocamlopt generates incorrect code on arm
DescriptionIn 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.
TagsNo tags attached.
Attached Filestxt file icon configure-output.txt [^] (4,265 bytes) 2017-09-27 13:51 [Show Content]
? file icon ocamlopt_bug.s [^] (4,141 bytes) 2017-09-27 14:01
txt file icon ocamlopt_bug_dcmm_dsel_dlinear.txt [^] (210,810 bytes) 2017-09-27 14:31 [Show Content]
patch file icon 0010-arm-default-PIC.patch [^] (592 bytes) 2017-09-29 14:41 [Show Content]
patch file icon armhf-movw-movt.patch [^] (645 bytes) 2017-09-29 18:39 [Show Content]
diff file icon XL-001-tests-asmcomp.diff [^] (529 bytes) 2017-10-03 09:24 [Show Content]

- Relationships

-  Notes
shinwell (developer)
2017-09-27 11:10

I will look at this now.
shinwell (developer)
2017-09-27 13:17

@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.
glondu (reporter)
2017-09-27 13:59

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.
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.
glondu (reporter)
2017-09-27 14:38

4: attached

5: attached

abel% ocamlopt.opt
abel% ./a.out 10
10 / 10 = 0
abel% ./a.out 20
20 / 10 = 0
abel% ocamlopt.byte
abel% ./a.out 10
10 / 10 = 1
abel% ./a.out 20
20 / 10 = 2

abel% ocamlopt.opt
abel% ./a.out 10
0 / 10 = 10
abel% ./a.out 20
0 / 10 = 20
abel% ocamlopt.byte
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).
glondu (reporter)
2017-09-27 14:42

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

Cf. [^]
shinwell (developer)
2017-09-27 15:16
edited on: 2017-09-27 15:20

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

shinwell (developer)
2017-09-27 15:17
edited on: 2017-09-27 15:18

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

glondu (reporter)
2017-09-27 18:49

Regarding access: if possible, the procedure is at [^] . 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.
shinwell (developer)
2017-09-28 09:44

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.
glondu (reporter)
2017-09-28 11:17

On Debian stable, the bug disappears!

gcc -v output:
Using built-in specs.
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)
shinwell (developer)
2017-09-28 12:31

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?
shinwell (developer)
2017-09-28 12:32

Sorry, that should have said: run "make opt.opt", not "make opt".
glondu (reporter)
2017-09-29 14:41

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.
infinity0 (reporter)
2017-09-29 18:20

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 && ./a.out 10
10 / 10 = 1
without my patch: $ ./ocaml/ocamlopt.opt -I ocaml/stdlib/ -fPIC && ./a.out 10
10 / 10 = 1

with my patch: $ ./ocaml/ocamlopt.opt -I ocaml/stdlib/ -fno-PIC && ./a.out 10
10 / 10 = 0
with my patch: $ ./ocaml/ocamlopt.opt -I ocaml/stdlib/ -fPIC && ./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.
infinity0 (reporter)
2017-09-29 18:46

The original reason for the arm-PIC patch is documented here: [^]

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.
xleroy (administrator)
2017-09-29 19:34
edited on: 2017-09-29 19:36

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.

infinity0 (reporter)
2017-09-29 21:26

> 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/ 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] [^]
[2] [^]
xleroy (administrator)
2017-09-30 18:35

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.
bunk (reporter)
2017-10-01 11:58

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/ 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)?
bunk (reporter)
2017-10-01 12:39

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?
xleroy (administrator)
2017-10-02 14:02

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 ( [^]); 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.
infinity0 (reporter)
2017-10-02 15:46
edited on: 2017-10-02 15:50

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 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
CXXFLAGS=-g -O2 -fdebug-prefix-map=$PWD=. -fstack-protector-strong -Wformat -Werror=format-security

(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] [^]

bunk (reporter)
2017-10-02 15:48

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.
gasche (administrator)
2017-10-02 15:55

> 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.)
infinity0 (reporter)
2017-10-02 17:04

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.
xleroy (administrator)
2017-10-03 09:41

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 [^] 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.
infinity0 (reporter)
2017-10-03 13:48

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.
xleroy (administrator)
2017-10-03 14:00

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 [^] 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).
xleroy (administrator)
2017-10-05 19:34

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.
xleroy (administrator)
2017-10-05 20:55

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

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
infinity0 (reporter)
2017-10-06 17:47

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.
xleroy (administrator)
2017-10-07 11:46

Fix submitted here: [^]

- Issue History
Date Modified Username Field Change
2017-09-27 10:50 glondu New Issue
2017-09-27 11:10 shinwell Note Added: 0018353
2017-09-27 11:10 shinwell Assigned To => shinwell
2017-09-27 11:10 shinwell Status new => assigned
2017-09-27 13:17 shinwell Note Added: 0018355
2017-09-27 13:51 glondu File Added: configure-output.txt
2017-09-27 13:59 glondu Note Added: 0018356
2017-09-27 14:01 glondu File Added: ocamlopt_bug.s
2017-09-27 14:31 glondu File Added: ocamlopt_bug_dcmm_dsel_dlinear.txt
2017-09-27 14:38 glondu Note Added: 0018358
2017-09-27 14:42 glondu Note Added: 0018359
2017-09-27 15:16 shinwell Note Added: 0018360
2017-09-27 15:17 shinwell Note Added: 0018361
2017-09-27 15:18 shinwell Note Edited: 0018361 View Revisions
2017-09-27 15:20 shinwell Note Edited: 0018360 View Revisions
2017-09-27 18:49 glondu Note Added: 0018374
2017-09-28 09:44 shinwell Note Added: 0018377
2017-09-28 11:17 glondu Note Added: 0018380
2017-09-28 12:31 shinwell Note Added: 0018382
2017-09-28 12:32 shinwell Note Added: 0018383
2017-09-29 14:41 glondu Note Added: 0018393
2017-09-29 14:41 glondu File Added: 0010-arm-default-PIC.patch
2017-09-29 18:20 infinity0 Note Added: 0018396
2017-09-29 18:39 infinity0 File Added: armhf-movw-movt.patch
2017-09-29 18:46 infinity0 Note Added: 0018397
2017-09-29 19:34 xleroy Note Added: 0018398
2017-09-29 19:36 xleroy Note Edited: 0018398 View Revisions
2017-09-29 21:26 infinity0 Note Added: 0018406
2017-09-30 18:31 xleroy Target Version => 4.06.0 +dev/beta1/beta2/rc1
2017-09-30 18:35 xleroy Note Added: 0018428
2017-10-01 11:58 bunk Note Added: 0018441
2017-10-01 12:39 bunk Note Added: 0018442
2017-10-02 14:02 xleroy Note Added: 0018448
2017-10-02 15:46 infinity0 Note Added: 0018450
2017-10-02 15:47 infinity0 Note Edited: 0018450 View Revisions
2017-10-02 15:48 bunk Note Added: 0018451
2017-10-02 15:50 infinity0 Note Edited: 0018450 View Revisions
2017-10-02 15:55 gasche Note Added: 0018452
2017-10-02 17:04 infinity0 Note Added: 0018453
2017-10-03 09:24 xleroy File Added: XL-001-tests-asmcomp.diff
2017-10-03 09:41 xleroy Note Added: 0018462
2017-10-03 13:48 infinity0 Note Added: 0018465
2017-10-03 14:00 xleroy Note Added: 0018466
2017-10-05 19:34 xleroy Note Added: 0018489
2017-10-05 20:55 xleroy Note Added: 0018490
2017-10-06 17:47 infinity0 Note Added: 0018496
2017-10-07 11:46 xleroy Note Added: 0018498
2017-10-07 11:46 xleroy Assigned To shinwell => xleroy
2017-10-07 11:46 xleroy Status assigned => resolved
2017-10-07 11:46 xleroy Resolution open => fixed
2017-10-07 11:46 xleroy Fixed in Version => 4.06.0 +dev/beta1/beta2/rc1

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker