On Tuesday, 26 August 2014 at 10:57:51 UTC, Kai Nacke wrote:
>
> Thanks for debugging! I commit this asap.
>
> Regards,
> Kai

Awesome, No problem!

You probably realized already, but just to make sure, grepping after isWindowsGNUEnvironment revealed more of the same:
./driver/linker.cpp
./driver/main.cpp
./driver/toobj.cpp
./gen/declarations.cpp
./gen/naked.cpp:

Regards,
Daniel N

On Tuesday, 26 August 2014 at 12:08:53 UTC, Daniel N wrote:
> On Tuesday, 26 August 2014 at 10:57:51 UTC, Kai Nacke wrote:
>>
>> Thanks for debugging! I commit this asap.
>>
>> Regards,
>> Kai
>
> Awesome, No problem!
>
> You probably realized already, but just to make sure, grepping after isWindowsGNUEnvironment revealed more of the same:
> ./driver/linker.cpp
> ./driver/main.cpp
> ./driver/toobj.cpp
> ./gen/declarations.cpp
> ./gen/naked.cpp:
>
> Regards,
> Daniel N

Thanks for the hint. I committed the change. If you like you can try it...

Regards,
Kai

On Tuesday, 26 August 2014 at 17:00:37 UTC, Kai Nacke wrote:
> Thanks for the hint. I committed the change. If you like you can try it...
>
> Regards,
> Kai

Thanks, the patch works like a Charm! It allowed me to find the next(and probably final issue).

When building with LLVM 3.5 my GCC/GAS is not happy with certain COMDAT directives, I tested switching to build with my own compiled LLVM 3.4.2 that is fully functional as expected.

If I use "-disable-linker-strip-dead" then the 'one_only' syntax returns to the old 3.4.2 style, but the new 'discard' syntax remain despite the switch, see below comparison for what I mean.

=== 34 ===
.text
.linkonce discard

=== 35 ===
.section	.text,"xr",one_only,__Dmain
.section	.text,"xr",discard,__D4dial13__T6createTiZ6createFNaNbNfiZi

=== 35 && -disable-linker-strip-dead ===
.text
.section	.text,"xr",discard,__D4dial13__T6createTiZ6createFNaNbNfiZi

Regards,
Daniel N

On Tuesday, 26 August 2014 at 12:07:59 UTC, Joakim wrote:
> If you want to know what's currently enabled for any particular invocation of the compiler, add the -v flag and it'll show them at the top.

Super, that was exactly what I was looking for. :)

Thanks!
Daniel N

On Wednesday, 27 August 2014 at 14:59:33 UTC, Daniel N wrote:
> === 35 && -disable-linker-strip-dead ===
> .text
> .section	.text,"xr",discard,__D4dial13__T6createTiZ6createFNaNbNfiZi

PS I found a fix so that I don't have to specify -disable-linker-strip-dead

.\driver\targetmachine.cpp

= Before =
if (!noLinkerStripDead && (triple.getOS() == llvm::Triple::Linux || triple.getOS() == llvm::Triple::Win32))

But for "LDC_LLVM_VER >= 305" I guess you need to use
"triple.isWindowsMSVCEnvironment()" instead of "triple.getOS() == llvm::Triple::Win32".

I didn't find a fix for the 2nd issue yet though.

Regards,
Daniel N

On Wednesday, 27 August 2014 at 14:59:33 UTC, Daniel N wrote:
> On Tuesday, 26 August 2014 at 17:00:37 UTC, Kai Nacke wrote:
>> Thanks for the hint. I committed the change. If you like you can try it...
>>
>> Regards,
>> Kai
>
> Thanks, the patch works like a Charm! It allowed me to find the next(and probably final issue).
>
> When building with LLVM 3.5 my GCC/GAS is not happy with certain COMDAT directives, I tested switching to build with my own compiled LLVM 3.4.2 that is fully functional as expected.
>
> If I use "-disable-linker-strip-dead" then the 'one_only' syntax returns to the old 3.4.2 style, but the new 'discard' syntax remain despite the switch, see below comparison for what I mean.
>
> === 34 ===
> .text
> .linkonce discard
>
> === 35 ===
> .section	.text,"xr",one_only,__Dmain
> .section	.text,"xr",discard,__D4dial13__T6createTiZ6createFNaNbNfiZi
>
> === 35 && -disable-linker-strip-dead ===
> .text
> .section	.text,"xr",discard,__D4dial13__T6createTiZ6createFNaNbNfiZi
>
> Regards,
> Daniel N

Hi Daniel!

You could try the integrated LLVM assembler. I am currently testing this setup.

1. In driver/toobj.cpp, set bool const assembleExternally = false;
2. in std.math, exchange in real poly(...) the inline assembler with the D version (simply replace D_InlineAsm_X86 with none).

This is what I am currently testing.

Regards,
Kai

On Wednesday, 27 August 2014 at 17:14:24 UTC, Kai Nacke wrote:
> Hi Daniel!
>
> You could try the integrated LLVM assembler. I am currently testing this setup.
>
> 1. In driver/toobj.cpp, set bool const assembleExternally = false;
> 2. in std.math, exchange in real poly(...) the inline assembler with the D version (simply replace D_InlineAsm_X86 with none).
>
> This is what I am currently testing.
>
> Regards,
> Kai

Hi Kai,

yay, it works! Thanks for the fantastic support.

Regards,
Daniel N

On 2 Sep 2014, at 2:09, David Nadlinger wrote:
> SEH support to the MC assembler […]
>
> SEH […]

Whoops, I of course meant to write DW(arf) 2 EH, not SEH.

On 27 Aug 2014, at 19:14, Kai Nacke via digitalmars-d-ldc wrote:
> You could try the integrated LLVM assembler. I am currently testing this setup.
>
> 1. In driver/toobj.cpp, set bool const assembleExternally = false;
> 2. in std.math, exchange in real poly(...) the inline assembler with the D version (simply replace D_InlineAsm_X86 with none).
>
> This is what I am currently testing.

Have the LLVM folks added SEH support to the MC assembler recently? Otherwise, this will not work.

SEH is the sole reason for which I switched the MinGW port to using GAS. The sooner we can get rid of it, the better.

Best,
David

On Tuesday, 2 September 2014 at 00:22:52 UTC, David Nadlinger via digitalmars-d-ldc wrote:
> On 2 Sep 2014, at 2:09, David Nadlinger wrote:
>> SEH support to the MC assembler […]
>>
>> SEH […]
>
> Whoops, I of course meant to write DW(arf) 2 EH, not SEH.

Hi David,

it seems OK to me(disclaimer: I don't speak fluent dwarf).

objdump.exe dial.exe --dwarf=frames-interp

dial.exe:     file format pei-i386

Contents of the .eh_frame section:

00000000 00000014 00000000 CIE "zR" cf=1 df=-4 ra=8
   LOC   CFA      ra
00000000 esp+4    c-4

00000018 00000010 0000001c FDE cie=00000000 pc=ffebb000..ffebb002
   LOC   CFA      ra
ffebb000 esp+4    c-4

0000002c 00000020 00000030 FDE cie=00000000 pc=ffebb010..ffebb12e
   LOC   CFA      ra
ffebb010 esp+4    c-4
ffebb013 esp+32   c-4
ffebb098 esp+4    c-4
ffebb0a0 esp+4    c-4
ffebb111 esp+4    c-4
ffebb112 esp+4    c-4