After intensive debugging, the strange issue responsible for most failures seems to be reducible to some unit tests allocating GC memory, this in turn leading to a GC collection pass which then destroys the `__gshared core.thread.Thread core.thread.Thread.sm_tbeg` object representing the main thread (it's actually the start of a linked list of threads). The object should actually be kept alive by the sm_tbeg reference (and the main Thread additionally by sm_main). After initializing the reference with the main Thread at program startup, it isn't touched (i.e., not reset to null - verified via data breakpoint), but the object is finalized anyway.

So it looks as if the GC doesn't know about these __gshared references. When accessing the linked list later, when terminating all threads right before exiting the program, funny things happen due to garbage in the .next and .prev references.

I've just tried storing another reference to the main Thread as `static Thread core.thread.Thread.sm_mainDummy`, and the object isn't destroyed anymore. So `gshared` seems to be the problem. And most likely all other targets are affected too by this bug.

"kinke" <noone@nowhere.com> writes:

> I've just tried storing another reference to the main Thread as `static Thread core.thread.Thread.sm_mainDummy`, and the object isn't destroyed anymore. So `gshared` seems to be the problem. And most likely all other targets are affected too by this bug.

Could sections_ldc.initSections() be neglecting the BSS section?  I
noticed the version(Win64) code has:

        if (_bss_start__ != null)
        {
            pushRange(&_bss_start__, &_bss_end__);
        }

--
Dan

Dan Olson <zans.is.for.cans@yahoo.com> writes:

> "kinke" <noone@nowhere.com> writes:
>
>> I've just tried storing another reference to the main Thread as `static Thread core.thread.Thread.sm_mainDummy`, and the object isn't destroyed anymore. So `gshared` seems to be the problem. And most likely all other targets are affected too by this bug.
>
> Could sections_ldc.initSections() be neglecting the BSS section?  I
> noticed the version(Win64) code has:
>
>         if (_bss_start__ != null)
>         {
>             pushRange(&_bss_start__, &_bss_end__);
>         }

I don't have a Windows host available right now, but am assuming that _bss_start__ is a symbol created by linker that overlays first variable in BSS, which very likely is 0 because it is in BSS.  But again, just guessing.

Thx for the hint, Dan!!!

99% tests passed, 4 tests failed out of 556

The following tests FAILED:
        175 - std.math (Failed)
        191 - std.stream (Failed)
        460 - std.socket-debug (Failed)
        465 - std.stream-debug (Failed)

!!! :))

The problem was that instead of using the range [_data_start__, _data_end__) (computed in rt/msvc.c), we've used [&_data_start__, &_data_end__). We also did so for the BSS section, which isn't present in my druntime-test-runner-debug.exe though.

Hi all !
http://goo.gl/0JI4qJ
Why ldc cannot optimize it ?
Should i create an issue ?
For example gdc uses only one mulfps.

For example that code is ok: http://goo.gl/QMfpzg

Can we rewrite vector operations with foreach rather than call vector functions ?

On Wednesday, 20 May 2015 at 13:34:50 UTC, Temtaime wrote:
> Hi all !
> http://goo.gl/0JI4qJ
> Why ldc cannot optimize it ?
> Should i create an issue ?
> For example gdc uses only one mulfps.

Rule of thumb: don't use array ops for short arrays. They are quite well optimised for large arrays, but aren't great in cases like your example.

On Thursday, 21 May 2015 at 19:05:33 UTC, John Colvin wrote:
> Rule of thumb: don't use array ops for short arrays. They are quite well optimised for large arrays, but aren't great in cases like your example.

We should be able to do better, though, especially for cases like this where the length is known statically.

 — David

On Thursday, 21 May 2015 at 19:07:20 UTC, David Nadlinger wrote:
> We should be able to do better, though, especially for cases like this where the length is known statically.

Definitely, if GDC manages to do so, we should too.

Some years ago, I ported some math-intensive C++ code to D and rewrote all simple loops by array ops, for better readability but primarily because I assumed that'd help with SSE vectorization. No wonder the runtime was about an order of magnitude higher compared to the corresponding C++ version. The disappointment was rather high and lowered my interest in D, so yes, please create a Github issue about this.

Hi guys !
I recently found that ldc doesn't compile with llvm master anymore.
They removed CreateCall[2-3] functions ans some of overloads of CreateCall too.

Now all the parameters should be passed to that function by vector<llvm::Value *>.
Anyone to fix ?