date:20160712

[Issue 16274] The curses of debugging: short argument passed in 16-bit register, against ABI

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16274

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ag0ae...@gmail.com

--

[Issue 16274] The curses of debugging: short argument passed in 16-bit register, against ABI

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16274

Luís Marques  changed:

   What|Removed |Added

   Hardware|x86 |x86_64
   Severity|enhancement |major

--- Comment #1 from Luís Marques  ---
(I'm using the latest DMD, v2.071.1, although this problem has existed for
quite a while)

--

[Issue 16274] New: The curses of debugging: short argument passed in 16-bit register, against ABI

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16274

  Issue ID: 16274
   Summary: The curses of debugging: short argument passed in
16-bit register, against ABI
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: l...@luismarques.eu

On my system (OS X 10.11.5 (15F34), 64-bit), if you compile (with DMD) and run
the following program you'll get an executable that behaves incorrectly about
half of the executions:

extern(C)
{
void* initscr();
int start_color();
int init_pair(short pair, short f, short b);
int attron(int attrs);
int mvprintw(int y, int x, const(char)* fmt, ...);
int attroff(int attrs);
int getch();
int endwin();
int refresh();
}

enum
{
COLOR_BLACK   = 0,
COLOR_RED = 1,
COLOR_GREEN   = 2,
COLOR_YELLOW  = 3,
COLOR_BLUE= 4,
COLOR_MAGENTA = 5,
COLOR_CYAN= 6,
COLOR_WHITE   = 7
}

int COLOR_PAIR(int n)
{
return n << 8;
}

void main()
{
initscr();
start_color();
init_pair(1, COLOR_WHITE, COLOR_BLUE);
int pair = COLOR_PAIR(1);
attron(pair);
mvprintw(1, 1, "Test");
attroff(pair);
refresh();
getch();
endwin();
}

$ rdmd -L-lcurses test.d

If all is well, you'll see the text "Test" in white text on a blue background.
If the bug is exercised then you won't see any text. Sometimes it takes quite a
few number of executions until it starts or stops exhibiting the problem.

This reduced text case was taken very painstakingly from a large codebase,
where changing unrelated things around would make the problem come and go ---
probably; it was sometimes hard to tell, given the non-deterministic bug.

Currently, it seems that this program always works fine when using LDC,
although my vague recollection is that this wasn't true when I had last looked
at this issue (which was before the latest LDC). That might be because of the
following difference in compilation:

LDC:
__Dmain:
subq$0x38, %rsp
callq   _initscr
movq%rax, 0x28(%rsp)
callq   _start_color
movl$0x1, %edi   <---
movl$0x7, %esi   <---
movl$0x4, %edx  <---
movl%eax, 0x24(%rsp)
callq   _init_pair

DMD:
__Dmain:
pushq   %rbp
movq%rsp, %rbp
subq$0x10, %rsp
callq   _initscr
callq   _start_color
movw$0x4, %dx  <---
movw$0x7, %si<---
movw$0x1, %di   <---
callq   _init_pair

And indeed, if you change the code to the following the problem goes away:

void main()
{
initscr();
start_color();

asm
{
xor EDX, EDX;
xor ESI, ESI;
xor EDI, EDI;
}

init_pair(1, COLOR_WHITE, COLOR_BLUE);
int pair = COLOR_PAIR(1);
attron(pair);
mvprintw(1, 1, "Test");
attroff(pair);
refresh();
getch();
endwin();
}

I guess the ABI requires the whole register to be used for a 16-bit value?

The docs for my system say "The OS X x86-64 function calling conventions are
the same as the function calling conventions described in System V Application
Binary Interface AMD64 Architecture Processor Supplement, found at
http://people.freebsd.org/~obrien/amd64-elf-abi.pdf. See that document for
details."

In that document I found the following:

• Arguments of types (signed and unsigned) _Bool, char, short, int,
long, long long, and pointers are in the INTEGER class

 (...)

2. If the class is INTEGER, the next available register of the sequence
%rdi,
%rsi, %rdx, %rcx, %r8 and %r9 is used

So I guess this is a DMD code generation bug?

--

[Issue 16251] regex - `(..).*\1` doesn't match "axxxx"

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16251

--- Comment #2 from Vladimir Panteleev  ---
(In reply to TJ Ryan from comment #1)
> The regex module doesn't appear to
> currently support any context sensitive tokens.

What makes you say that?

--

[Issue 16272] Yield like semantics for function execution

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16272

--- Comment #2 from teddybear12...@gmail.com ---
(In reply to Mathias Lang from comment #1)
> This is already possible using a library solution, see
> https://dlang.org/phobos/std_concurrency.html#.Generator

I believe their is a subtle difference. I could be mistaken because I don't
know the depth of fibers.

Fibers are more concurrency related and imitate a task switch. In this case
with functions, no task switching like behavior is needed. Just a push and pop
of the locals and a few other little things. It may be exactly what a fiber
does though?

I'm thinking it is more like thread(heavy) > fiber(medium) > functional
yield(light weight).

--

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=14251

--- Comment #8 from Walter Bright  ---
(In reply to ZombineDev from comment #7)
> The OP issue doesn't mention class monitors. The bug also affects raw sync
> primitives like core.sync.mutex and in general everything using
> Object.IMonitor.

'Klass' is a class, and so has a class monitor.

--

[Issue 16273] New: [REG 2.072a] dmd segfault with inheritance, templates, override

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16273

  Issue ID: 16273
   Summary: [REG 2.072a] dmd segfault with inheritance, templates,
override
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: ice
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Compiles up to 2.071. Git head dmd (24f0d1c) segfaults.


class A()
{
alias MyD = D!();
}

class B
{
void f() {}
alias MyA = A!();
}

class C : B
{
override void f() {}
}

class D() : A!()
{
void g() { new C; }
}


--

[Issue 16272] Yield like semantics for function execution

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16272

Mathias Lang  changed:

   What|Removed |Added

 CC||mathias.l...@sociomantic.co
   ||m

--- Comment #1 from Mathias Lang  ---
This is already possible using a library solution, see
https://dlang.org/phobos/std_concurrency.html#.Generator

--

[Issue 16272] New: Yield like semantics for function execution

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16272

  Issue ID: 16272
   Summary: Yield like semantics for function execution
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: teddybear12...@gmail.com

In some cases it would be nice to break the execution flow of a function and
re-continue at a later time. This reduces bloat and complexity.


int A(int i)
{
...
?yield;
...
?yield;
...
?yield;
...
return 0;
}

void B()
{
int x = 3;
auto uuid = yield A(ref x)  // Calls A but activates ?yields
//returns from A after first ?yield
...
x = 6;
continue!uuid(A(ref x)) // continues
// returns from A after second ?yield
...
continue!uuid(A(ref x));
// returns from A after third ?yield
...   
break!uud(A()); 
// breaks out of A as it A executed a return statement. No return value is
given.


}

All inputs to A are by ref when yielding so they can be modified. The break is
optional but allows one to terminate execution of the function.  Every continue
must match a ?yield up to a break.

uuid's are simply ways to identify different function execution strains.

Does this allow for total chaos if used wrong? Yes! It's more valuable to
create simple and complex state machines very effectively with minimal work and
better understanding of the complexity. Each ?yield statement can be seen as a
pause in the state machine between transitions.

--

[Issue 16268] Wrong optimization in code with integer overflow

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16268

Lodovico Giaretta  changed:

   What|Removed |Added

 CC||lodov...@giaretart.net

--- Comment #1 from Lodovico Giaretta  ---
Looking at the generated assembly, it looks like, as a check x >= 0 is
performed before entering the loop, the compiler establishes that overflow will
not happen while condition i <= x holds (with x not negative).
Of course this is false for the edge case of x = typeof(x).max.

00  push   rbp
01  movrbp,rsp
04  push   rbx
05  push   r12
07  movr12,rdi
0a  xorebx,ebx ; i = 0
0c  test   r12b,r12b
0f  js 21  ; if x < 0 skip for loop
11  movsx  edi,bl
15  call  ; call writeln
1a  incbl  ; i++
1c  cmpbl,r12b
1f  jle11  ; if i <= x continue for loop
21  popr12
23  poprbx
24  poprbp
25  ret

--

[Issue 16271] New: Should be able to express that a lambda returns by reference

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16271

  Issue ID: 16271
   Summary: Should be able to express that a lambda returns by
reference
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

This literal takes one parameter by ref and the other by value, and returns by
value:

(ref x, y) { x += y; return x; }
function (ref x, y) { x += y; return x; } // alternative

There is no way to specify that we want it to return e.g. x by reference. These
syntaxes do not work:

function ref (ref x, y) { x += y; return x; }
function ref typeof(x) (ref x, y) { x += y; return x; }

I think the first one should work. For that, the "return" attribute will also
be deduced.

--

[Issue 16270] New: scoped Alignment

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16270

  Issue ID: 16270
   Summary: scoped Alignment
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: teddybear12...@gmail.com

C++ has the ability to align all members of struct/class in a scope: e.g.,
#pragma pack(push,16)

Without this in D, it requires aligning each type manually. It may seem like
trivial work, but it is not and posses serious problems when converting C code
that uses scoped alignment. 

A simple

align(n)
{
   struct x { int a, b, c; }
}

would be identical do

align(n) struct x
{
   align(n)
  int a, b, c;
}

It should be a trivial enhancement.  I'm only concerned about the member
alignment.

Alternatives are


align(n)
{
   struct x { int a, b, c; }
}

would be identical do

struct x
{
   align(n)
  int a, b, c;
}

or

malign(n)
{
   struct x { int a, b, c; }
}

would be identical do

struct x
{
   align(n)
  int a, b, c;
}



pragma could be used



pragma(align(n)) 

struct x { int a, b, c; }
struct y { int a, b, c; }

pragma(align(m)) 
struct z { int a, b, c; }



would be identical do

struct x
{
   align(n)
  int a, b, c;
}

struct y
{
   align(n)
  int a, b, c;
}

struct z
{
   align(m)
  int a, b, c;
}


The responses that a simply search and replace are not acceptable. It is not
robust, may quietly fail, etc. Adding by hand to every struct or member is also
not acceptable because because it depends on size. (trivial for one struct but
not so for 100 structs)

I believe this is not an enhancement but an oversight.  It is required for
large complex code unless man hours is not a factor.

--

[Issue 16269] add `aa.clear!true` method to associative array to clear and initialize it

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16269

--- Comment #3 from Ketmar Dark  ---
p.s. i created this ER in the hope that people will talk about API too: i'm
usually sux at inventig APIs.

--

[Issue 16269] add `aa.clear!true` method to associative array to clear and initialize it

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16269

--- Comment #2 from Ketmar Dark  ---
i just thought that `.clear!true` is better. i don't know why: probably 'cause
i just love D templates and want to use 'em everywhere. ;-)

still, it's a matter of simple renaming, i don't have real API preferences
here. something like `.clear!(init:true)` may be better, but D doesn't support
that. T_T

--

[Issue 16269] add `aa.clear!true` method to associative array to clear and initialize it

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16269

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
Thanks. I don't love the API. aa.clear!true is not "clear" (pun not intended)
on what it is doing as opposed to aa.clear.

I like the idea though -- have a function that clears, and if it's not
allocated, do that too. Why not use your internal name: clearInit?

--

[Issue 16269] add `aa.clear!true` method to associative array to clear and initialize it

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16269

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 16269] New: add `aa.clear!true` method to associative array to clear and initialize it

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16269

  Issue ID: 16269
   Summary: add `aa.clear!true` method to associative array to
clear and initialize it
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

q patch:


diff --git a/src/object.d b/src/object.d
index 40e2391..f2f29de 100644
--- a/src/object.d
+++ b/src/object.d
@@ -1876,6 +1876,7 @@ extern (C)
 inout(void)[] _aaKeys(inout void* p, in size_t keysize, const TypeInfo
tiKeyArray) pure nothrow;
 void* _aaRehash(void** pp, in TypeInfo keyti) pure nothrow;
 void _aaClear(void* p) pure nothrow;
+void _aaClearInit(void* p, const TypeInfo_AssociativeArray ti) pure
nothrow;

 // alias _dg_t = extern(D) int delegate(void*);
 // int _aaApply(void* aa, size_t keysize, _dg_t dg);
@@ -1914,9 +1915,20 @@ void clear(T : Value[Key], Value, Key)(T aa)
 _aaClear(*cast(void **) );
 }

-void clear(T : Value[Key], Value, Key)(T* aa)
+void clear(bool doalloc:true, T : Value[Key], Value, Key)(ref T aa)
 {
-_aaClear(*cast(void **) aa);
+static if (!doalloc)
+_aaClear(*cast(void **) );
+else
+_aaClearInit(cast(void **) , typeid(T));
+}
+
+void clear(bool doalloc=false, T : Value[Key], Value, Key)(T* aa)
+{
+static if (!doalloc)
+_aaClear(*cast(void **) aa);
+else
+_aaClearInit(*cast(void **) , typeid(T));
 }

 T rehash(T : Value[Key], Value, Key)(T aa)
diff --git a/src/rt/aaA.d b/src/rt/aaA.d
index cf8943e..2e5a3a1 100644
--- a/src/rt/aaA.d
+++ b/src/rt/aaA.d
@@ -443,6 +443,20 @@ extern (C) void _aaClear(AA aa) pure nothrow
 }
 }

+/// Remove all elements from AA, allocate new AA if it isn't allocated yet.
+extern (C) void _aaClearInit(AA* aa, const TypeInfo_AssociativeArray ti)
+{
+if (!aa.empty)
+{
+aa.impl.clear();
+}
+else if (aa.impl is null)
+{
+  // alloc implementation
+  aa.impl = new Impl(ti);
+}
+}
+
 /// Rehash AA
 extern (C) void* _aaRehash(AA* paa, in TypeInfo keyti) pure nothrow
 {
-- 
2.9.0

--

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=14251

Lodovico Giaretta  changed:

   What|Removed |Added

 CC||lodov...@giaretart.net

--- Comment #6 from Lodovico Giaretta  ---
(In reply to Walter Bright from comment #5)
> I'm not convinced this is a bug. The _monitor field is one that is totally
> managed by the language, and it outside of its rules.

That is true. But having "logically inexistent" fields with different
attributes from "normal" fields means that these attributes can not be
"physically" exploited, but only "logically" enforced.

E.g.: if an immutable object has a mutable mutex, than an immutable object
cannot reside in read-only memory.

So it's a tradeoff, and it must be clearly defined what is D's way here.

--

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=14251

--- Comment #7 from ZombineDev  ---
The OP issue doesn't mention class monitors. The bug also affects raw sync
primitives like core.sync.mutex and in general everything using
Object.IMonitor.

--

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=14251

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #5 from Walter Bright  ---
I'm not convinced this is a bug. The _monitor field is one that is totally
managed by the language, and it outside of its rules.

--

[Issue 16268] Wrong optimization in code with integer overflow

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16268

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ag0ae...@gmail.com

--

[Issue 16268] New: Wrong optimization in code with integer overflow

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16268

  Issue ID: 16268
   Summary: Wrong optimization in code with integer overflow
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: guillaume.bouche...@outlook.com

The following program behaves incorrectly when compiled with "-O":

import std.stdio;

void f(byte x)
{
for (byte i = 0; i <= x && i >= 0; ++i)
{
assert(i >= 0);
writeln(i);
}
}

void main()
{
f(byte.max);
}

Compiled without flags, this program prints the numbers from 0 to 127 and
terminates.

Compiled with "-O", this program prints the numbers from 0 to 127, and then
repeats -128, -127, ..., 127 infinitely.  It does not terminate.

The program should print the numbers from 0 to 127 once.  Signed overflow is
defined behaviour, therefore "i >= 0" can not be assumed to be true.  Note how
even the assertion is ignored.

Same problem happens with short and int instead of byte.

If one replaces 0 with 1, the program prints 0..127, -128..-1 and terminates. 
It should only print 1..127.

(DMD v2.071.1)

--

[Issue 12558] try/catch allows implicit catching of Errors without specifying any Exception type

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=12558

--- Comment #18 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/458ff506e385c05c8eb9f08b6915267c662780c3
Issue 12558 - Document implicit catch statement deprecation

See dlang/dmd#5183

https://github.com/dlang/dlang.org/commit/51b3a5808c191dd2d04ebdf718d3f411c1468b6c
Merge pull request #1423 from Geod24/throwable

Issue 12558 - Document implicit catch statement deprecation

--

[Issue 16227] std.numeric unit tests fail when run in isolation

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16227

TJ Ryan  changed:

   What|Removed |Added

 CC||tjfr...@outlook.com

--- Comment #1 from TJ Ryan  ---
Throwing `writeln(!e);` before the `if (!e) continue;` on line 1943 of
numeric.d somehow got the unittest to pass.  What's more interesting is that
every time the continue is taken, !e is reported to be false.

--

[Issue 16251] regex - `(..).*\1` doesn't match "axxxx"

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16251

TJ Ryan  changed:

   What|Removed |Added

 CC||tjfr...@outlook.com

--- Comment #1 from TJ Ryan  ---
The \1 token isn't context free.  The regex module doesn't appear to currently
support any context sensitive tokens.

--

[Issue 16264] BigInt multiplication crashes on 64-bit (biguintnoasm.d(276): Range violation)

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16264

Kirill Kryukov  changed:

   What|Removed |Added

 CC||kkryu...@gmail.com

--

[Issue 11599] BigInt crashes on very large operations.

2016-07-12 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=11599

Kirill Kryukov  changed:

   What|Removed |Added

 CC||kkryu...@gmail.com

--- Comment #2 from Kirill Kryukov  ---
This might be same (or related) with the newly reported bug #16264 (
https://issues.dlang.org/show_bug.cgi?id=16264 ). Bug #16264 has a slightly
more reduced test case and a table of affected operand sizes.

--

[Issue 16274] The curses of debugging: short argument passed in 16-bit register, against ABI

[Issue 16274] The curses of debugging: short argument passed in 16-bit register, against ABI

[Issue 16274] New: The curses of debugging: short argument passed in 16-bit register, against ABI

[Issue 16251] regex - `(..).*\1` doesn't match "axxxx"

[Issue 16272] Yield like semantics for function execution

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

[Issue 16273] New: [REG 2.072a] dmd segfault with inheritance, templates, override

[Issue 16272] Yield like semantics for function execution

[Issue 16272] New: Yield like semantics for function execution

[Issue 16268] Wrong optimization in code with integer overflow

[Issue 16271] New: Should be able to express that a lambda returns by reference

[Issue 16270] New: scoped Alignment

[Issue 16269] add `aa.clear!true` method to associative array to clear and initialize it

[Issue 16269] add `aa.clear!true` method to associative array to clear and initialize it

[Issue 16269] add `aa.clear!true` method to associative array to clear and initialize it

[Issue 16269] add `aa.clear!true` method to associative array to clear and initialize it

[Issue 16269] New: add `aa.clear!true` method to associative array to clear and initialize it

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

[Issue 16268] Wrong optimization in code with integer overflow

[Issue 16268] New: Wrong optimization in code with integer overflow

[Issue 12558] try/catch allows implicit catching of Errors without specifying any Exception type

[Issue 16227] std.numeric unit tests fail when run in isolation

[Issue 16251] regex - `(..).*\1` doesn't match "axxxx"

[Issue 16264] BigInt multiplication crashes on 64-bit (biguintnoasm.d(276): Range violation)

[Issue 11599] BigInt crashes on very large operations.

27 matches

Site Navigation

Mail list logo

Footer information