[Issue 15548] [Home] Interaction with the code box adds vertical space

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull
 CC||thecybersha...@gmail.com

--- Comment #4 from Vladimir Panteleev  ---
https://github.com/D-Programming-Language/dlang.org/pull/1206

--

[Issue 15550] [Reg 2.070.0-b1] compile error while testing template constraint

[via Digitalmars-d-bugs]

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

ponce  changed:

   What|Removed |Added

 CC||alil...@gmail.com

--- Comment #3 from ponce  ---
Thanks Martin for reporting this!

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

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

--- Comment #17 from Ketmar Dark  ---
this will pollute module scope with imported symbols.

imagine that i have `mymodule.foo (float v)` function, and defined local `foo
(int v)` function. with your "hidden global import" whenever i'll import
"mymodule", it will add unexpected `foo` overload for the whole code.

also, it breaks "module importing orger doesn't matter" rule.

--

[Issue 15550] [Reg 2.070.0-b1] compile error while testing template constraint

[via Digitalmars-d-bugs]

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

--- Comment #5 from ponce  ---
Found a work-around.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

--- Comment #18 from timon.g...@gmx.ch ---
(In reply to Ketmar Dark from comment #17)
> this will pollute module scope with imported symbols.
> 
> imagine that i have `mymodule.foo (float v)` function, and defined local
> `foo (int v)` function. with your "hidden global import" whenever i'll
> import "mymodule", it will add unexpected `foo` overload for the whole code.
> 
> also, it breaks "module importing orger doesn't matter" rule.


Those statements are all incorrect, so maybe you misunderstood the suggestion.
The suggestion is that name lookup should behave as if the set of global
imports considered depended on the local scope. The net effect is that imports
never hide each other, but symbols of the current module always hide imported
symbols.

--

[Issue 15573] @safe code using TLS works in debug; crashes in release

[via Digitalmars-d-bugs]

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

--- Comment #2 from thomas.bock...@gmail.com ---
I'm trying to keep working on the original program, but I'm now starting to see
the same kind of problems in debug mode and on LDC, as well. Other error
messages I've gotten recently:

Program exited with code -11
Program exited with code -8
Program exited with code -4
Illegal Instruction

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

thomas.bock...@gmail.com changed:

   What|Removed |Added

Summary|@safe code using TLS works  |mystery crashes in @safe
   |in debug; crashes in|code
   |release |

--- Comment #3 from thomas.bock...@gmail.com ---
I have now reproduced this problem without using TLS. I have no idea what is
going on at this point.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

--- Comment #19 from Ketmar Dark  ---
ah, i see, thank you. i really misread the suggesion. still, i like Kenji's
PR4915 more. ;-) i'd better see "shadowing error", so i can simply rename
symbols, and don't guess if there is conflict or not.

--

[Issue 15579] extern(C++) interfaces/multiple-inheritance

[via Digitalmars-d-bugs]

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

deadalnix  changed:

   What|Removed |Added

 CC||deadal...@gmail.com

--- Comment #1 from deadalnix  ---
https://mentorembedded.github.io/cxx-abi/abi.html#vtable

--

[Issue 15582] Slice returned by opSlice() not accepted as lvalue

[via Digitalmars-d-bugs]

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

--- Comment #2 from Marc Schütz  ---
(In reply to b2.temp from comment #1)
> I don't aggree, it's like if you say that
> 
> s.opSlice() = 10;
> 
> should work.

That should work, too.

Note that appending another pair of brackets is already accepted. As long as
there's no ambiguity with assigning to the slice itself (i.e. the lhs is not an
lvalue, and opSlice doesn't return by ref), it should just do the appropriate
element-wise operation.

Analogously with *=, += etc.

--

[Issue 15571] .dup is incompatible with self referencing structs

[via Digitalmars-d-bugs]

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

Marc Schütz  changed:

   What|Removed |Added

 CC||schue...@gmx.net

--- Comment #2 from Marc Schütz  ---
Here's the error message:

/home/marc/d/druntime/import/object.d(3361): Error: struct
xx.__unittestL10_1.Node no size yet for forward reference
/home/marc/d/druntime/import/object.d(3361): Error: struct
xx.__unittestL10_1.Node no size yet for forward reference
xx.d(11): Error: struct xx.__unittestL10_1.Node no size yet for forward
reference
/home/marc/d/druntime/import/object.d(3378): Error: struct
xx.__unittestL10_1.Node no size yet for forward reference
/home/marc/d/druntime/import/object.d(3365): Error: template instance
object._rawDup!(Node) error instantiating
/home/marc/d/druntime/import/object.d(3352):instantiated from here:
_dup!(const(Node), Node)
/home/marc/d/druntime/import/object.d(3319):instantiated from here:
_trustedDup!(const(Node), Node)
xx.d(5):instantiated from here: dup!(Node)
xx.d(12):instantiated from here: Wrapper!(Node)

--

[Issue 15542] pure function with no argument returning different values (with void-initialized static array)

[via Digitalmars-d-bugs]

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

Marc Schütz  changed:

   What|Removed |Added

 CC||schue...@gmx.net

--- Comment #1 from Marc Schütz  ---
Quoting https://dlang.org/spec/declaration.html#VoidInitializer :
"If the Initializer is void, however, the variable is not initialized. If its
value is used before it is set, undefined program behavior will result."

Note how it says "undefined program behavior", not even "undefined value". So
technically, the current behaviour is within the spec.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #8 from thomas.bock...@gmail.com ---
Thanks for explaining the error codes. Here's what the DMD command looks like:

dmd -c
-of.dub/build/application-release-linux.posix-x86_64-dmd_2069-CB9CA9A6812DFD37D33F5377E56B63D5/bug.o
-release -inline -O -v -w -version=Have_bug -Isource/ source/app.d -vcolumns

I checked the import paths, and they looked right to me. You can check the
attachment in my previous message if you want, though.

Note that I'm not currently using a standard DMD install; I'm basically running
DMD HEAD out of /opt. However, I have reproduced this issue using the .deb
package for DMD 2.069.2 and 2.068.2 as well.

LDC does not have a problem with the exact source code included above, but I've
hit what seems to be the same issue in the latest version of the original
pre-reduction code for my checkedint project.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #16 from thomas.bock...@gmail.com ---
> Have you looked into DustMite? It can reduce your code while you work on 
> something else.

I've heard of DustMite, and it sounds very cool.

I doubt it could effectively reduce my *original* code though, because it makes
such heavy use of meta-programming that it would probably need to be able to
solve the halting problem to do a good job.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #22 from hst...@quickfur.ath.cx ---
Basically, dustmite does textual simplification, which often, though not
always, corresponds with semantic simplification. For example, it does replace
selective imports with non-selective imports -- it's a textual simplification
but not necessarily a semantic one. It doesn't actually look into the imported
code unless the imported module is also part of the source tree being reduced.

Anyway, dustmite didn't get me very far in reducing the code any further;
here's how far it got:

--
import std.stdio;

enum IntFlag {NULL, error}
IntFlag intFlag;
int dummyVar;

int safeDiv(byte left, byte right)
{
const div0 = right == 0;
const posOver = left == int.min&& right ;
if(div0)
{
intFlag = posOver ? IntFlag.error : IntFlag.error;
return 0;
}
return left / right;
}

void main()
{
byte[] testValues = [-2];
foreach(m; testValues)
foreach(n; testValues)
{
const theory = cast(real)n / m;
const thrInval = theory.isNaN;
intFlag = IntFlag.NULL;

const practice1 = safeDiv(n, m);
writeln(practice1 == theory); /* false with -inline -O */

void require(bool success)
{
if(success) dummyVar = m;
}
require(thrInval);
}
}
bool isNaN(real x) {
enum EXPMASK = 0x7FFF;
enum EXPPOS_SHORT = 4;
const e = EXPMASK & (cast(ushort *))[EXPPOS_SHORT];
const ps = *cast(ulong *)
return e == EXPMASK &&
ps & 0x7FFF___;
}
--

(I left std.stdio in there and replaced the assert with a writeln, because
dustmite needed a script that can tell the difference between a correct
reduction and an incorrect reduction -- I have to compile it with and without
the offending flags and grep for "false" and "true", respectively, so that
dustmite doesn't barge ahead and just replace the assert with something that
vacuously fails. :-P)

Looks like I will have to look into the generated asm next...

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #9 from thomas.bock...@gmail.com ---
As far as DUB caching stuff goes - it's true I've had some issues with that,
but I don't think that's the fundamental cause here. This problem persists even
if I just move the source to a fresh project directory, or open up the hidden
".dub" folder in the project and delete the cache folders.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #13 from thomas.bock...@gmail.com ---
> Removing either -inline or -O makes the problem go away. Going to dig deeper 
> now...

Just keep in mind that I have a newer version of the non-reduced code that
seems to show the same problem across a much wider variety of permutations of
compilers and options.

If you can't figure out what's going on from this one, let me know and I'll try
to reduce the newer code. (But I'd rather not unless I have to, because this
project takes a while to reduce.)

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #18 from thomas.bock...@gmail.com ---
I should definitely give it a try some time.

I guess what I'm saying, though, is that I'm pretty sure it would need a lot of
intervention by me (at least at the beginning) in order to accomplish much with
this particular project.

The reduction I submitted here is in no way simply a trimming of the syntax
tree; I had to write shims, instantiate various templates, and mixin strings by
hand in order to get the ball rolling.

The original code also compiles very slowly, as well, which would make a blind
guess-and-check process rather painful until it got far enough along to
eliminate the part that causes the slow compilation.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #20 from thomas.bock...@gmail.com ---
Will DustMite automatically import dependencies like isNaN(), or did you do
that?

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #4 from hst...@quickfur.ath.cx ---
Exit code -8 seems to be SIGFPE (floating point exception). Exit code -11 is
your usual segmentation fault, usually the result of dereferencing an illegal
pointer (usually null, but can be other things like random int values
accidentally overwriting a pointer). Exit code -4 is, as it says, illegal
instruction, usually the result of a corrupted function pointer. You can see
the full list of signal numbers by running `kill -l` in a terminal.

Anyway, I've been trying to compile your code with various flags, but I could
not reproduce any of the errors you're seeing. Do you know exactly what's the
command line dub uses to invoke dmd (I don't have dub installed)?  I tried
various combinations like:

dmd -unittest test.d
dmd -release test.d
dmd -debug test.d
dmd -release -noboundscheck test.d
...
etc., and running the resulting executable afterwards, but none of them give
any of the consistency errors or crashes that you're seeing. I'm also running
on Linux/x86_64.

Based on the nature of your crashes, I'm suspecting that it has something to do
with linker problems... perhaps dub is somehow picking up an incorrect version
of a shared library (probably druntime or phobos), so the runtime functions
used by the program aren't doing what they're expected to do, causing various
memory corruption issues that lead to consistency errors and crashes.  You
might want to try a fresh installation of the dmd toolchain in a sandbox (in a
VM or a chroot, perhaps) and see if that makes a difference.

Failing that, try looking at the output of 'dmd -v test.d' and carefully check
the output to see if it's pulling in imports and shared libraries that are in
the expected places.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #7 from thomas.bock...@gmail.com ---
Created attachment 1576
  --> https://issues.dlang.org/attachment.cgi?id=1576=edit
compiler output

This is the complete output from a run of DUB and DMD.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #10 from hst...@quickfur.ath.cx ---
Thanks for posting the dub output, I've managed to reproduce the problem now.
I'll do some investigation to see what's going on here...

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #21 from ag0ae...@gmail.com ---
(In reply to thomas.bockman from comment #20)
> Will DustMite automatically import dependencies like isNaN(), or did you do
> that?

I haven't used Dustmite here at all. I don't know what it does with library
code.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #5 from hst...@quickfur.ath.cx ---
P.S. An example of an "unexpected place" would be dmd reading import files from
/usr/src/d/phobos when dmd itself is installed in /usr/share/local/bin/ (i.e.,
it seems likely that the version of phobos it's picking up may not be the same
version as the one dmd was shipped with). Another thing to watch out for is
when it invokes cc or gcc (usually as a last step) with -L paths that point to
somewhere that seems inconsistent with where dmd is installed.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #12 from hst...@quickfur.ath.cx ---
It seems to be triggered by the -inline -O flags to dmd. I managed to reduce
the compiler call to the following:

dmd -inline -O source/app.d -ofapp && ./app

Removing either -inline or -O makes the problem go away. Going to dig deeper
now...

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #19 from ag0ae...@gmail.com ---
Reduced further, got rid of phobos:


enum IntFlag {NULL, error}

IntFlag intFlag = IntFlag.NULL;
int dummyVar;

int safeDiv(const byte left, const byte right)
{
const div0 = (right == 0);
const posOver = (left == int.min) && (right == -1);

if(div0)
{
intFlag = (posOver ? IntFlag.error : IntFlag.error);
return 0;
}
else return left / right;
}

void main()
{
const byte[] testValues = [-2];
foreach(const m; testValues)
{
foreach(const n; testValues)
{
const theory = cast(real)n / cast(real)m;
const bool thrInval = theory.isNaN;

intFlag = IntFlag.NULL;

assert(safeDiv(n, m) == theory); /* fails with -inline -O */

void require(const bool success)
{
if(success) return;
dummyVar = m;
}

require(!thrInval);
}
}
}

bool isNaN(real x) @nogc @trusted pure nothrow
{
static assert(real.mant_dig == 64);
enum ushort EXPMASK = 0x7FFF;
enum EXPPOS_SHORT = 4;
const ushort e = EXPMASK & (cast(ushort *))[EXPPOS_SHORT];
const ulong ps = *cast(ulong *)
return e == EXPMASK &&
ps & 0x7FFF___;
}


--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #6 from hst...@quickfur.ath.cx ---
P.S.S. Oh, and another thought occurred to me: maybe try flushing dub's cache
of previously-built targets?  E.g., if you copy your source files to new, empty
directory and build everything from scratch.  Sometimes stale object files left
in build caches can get wrongly linked to the newest version of the program,
causing heisenbugs that vanish when you rebuild the code from fresh.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #14 from hst...@quickfur.ath.cx ---
Have you looked into DustMite? It can reduce your code while you work on
something else.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #15 from ag0ae...@gmail.com ---
A first reduction:

test.d:

import std.math: isNaN, trunc;
import std.stdio: writeln;

enum IntFlag {NULL, error}

IntFlag intFlag = IntFlag.NULL;
int dummyVar;

int safeDiv(const byte left, const byte right)
{
const div0 = (right == 0);
const posOver = (left == int.min) && (right == -1);

if(div0)
{
intFlag = (posOver ? IntFlag.error : IntFlag.error);
return 0;
}
else return left / right;
}

void main()
{
const byte[] testValues = [-2];
foreach(const m; testValues)
{
foreach(const n; testValues)
{
writeln("", m, "", n);

const theory = trunc(cast(real)n / cast(real)m);
const bool thrInval = theory.isNaN;

intFlag = IntFlag.NULL;

const practice1 = safeDiv(n, m);
assert(practice1 == theory); /* fails with -inline -O */

void require(const bool success)
{
if(success) return;

dummyVar = m;
dummyVar = n;
}

require(!thrInval);
intFlag = IntFlag.NULL;
}
}
}


`dmd --version && dmd -inline -O test.d && ./test`:

DMD64 D Compiler v2.069-devel-605be4c
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
-2-2
core.exception.AssertError@test.d(37): Assertion failure

??:? _d_assert [0x43ab53]
??:? void test.__assert(int) [0x439da4]
??:? _Dmain [0x43924c]
??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv [0x43b192]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x43b0d0]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() [0x43b14e]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x43b0d0]
??:? _d_run_main [0x43b02d]
??:? main [0x439de5]
??:? __libc_start_main [0x375cea3f]


--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #17 from hst...@quickfur.ath.cx ---
The way dustmite works is not by some clever solution to the halting problem
(haha), it's simply by trial-and-error deleting parts of the syntax tree of the
program until the original error no longer occurs. It recursively refines its
reduction, so that by the time it's done, what's left is usually pretty close
to minimal code.

Sometimes, it does get stuck, but a little human editing of the intermediate
reduction and running dustmite again on the result often gets even closer to
minimal. It beats hand-reducing the code through the entire process, if nothing
else.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #23 from hst...@quickfur.ath.cx ---
There appears to be a codegen bug in dmd. Prior to the idiv instruction
(integer division, at n/m), it needs to load EDX:EAX with the (extended) value
of n. EAX is loaded correctly but EDX is not correctly zeroed (since we are
dividing byte values, EDX should be zeroed). As a result, the idiv instruction
will produce a garbage value.

In the code compiled without -O -inline, there is an "xor %edx,%edx"
instruction prior to the idiv. Apparently, -O and -inline interacts together
badly and this instruction somehow gets elided.

Here's the disassembly of main(), compiled with dmd -O -inline (with some
embedded comments mapping sections to various source code snippets):

--
00438bc8 <_Dmain>:
  438bc8:   55  push   %rbp
  438bc9:   48 8b ecmov%rsp,%rbp
  438bcc:   48 81 ec 80 00 00 00sub$0x80,%rsp
  438bd3:   48 89 5d 88 mov%rbx,-0x78(%rbp)
  438bd7:   4c 89 65 90 mov%r12,-0x70(%rbp)
  438bdb:   4c 89 6d 98 mov%r13,-0x68(%rbp)
  438bdf:   4c 89 75 a0 mov%r14,-0x60(%rbp)
  438be3:   4c 89 7d a8 mov%r15,-0x58(%rbp)
  438be7:   be 01 00 00 00  mov$0x1,%esi
  438bec:   bf 30 27 68 00  mov$0x682730,%edi
// testValues = [-2]
  438bf1:   e8 b2 21 00 00  callq  43ada8 <_d_arrayliteralTX>
  438bf6:   49 89 c4mov%rax,%r12
  438bf9:   41 c6 04 24 fe  movb   $0xfe,(%r12)
  438bfe:   4c 89 65 c8 mov%r12,-0x38(%rbp)
  438c02:   48 c7 45 c0 01 00 00movq   $0x1,-0x40(%rbp)
  438c09:   00 
  438c0a:   31 db   xor%ebx,%ebx
// foreach(m; testValues)
  438c0c:   48 83 fb 01 cmp$0x1,%rbx
  438c10:   72 0a   jb 438c1c <_Dmain+0x54>
  438c12:   bf 16 00 00 00  mov$0x16,%edi
// array bounds check
  438c17:   e8 94 07 00 00  callq  4393b0 <_D4test7__arrayZ>
  438c1c:   48 8b 45 c8 mov-0x38(%rbp),%rax
// ecx := testValues[i]
  438c20:   0f be 0c 03 movsbl (%rbx,%rax,1),%ecx
// -0x8(%rbp) := (byte) m
  438c24:   88 4d f8mov%cl,-0x8(%rbp)
  438c27:   45 31 e4xor%r12d,%r12d
  438c2a:   48 89 5d f0 mov%rbx,-0x10(%rbp)
// foreach (n; testValues)
  438c2e:   49 83 fc 01 cmp$0x1,%r12
  438c32:   72 0a   jb 438c3e <_Dmain+0x76>
  438c34:   bf 17 00 00 00  mov$0x17,%edi
// array bounds check
  438c39:   e8 72 07 00 00  callq  4393b0 <_D4test7__arrayZ>
  438c3e:   48 8b 55 c8 mov-0x38(%rbp),%rdx
// ebx := testValues[i]
  438c42:   41 0f be 1c 14  movsbl (%r12,%rdx,1),%ebx
// -0x7(%rbp) := (byte) n
  438c47:   88 5d f9mov%bl,-0x7(%rbp)
// extend to 32 bits
  438c4a:   0f be dbmovsbl %bl,%ebx
  438c4d:   89 5d b0mov%ebx,-0x50(%rbp)
  438c50:   db 45 b0fildl  -0x50(%rbp)
  438c53:   0f be 45 f8 movsbl -0x8(%rbp),%eax
  438c57:   89 45 b0mov%eax,-0x50(%rbp)
  438c5a:   db 45 b0fildl  -0x50(%rbp)
// theory = cast(real)n / m;
  438c5d:   de f9   fdivrp %st,%st(1)
  438c5f:   db 7d d0fstpt  -0x30(%rbp)
  438c62:   66 c7 45 da 00 00   movw   $0x0,-0x26(%rbp)
  438c68:   c7 45 dc 00 00 00 00movl   $0x0,-0x24(%rbp)
  438c6f:   f2 48 0f 10 45 d0   rex.W movsd -0x30(%rbp),%xmm0
  438c75:   f2 48 0f 11 45 e0   rex.W movsd %xmm0,-0x20(%rbp)
  438c7b:   f2 48 0f 10 4d d8   rex.W movsd -0x28(%rbp),%xmm1
  438c81:   f2 48 0f 11 4d e8   rex.W movsd %xmm1,-0x18(%rbp)
  438c87:   0f b7 4d d8 movzwl -0x28(%rbp),%ecx
// (inlined isNan): EXPMASK & (cast(ushort*))[EXPPOS_SHORT]
  438c8b:   66 81 e1 ff 7f  and$0x7fff,%cx
  438c90:   ba ff 7f 00 00  mov$0x7fff,%edx
// e == EXPMASK
  438c95:   66 3b cacmp%dx,%cx
  438c98:   75 13   jne438cad <_Dmain+0xe5>
// rax := -0x20(%rbp) == ps
  438c9a:   48 8b 45 e0 mov-0x20(%rbp),%rax
// isNaN: ps & 0x7fff___
  438c9e:   48 bb ff ff ff ff ffmovabs $0x7fff,%rbx
  438ca5:   ff ff 7f 
  438ca8:   48 85 c3test   %rax,%rbx
  438cab:   75 05   jne438cb2 <_Dmain+0xea>
// isNaN == false
  438cad:   45 31 edxor%r13d,%r13d
// r13d := return value of isNaN
  438cb0:   eb 06 

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords||wrong-code

--

[Issue 15573] -O -inline causes wrong code with idiv instruction

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

Summary|mystery crashes in @safe|-O -inline causes wrong
   |code|code with idiv instruction

--

[Issue 15513] Memory Corruption with thread local objects

[via Digitalmars-d-bugs]

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

--- Comment #1 from Puneet Goel  ---
I am getting hit by this issue often when I have static variables declared
inside a function and the function is being called in multiple threads.

Another observation is that the memory corruption happens if the static
variable is allocated on the heap rather than stack. For example if I declare a
static variable array with fixed length, then there will not be any issue. But
if the static variable is a dynamically sized array which gets allocated on the
heap on the first call to the function, it gets corrupted after a while.

I am reducing another test case where the contents of a dynamic array are
getting corrupted though the code writes into it only once. Since I work on a
large project with almost 10 lines of code, dustmite takes days to reduce.

--

[Issue 15578] Should have access to namespace private symbols from same module

[via Digitalmars-d-bugs]

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

--- Comment #1 from Walter Bright  ---
https://github.com/D-Programming-Language/dmd/pull/5358

--

[Issue 15578] Should have access to namespace private symbols from same module

[via Digitalmars-d-bugs]

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

Manu  changed:

   What|Removed |Added

 CC||turkey...@gmail.com

--- Comment #2 from Manu  ---
Thanks

--

[Issue 15513] Memory Corruption with thread local objects

[via Digitalmars-d-bugs]

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

--- Comment #2 from Puneet Goel  ---
Even when I move the static variable to a class, I still get memory corruption.
The following seem necessary to reproduce the issue:

1. Static variable that gets allocated on heap.
2. The variable has to be used in multiple threads.

Also, as of now I am able to reproduce the issue only when a shared D library
is loaded from C. But since the execution control is totally with D after that,
I believe the memory corruption issue is more generic and could happen in
standalone D applications as well.

--

[Issue 15581] foreach should avoid bounds checking

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords||performance
 CC||hst...@quickfur.ath.cx

--

[Issue 15548] [Home] Interaction with the code box adds vertical space

[via Digitalmars-d-bugs]

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

--- Comment #5 from ag0ae...@gmail.com ---
Bastiaan, can you confirm that the fix works? That is, please check this page:

http://dtest.thecybershadow.net/artifact/website-e5e6719ce761346186b67bbc94818c0dc8709308-70afad9f70896cec0f622d7a20e38d70/web/index.html

and confirm that the issue doesn't occur there.

--

[Issue 15550] [Reg 2.070.0-b1] compile error while testing template constraint

[via Digitalmars-d-bugs]

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

--- Comment #4 from ponce  ---
- Still happen in DMD 2.071-b
- Can't reproduce on Windows

FWIW I could change the code, but I don't seem to find a workaround. I've tried
std.traits.hasMember instead and it fails similarly.

--

[Issue 15548] [Home] Interaction with the code box adds vertical space

[via Digitalmars-d-bugs]

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

--- Comment #6 from Bastiaan Veelo  ---
Yes, that solves the problem.

--

[Issue 14205] Document D compatibility with fork

[via Digitalmars-d-bugs]

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

Sobirari Muhomori  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=15511

--

[Issue 15511] fork: Invalid memory operation

[via Digitalmars-d-bugs]

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

Sobirari Muhomori  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=14205

--

[Issue 15579] extern(C++) interfaces/multiple-inheritance

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com
Summary|extern(C++) |extern(C++)
   |interfaces/multiple-inherit |interfaces/multiple-inherit
   |ence|ance

--

[Issue 15583] [REG] topN without uniform can show quadratic performance

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #3 from Andrei Alexandrescu  ---
https://github.com/andralex/phobos/commit/4ba95cd1bd5124b53324c441e62c51d759481b04
which is part of https://github.com/D-Programming-Language/phobos/pull/3934
should fix this.

--

[Issue 15573] mystery crashes in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #11 from thomas.bock...@gmail.com ---
> I've managed to reproduce the problem now.

Excellent. So I'm not crazy :-D

> I'll do some investigation to see what's going on here...

Many thanks. This has been driving me nuts.

--