On 11 January 2014 23:04, Iain Buclaw <ibuclaw@gdcproject.org> wrote:

> On 11 January 2014 00:24, Manu <turkeyman@gmail.com> wrote:
> > On 11 January 2014 06:59, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> >>
> >> On 10 January 2014 20:54, John Colvin <john.loughran.colvin@gmail.com> wrote:
> >> > On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:
> >> >>
> >> >> This might have been brought up before but I couldn't find any thread
> >> >> about this. As things has progressed I wonder if Digital Mars DMD
> >> >> should
> >> >> move over to use LLVM instead of its own code generation and compiler
> >> >> framework.
> >> >>
> >> >> As I see it with the small amount of contributors D-language has, DMD
> >> >> will
> >> >> never support anything beyond x86 as there are no resources for this.
> >> >> Also,
> >> >> why spend time on recreating the the code generation which has
> already
> >> >> been
> >> >> done with LLVM? This enables this community to focus on the language
> >> >> which
> >> >> is the most important part as well as supporting more and future
> >> >> processor
> >> >> targets.
> >> >
> >> >
> >> > This comes up regularly. It's already been done. Ldc *is* dmd with
> llvm
> >> > backend. Gdc is the same idea but with the gcc framework.
> >>
> >> Indeed. But naturally I'd suggest they move to GCC.  ;-)
> >
> >
> > Is it possible that GDC will ever produce binaries that will link against
> > the microsoft libs without problems?
> > In my experience, GDC produces intrinsic calls to its own runtime all
> over
> > the place, and it's not compatible with the microsoft runtime. I also
> recall
> > library format mismatch, but that was a long time ago, and I think we discussed it again since deciding that GDC is now using the same format
> as
> > VisualC in windows...?
> > Can GDC write PDB debuginfo into the objects (CV8 I think it is)?
>
> As I understand, neither GCC nor LLVM are capable of producing PDB. Has Microsoft even release any documentation or code necessary to produce files in their PDB format?
>

Walter did it for DMD. I think CV8 is more or less documented, but he found some Microsoft tweaks to the format, or something like that.

On 12 January 2014 00:35, Kai Nacke <kai@redstar.de> wrote:

> On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:
>
>> This might have been brought up before but I couldn't find any thread about this. As things has progressed I wonder if Digital Mars DMD should move over to use LLVM instead of its own code generation and compiler framework.
>>
>> As I see it with the small amount of contributors D-language has, DMD will never support anything beyond x86 as there are no resources for this. Also, why spend time on recreating the the code generation which has already been done with LLVM? This enables this community to focus on the language which is the most important part as well as supporting more and future processor targets.
>>
>
> You currently can't get the best of all worlds in a single compiler.
>
> LLVM does not support exceptions on native Win32. (Same is true for Win64
> but I hope to change this.) LLVM does not support CodeView debug symbols.
> Not in the format embedded in object file and not as PDB.
> In short, you loose the complete native Windows tool chain.
>

Is there any progress on any of these things BTW?
At some point, sooner or later, we're REALLY going to need a performance
compiler on Windows...

With LDC, you can use other platforms. E.g. it runs on Linux/PPC64. But you
> can't ignore the backend because it has bugs and is incomplete.
>
> E.g. on Linux/ARM I have a linker error when I enable generation of debug symbols. LLVM for arm-apple-darwin does not support TLS. LLVM for PPC supports only 2 of the 4 TLS models. In addition, the assembler for PPC/PPC64 does not support all instructions I need for std.math.
>
> Regards,
> Kai
>

On Monday, 13 January 2014 at 05:04:46 UTC, Manu wrote:
> On 12 January 2014 00:35, Kai Nacke <kai@redstar.de> wrote:
>
>> On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:
>>
>>> This might have been brought up before but I couldn't find any thread
>>> about this. As things has progressed I wonder if Digital Mars DMD should
>>> move over to use LLVM instead of its own code generation and compiler
>>> framework.
>>>
>>> As I see it with the small amount of contributors D-language has, DMD
>>> will never support anything beyond x86 as there are no resources for this.
>>> Also, why spend time on recreating the the code generation which has
>>> already been done with LLVM? This enables this community to focus on the
>>> language which is the most important part as well as supporting more and
>>> future processor targets.
>>>
>>
>> You currently can't get the best of all worlds in a single compiler.
>>
>> LLVM does not support exceptions on native Win32. (Same is true for Win64
>> but I hope to change this.) LLVM does not support CodeView debug symbols.
>> Not in the format embedded in object file and not as PDB.
>> In short, you loose the complete native Windows tool chain.
>>
>
> Is there any progress on any of these things BTW?
> At some point, sooner or later, we're REALLY going to need a performance
> compiler on Windows...
>

Only recently LLVM developers really started caring about Windows, so it will take awhile until LLVM is a first class citizen.

http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html

--
Paulo

On Saturday, 11 January 2014 at 20:38:32 UTC, Jacob Carlborg wrote:
> On 2014-01-10 23:16, Joseph Rushton Wakeling wrote:
>
>> Yes, but there's a difference between "restrictive" and "intrusive".
>> Using GDC doesn't intrude into anything -- the standard libraries are
>> still Boost-licensed and simply _using_ a GPL'd piece of software
>> doesn't place any obligations on you.
>
> The way Apple has integrated Clang into Xcode would never be possible with GCC since that would require Apple to release Xcode under the GPL license.

Right, but they are not merely using -- they are redistributing (and distributing derivative works).  The GPL places certain constraints here, I think we can all agree, but it can hardly be described as "intrusive"; there's no obligation to base one's work on GPL-licensed code.

On 13 January 2014 05:01, Manu <turkeyman@gmail.com> wrote:
> On 11 January 2014 23:04, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>>
>> On 11 January 2014 00:24, Manu <turkeyman@gmail.com> wrote:
>> > On 11 January 2014 06:59, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>> >>
>> >> On 10 January 2014 20:54, John Colvin <john.loughran.colvin@gmail.com> wrote:
>> >> > On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:
>> >> >>
>> >> >> This might have been brought up before but I couldn't find any
>> >> >> thread
>> >> >> about this. As things has progressed I wonder if Digital Mars DMD
>> >> >> should
>> >> >> move over to use LLVM instead of its own code generation and
>> >> >> compiler
>> >> >> framework.
>> >> >>
>> >> >> As I see it with the small amount of contributors D-language has,
>> >> >> DMD
>> >> >> will
>> >> >> never support anything beyond x86 as there are no resources for
>> >> >> this.
>> >> >> Also,
>> >> >> why spend time on recreating the the code generation which has
>> >> >> already
>> >> >> been
>> >> >> done with LLVM? This enables this community to focus on the language
>> >> >> which
>> >> >> is the most important part as well as supporting more and future
>> >> >> processor
>> >> >> targets.
>> >> >
>> >> >
>> >> > This comes up regularly. It's already been done. Ldc *is* dmd with
>> >> > llvm
>> >> > backend. Gdc is the same idea but with the gcc framework.
>> >>
>> >> Indeed. But naturally I'd suggest they move to GCC.  ;-)
>> >
>> >
>> > Is it possible that GDC will ever produce binaries that will link
>> > against
>> > the microsoft libs without problems?
>> > In my experience, GDC produces intrinsic calls to its own runtime all
>> > over
>> > the place, and it's not compatible with the microsoft runtime. I also
>> > recall
>> > library format mismatch, but that was a long time ago, and I think we
>> > discussed it again since deciding that GDC is now using the same format
>> > as
>> > VisualC in windows...?
>> > Can GDC write PDB debuginfo into the objects (CV8 I think it is)?
>>
>> As I understand, neither GCC nor LLVM are capable of producing PDB. Has Microsoft even release any documentation or code necessary to produce files in their PDB format?
>
>
> Walter did it for DMD. I think CV8 is more or less documented, but he found some Microsoft tweaks to the format, or something like that.

Yes, however Walter has *ehem* ties with Microsoft, so he may have access to information the Free Software community don't. ;)

On 13 January 2014 08:07, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On Saturday, 11 January 2014 at 20:38:32 UTC, Jacob Carlborg wrote:
>>
>> On 2014-01-10 23:16, Joseph Rushton Wakeling wrote:
>>
>>> Yes, but there's a difference between "restrictive" and "intrusive". Using GDC doesn't intrude into anything -- the standard libraries are still Boost-licensed and simply _using_ a GPL'd piece of software doesn't place any obligations on you.
>>
>>
>> The way Apple has integrated Clang into Xcode would never be possible with GCC since that would require Apple to release Xcode under the GPL license.
>
>
> Right, but they are not merely using -- they are redistributing (and distributing derivative works).  The GPL places certain constraints here, I think we can all agree, but it can hardly be described as "intrusive"; there's no obligation to base one's work on GPL-licensed code.

Yah, but s/constraints/freedoms/.  :-)

On 13/01/14 09:13, Iain Buclaw wrote:
> Yah, but s/constraints/freedoms/.  :-)

Quite. :-)

On 2014-01-13 09:07, Joseph Rushton Wakeling wrote:

> Right, but they are not merely using -- they are redistributing (and
> distributing derivative works).  The GPL places certain constraints
> here, I think we can all agree, but it can hardly be described as
> "intrusive"; there's no obligation to base one's work on GPL-licensed code.

I think the "intrusive" part referrers to, if you use GPL licensed code your own coded need to be GPL licensed as well.

-- 
/Jacob Carlborg

On 2014-01-13 09:11, Iain Buclaw wrote:

> Yes, however Walter has *ehem* ties with Microsoft, so he may have
> access to information the Free Software community don't. ;)

It doesn't hurt to ask ;)

-- 
/Jacob Carlborg

On Monday, 13 January 2014 at 05:04:46 UTC, Manu wrote:
> On 12 January 2014 00:35, Kai Nacke <kai@redstar.de> wrote:
>
>> On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:
>>
>>> This might have been brought up before but I couldn't find any thread
>>> about this. As things has progressed I wonder if Digital Mars DMD should
>>> move over to use LLVM instead of its own code generation and compiler
>>> framework.
>>>
>>> As I see it with the small amount of contributors D-language has, DMD
>>> will never support anything beyond x86 as there are no resources for this.
>>> Also, why spend time on recreating the the code generation which has
>>> already been done with LLVM? This enables this community to focus on the
>>> language which is the most important part as well as supporting more and
>>> future processor targets.
>>>
>>
>> You currently can't get the best of all worlds in a single compiler.
>>
>> LLVM does not support exceptions on native Win32. (Same is true for Win64
>> but I hope to change this.) LLVM does not support CodeView debug symbols.
>> Not in the format embedded in object file and not as PDB.
>> In short, you loose the complete native Windows tool chain.
>>
>
> Is there any progress on any of these things BTW?
> At some point, sooner or later, we're REALLY going to need a performance
> compiler on Windows...

My patch for exceptions on Win64 is finally in review. I hope to commit it soon.

The Google guys are adding COFF line number support right now.

Regards,
Kai

>
> With LDC, you can use other platforms. E.g. it runs on Linux/PPC64. But you
>> can't ignore the backend because it has bugs and is incomplete.
>>
>> E.g. on Linux/ARM I have a linker error when I enable generation of debug
>> symbols. LLVM for arm-apple-darwin does not support TLS. LLVM for PPC
>> supports only 2 of the 4 TLS models. In addition, the assembler for
>> PPC/PPC64 does not support all instructions I need for std.math.
>>
>> Regards,
>> Kai