bugGNU Octave - Bugs: bug #45945, Missing Matlab's special support...

 
 

bug #45945: Missing Matlab's special support for int64/uint64 integer literals

Submitter:  None
Submitted:  Sat 12 Sep 2015 07:03:02 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Chris Wellons Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 15 Jul 2021 08:00:34 AM UTC, comment #36: 

Seems to be working on all platforms for which we have CI.

Closing as fixed.

Markus Mützel <mmuetzel>
Group administrator
Wed 14 Jul 2021 08:23:12 PM UTC, comment #35: 

I thought the changes were made before we started the version 6 release series, but they were not made until after that so are not on the stable branch.  I pushed the new change to default here:

http://hg.savannah.gnu.org/hgweb/octave/rev/38c47f8f7cd6

John W. Eaton <jwe>
Group administrator
Wed 14 Jul 2021 07:01:11 PM UTC, comment #34: 

Thanks for the quick diff.
It appears to fix the problem for me, too.

Do I understand correctly that integer literals below `-flintmax()` don't work correctly without this patch (unless they are exactly representable in floating point precision)? In that case, I agree that it would be good to go on stable.

Just a minor change: There is a typo in "octave_magic_int" in the comment (duplicate "i").

Markus Mützel <mmuetzel>
Group administrator
Wed 14 Jul 2021 05:05:31 PM UTC, comment #33: 

The attached change appears to fix the problem for me.

I think unary minus only worked correctly after the initial changeset (ee9b1081471f) and the one that fixed the problem described in comments #26-28 (5b1143d1d74b).

Maybe this change should go on stable?


(file #51665)

John W. Eaton <jwe>
Group administrator
Wed 14 Jul 2021 09:18:45 AM UTC, comment #32: 

It looks like one of the tests with large integer literals is failing (after a bug in `assert` was fixed):

>> int64 (-9007199254740993)
ans = -9007199254740992
>> int64 (-flintmax ()) - 1
ans = -9007199254740993
>> assert (int64 (-9007199254740993),int64 (-flintmax ()) - 1)

error: ASSERT errors for:  assert (int64 (-9007199254740993),int64 (-flintmax ()) - 1)

  Location  |  Observed  |  Expected  |  Reason
     ()      -9007199254740992 -9007199254740992   Abs err 1 exceeds tol 0 by 1


Since the test passed (erroneously) previously, I don't know if this is a regression.

Re-opening report.

Markus Mützel <mmuetzel>
Group administrator
Mon 27 Jul 2020 03:24:20 AM UTC, comment #31: 

Can this issue be closed?  Seems like large integer literals are now supported at least as well as Matlab.

Rik <rik5>
Group administrator
Tue 21 Jul 2020 09:05:59 PM UTC, comment #30: 

On current Debian systems, I have to pass


CPPFLAGS=-I/usr/include/suitesparse -I/usr/include/hdf5/serial LDFLAGS=-L/usr/lib/x86_64-linux-gnu/hdf5/serial


to configure for it to find SuiteSparse and HDF5.  The buildbot config isn't using those options yet.  I'll see if I can fix it.

Even so, it should be possible to configure without HDF5 and still compile the new ov-magic-int.cc file.  I checked in the following change:

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

John W. Eaton <jwe>
Group administrator
Tue 21 Jul 2020 07:30:41 PM UTC, comment #29: 

All debian buildbots seems to be failing.
Is hdf5 too old over there? On fedora it is 1.10.5 

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 21 Jul 2020 07:11:03 PM UTC, comment #28: 

Thanks for the quick feedback.  I pushed the following additional changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/5b1143d1d74b

John W. Eaton <jwe>
Group administrator
Tue 21 Jul 2020 06:46:21 PM UTC, comment #27: 

In Matlab R2020a, I get this:

>> y = int64([int64(9223372036854775803); 9223372036854775804; 9223372036854775805; 9223372036854775806; 9223372036854775807])

y =

  5×1 int64 column vector

   9223372036854775803
   9223372036854775807
   9223372036854775807
   9223372036854775807
   9223372036854775807


Markus Mützel <mmuetzel>
Group administrator
Tue 21 Jul 2020 06:42:30 PM UTC, comment #26: 

I pushed the following changeset so that integers larger than flintmax get special treatment.  My change uses the method I described in comment #21.

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

After pushing and looking at this report again, I see one detail that I may have missed.  As shown in comment #23, Matlab does this:


>> y = int64([9223372036854775803; 9223372036854775804; 9223372036854775805; 9223372036854775806; 9223372036854775807])
y =
  9223372036854775807
  9223372036854775807
  9223372036854775807
  9223372036854775807
  9223372036854775807


and Octave will do the same.  However, Octave will also do this:


octave> y = int64([int64(9223372036854775803); 9223372036854775804; 9223372036854775805; 9223372036854775806; 9223372036854775807])
y =

  9223372036854775803
  9223372036854775804
  9223372036854775805
  9223372036854775806
  9223372036854775807


because after it sees the first int64() element and chooses the output type for the array, it is calling int64_value on the remaining elements instead of converting them to double first.  Is that what Matlab does as well, or does it treat the remaining elements as double values first, then convert to int64?  If so, then I expect the result to be


  9223372036854775803
  9223372036854775807
  9223372036854775807
  9223372036854775807
  9223372036854775807


with the class still being int64.  If someone can confirm, I think I see a simple fix.

John W. Eaton <jwe>
Group administrator
Tue 23 Aug 2016 03:25:37 PM UTC, comment #25: 

Good, thanks for the confirmation. So re comment #21, maybe we need a new token type to handle things that look like integers, store the integer value and special status, but convert the value back to a double if the value is used in any context other than being passed as a scalar to the actual int64 or uint64 functions, called directly as "int64" or "uint64".

Mike Miller <mtmiller>
Group Member
Tue 23 Aug 2016 10:42:53 AM UTC, comment #24: 

One more case I forgot to include:


>> int64(9223372036854775803):int64(9223372036854775807)
ans =
  9223372036854775803  9223372036854775804  9223372036854775805  9223372036854775806  9223372036854775807
>> class(ans)
ans =
int64


(again this is all tested in MATLAB R2016a)

Amro <amro_octave>
Tue 23 Aug 2016 10:36:52 AM UTC, comment #23: 

@mtmiller comment #16:

The case of array of literals:


>> y = int64([9223372036854775803; 9223372036854775804; 9223372036854775805; 9223372036854775806; 9223372036854775807])
y =
  9223372036854775807
  9223372036854775807
  9223372036854775807
  9223372036854775807
  9223372036854775807
>> class(y)
ans =
int64


same thing with the colon operator:


>> int64(9223372036854775803:9223372036854775807)
ans =
  9223372036854775807
>> class(ans)
ans =
int64


The above results are consistent with before, only when u?int64 is called with a scalar literal number then it is treated as a special case, everything else is first interpreted as double-type for the intermediate value before getting cast to the target class in the final result.

Another example is when combining elements of unlike classes:


>> [int64(9223372036854775803) 9223372036854775803]
ans =
  9223372036854775803  9223372036854775807
>> class(ans)
ans =
int64


So concatenating integers with numeric types always yields integers.
And when combining different integer types, all elements of the resulting matrix are given the data type of the left-most integer (MATLAB evaluates each element prior to concatenating them into a combined array).
These cases are documented here:
http://www.mathworks.com/help/matlab/matlab_prog/valid-combinations-of-unlike-classes.html
http://www.mathworks.com/help/matlab/matlab_prog/combining-unlike-integer-types.html

Amro <amro_octave>
Tue 23 Aug 2016 10:34:34 AM UTC, comment #22: 

@mtmiller comment #15:

(Everything below is tested in MATLAB R2016a on Windows x64)

The case of overloading with a class method:


>> x = foo;
>> y = x.int64(9223372036854775806)
foo
double
y =
     9.223372036854776e+18
>> z = 9223372036854775806;
>> isequal(y,z)
ans =
     1


The case of overloading with a package function:


>> z = 9223372036854775806;
>> y = mypkg.int64(9223372036854775806)
double
y =
     9.223372036854776e+18
>> isequal(y,z)
ans =
     1
>>
>> import mypkg.int64
>> y = int64(9223372036854775806)
double
double
y =
     9.223372036854776e+18
>> isequal(y,z)
ans =
     1


The case of overloading with a function handle:


>> int64 = @abs;
>> int64(9223372036854775806)
ans =
     9.223372036854776e+18
>> class(ans)
ans =
double
>> int64(-2)
ans =
     2
>> class(ans)
ans =
double


The case of indirectly calling int64 using a function handle:


>> int64(9223372036854775806)
ans =
  9223372036854775806
>> fcn = @int64;
>> fcn(9223372036854775806)
ans =
  9223372036854775807
>> class(ans)
ans =
int64
>> fcn(-2)
ans =
                   -2
>> class(ans)
ans =
int64


All the above confirm the fact that MATLAB treats "u?int64(literal-number)" as a special case only when called directly, non-overloaded, and with integer-like literal argument.
Your third example shows that it is likely not naively handled during parsing, but later on after resolving symbols and overloaded functions.

Amro <amro_octave>
Mon 22 Aug 2016 10:35:22 PM UTC, comment #21: 

Yeah, I don't think this is handled by special casing "int64" in the lexer.  That would cause other trouble anyway because functions may be overloaded, as you show.

I'm pretty sure the way to handle it is to store the int64 value and use it in certain contexts.  Weirdly, that apparently only applies to scalar contexts.

This seems similar to the way that "x(idx) = []" deletes elements from X, but "null = []; x(idx) = null" does not.  In Octave, we give "[]" special status until an assignment happens.  We could do something similar for integer literals.

John W. Eaton <jwe>
Group administrator
Mon 22 Aug 2016 09:24:53 PM UTC, comment #20: 

I some results back from someone with Matlab R2014. The script tested constructions like this


int64(9223372036854775804)
int64(9223372036854775804*1)
int64(9223372036854775804)*1
int64([9223372036854775803;9223372036854775804])
builtin('int64', 9223372036854775804)
myfcn = @int64;
myfcn(9223372036854775804)
int64 = @abs;
int64(9223372036854775804)


Only when a single literal number is enclosed within the parentheses, and only when the function being called is actually the function int64, is the value interpreted as an int64 literal value. These are the 1st and 3rd cases above. In all other cases, the value is parsed and stored as a double value first and passed to the int64 function (or abs function in the last case) as a double-valued argument.

In particular, the last case does not parse its argument as an int64 literal, even though to the parser it looks identical to the first case.

Mike Miller <mtmiller>
Group Member
Fri 19 Aug 2016 06:10:15 PM UTC, comment #19: 

unconventional question:

>> uint64(18446744073709551614)

ans = 18446744073709551614

>> uint64(18446744073709551614 * 1)

ans = 18446744073709551615

seems a case for a bug report to mathworks.
Or has this a serious background???

Ernst Reissner <ernstreissner>
Fri 19 Aug 2016 05:38:10 PM UTC, comment #18: 

This has already been covered in the bug log. To repeat, in Matlab:



>> uint64(18446744073709551614)
ans = 18446744073709551614
>> uint64(18446744073709551614 * 1)
ans = 18446744073709551615
>> uint64(18446744073709551614.0)
ans = 18446744073709551615


I would like to know what Matlab does with uint64(array-literal-expression).

Mike Miller <mtmiller>
Group Member
Fri 19 Aug 2016 04:53:01 PM UTC, comment #17: 

@Mike,
could you explain me why we need considering a token within the int64 function??
What if we have int64(a very complicated expression)?
This treated in the parser????

Ernst Reissner <ernstreissner>
Fri 19 Aug 2016 03:45:40 PM UTC, comment #16: 

Also WDMD with arrays of literals:


>> int64([9223372036854775803 9223372036854775804 9223372036854775805 9223372036854775806 9223372036854775807])
>> class(ans)


Mike Miller <mtmiller>
Group Member
Fri 19 Aug 2016 03:43:37 PM UTC, comment #15: 

Rik and jwe: re your earlier comments about avoiding treating the function name as a special token, and just looking at the number of digits in the number, notice what is shown in comment #1. To be Matlab compatible, the number should be treated as a int64/uint64 constant if and only if it is appears as the only token within the int64/uint64 function.

Still I'd be curious for some more Matlab testing. WDMD:



@foo/foo.m:

classdef foo < handle
end

@foo/int64.m:

function z = int64(x, y)
  disp(class(x));
  disp(class(y));
  z = y;
end

+mypkg/int64.m:

function z = int64(x)
  disp(class(x));
  z = x;
end

>> x = foo;
>> y = x.int64(9223372036854775806)

>> mypkg.int64(9223372036854775806)
>> import mypkg.int64
>> int64(9223372036854775806)

%% New session

>> int64 = @abs;
>> int64(9223372036854775806)
>> class(ans)
>> int64(-2)
>> class(ans)


>> fcn = @int64;
>> fcn(9223372036854775806)
>> class(ans)
>> fcn(-2)
>> class(ans)


Mike Miller <mtmiller>
Group Member
Thu 18 Aug 2016 11:42:57 AM UTC, comment #14: 

Another thought:
It is no lexer problem:
I think, the lexer/parser shall treat signed floating point numbers which include signed and unsigned integers.

It is the interpreter which turns this into a number.
I cannot see a problem that a number literal may result in different types.
This may occur for any other expression also including functions.

Ernst Reissner <ernstreissner>
Thu 18 Aug 2016 11:30:32 AM UTC, comment #13: 

Maybe I do not fully understand the problem but I have the impression that octaves favorite scalar type is double.
Thus for literals no matter whether we have 42 or 42.0,
this is a double although it fits into an int8 and into a single also.
This is appropriate for all numeric types but two:
int64 and uint64, because mantissa length of double is 53,
whereas for uint64 it is 64 and for int64 it is 63.
All other types fit into double.

I would expect that all is ok, if the parser checks
whether the literal fits into a double.
If so it is treated as a double.
Otherwise it is checked whether it fits into an int64.
If so, it is an int64.
Else it is checked whether it fits into an uint64.
If so, it is an uint64.
Else it is an error.
Maybe it is a question how to treat a number which is written as a float whereas it is an integer like 42.0 or what.

Ernst Reissner <ernstreissner>
Mon 18 Apr 2016 04:00:59 PM UTC, comment #12: 

I am going to post the part that fixes bug #47690 at that bug report.

The rest that would be necessary to fix this bug is probably a too far reach for me.

Markus Mützel <mmuetzel>
Group administrator
Fri 15 Apr 2016 08:10:25 PM UTC, comment #11: 

Mike:
Thank you for your hints. With your changes, this patch fixes bug #47690 on Windows.

However, I cannot track down where the conversion of the unsigned long integer from the lexer to the double value happens in the code. Do you know where to look for this?

(file #36944)

Markus Mützel <mmuetzel>
Group administrator
Fri 15 Apr 2016 03:29:46 PM UTC, comment #10: 

This bug is not Windows specific, but bug #47690 is. They are similar but not the same.

Mike Miller <mtmiller>
Group Member
Fri 15 Apr 2016 03:27:19 PM UTC, comment #9: 

Sorry. I did not realize that this problem was Windows only and compared 4.0.1 on Windows with my patch on Ubuntu (d'oh). Cross-building right now.

Markus Mützel <mmuetzel>
Group administrator
Fri 15 Apr 2016 03:27:00 PM UTC, comment #8: 

Just a quick note, I don't think using "%lx" is universally safe for reading values of type uintmax_t (e.g. it should be "%llx" on 32-bit architectures).

According to POSIX, the "j" prefix should work for integers of type intmax_t or uintmax_t, for example:


nread = sscanf (tmptxt, "%jx", &li);


It would also be nice if this variable were named "long_int_value" or something readable than "li".

Mike Miller <mtmiller>
Group Member
Fri 15 Apr 2016 03:04:11 PM UTC, comment #7: 

The attached patch adds support for uint64 integers to the lexer. It should handle hexadecimal and binary input correctly without truncating to 32bit max. It does not change anything on the precission issues with high numbers.

Without patch:

>> format hex
>> uint64 (0xffffffffffffffff)
ans =  0 0 0 0ffffffff


With this patch:

>> format hex
>> uint64 (0xffffffffffffffff)
ans = ffffffffffffffff


However, the following still is the case:

>> uint64 (0xfffffffffffffffe)
ans = ffffffffffffffff


The value is still cast to double.

>> class (0xffffffffffffffff)
ans = double


And that should not change (or probably lots of things could break).
Maybe changing "unsigned long" to "uintmax_t" for the hex parser would have done the same job (I did not try).
However, now it would be possible to additionally store the integer value in the octave_value<double> class that could lateron be accessed (exclusively) by builtin integer functions. Thus, we could achieve the same results as Matlab without changing anything on the frontend.
The lexer should be prepared for reading and processing (high) integers with this patch.

How would octal numbers be entered? I did not find a special case for them.

(file #36941)

Markus Mützel <mmuetzel>
Group administrator
Fri 23 Oct 2015 11:54:51 PM UTC, comment #6: 

That's fine.  Method 1 would also only have worked for (u)int64 constants, and not more generally for long hex and binary constants.

Rik <rik5>
Group administrator
Fri 23 Oct 2015 08:50:07 PM UTC, comment #5: 

I'd rather not treat function names in the lexer or parser as special if at all possible because it is possible for them to be overloaded, possibly at run time even when the function is not overloaded when the lexer sees the name.

Given the functions


function y = uint64 (x)
  y = x;
end

function x = f ()
  x = uint64 (18446744073709551614);
end


and the statement


class (f ())


when uint64 is initially not in the load path and again after uint64 is added to the load path?

John W. Eaton <jwe>
Group administrator
Fri 23 Oct 2015 04:46:44 PM UTC, comment #4: 

It will undoubtedly get messier in the actual implementation, but I can see at least two ways to tackle this

1) Find the pattern (u)int64 in the lexer, possible using state code prefixed to patterns, and convert the number that follows into (u)int64 rather than double.  We don't need to worry about the other integer families like int32 because they can always be represented correctly by a double.

2) In the handle_number routine in lex.ll we can find the length of the string representing the number to be converted.  If it is hex and greater then 13 characters, then convert to an int64.  If it is binary and greater than 53 characters, then convert to int64.  If it is decimal and greater than 16 characters (log10(2^53), convert to an int64.

Might work.  Might still require tweaking the parser as well if it is always expecting an object of type double rather than an octave_value.  Could get around that, possibly, by using a union type.

Rik <rik5>
Group administrator
Wed 16 Sep 2015 12:46:52 PM UTC, comment #3: 

I agree that hexadecimal or octal integer literals should handle 64-bit values.

I had no idea that integer literals in Matlab were handled in some special way.

Before adding special treatment for int64 and uint64 in the parser, maybe there is something else that can be done?  I'm thinking that special treatment of those symbols in the parser will cause trouble with overloading those functions?  I'm not sure about that, but it's my initial reaction so I would proceed with some caution here.

John W. Eaton <jwe>
Group administrator
Mon 14 Sep 2015 10:21:43 AM UTC, comment #2: 

Oh, I also noticed that Octave supports 0x... to directly enter unsigned integers in hex format, but in my version it only goes up to 32-bit.


% Octave 4.0.0
>> format long
>> 0xffff
ans =  65535
>> 0xffffffff
ans =  4294967295
>> 0xffffffffffffffff
ans =  4294967295
>> intmax('uint32')
ans = 4294967295


Amro <amro_octave>
Mon 14 Sep 2015 10:14:58 AM UTC, comment #1: 

This really comes down to a weakness in the MATLAB/Octave language syntax; there is no (documented) way to directly specify integer literals. Other languages have suffixes like U, L, and LL for this purpose...

I guess MATLAB solved this issue by having a special case when calling the u?int(8|16|32|64) functions specifically with a literal integer.


% MATLAB
>> format hex
>> intmax('uint64')
ans =
   ffffffffffffffff
>> uint64(18446744073709551614)    # special case in MATLAB
ans =
   fffffffffffffffe
>> uint64(18446744073709551614.0)  # usual interpretation
ans =
   ffffffffffffffff


Octave however isn't doing anything special, and instead first interprets the literal number as double type (as usual), and then casts the temporary value to uint64. There is an entry on the wiki FAQ: http://wiki.octave.org/FAQ#How_do_I_make_Octave_use_more_precision.3F

Now the reason the number comes out as ...615 instead of ...614 is obviously explained by the limitations of IEEE754 double-precision floating-point format. Integers up to 2^53 can be exactly represented as double, above that there is gap of one between every representable integer-valued floating-point. The gap doubles every time we go up by one exponent (2^54, 2^55, etc...). In this case the number you used is one less than intmax('uint64') (2^64-2 to be exact). So according to the default "round-to-nearest" floating-point rounding mode, it ends up getting rounded along with a bunch of nearby numbers all rounded to the same value of ...615 (I think at that range the gaps are 2048 and 4096, half of 2048 rounded up, and half of 4096 rounded down, middle value resolved with a tie-breaker rule).


% MATLAB
>> format hex
>> [18446744073709550591; 18446744073709550592; (18446744073709551614); 18446744073709553664; 18446744073709553665]
ans =
   43efffffffffffff
   43f0000000000000
   43f0000000000000   % your value
   43f0000000000000
   43f0000000000001


As for STR2NUM, it actually uses EVAL to parse the input (both MATLAB and Octave), so it's expected to behave similar to typing the commands on the prompt directly..

The solution in this case is to use a bignum library (like the Symbolic Math Toolbox in MATLAB). I think there are some wrappers for GNU GMP and GNU MPFR libraries for Octave that provide arbitrary precision integer and float numbers.

Amro <amro_octave>
Sat 12 Sep 2015 07:03:02 PM UTC, original submission:  

In Octave:


octave:1> uint64(18446744073709551614)
ans = 18446744073709551615


But in Matlab I get:


ans = 18446744073709551614


This behavior is not documented by MathWorks, but from experimentation it looks like the Matlab interpreter treats conversion functions as special when the argument is an integer-like literal. It doesn't use an intermediate double-precision value as you would expect. For example, make it any expression at all and Octave and Matlab will agree on the output, due to the intermediate double result:


octave:4> uint64(18446744073709551614 * 1)
ans = 18446744073709551615


It's weird, but it's at least a way to specify an integer literal, otherwise absent from the language.

Very similarly, Octave and Matlab disagree on str2num here:


str2num('uint64(18446744073709551614)')


Ran into all this when I was trying to put large integer values in my code.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #51665:  magic-int-diffs.txt added by jwe (892B - text/plain)
file #36944:  lexer_uint_v2.patch added by mmuetzel (7KiB - text/x-diff)
file #36941:  lexer_uint.patch added by mmuetzel (7KiB - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by apjanke (subscribing to CC list)
  • -email is unavailable- added by ernstreissner (Posted a comment)
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by amro_octave (Posted a comment)
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by None (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 18 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-07-15 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-07-14 jwe StatusConfirmed Ready For Test
    2021-07-14 jwe Attached File- Added magic-int-diffs.txt, #51665
    2021-07-14 mmuetzel StatusFixed Confirmed
        Open/ClosedClosed Open
        Operating SystemGNU/Linux Any
    2020-07-27 jwe StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-07-21 jwe StatusConfirmed Ready For Test
    2019-01-12 apjanke Carbon-Copy- Added -email is unavailable-
    2016-08-22 mtmiller SummaryMissing Matlab's special support for integer literals Missing Matlab's special support for int64/uint64 integer literals
    2016-08-17 mtmiller Dependencies- bugs #48804 is dependent
    2016-04-15 mmuetzel Attached File- Added lexer_uint_v2.patch, #36944
    2016-04-15 mmuetzel Attached File- Added lexer_uint.patch, #36941
    2015-10-23 rik5 Item GroupWTF, Matlab?!? Matlab Compatibility
    2015-09-12 mtmiller StatusNone Confirmed
        Release3.8.2 dev

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code