[Issue 17029] [Reg 2.072] scope variable may not be returned
https://issues.dlang.org/show_bug.cgi?id=17029 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to scope at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/c8d9e33ea2f7337b40866f15f37fbec058262eed Merge pull request #6363 from WalterBright/fix17029 fix Issue 17029 - [Reg 2.072] scope variable may not be returned # Conflicts: #src/escape.d --
[Issue 16979] Race in druntime leads to undefined behaviour
https://issues.dlang.org/show_bug.cgi?id=16979 safety0ff.bugz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --
[Issue 17029] [Reg 2.072] scope variable may not be returned
https://issues.dlang.org/show_bug.cgi?id=17029 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/063bcfca0b30f31a18ebf2b1fae2873805b7d445 fix Issue 17029 - [Reg 2.072] scope variable may not be returned https://github.com/dlang/dmd/commit/83d7bc0d500edf95589e723f2ecc3a4fca51c54a Merge pull request #6363 from WalterBright/fix17029 --
[Issue 16794] dmd not working on Ubuntu 16.10 because of default PIE linking
https://issues.dlang.org/show_bug.cgi?id=16794 --- Comment #17 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/9fbce55814bdc8f78d6fead3243db657eafc4ec7 fix Issue 16794 - dmd not working on Ubuntu 16.10 https://github.com/dlang/dmd/commit/ad1e5d3ee5b9de164bd2acc3218047eac1f7d36a Merge pull request #6359 from MartinNowak/fix16794 --
[Issue 17035] New: extern(C) and extern(C++) module ctor/dtor should behave like the C init/fini functions
https://issues.dlang.org/show_bug.cgi?id=17035
Issue ID: 17035
Summary: extern(C) and extern(C++) module ctor/dtor should
behave like the C init/fini functions
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: and...@erdani.com
If a module ctor is declared as:
extern(C) static shared this() {}
or
extern(C++) static shared this() {}
then it should follow the C/C++ convention of library initialization: no
circularity checking, no guaranteed order of execution, no guarantee the GC is
initialized etc. The way this is done on Linux is by placing pointers to these
functions in a segment called "init_array".
Similarly, if a module dtor is declared as:
extern(C) static shared ~this() {}
or
extern(C++) static shared ~this() {}
then it should follow the same regime as C++ static destructors. On Linux
pointers to these functions are placed in a segment called "fini_array".
For reference see gcc's __attribute__((constructor)),
__attribute__((destructor)).
This should make it easier to write library initialization code that does not
depend on druntime.
--
[Issue 15984] [REG2.071] Interface contracts retrieve garbage instead of parameters
https://issues.dlang.org/show_bug.cgi?id=15984 --- Comment #11 from Martin Nowak --- An analysis of the current state of affairs, took me a while to dig through the numerous hacks, related changes and PRs. == Context information == - Accessing upvalues (variables from outer scopes) in nested functions is currently done via 2 different mechanisms, either by passing a pointer to a GC closure [¹] or by direct-stack access [²][³]. The layouts of those 2 are very different and it would be difficult to make them identical, the former is generated by the frontend the latter by the backend. - frequire (in contracts) gets treated like a nested function and would therefor also uses either of the access variants. At the moment frequire also supports escaping of parameters (triggers a GC closure allocation), just like a normal nested function. - frequire of base classes/interfaces are also called as nested functions, but from the class implementing/overriding the method. So currently Derived.foo is calling Base.foo.frequire (nested in Base.foo), but uses the access method (passes sclosure or sthis pointer) for Derived.foo.frequire. - Code for Base.foo is generated independent of any derived classes, thus the current implementation requires that all nested frequire implementations use the same access method, or that both access methods have the same memory layout. Furthermore the offsets of all accessed variables must be identical. - Whether or not a closure for parameters and variables is allocated, depends on the individual and separately compiled, i.e. invisible, implementation of each implementing/overriding method (see issue 9383). [¹]: [buildClosure](https://github.com/dlang/dmd/blob/e087760eda0dd0242d6edb1c4acdfea36bce8821/src/toir.d#L779) [²]: [getEthis](https://github.com/dlang/dmd/blob/0e4152265a2e16ca49ea8ea34a82109ce6c59cbc/src/toir.d#L99) [³]: [e2ir/SymbolExp](https://github.com/dlang/dmd/blob/e087760eda0dd0242d6edb1c4acdfea36bce8821/src/e2ir.d#L1049)) == Recent attempts at fixing the problem == Issue 9383 was somewhat fixed by https://github.com/dlang/dmd/pull/4788. This is a hack that tried to make frequire a special nested function, that will always access upvalues directly through the stack [¹]. It relies on very specific and fragile backend details of the function prologue. - As a first step in a function with GC closure, memory will be allocated. Before calling _d_allocmemory, all parameters need to be saved to the stack. So indeed anything that could be referenced from a nested frequire is already on the stack. - But frequire is only called after the closure allocation has been completed, so all parameters (and variables) have already been moved to the GC closure, and the variable offsets in the frontend are adjusted accordingly. - The forceStackAccess hack ignores those offsets, and instead uses the now stale backend offsets for the initial parameter spilling [²]. - Nobody ever told the backend, that those initial stack locations are referenced by the frontend. This of course led to subtle bugs when trying to bend (in the frontend) how parameters are accessed (https://github.com/dlang/dmd/pull/5420/files). https://github.com/dlang/dmd/pull/5765 tries to fix `this` usage in interfaces, b/c accessing that was bend to the spilled `this` parameter in some class' function implementation. The idea of that PR is to pass the class-to-interface offset as "hidden" argument to the nested frequire function. [¹]: https://github.com/dlang/dmd/pull/4788/files#diff-6e3ab8a500e476994f345ede433811bbR961 [²]: https://github.com/dlang/dmd/pull/4788/files#diff-6e3ab8a500e476994f345ede433811bbR982 == Currently remaining issues == - When the parameters aren't used in the implementation class, they won't get saved on the stack and the nested frequire function will find garbage instead. This works for normal nested functions, so likely some of the frequire hacks break this. - Adjusting the this pointer for interfaces isn't yet solved, the PR adds a lot more hacks to an already hard to maintain implementation. - Escaping parameters in frequire, e.g. by using them in a delegate, will no longer work when being forced to use the stack access. == Proposed resolution == - We make frequire a special nested function that always get's called with a closure. When no GC closure is needed, the closure can be allocated with the same layout on the stack. - Allows to get rid of existing Ffakeeh, frame pointer, and function prolog hacks. - The variable locations in the closure (on the stack) can replace any other stack location of that variable, so no overhead on stack space should be necessary. It might be somewhat tricky to get the backend to enregister variables after the frequire contracts have been validated. - One way to support interfaces would be to set a 'this' pointer in the closure to the correct offset before each frequire call in the
[Issue 17027] Add support for tzcnt and lzcnt in x86(64) iasm
https://issues.dlang.org/show_bug.cgi?id=17027 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/ab9a6a2582bc061754566e4f49ef5ac7be67baab issue 17027 - add TZCNT and LZCNT to inline assembler https://github.com/dlang/dmd/commit/91f0c943368d50efe70816bc499bb8cbcbd5c9b5 Merge pull request #6364 from BBasile/issue-17027 issue 17027 - add TZCNT and LZCNT to inline assembler --
[Issue 16626] [Reg 2.073] extreme CTFE memory usage with compile time regex
https://issues.dlang.org/show_bug.cgi?id=16626 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/07090ae2fdaddd1c40b8c149f32733e908094ac3 disable kickstart in ctfe to workaround Issue 16626 - consumes too much memory, introduced by e98fa4ad5ad39487844c91357cfec4f698e88230 (#4286) https://github.com/dlang/phobos/commit/9cbc862544a9a4afa14bb526ec4aff7792a71e49 Merge pull request #4995 from MartinNowak/fix16626 disable kickstart in ctfe to workaround Issue 16626 --
[Issue 17034] DMD 32 bit PIC wrong code
https://issues.dlang.org/show_bug.cgi?id=17034 safety0ff.bugz changed: What|Removed |Added Keywords||pull --- Comment #1 from safety0ff.bugz --- https://github.com/dlang/dmd/pull/6366 --
[Issue 16783] std.net.curl application throws an exception
https://issues.dlang.org/show_bug.cgi?id=16783 Erdem changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #2 from Erdem --- I may reproduce this bug on Ubuntu 12.04 64 bit. $ dmd -v DMD64 D Compiler v2.072.1 Also I should be able to use arsd.curl library without any problems. https://github.com/adamdruppe/arsd/blob/master/curl.d --
[Issue 1164] Wrong order of memory deallocation
https://issues.dlang.org/show_bug.cgi?id=1164 --- Comment #13 from safety0ff.bugz --- (In reply to Pieter Penninckx from comment #9) > > Am I right that the garbage collector currently works as follows: It currently works as follows: * Mark * For each unmarked object: * Finalize it if necessary * If it can be released without overwriting it do so * For each unmarked unreleased object: * release memory of the object However, you shouldn't rely on this: http://dlang.org/spec/class.html#destructors If you recompile druntime with the MEMSTOMP option, the GC and it will write arbitrary data to finalized memory. Therefore it follows that referencing GC managed objects from invariants of other GC managed objects is unadvised. I think a case could be made for being able to control insertion of invariant calls in destructors. --
[Issue 1164] Wrong order of memory deallocation
https://issues.dlang.org/show_bug.cgi?id=1164
--- Comment #12 from safety0ff.bugz ---
(In reply to Pieter Penninckx from comment #7)
>
> invariant() {
> if(sibling !is null) {
> if (sibling.fun())
> { assert(true); }
> }
> }
>
Also:
https://dlang.org/spec/contracts.html#Invariants "The code in the invariant may
not call any public non-static members of the class or struct, either directly
or indirectly. Doing so will result in a stack overflow, as the invariant will
wind up being called in an infinitely recursive manner."
--
[Issue 1164] Wrong order of memory deallocation
https://issues.dlang.org/show_bug.cgi?id=1164
safety0ff.bugz changed:
What|Removed |Added
CC||safety0ff.b...@gmail.com
--- Comment #11 from safety0ff.bugz ---
(In reply to Pieter Penninckx from comment #7)
>
> int main() {
> X x = new X();
> return 0;
> }
Your invariant gets called infinitely:
x.sibling.sibling == x
sibling's invariant() executes before and after sibling.fun() executes.
The invariant has the line: if (sibling.fun())
--
[Issue 1164] Wrong order of memory deallocation
https://issues.dlang.org/show_bug.cgi?id=1164 --- Comment #10 from Andrei Alexandrescu --- (In reply to Pieter Penninckx from comment #9) > Just to be sure I understand you correctly. > > Am I right that the garbage collector currently works as follows: > > * Mark (= mark all reachable objects as reachable) > * For each collectable (= non-reachable) object: > * Call dtor > * release memory of the collectable object I don't know exactly. I am pretty certain, however, that freed objects are currently not overwritten with .init. --
[Issue 17027] Add support for tzcnt and lzcnt in x86(64) iasm
https://issues.dlang.org/show_bug.cgi?id=17027 b2.t...@gmx.com changed: What|Removed |Added Summary|Add support for tzcnt in|Add support for tzcnt and |x86(64) iasm|lzcnt in x86(64) iasm --
[Issue 17034] DMD 32 bit PIC wrong code
https://issues.dlang.org/show_bug.cgi?id=17034 safety0ff.bugz changed: What|Removed |Added Keywords||wrong-code --
[Issue 17034] New: DMD 32 bit PIC wrong code
https://issues.dlang.org/show_bug.cgi?id=17034
Issue ID: 17034
Summary: DMD 32 bit PIC wrong code
Product: D
Version: D2
Hardware: x86
OS: All
Status: NEW
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: safety0ff.b...@gmail.com
Created attachment 1628
--> https://issues.dlang.org/attachment.cgi?id=1628&action=edit
full details & code
For the following snippet from the attached code:
struct S
{
long _value;
void popFront()
{
_value >>>= 1;
if (!_value)
return;
_value >>>= 1; // arbitrary code here
}
}
Dmd emits the snippet (with -m32 -fPIC):
1:shrl 0x4(%edx)
2:rcrl (%edx)
3:mov0x4(%edx),%edx
4:mov(%edx),%eax
5:or %eax,%edx
6:jne SomeAddress
On line 3 Dmd overwrites the address of _value in EDX with the top 4 bytes of
_value.
Then on line 4, dmd loads the bottom 4 bytes of _value into EAX, but EDX no
longer contains the address of _value, which leads to a segfault.
--
[Issue 1164] Wrong order of memory deallocation
https://issues.dlang.org/show_bug.cgi?id=1164 --- Comment #9 from Pieter Penninckx --- Just to be sure I understand you correctly. Am I right that the garbage collector currently works as follows: * Mark (= mark all reachable objects as reachable) * For each collectable (= non-reachable) object: * Call dtor * release memory of the collectable object Am I right that the steps you are thinking about can also be formulated as follows: * Mark (= mark all reachable objects as reachable) * For each collectable (= non-reachable) object: * Call dtor * Obliterate with .init * For each collectable object: * release memory of the collectable object --
[Issue 16990] Ensure that every Phobos function has a unittest
https://issues.dlang.org/show_bug.cgi?id=16990 --- Comment #1 from greenify --- The tools has been integrated into the tools repo: https://github.com/dlang/tools/blob/master/styles/has_public_example.d run with e.g. dub --root=../tools/styles -c has_public_example -i std Moreover, there's an open PR to Phobos to enable it with a blacklist: https://github.com/dlang/phobos/pull/4998 It will introduce this as `has_public_example` Makefile target, thus from the Phobos repo: make -f posix.mak has_public_example Help to reduce the blacklist is very welcome! --
