[Issue 18750] [Tracker] everything wrong with code generation for bt instruction

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0aep6g  changed:

   What|Removed |Added

 Depends on||18794


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18794
[Issue 18794] Compiling with -O causes runtime segfault
--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0aep6g  changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com
 Blocks||18750

--- Comment #1 from ag0aep6g  ---
Reduced:


bool method(size_t* p)
{
int bitIdx = 0;
func();
return (*p & (1UL << bitIdx)) != 0;
}

void func() {}

void prep()
{
asm {}
ulong[2] x = -1;
}

void main()
{
prep();
size_t s;
method();
}


Generated code for `method`:


   0:   55  push   rbp
   1:   48 8b ecmovrbp,rsp
   4:   48 83 ec 10 subrsp,0x10
   8:   48 89 7d f8 movQWORD PTR [rbp-0x8],rdi
   c:   c7 45 f0 00 00 00 00movDWORD PTR [rbp-0x10],0x0
  13:   e8 00 00 00 00  call   18 <_D4test6methodFPmZb+0x18>
14: R_X86_64_PLT32  _D4test4funcFZv-0x4
  18:   48 8b 45 f8 movrax,QWORD PTR [rbp-0x8]
  1c:   48 8b 4d f0 movrcx,QWORD PTR [rbp-0x10]
  20:   48 0f a3 08 bt QWORD PTR [rax],rcx
  24:   48 0f 92 c0 rex.W setb al
  28:   48 8b e5movrsp,rbp
  2b:   5d  poprbp
  2c:   c3  ret


bitIdx is a DWORD at rbp-0x10. But later a QWORD is read from there and used in
the bt instruction. So that reads garbage from the stack. The garbage can be
controlled by prep.

Looks like this is directly related to the generation of the bt instruction,
which is horribly broken. But it doesn't seem to be a duplicate of the known
issues. Adding to the tracker.


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18750
[Issue 18750] [Tracker] everything wrong with code generation for bt
instruction
--

[Issue 3523] [GC] Fiber is not garbage collected properly

[d-bugmail--- via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #15 from Steven Schveighoffer  ---
This is pretty old, but I wonder if it's still broken?

>From this recent thread, it may already be fixed, as peppering in GC
collections seems to solve the problem:

https://forum.dlang.org/post/vfqvmyossdcqadgas...@forum.dlang.org

I was coming to file a bug on this, but this seems (at least) to be close to
explaining what is happening.

Note that we have a separate issue with Fibers and GC. The GC only associates a
small block with the Fiber -- the Fiber object itself, whereas the stack is
huge comparatively. In 32-bit windows, a fiber stack is default 32k. This means
that 10,000 Fibers probably takes up 1.2MB in the GC (assuming 128 bytes per
fiber), but the stack space is 320MB. There is a lack of correlation here
between memory pressure and when the memory should be cleaned up.

Would it be possible to deallocate the stack when the Fiber terminates vs. when
it's GC'd? That would at least help with Fibers that are completed and just
left for garbage.

--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from hst...@quickfur.ath.cx ---
Just a side-note that although in my own environment, the problem can be
reproduced with -O alone, apparently in some other environments specifying both
-O and -profile is necessary to trigger the bug.

--

[Issue 18639] VisualD - First 5 minutes - Improve list of project wizards, propritise MSBuild projects

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Manu  ---
> - add imports from project dependencies

Not sure what this means... 'add imports'? You mean dependent project's
source-tree paths so clients can import modules from libs? How do you know a
project's 'root' path?


- demangling support

Is this impossible? Can we bolt-in an output translator to the normal VS link
stage?


- some special handling for error messages

What special handling?


- integration with compiler generated JSON

What integration is possible/missing? I don't know if I ever used this with the
old projects...?


- better handling of link dependencies

What can't we do? Can we not just do all the same things that C++ does to make
it all work the same way?



I agree, we shouldn't switch over until the experience is tight, but the
experience is close, and it doesn't look like a lot of work to get it there.
There's a lot of missing wizards though for the various project types.


> Do you have suggestions for better wording?

Wording where?

--

[Issue 18794] New: Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18794
   Summary: Compiling with -O causes runtime segfault
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Reduced code:


void func() {}

struct S
{
size_t[] impl;
this(int v)
{
impl = [0];
}
bool method(int v)
{
int wordIdx = v >> 6;
int bitIdx = v & 0b0011;

func();

if (wordIdx >= impl.length)
return false;

return (impl[0] & (1UL << bitIdx)) != 0;
}
}

void main()
{
auto s = S(0);
s.method(0);
}



Compile command: dmd -O -run test.d

Output:


Error: program killed by signal 11


Compiling without -O fixes the problem.  Commenting out the call to func() also
makes the problem go away.  Also, the details of method() seem quite important;
changing the return statement in various ways seems to make the problem go
away, though I'm not 100% certain the current form is minimal.  Eliding the
ctor call also makes the problem go away, though I didn't explore all possible
combinations.

In the original call, wordIdx is used to index the impl array, but the problem
seems to persist even when impl[0] is hardcoded.  However, removing the test
`wordIdx >= impl.length` seems to mask the problem. So there's something about
it that's triggering the wrong code.

--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

   Keywords||wrong-code

--

[Issue 18641] VisualD - First 5 minutes - Improve experience adding .d files to existing C++ projects

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Manu  ---
Why don't we just amend the global C/C++ props and include the D lib paths the
same as MS does for CRT paths? I don't think anyone will mind ;)

The link comment thing is interesting. Why only in main? MSC definitely
includes the runtime lib reference in every single .obj file it emits (unless
compiling with /Zl). I feel like we should do the same thing.
Have you had experience where the linker ignores it?


> With static libraries this gets a bit more complicated as these settings must 
> be propagated to the actual link step in a different project.

What does MSC do?
I feel like we should probably just match MSC's patterns verbatim, with respect
to link paths, embedding library references, etc.

--

[Issue 5413] (diagnostic): No notification that warnings are treated as errors

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike Franklin  changed:

   What|Removed |Added

   Keywords||bootcamp, trivial
 CC||slavo5...@yahoo.com

--

[Issue 18795] New: Add pragma(stackStomp, [true|false]) to control -gx on per-function basis

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18795
   Summary: Add pragma(stackStomp, [true|false]) to control -gx on
per-function basis
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

Stomping the stack is important for detecting certain kinds of dangling
reference bugs (shouldn't be possible in @safe code), but also for
cryptographic code that aims to prevent a function from leaking any information
to its caller:

  http://www.cl.cam.ac.uk/~rja14/Papers/whatyouc.pdf

This should be controllable on a per-function basis, and the best way is
analogous to the way the `pragma(inline)` works, i.e.:

  pragma(stackStomp) // default, meaning set to the setting of the -gx switch
  pragma(stackStomp, true)  // enable for this function
  pragma(stackStomp, false)  // disable for this function

References:

  https://dlang.org/dmd-windows.html#switch-gx
  https://dlang.org/spec/pragma.html#inline
  https://github.com/dlang/dmd/blob/master/src/dmd/backend/cod3.c#L3919

The stomp code should also be improved to overwrite all scratch registers
modified by the function that are not part of the return value or the registers
already preserved by the function.0

--

[Issue 17806] processAllocator getter will override set value if it was set before getter was called at least once

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/4b0b02e9e1b8076630f4df707610b81746b391d4
Fix Issue 17806 - processAllocator getter will override set value if it was set
before getter was called at least once

https://github.com/dlang/phobos/commit/832ace083257d4c8501a3772748c20ac10d932bd
Merge pull request #6413 from edi33416/fix_i17806

Fix Issue 17806 - processAllocator getter will override set value if …
merged-on-behalf-of: Nathan Sashihara 

--

[Issue 17806] processAllocator getter will override set value if it was set before getter was called at least once

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 11970] Self-assigned variable expression with no effect doesn't have compiler error

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike Franklin  changed:

   What|Removed |Added

   Keywords||pull
 CC||slavo5...@yahoo.com

--- Comment #2 from Mike Franklin  ---
Potential fix: https://github.com/dlang/dmd/pull/8208

--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #3 from Jonathan M Davis  ---
I can reproduce this on FreeBSD x86_64 with master, but I have to use -profile
with -O. -O by itself doesn't trigger it for me. And adding -inline seems to
get rid of the problem.

--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from hst...@quickfur.ath.cx ---
Just tested in my environment, -inline does indeed make the problem go away.
(Mask it, probably.)

However, I can still reproduce the problem with just -O, even though the
original problem was discovered when I compiled with -O -profile. For
reference, I'm running dmd git commit b7f9af8766af90f221227946ba52f546e3188f9c.

--

[Issue 18750] [Tracker] everything wrong with code generation for bt instruction

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18750
Issue 18750 depends on issue 18730, which changed state.

Issue 18730 Summary: dmd miscompiles core.bitop.bt with -O
https://issues.dlang.org/show_bug.cgi?id=18730

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18730] dmd miscompiles core.bitop.bt with -O

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18730] dmd miscompiles core.bitop.bt with -O

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/dbbb00a2055c074004bf294b71ffe1b090ff984a
fix issue 18730 - dmd miscompiles core.bitop.bt with -O

https://github.com/dlang/dmd/commit/4a0437981a2754ca74d47a2371d80072e02d1e2c
fixup! fix issue 18730 - dmd miscompiles core.bitop.bt with -O

https://github.com/dlang/dmd/commit/61e96ecf532e5480d609402a5b8e0e4c24cae89d
run tests for issue 18730 only on x86-64

https://github.com/dlang/dmd/commit/7f30e528231de450d5491278b408ddfb1e02061c
Merge pull request #8142 from aG0aep6G/18730

fix issue 18730 - dmd miscompiles core.bitop.bt with -O
merged-on-behalf-of: Walter Bright 

--

[Issue 18796] New: std.algorithm.substitute asserts on empty range

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18796
   Summary: std.algorithm.substitute asserts on empty range
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: criman...@gmail.com

Code:

unittest
{
import std.algorithm: substitute, equal;
assert("".substitute!("a","b").equal(""));
}

Expectation: test passed

Actual result:

core.exception.AssertError@/usr/include/dmd/phobos/std/algorithm/iteration.d(4901):
Attempting to popFront an empty substitute.

??:? _d_assert_msg [0x42de16]
??:? pure @safe void
std.algorithm.iteration.substitute!(std.algorithm.iteration.__lambda167,
immutable(char)[], immutable(char)[], immutable(char)[]).substitut]
??:? pure ref @safe
std.algorithm.iteration.substitute!(std.algorithm.iteration.__lambda167,
immutable(char)[], immutable(char)[], immutable(char)[]).substitute]
??:? pure @safe
std.algorithm.iteration.joiner!(std.algorithm.iteration.MapResult!(std.algorithm.iteration.substitute!(std.algorithm.iteration.__lambda167,
immu]
??:? pure @safe
std.algorithm.iteration.joiner!(std.algorithm.iteration.MapResult!(std.algorithm.iteration.substitute!(std.algorithm.iteration.__lambda167,
immu]
??:? void substitute.__unittest_L1_C1() [0x42afa8]
??:? void substitute.__modtest() [0x42d018]
??:? int core.runtime.runModuleUnitTests().__foreachbody2(object.ModuleInfo*)
[0x43354b]
??:? int object.ModuleInfo.opApply(scope int
delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*))
[0x42dbfe]
??:? int rt.minfo.moduleinfos_apply(scope int
delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref
rt.sections_elf_shared.DSO) [0x4300e9]
??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref
rt.sections_elf_shared.DSO)) [0x430178]
??:? int rt.minfo.moduleinfos_apply(scope int
delegate(immutable(object.ModuleInfo*))) [0x430075]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*))
[0x42dbd5]
??:? runModuleUnitTests [0x433321]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() [0x42e3c0]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x42e347]
??:? _d_run_main [0x42e2b2]
??:? main [0x42d033]
??:? __libc_start_main [0xe29d382f]
1/1 unittests FAILED

--

[Issue 18794] Compiling with -O causes runtime segfault

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from ag0aep6g  ---
(In reply to ag0aep6g from comment #1)
> bitIdx is a DWORD at rbp-0x10. But later a QWORD is read from there and used
> in the bt instruction. So that reads garbage from the stack. The garbage can
> be controlled by prep.
It's probably worth pointing out that the result is still wrong even when prep
zeroes the high bits. An int can't just be used as the low half of a long.

(In reply to hsteoh from comment #2)
> Just a side-note that although in my own environment, the problem can be
> reproduced with -O alone, apparently in some other environments specifying
> both -O and -profile is necessary to trigger the bug.
(In reply to Jonathan M Davis from comment #3)
> I can reproduce this on FreeBSD x86_64 with master, but I have to use
> -profile with -O. -O by itself doesn't trigger it for me.
You guys are talking about the original code, right? The behavior relies on
stack garbage, so it makes sense that it isn't reproducible everywhere. If you
happen to have zeroes at the particular stack address, you won't see a
segfault.

The modified code in comment #1 should segfault consistently with just -O (and
without -inline).

--

[Issue 4791] Assigning a static array to itself should be allowed

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike Franklin  changed:

   What|Removed |Added

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

--

[Issue 11970] Self-assigned variable expression with no effect doesn't have compiler error

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike Franklin  changed:

   What|Removed |Added

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

--

[Issue 18640] VisualD - First 5 minutes - Default debuginfo configuration emits warnings.

[d-bugmail--- via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze  ---
I'm not sure the deprecation is warranted, as -gc might still be needed if you
are using a debugger iwthout mago as engine or extension. 

For VS projects, we should assume mago is installed, so I changed the default
to -g.

--

[Issue 18641] VisualD - First 5 minutes - Improve experience adding .d files to existing C++ projects

[d-bugmail--- via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze  ---
The runtime library link comments are usually added to the object file that
contains main(), but this falls short in your case of building a static
library. Adding it elsewhere into the library doesn't help because there is no
guarantee that it will be dragged in by the linker.

So far, I've been trying not to interfere with projects that don't use D at
all. Adding D files to a C++ project already modifies linker search paths, but
doesn't add the runtime libraries. I guess that would be better.

With static libraries this gets a bit more complicated as these settings must
be propagated to the actual link step in a different project.

--

[Issue 18639] VisualD - First 5 minutes - Improve list of project wizards, propritise MSBuild projects

[d-bugmail--- via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze  ---
Sorry, I didn't look at the bug list for a while. You might want to assign
visuald reports directly to me so I get notified.

I agree, the msbuild based projects look much better, but unfortunately, the
custom projects still have some advantages, also found in your other reports:

- add imports from project dependencies
- demangling support
- some special handling for error messages
- integration with compiler generated JSON
- better handling of link dependencies

I'm on the fence whether we should make the msbuild version the recommended
project type before solving these issues.

I've changed the icon to look more like the C++ projects. Do you have
suggestions for better wording?

I guess templates for DLL and static libs should be added, too. More involved
stuff would be nice, but needs external dependencies, e.g. vibe.d or UI
libraries.

--

[Issue 17373] traits getOverloads + multiple interface inheritance only see one of the interfaces' overloads

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/56e85cc59b594456bf56132ce2bcb73f559892a3
Fix Issue 17373 - traits getOverloads + multiple interface inheritance only see
one of the interfaces' overloads

https://github.com/dlang/dmd/commit/1848c70c977c1ee66dd1fdbd40c729fc5a18898d
Merge pull request #7959 from RazvanN7/Issue_17373

Fix Issue 17373 -  traits getOverloads + multiple interface inheritan…
merged-on-behalf-of: Mike Franklin 

--

[Issue 17373] traits getOverloads + multiple interface inheritance only see one of the interfaces' overloads

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18793] Semantics of scope(exit/success) modifying return value

[d-bugmail--- via Digitalmars-d-bugs]

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

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #1 from Simen Kjaeraas  ---
Worth noting: On win32, the Small struct used above is not small enough to be
passed by value. The intended behavior shows up when Small.sizeof <= 8.

--

[Issue 18792] Incorrect scope analysis with -dip1000 for small-sized-optimized string

[d-bugmail--- via Digitalmars-d-bugs]

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

Per Nordlöw  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--

[Issue 17084] Can't sort array of structs with alias this: swap can't call non-@nogc function doesPointTo

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/5d2590ed8ce168a455c031ff3c8ef127d6046a46
fix issue 17084 - Can't sort array of structs with alias this (#6472)

--

[Issue 17084] Can't sort array of structs with alias this: swap can't call non-@nogc function doesPointTo

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--