On Saturday, 11 January 2014 at 13:22:52 UTC, Iain Buclaw wrote:
> Remember when I told you that LLVM devs reverted commits made by core
> GCC developers because apparently there was no explicit contribution by them to LLVM?  :-)

I don't recall the details, but I don't see how this is relevant to this discussion. There is a difference between requiring copyright assignment from contributors and being cautious about including code that you suspect to be incompatible with the (more liberal) license of your project.

David

On Saturday, 11 January 2014 at 13:16:40 UTC, Paulo Pinto wrote:
> He is the best person to explain such issues, I would say.

…which is precisely why I found it odd that you posted such an unqualified umbrella statement here in the first place. ;)

No offense intended, but just speculating about Walter's motives doesn't really help the discussion at all.

If I remember correctly, Walter joined the last bigger discussion on this issue here on the NG a year ago or so, and licensing issues were *not* one of the arguments that lasted.

David

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.

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

Am Fri, 10 Jan 2014 13:44:52 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> We plan to rig Facebook's build system to use dmd in debug mode and gdc in release mode by default. Best of both worlds.
> 
> Andrei

I do that too, and part of the reason why I hacked something
together for the Gentoo Linux package manager, so I could
install libraries for multiple compilers at once.
It seems so trivial to use dmd and a companion compiler gdc
or ldc, but once shared libraries and multiple D releases come
into the mix, it means patching up dmd, make files and dealing
with "rpath" to load the correct .so (compiler using a
specific compiler vendor/version combination).

-- 
Marco

Am 10.01.2014 21:56, schrieb John Colvin:
>
> also, the digital mars backend is very fast, which is actually good
> selling point for some use-cases where compilation speed is important.

I would also prefer to keep the digital mars backend for exactly that reason. The GCC and LLVM backends are just way to slow.

Kind Regards
Benjamin Thaut

On Saturday, 11 January 2014 at 13:04:13 UTC, Iain Buclaw wrote:
> 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?

There are plenty of PDB parsers available, so it should be possible to uncover the format from there.

Here's one.

https://code.google.com/p/pdbparse/

On 11 Jan 2014 16:55, "Peter Alexander" <peter.alexander.au@gmail.com> wrote:
>
> On Saturday, 11 January 2014 at 13:04:13 UTC, Iain Buclaw wrote:
>>
>> 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?
>
>
> There are plenty of PDB parsers available, so it should be possible to
uncover the format from there.
>
> Here's one.
>
> https://code.google.com/p/pdbparse/

But just to clarify, that is a reverse engineering effort?

On Sat, 11 Jan 2014 05:04:03 -0800, 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?

This is no longer true of LLVM, they've got Windows specific builds that output PDB and link with COFF natively. See: http://llvm.org/builds/

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

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.

-- 
/Jacob Carlborg

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.

LLVM is also the finalizer for HSAIL, AMD is using it for their linux port of C++AMP. But I would assume that ldc probably wouldn't have any issues generating HSA compatible code with minor modifications as is(as the LLVM backend will support it).

I have no idea if GCC will support HSA or not however Microsoft is fully supporting it, as is ARM. So I wouldn't think that GCC would be to far behind on that one.