bugGNU Octave - Bugs: bug #40607, mxe-octave: mixed uint64/double...

 
 

bug #40607: mxe-octave: mixed uint64/double arithmetic incorrect (GUI-only)

Submitter:  John Donoghue <lostbard>
Submitted:  Sun 17 Nov 2013 02:39:37 AM UTC
   
 
Category:  GUI Severity:  5 - Blocker
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  John D Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 26 Nov 2013 09:34:36 PM UTC, comment #52: 

It seems to be working now for MinGW with a cross-built binary.  Closing report.

Rik <rik5>
Group administrator
Tue 26 Nov 2013 01:24:25 PM UTC, comment #51: 

Native compiled mingw running in GUI mode still works ok with me as of hg id 9acd7b0f0639.

John Donoghue <lostbard>
Group Member
Tue 26 Nov 2013 11:19:10 AM UTC, comment #50: 

That was running the GUI natively compiled on my windows machine.

I will retry with the latest changes.

John Donoghue <lostbard>
Group Member
Tue 26 Nov 2013 07:08:38 AM UTC, comment #49: 

I checked in the following changeset on the stable branch and merged stable to default.

  http://hg.savannah.gnu.org/hgweb/octave/rev/0cd39f7f2409

This seems to fix the problem for me that you reported in comment #46.

John W. Eaton <jwe>
Group administrator
Tue 26 Nov 2013 05:29:31 AM UTC, comment #48: 

John D:  Even running in the GUI?

Rik:  I think the problem is that the conversion to long double from octave_uint64 must also take place while the long double rounding mode is in effect.  I'm testing that to be sure.  If I'm right I should have a patch soon.

John W. Eaton <jwe>
Group administrator
Tue 26 Nov 2013 01:00:44 AM UTC, comment #47: 

Under native compiled mingw it works with the latest changeset.

John Donoghue <lostbard>
Group Member
Tue 26 Nov 2013 12:46:27 AM UTC, comment #46: 

The original behavior with adding or subtracting to uint64(2)^63 is fixed.  However, I now get a different failing test:


a = uint64 (2**61) + 2; assert (1.25*a == (5*a)/4);


Further debug shows


a = uint64 (2**61) + 2
a = 2305843009213693954
b = 1.25*a
b = 2882303761517117443
c = (5*a)/4
c = 2882303761517117440


Rik <rik5>
Group administrator
Mon 25 Nov 2013 10:57:03 PM UTC, comment #45: 

Sigh.  It's going to be another hour.  Twice I have noticed in the past few days that I have to issue 'make all' twice in order for all files to get compiled.  Hopefully this is just a transient issue.

Rik <rik5>
Group administrator
Mon 25 Nov 2013 10:11:12 PM UTC, comment #44: 

I'm building right now to check.  Should know in about 1.5 hours.

--Rik

Rik <rik5>
Group administrator
Mon 25 Nov 2013 09:28:21 PM UTC, comment #43: 

I checked in the following changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/79653c5b6147

Does this change solve the problem for you?

John W. Eaton <jwe>
Group administrator
Mon 25 Nov 2013 07:55:56 PM UTC, comment #42: 

Going back to the #define sub operation and then adding print direct to the #define in /liboctave/util/oct-inttypes.cc


@@ -120,6 +120,7 @@
     BEGIN_LONG_DOUBLE_ROUNDING (); \
  \
     long double retval = x OP y; \
+printf("a=%Lf\n", retval); \
  \
     END_LONG_DOUBLE_ROUNDING (); \
  \


With the printf statement in there, I get the correct answer returned. Without it I do not.

With the printf:


>> uint64(2)^63
ans = 9223372036854775808
>> uint64(2)^63-1
a=9223372036854775807.000000
ans = 9223372036854775807
>> uint64(2)^63-2
a=9223372036854775806.000000
ans = 9223372036854775806
>>


John Donoghue <lostbard>
Group Member
Mon 25 Nov 2013 06:45:10 PM UTC, comment #41: 

ok - found it.

Assuming the change in comment 35:

if I did a make clean; make and then run ./run-octave, uint64(2)^63-1 doesn't work, and I couldn't seem to make a breakpoint and see what was going on in gdb.

If I comment out OCTAVE_LONG_DOUBLE_OP (-, sub) and manually add the equivalent of expanded #define OCTAVE_LONG_DOUBLE_OP, and put a printf("%Lf\n", retval) in it, it prints out the correct answer AND returns the correct answer.


John Donoghue <lostbard>
Group Member
Mon 25 Nov 2013 05:05:59 PM UTC, comment #40: 

oct-inttypes.cc, but it's generated by a macro.  Search for octave_external_long_double.

John W. Eaton <jwe>
Group administrator
Mon 25 Nov 2013 11:34:44 AM UTC, comment #39: 

What file has the code of octave_external_long_double_sub in it?

John Donoghue <lostbard>
Group Member
Mon 25 Nov 2013 01:50:25 AM UTC, comment #38: 

The function that should handle the subtraction in this case is octave_external_long_double_sub.  Can you verify that this function is called for the expression uint64(2)^63-1?

John W. Eaton <jwe>
Group administrator
Mon 25 Nov 2013 01:24:32 AM UTC, comment #37: 

In native mingw, If I backtrack to hg id=b8cd17571a1d, the GUI uint64 math works correctly.

John Donoghue <lostbard>
Group Member
Mon 25 Nov 2013 12:18:05 AM UTC, comment #36: 

I just compiled a native built mingw build octave that I am running through ./run-octave:

./run-octave: uint64(2)^63-1 gives wrong result
./run-octave --no-gui: uint64(2)^63-1 gives wrong result
./run-octave --no-gui-libs: works correctly.

John Donoghue <lostbard>
Group Member
Sun 24 Nov 2013 11:51:24 PM UTC, comment #35: 

Changed to:


#if (SIZEOF_LONG_DOUBLE >= 10) && defined (HAVE_ROUNDL)
# define OCTAVE_INT_USE_LONG_DOUBLE
# if (SIZEOF_LONG_DOUBLE < 16 \
      && (defined __i386__ || defined __x86_64__) && defined __GNUC__)
#define OCTAVE_ENSURE_LONG_DOUBLE_OPERATIONS_ARE_NOT_TRUNCATED 1
# endif
#endif


However after re-cross compiling and running it, I still get the same results as my last post.

Running in cli mode, octave works ok:

octave-cli.exe:2> uint64(2)^63
ans = 9223372036854775808
octave-cli.exe:3> uint64(2)^63-1
ans = 9223372036854775807
octave-cli.exe:4>


John Donoghue <lostbard>
Group Member
Sun 24 Nov 2013 08:50:39 PM UTC, comment #34: 

OK, can you try changing the condition that sets OCTAVE_ENSURE_LONG_DOUBLE_OPERATIONS_ARE_NOT_TRUNCATED in oct-conf-post.in.h from "SIZEOF_LONG_DOUBLE == 10" to "SIZEOF_LONG_DOUBLE < 16"?

I'm really not sure what the proper test should be.  We want to catch systems that might stupidly round to 53-bits precision even when explicitly performing operations on long double values.


John W. Eaton <jwe>
Group administrator
Sun 24 Nov 2013 08:41:01 PM UTC, comment #33: 



>>  uint64(2)^63
ans = 9223372036854775808
>>  uint64(2)^63-1
ans = 9223372036854775808
>>  uint64(2)^63-2
ans = 9223372036854775808
>>  int64(2)^63
ans = 9223372036854775807
>>  int64(2)^63-1
ans = 9223372036854775807
>>


Cross compiled config.h:


#define SIZEOF_LONG_DOUBLE 12
#define HAVE_ROUNDL 1


A earlier version of octave natively compiled reports the same in config.h


John Donoghue <lostbard>
Group Member
Sun 24 Nov 2013 08:12:55 PM UTC, comment #32: 

Precisely what test is failing for you?  For meproblem for

  uint64(2)^63-1  ==>  9223372036854775807
  uint64(2)^63-2  ==>  9223372036854775806

etc. and I see the same values when subtracting uint64(1), uint64(2), etc.  It also works with int64.

What hardware are you using and what are the values of

  SIZEOF_LONG_DOUBLE
  HAVE_ROUNDL

in config.h?

John W. Eaton <jwe>
Group administrator
Sun 24 Nov 2013 07:52:38 PM UTC, comment #31: 

I just built a new install with the latest devel octave id=ea1db0ede4ce and the issue with uint64 is back for me.

Can anyone else verify?

John Donoghue <lostbard>
Group Member
Sun 24 Nov 2013 04:45:53 PM UTC, comment #30: 

Thanks, I can mkoctfile again, closing again.

Mike Miller <mtmiller>
Group Member
Sun 24 Nov 2013 06:00:07 AM UTC, comment #29: 

I checked in the following changeset to fix the problem with the gnulib header file.

http://hg.savannah.gnu.org/hgweb/octave/rev/ac9fd5010620

If this change looks OK, please close this report.

John W. Eaton <jwe>
Group administrator
Fri 22 Nov 2013 02:26:14 PM UTC, comment #28: 

Oops, sorry about that.

I'm not sure we want to unconditionally move the operations out of a header file as I suspect not inlining these will be bad for performance.

I'll take another look at it.

John W. Eaton <jwe>
Group administrator
Fri 22 Nov 2013 01:03:47 PM UTC, comment #27: 

I should have commented on this bug report originally, but as I reported on the ML, this fix cannot be released because it leaks gnulib header files and definitions into Octave's public API.

Mike Miller <mtmiller>
Group Member
Fri 22 Nov 2013 12:54:31 PM UTC, comment #26: 

Works for me.

John Donoghue <lostbard>
Group Member
Thu 21 Nov 2013 10:18:34 PM UTC, comment #25: 

I checked in the following change.

http://hg.savannah.gnu.org/hgweb/octave/rev/824c05a6d3ec

It seems to fix the problem for me.  If someone can verify that it also fixes the problem for them, then please close the report.

John W. Eaton <jwe>
Group administrator
Tue 19 Nov 2013 08:05:08 PM UTC, comment #24: 

Other parts of Octave can change the floating point registers, we had that problem with Java previously and Mike Miller fixed it.  I think his solution was the same as what you are suggesting for [u]int64, save and restore FP flags, before and after every operation.

We could always benchmark the anticipated slowdown and see how bad it is.  My guess is that lots of the time people use uint32 or below so some potential slowdown might be acceptable.

Rik <rik5>
Group administrator
Tue 19 Nov 2013 04:39:36 PM UTC, comment #23: 

John,

Is it not true that the bad _controlfp call could
be in one of the libraries which are used by
both GUI and CLI?  The GUI could be making a
different call to something in the library.

Michael Godfrey <godfrey>
Group Member
Tue 19 Nov 2013 04:31:21 PM UTC, comment #22: 

Incorrect integer results are worse.

Has it been determined at what point the
register setting is required?

Michael Godfrey <godfrey>
Group Member
Tue 19 Nov 2013 06:26:35 AM UTC, comment #21: 

If we do decide to fix this problem by modifying the flag that controls precision of intermediate floating point ops, then should we worry about the possibility of some other code setting them (anyone can do it).  It seems like setting the fp flags for every operation 64-bit operation that uses floating point math to work would be slow.  But maybe we have no choice?  What's worse, a performance problem or incorrect integer math results?

John W. Eaton <jwe>
Group administrator
Tue 19 Nov 2013 06:22:25 AM UTC, comment #20: 

[I screwed it up again?  Srsly?]

Some library that is only linked with the GUI must be doing the equivalent of


  _controlfp (_PC_53, _MCW_PC);


Calling


  _controlfp (_PC_64, _MCW_PC);


Seems to avoid the problem.  I propose something like the attached patch.  We
should be able to get the declaration and constants from the MinGW float.h,
but we somehow aren't getting that version of float.h.  I don't know what the
right combination of -I magic is yet.  Someone else want to figure that one
out?  I already wasted a day on this problem.

Calling _controlfp any earlier than this doesn't seem to work.  So it looks
like something that is happening in QApplication::exec, but I'm not absolutely
sure that's correct.

I tried to find out what might be calling _controlfp by using nm on the
libraries in the mxe-octave build but the only ones that had that symbol or
_control87 were MinGW libraries that I think would be linked to both GUI and
CLI binaries.


(file #29659)

John W. Eaton <jwe>
Group administrator
Tue 19 Nov 2013 06:19:02 AM UTC, comment #19: 

[A botched verbatim command caused my previous comments to not appear correctly on the web.  --jwe]

Some library that is only linked with the GUI must be doing the equivalent of


_controlfp (_PC_53, _MCW_PC);
-verbatim+

Calling

+verbatim+
_controlfp (_PC_64, _MCW_PC);


Seems to avoid the problem.  I propose something like the attached patch.  We should be able to get the declaration and constants from the MinGW float.h, but we somehow aren't getting that version of float.h.  I don't know what the right combination of -I magic is yet.  Someone else want to figure that one out?  I already wasted a day on this problem.

Calling _controlfp any earlier than this doesn't seem to work.  So it looks like something that is happening in QApplication::exec, but I'm not absolutely sure that's correct.

I also tried to find out what might be calling _controlfp by using nm on the libraries in the mxe-octave build but the only ones that had that symbol or _control87 were MinGW libraries that I think would be linked to both GUI and CLI binaries.

(file #29658)

John W. Eaton <jwe>
Group administrator
Tue 19 Nov 2013 02:45:32 AM UTC, comment #18: 

Some library that is only linked with the GUI must be doing the equivalent of


_controlfp (_PC_53, _MCW_PC);
-verabtim-

Calling

+verbatim+
_controlfp (_PC_64, _MCW_PC);
-verabtim-

Seems to avoid the problem.  I propose something like the attached patch.  We should be able to get the declaration and constants from the MinGW float.h, but we somehow aren't getting that version of float.h.  I don't know what the right combination of -I magic is yet.  Someone else want to figure that one out?  I already wasted a day on this problem.

Calling _controlfp any earlier than this doesn't seem to work.  So it looks like something that is happening in QApplication::exec, but I'm not absolutely sure that's correct.

I tried to find out what might be calling _controlfp by using nm on the libraries in the mxe-octave build but the only ones that had that symbol or _control87 were MinGW libraries that I think would be linked to both GUI and CLI binaries.

(file #29656)

John W. Eaton <jwe>
Group administrator
Mon 18 Nov 2013 10:14:46 PM UTC, comment #17: 

I made the attached changes to try to diagnose why there is a difference between the GUI and CLI versions.

When I run it on my Windows system, I see the following results with the GUI version:


>> int64(2)^63-1
value: 2
rvalue: 2
cast value: 2
value: 9223372036854775808
thmax: 9223372036854774784
op: -
tx: 9223372036854775807
y:  1
tr: 9223372036854775808
value: 9223372036854775808
thmax: 9223372036854775807
ans = 9223372036854775807


I fail to understand how tr can be the result of tx - y.  The operator is clearly subtraction, so the result should be one less than tx.  But given the incorrect value of tx - y, the result is truncated back to the max value for int64.

Here's the result for the CLI version:


octave-cli.exe:1> int64(2)^63-1
value: 2
rvalue: 2
cast value: 2
value: 9223372036854775808
thmax: 9223372036854774784
op: -
tx: 9223372036854775807
y:  1
tr: 9223372036854775806
value: 9223372036854775806
rvalue: 9223372036854775806
cast value: 9223372036854775806
ans = 9223372036854775806


This result is what I expect -- you know, when you subtract one from a value, you get a value that is one less...
This also confirms that these operations are performed using long double on Windows systems.

How can long double operations be broken only when linking with the GUI libraries?

(file #29653)

John W. Eaton <jwe>
Group administrator
Mon 18 Nov 2013 06:04:00 PM UTC, comment #16: 

From the current evidence it appears that Rik's
comment #14 is closest to a possible cause.

In any case, this should be a blocker.

Michael Godfrey <godfrey>
Group Member
Mon 18 Nov 2013 05:57:57 PM UTC, comment #15: 

I upgraded the severity of this to Blocker for the 3.8. release.

Rik <rik5>
Group administrator
Mon 18 Nov 2013 05:32:08 PM UTC, comment #14: 

I suspect it only occurs in the GUI because when we build the GUI we link against a lot more external libraries.  I think the linker is looking for a function with the signature "minus (uint64, double)" and is finding something that matches in the extra libs instead of the function we have created to handle this.  But, this is just speculation.

Rik <rik5>
Group administrator
Mon 18 Nov 2013 05:15:09 PM UTC, comment #13: 

I was beginning to wonder the same thing when I saw the flintmax docs says:
On IEEE-754 compatible systems, 'flintmax' is 2^53 for "double".

My original comment showed that the uint64 issue exists for everything down to uint64(2)^54-1, but uint64(2)^53-1 worked.

Why only occurs in the GUI?

John Donoghue <lostbard>
Group Member
Mon 18 Nov 2013 04:47:00 PM UTC, comment #12: 

I think I see what is happening, but still no explanation for it.  Using the test case below:


>> uint64(2)^63-1
ans = 9223372036854775808
>> uint64(2)^63-uint64(1)
ans = 9223372036854775807


In the first case, mixed operations are supposed to coerce the double value into a uint64 value.  But this must not be happening.  Perhaps there is some other function signature in the symbol table that is matching the + operator and getting used instead.

Here is a bit more confirmation:


>> x = uint64(2)^63
ans = 9223372036854775808
>> plus (uint64(1), x)
ans = 9223372036854775809
>> plus (uint64(1), x, 1)
ans = 9223372036854775808
>> plus (uint64(1), x, uint64(1))
ans = 9223372036854775810
>> double (x)
ans =   9.2234e+018
>> format long
>> double (x)
ans =  9223372036854775808
>> ans + 1
ans =  9223372036854775808


Notice that in the three argument call "plus (uint64(1), x, 1)", x is getting cast to double rather than cast to uint64.  So 1 + double(x) + 1 returns just x because 1 is well below the machine precision of a double near 2^63.

Rik <rik5>
Group administrator
Mon 18 Nov 2013 01:23:29 PM UTC, comment #11: 

And why do these give different answers?

>> uint64(2)^63-1
ans = 9223372036854775808
>> uint64(2)^63-uint64(1)
ans = 9223372036854775807
>>



John Donoghue <lostbard>
Group Member
Mon 18 Nov 2013 12:55:39 PM UTC, comment #10: 

Just tried on Windows 8:
No fails for dec2base in the GUI (nor in the CLI).

If it helps, here's what I get on Win8 for John D's experiments:

>> a = uint64(2)^63-512
a = 9223372036854775296
>> a = uint64(2)^63-513
a = 9223372036854775295
>> a = uint64(2)^63
a = 9223372036854775808
>> a = a - 1
a = 9223372036854775807
>> a = a - 100
a = 9223372036854775707

..and...

>> uint64(2)^63
ans = 9223372036854775808
>> uint64(2)^63-1
ans = 9223372036854775807


This is the very same cross-built MinGW binary that I tested yesterday on XP and Win 7.

It starts too look like some obscure HW dependency.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 17 Nov 2013 10:47:21 PM UTC, comment #9: 

And:

>> a = uint64(2)^63-512
a = 9223372036854775808
>> a = uint64(2)^63-513
a = 9223372036854774784
>>


John Donoghue <lostbard>
Group Member
Sun 17 Nov 2013 10:44:42 PM UTC, comment #8: 

On mine, it fails in both _run_test_suite_ and test dec2base in GUI mode.

Also (on mine at least):

>> a = uint64(2)^63
a = 9223372036854775808
>> a = a - 1
a = 9223372036854775808
>> a = a - 100
a = 9223372036854775808
>>


John Donoghue <lostbard>
Group Member
Sun 17 Nov 2013 09:41:54 PM UTC, comment #7: 

@ comment #4:
Yes this looks to be a Windows all flavors GUI issue:

My tests in comment #1 were run in the GUI.
In the CLI, however, all dec2base tests pass - both invoking __run_test_suite.m and with "test dec2base". Same as Rik.

This is both on XP and Win7. Time permitting I might try tomorrow at work on Win8 as well but I think that's overkill.

If the Windows GUI code would modify FPU registers, why would _run_test_suite_.m results not be affected?

Philip Nienhuis <philipnienhuis>
Group Member
Sun 17 Nov 2013 08:53:56 PM UTC, comment #6: 

My cross build used -g O2


John Donoghue <lostbard>
Group Member
Sun 17 Nov 2013 08:25:23 PM UTC, comment #5: 

My recent MSVC build (loosely based on 929c95b33eae plus a few changes to fix MSVC compilation, changesets pending) does not seem to display the issue. Both CLI and GUI version runs "test dec2base" correctly.

Note that my build is compiled without any optimization and with debug enabled.

Michael Goffioul <goffioul>
Sun 17 Nov 2013 08:08:28 PM UTC, comment #4: 

Is is confirmed that this is Windows (all flavors?)
GUI only?

Is it possible that someone in the windows GUI
code is modifying the FPU registers?

Or is there any other explanation?

Michael Godfrey <godfrey>
Group Member
Sun 17 Nov 2013 07:57:36 PM UTC, comment #3: 

On my windows machine:

running octave-gui:

>> uint64 (2)^63-1
ans = 9223372036854775808


running octave-cli:

octave-cli.exe:3> uint64 (2)^63-1
ans = 9223372036854775807


John Donoghue <lostbard>
Group Member
Sun 17 Nov 2013 07:34:01 PM UTC, comment #2: 

All examples work for me on Windows XP using octave-cli.exe.  That is, running _run_test_suite_, running "test dec2base", and executing directly in the interpreter


assert (dec2base (uint64 (2)^63-1, 16), "7FFFFFFFFFFFFFFF")


On the other hand, I do get an error when running "test dec2base" under the GUI.  Maybe someone else can confirm that this is a GUI only problem, but that still leaves a very strange situation.

Rik <rik5>
Group administrator
Sun 17 Nov 2013 11:13:50 AM UTC, comment #1: 

Here it is a bit different:

On both my XP and Win7 box, dec2base succeeds when run in _run_test_suite_:


:
  strings\base2dec.m ..................................... PASS   12/12
  strings\bin2dec.m ...................................... PASS    9/9
  strings\blanks.m ....................................... PASS    8/8
  strings\cstrcat.m ...................................... PASS    6/6
  strings\deblank.m ...................................... PASS   10/10
  strings\dec2base.m ..................................... PASS   21/21
  strings\dec2bin.m ...................................... PASS    5/5
  strings\dec2hex.m ...................................... PASS    5/5
  strings\findstr.m ...................................... PASS    6/6
  strings\hex2dec.m ...................................... PASS    7/7
:


but does FAIL when run separately, like in your case.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 17 Nov 2013 02:39:37 AM UTC, original submission:  

On my fedora 19 building mxe-octave with current octave-dev 3.3.7+, (hg id 9799a996b2c1) installing on a Windows 7 machine and running _run_test_suite, the test for dec2base fails.

Run separately:

>> test dec2base
  ***** assert (dec2base (uint64 (2)^63-1, 16), "7FFFFFFFFFFFFFFF")
!!!!! test failed
ASSERT errors for:  assert (dec2base (uint64 (2) ^ 63 - 1, 16),"7FFFFFFFFFFFFFFF")
 Location  |  Observed  |  Expected  |  Reason
     []      8000000000000000   7FFFFFFFFFFFFFFF     Strings don't match


Looking at (uint64 (2)^63-1:

>> uint64(2)^63
ans = 9223372036854775808
>> uint64(2)^63-1
ans = 9223372036854775808

This is consistent with powers down to 54.

>> uint64(2)^54
ans = 18014398509481984
>> uint64(2)^54-1
ans = 18014398509481984
>>

With Powers less than that, the math works:

>> uint64(2)^53
ans = 9007199254740992
>> uint64(2)^53-1
ans = 9007199254740991


And this works:

>> uint64(2)^63
ans = 9223372036854775808
>> uint64(2)^63-uint64(1)
ans = 9223372036854775807
>>


John Donoghue <lostbard>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #29659:  diffs.txt added by jwe (937B - text/plain)
file #29658:  diffs.txt added by jwe (937B - text/plain)
file #29656:  diffs.txt added by jwe (937B - text/plain)
file #29653:  diffs.txt added by jwe (2KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by lostbard (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 20 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-11-26 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2013-11-26 rik5 StatusFixed In Progress
    2013-11-26 lostbard StatusIn Progress Fixed
    2013-11-26 rik5 StatusFixed In Progress
    2013-11-25 jwe Open/ClosedClosed Open
    2013-11-24 mtmiller StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2013-11-22 mtmiller StatusFixed Confirmed
        Open/ClosedClosed Open
    2013-11-22 lostbard StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2013-11-19 jwe Attached File- Added diffs.txt, #29659
    2013-11-19 jwe Attached File- Added diffs.txt, #29658
    2013-11-19 jwe Attached File- Added diffs.txt, #29656
    2013-11-18 jwe Attached File- Added diffs.txt, #29653
    2013-11-18 rik5 CategoryInterpreter GUI
        Severity3 - Normal 5 - Blocker
        Summarymxe-octave: 3.7.7+ test dec2base fails mxe-octave: mixed uint64/double arithmetic incorrect (GUI-only)
    2013-11-17 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code