Inline asm label naming issue

[dnadlinger]

ZILtoid1991/CPUblit@fa802a4 doesn't compile with LDC.

The cause is in src/CPUbilt/composing.d, which fails with errors like:

<inline asm>:6:2: error: unsupported relocation of undefined symbol 'L7CPUblit9composing11blitter8bit_eightpixel'
        jl L7CPUblit9composing11blitter8bit_eightpixel

I haven't had a proper look at this yet, but from a quick glance at the -vv output, it seems like we are emitting the label – properly! – as L_D7CPUblit9composing11blitter8bitFNiPhPhPhmZv_eightpixel, but try to reference it without the full mangle.

This only occurs if there is more than one overload of the function in question.

[ZILtoid1991]

Here's my experiences as a compiler noob:

For me it generated the code, however when I tried to run a program using it (see PixelPerfectEditor subpackage here: https://github.com/ZILtoid1991/pixelperfectengine ) the composing functions didn't work as intended and didn't perform the jumping out of the cycles when there were no more pixels left, also some of the parameters look really off. Did some modifications to the code, replaced the buffer for color lookup functions with D's built-in dynamic arrays (which is often more tolerant with out-of-bounds reads in my own experience), this time the code generates a stack overflow exception.

I'm trying to get rid of the current multithreading system in the rendering, as it allocates on the heap, and I want a @nogc-able solution in the future. I'll document how it changes the execution, might be an error regarding std.parallel.

[dnadlinger]

You are getting compiler errors, so don't expect the code to do anything sensible. Not sure why the compiler doesn't abort, which is an error in its own right.

[ZILtoid1991]

There's also seems to be a bug regarding passing arguments, don't know if the two are related of not. After some further testing it seems that the reason for the crash is this, if I can get around it I can test if the generated code is actually right.