www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Heads up, g++ in Xcode 5 points to Clang

reply Jacob Carlborg <doob me.com> writes:
I just wanted to let you know that after installing Xcode 5, g++ is 
actually pointing to Clang. Last time I tried to compile DMD with Clang 
all tests didn't pass.

-- 
/Jacob Carlborg
Oct 27 2013
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Sunday, 27 October 2013 at 10:36:56 UTC, Jacob Carlborg wrote:

 I just wanted to let you know that after installing Xcode 5, 
 g++ is actually pointing to Clang. Last time I tried to compile 
 DMD with Clang all tests didn't pass.


Same with gcc. It's really annoying that when you install the gnu
tools you have to change the symlinks yourself. I guess apple
prefers the clang tools.
Oct 27 2013
next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
genuine question: is there any advantage of gcc over llvm ?
Betting over clang/llvm/lldb seems to make more sense.



On Sun, Oct 27, 2013 at 3:57 AM, Gary Willoughby <dev nomad.so> wrote:


 On Sunday, 27 October 2013 at 10:36:56 UTC, Jacob Carlborg wrote:


 I just wanted to let you know that after installing Xcode 5, g++ is
 actually pointing to Clang. Last time I tried to compile DMD with Clang all
 tests didn't pass.


 Same with gcc. It's really annoying that when you install the gnu
 tools you have to change the symlinks yourself. I guess apple
 prefers the clang tools.
Oct 27 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-28 00:52, Timothee Cour wrote:

 genuine question: is there any advantage of gcc over llvm ?
 Betting over clang/llvm/lldb seems to make more sense.


No, I don't see any advantage. Although I don't like that Apple silently 
changes what gcc/g++ is.

-- 
/Jacob Carlborg
Oct 28 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Monday, 28 October 2013 at 08:02:45 UTC, Jacob Carlborg wrote:

 No, I don't see any advantage. Although I don't like that Apple 
 silently changes what gcc/g++ is.


They are trying to phase out GCC altogether, as they are stuck 
with an ancient version due to licensing issues (GPLv3).

The Clang driver was specifically engineered to be a drop-in 
replacement for GCC, so given that many Makefiles are hard-coded 
to use "gcc" or "g++", I think what they are doing makes sense.

David
Oct 28 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-10-28 09:40, David Nadlinger wrote:


 They are trying to phase out GCC altogether, as they are stuck with an
 ancient version due to licensing issues (GPLv3).

 The Clang driver was specifically engineered to be a drop-in replacement
 for GCC, so given that many Makefiles are hard-coded to use "gcc" or
 "g++", I think what they are doing makes sense.


I know the story, doesn't mean I like it. I like that they're changing 
to the LLVM tool chain, but not they way they're doing it. Apparently 
some tests fails when DMD is compiled with Clang.

-- 
/Jacob Carlborg
Oct 28 2013
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 28/10/13 00:52, Timothee Cour wrote:

 genuine question: is there any advantage of gcc over llvm ?


For Apple, probably not.  But GCC supports a much, much wider set of 
architectures than LLVM.
Oct 28 2013
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Monday, 28 October 2013 at 12:39:53 UTC, Joseph Rushton 
Wakeling wrote:

 On 28/10/13 00:52, Timothee Cour wrote:

 genuine question: is there any advantage of gcc over llvm ?


 For Apple, probably not.  But GCC supports a much, much wider 
 set of architectures than LLVM.


sure, but i would prefer LLVM license over GCC if i were in Apple 
dev team(and that what they did). also LLVM is quite young, so 
who knows what people contribute to it in near future...
Oct 28 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 28/10/13 14:22, evilrat wrote:

 sure, but i would prefer LLVM license over GCC if i were in Apple dev team(and
 that what they did). also LLVM is quite young, so who knows what people
 contribute to it in near future...


Surely, but we should have sympathy for Apple's desire to be able to exert 
proprietary control over their products because ... ? :-)

Don't get me wrong, LLVM itself is a fantastic project, and as long as people 
contribute great code to great free software projects I don't really mind what 
their motivation is, but if Apple's goal is to avoid the patent-related 
provisions of GPLv3, we could be in for a nasty surprise at some point in the 
future if compiler-related patents Apple holds become part of the battleground 
of the computing market.

 From a purely technical point of view, Apple doesn't need a compiler that 
supports a wide range of platforms, so GCC's much broader range of hardware 
support is irrelevant to it.  But it's an advantage GCC continues to have in
the 
bigger picture.
Oct 28 2013
next sibling parent reply "Joakim" <joakim airpost.net> writes:
On Monday, 28 October 2013 at 15:49:41 UTC, Joseph Rushton 
Wakeling wrote:

 On 28/10/13 14:22, evilrat wrote:

 sure, but i would prefer LLVM license over GCC if i were in 
 Apple dev team(and
 that what they did). also LLVM is quite young, so who knows 
 what people
 contribute to it in near future...


 Surely, but we should have sympathy for Apple's desire to be 
 able to exert proprietary control over their products because 
 ... ? :-)


Do you have any evidence that they've exerted "proprietary 
control" over llvm, say by adding closed modules to their 
compiler?

I actually talked to the head llvm guy at Apple about this 
possibility a couple years back and he was adamantly against 
anyone outside closing up parts of the compiler.  Of course, he 
may not get to make that decision at Apple and we can't know the 
truth unless we peek at the source for the shipping compiler at 
Apple, but I haven't seen any evidence that llvm isn't developed 
in the open.

Have you?


 Don't get me wrong, LLVM itself is a fantastic project, and as 
 long as people contribute great code to great free software 
 projects I don't really mind what their motivation is, but if 
 Apple's goal is to avoid the patent-related provisions of 
 GPLv3, we could be in for a nasty surprise at some point in the 
 future if compiler-related patents Apple holds become part of 
 the battleground of the computing market.


While I do not buy Apple products because of their odious patent 
stance, I highly doubt they would ever use such compiler patents, 
if they even have any.  Microsoft has a patent on continually 
scanning a document for spelling errors and highlighting them 
(http://www.google.com/patents/US5787451), yet _as far as we 
know_ (and according to a former Microsoft employee - 
http://keithcu.com/wordpress/?page_id=1548), they've never 
asserted it on the dozens of applications with such 
spell-checking in their text editing controls, including this 
Chrome browser tab I'm currently typing into.

I agree that it is a problem that Apple doesn't do a patent grant 
for their open source projects, assuming they even have any 
compiler or other software patents on them, but I'm skeptical 
they'd ever enforce those anyway.  Also, IANAL, but I believe 
they'd never be able to extract any money from such a lawsuit 
anyway, since they don't make any money from clang or Safari and 
give them away for free.


 From a purely technical point of view, Apple doesn't need a 
 compiler that supports a wide range of platforms, so GCC's much 
 broader range of hardware support is irrelevant to it.  But 
 it's an advantage GCC continues to have in the bigger picture.


Sure.
Oct 28 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-10-28 18:33, Joakim wrote:


 I actually talked to the head llvm guy at Apple about this possibility a
 couple years back and he was adamantly against anyone outside closing up
 parts of the compiler.  Of course, he may not get to make that decision
 at Apple and we can't know the truth unless we peek at the source for
 the shipping compiler at Apple, but I haven't seen any evidence that
 llvm isn't developed in the open.

 Have you?


No, but LLVM shipped by Apple might not be the same LLVM you can access 
the source code to.

-- 
/Jacob Carlborg
Oct 28 2013
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 28/10/13 18:33, Joakim wrote:

 Do you have any evidence that they've exerted "proprietary control" over llvm,
 say by adding closed modules to their compiler?


I understand how you could interpret it that way, but my email didn't actually 
suggest that Apple had any plans to close-source the compiler.

My impression -- and I'm happy to be proven wrong -- is that Apple disliked the 
idea of a GPLv3-licensed compiler because its patent grants might have created 
problems for other parts of their software portfolio, which indeed _are_ 
proprietary.


 While I do not buy Apple products because of their odious patent stance, I
 highly doubt they would ever use such compiler patents, if they even have any.
 Microsoft has a patent on continually scanning a document for spelling errors
 and highlighting them (http://www.google.com/patents/US5787451), yet _as far as
 we know_ (and according to a former Microsoft employee -
 http://keithcu.com/wordpress/?page_id=1548), they've never asserted it on the
 dozens of applications with such spell-checking in their text editing controls,
 including this Chrome browser tab I'm currently typing into.


I think we've all seen enough software history to know that "highly unlikely"
is 
not the same as "won't happen". :-)


 I agree that it is a problem that Apple doesn't do a patent grant for their
open
 source projects, assuming they even have any compiler or other software patents
 on them, but I'm skeptical they'd ever enforce those anyway.  Also, IANAL, but
I
 believe they'd never be able to extract any money from such a lawsuit anyway,
 since they don't make any money from clang or Safari and give them away for
free.


I doubt they'd try to use their patents to extract money from anyone, but I 
could see them using them to put a competitor out of business.  If (say)
Firefox 
OS or Ubuntu Touch become significant forces in the mobile/tablet market, I 
wouldn't put it past any of the traditional mobile players to pull out their 
patent portfolios to try and damage them.
Oct 28 2013
next sibling parent reply "Joakim" <joakim airpost.net> writes:
On Monday, 28 October 2013 at 18:34:11 UTC, Joseph Rushton 
Wakeling wrote:

 On 28/10/13 18:33, Joakim wrote:

 Do you have any evidence that they've exerted "proprietary 
 control" over llvm,
 say by adding closed modules to their compiler?


 I understand how you could interpret it that way, but my email 
 didn't actually suggest that Apple had any plans to 
 close-source the compiler.


No, I got it, I knew you said they'd be "able to exert 
proprietary control," not that they'd done it.  I was just 
wondering if you had evidence that they actually had done any of 
that already, since I don't follow llvm closely.

It is a valid concern, as Google has been closing up a bunch of 
their initially Apache-licensed Android apps:

http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/

But the source is still out there for the older versions, and 
these companies don't have any responsibility to keep giving 
their work away for free.


 My impression -- and I'm happy to be proven wrong -- is that 
 Apple disliked the idea of a GPLv3-licensed compiler because 
 its patent grants might have created problems for other parts 
 of their software portfolio, which indeed _are_ proprietary.


Yeah, the GPLv3 is why Apple and FreeBSD stopped updating to the 
latest gcc after 4.2.1, which was the last GPLv2 release.  OS X 
10.8 and iOS 6 were completely built by clang and FreeBSD 10, the 
next major release, is making clang the default compiler.  I 
don't know if it's because of patent grants or other aspects of 
GPLv3.


 While I do not buy Apple products because of their odious 
 patent stance, I
 highly doubt they would ever use such compiler patents, if 
 they even have any.
 Microsoft has a patent on continually scanning a document for 
 spelling errors
 and highlighting them 
 (http://www.google.com/patents/US5787451), yet _as far as
 we know_ (and according to a former Microsoft employee -
 http://keithcu.com/wordpress/?page_id=1548), they've never 
 asserted it on the
 dozens of applications with such spell-checking in their text 
 editing controls,
 including this Chrome browser tab I'm currently typing into.


 I think we've all seen enough software history to know that 
 "highly unlikely" is not the same as "won't happen". :-)


Valid point.


 I agree that it is a problem that Apple doesn't do a patent 
 grant for their open
 source projects, assuming they even have any compiler or other 
 software patents
 on them, but I'm skeptical they'd ever enforce those anyway.  
 Also, IANAL, but I
 believe they'd never be able to extract any money from such a 
 lawsuit anyway,
 since they don't make any money from clang or Safari and give 
 them away for free.


 I doubt they'd try to use their patents to extract money from 
 anyone, but I could see them using them to put a competitor out 
 of business.  If (say) Firefox OS or Ubuntu Touch become 
 significant forces in the mobile/tablet market, I wouldn't put 
 it past any of the traditional mobile players to pull out their 
 patent portfolios to try and damage them.


How do they put them out of business if they don't get money out 
of them?  They could stop them from using that patented 
functionality, but you can usually design around such patents, 
unless they're overly broad, so it's a small hindrance, not 
really going to put you out of business.  Of course, "traditional 
mobile players" are a different issue, as they actually make 
money by selling the features they're patenting.

On Monday, 28 October 2013 at 17:45:39 UTC, Jacob Carlborg wrote:

 On 2013-10-28 18:33, Joakim wrote:


 I actually talked to the head llvm guy at Apple about this 
 possibility a
 couple years back and he was adamantly against anyone outside 
 closing up
 parts of the compiler.  Of course, he may not get to make that 
 decision
 at Apple and we can't know the truth unless we peek at the 
 source for
 the shipping compiler at Apple, but I haven't seen any 
 evidence that
 llvm isn't developed in the open.

 Have you?


 No, but LLVM shipped by Apple might not be the same LLVM you 
 can access the source code to.


Yep, that's why I mentioned that "we can't know the truth unless 
we peek at the source for the shipping compiler at Apple." :)

On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote:

 On 28 October 2013 18:38, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:

 It certainly seems to be true that LLVM is moving faster 
 innovation-wise.  I
 don't know how much of that is down to any architectural 
 advantages, how
 much might be because they support less targets and so have a 
 lower
 maintenance burden, and how much of it is just the scale of 
 resources being
 put into it.


 I don't see it that way.  Up until now at least I haven't seen
 anything they do that wasn't already do-able in GCC.  They just 
 do a
 better job at PR (which is what you expect from Apple anyway).


Really?  The claims that llvm has a cleaner codebase, is easier 
to use because it's all properly split up into different 
libraries, and introduces new features like better error 
reporting: that's all "PR?"
Oct 28 2013
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 28 October 2013 20:22, Joakim <joakim airpost.net> wrote:

 On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote:

 On 28 October 2013 18:38, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:

 It certainly seems to be true that LLVM is moving faster innovation-wise.
 I
 don't know how much of that is down to any architectural advantages, how
 much might be because they support less targets and so have a lower
 maintenance burden, and how much of it is just the scale of resources
 being
 put into it.


 I don't see it that way.  Up until now at least I haven't seen
 anything they do that wasn't already do-able in GCC.  They just do a
 better job at PR (which is what you expect from Apple anyway).


 Really?  The claims that llvm has a cleaner codebase, is easier to use
 because it's all properly split up into different libraries, and introduces
 new features like better error reporting: that's all "PR?"


GCC approach to libraries has not been to load them dynamically, take
libiberty for example:
http://gcc.gnu.org/onlinedocs/libiberty/Using.html#Using  - and the
"better" error reporting was in gcc, just off by default (Clang added
a little more with addition of ~~ tildas ~~).


From what I've read and gathered from David over a period of some


conversations.  Clang infrastructure-wise is much like gcc-3.3/gcc-4.0
was - they have a well defined AST that is capable of representing
everything you'd expect in a typical C-family language, with a
backdoor to lower level register/assembly representations for
target-specific implementations. The direction that GCC went in later
versions was closing the backdoor and moving backend-specific code in
various frontends to the middle end.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 28 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Monday, 28 October 2013 at 21:07:07 UTC, Iain Buclaw wrote:

 From what I've read and gathered from David over a period of 
 some
 conversations.  Clang infrastructure-wise is much like 
 gcc-3.3/gcc-4.0
 was - they have a well defined AST that is capable of 
 representing
 everything you'd expect in a typical C-family language, with a
 backdoor to lower level register/assembly representations for
 target-specific implementations.


If you are referring to LLVM here: Yes and no.

It's true that the LLVM IR is mostly target-independent (except 
for data type sizes and so on) with a number of backdoors in the 
form of inline assembly, special intrinsics and so on.

But at the same time, the LLVM IR is also of a very different 
quality than GCC GENERIC, being strictly in SSA form. I have not 
looked into the current GCC architecture in any detail, but I'd 
guess that LLVM itself starts approximately at the point where 
the middle-end does in GCC.

Clang itself is obviously on a higher layer, but unlike GENERIC, 
its data structures are not designed to be reused for 
non-C-family languages. So, the questions of whether its AST can 
represent every concept from another language or if it needs 
contains backdoors to a lower level are somewhat moot.

David
Oct 28 2013
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 28 October 2013 21:24, David Nadlinger <code klickverbot.at> wrote:

 On Monday, 28 October 2013 at 21:07:07 UTC, Iain Buclaw wrote:

 From what I've read and gathered from David over a period of some
 conversations.  Clang infrastructure-wise is much like gcc-3.3/gcc-4.0
 was - they have a well defined AST that is capable of representing
 everything you'd expect in a typical C-family language, with a
 backdoor to lower level register/assembly representations for
 target-specific implementations.



 If you are referring to LLVM here: Yes and no.

 It's true that the LLVM IR is mostly target-independent (except for data
 type sizes and so on) with a number of backdoors in the form of inline
 assembly, special intrinsics and so on.

 But at the same time, the LLVM IR is also of a very different quality than
 GCC GENERIC, being strictly in SSA form. I have not looked into the


current

 GCC architecture in any detail, but I'd guess that LLVM itself starts
 approximately at the point where the middle-end does in GCC.


That is pretty much what I gathered.  SSA forms are something of a
middle-end representation lowered from the GENERIC it receives from the
frontend.


 Clang itself is obviously on a higher layer, but unlike GENERIC, its data
 structures are not designed to be reused for non-C-family languages. So,


the

 questions of whether its AST can represent every concept from another
 language or if it needs contains backdoors to a lower level are somewhat
 moot.


I didn't say it needs to contain backdoors, I was just pointing out that
with LLVM you have the choice to drop to lower level if you choose to, I'd
imagine at some cost to the optimiser too.  For example, you are free to
implement your own calling convention from within the front-end in LLVM.
Something of which is not considered something to be language-dependent by
GCC, so you have no control over eg: *which* parameters are passed in
registers, the only possible talking with the backend is through target
hooks and setting the back-end attributes (such as 'regparm') to give hints.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 28 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 28/10/13 21:22, Joakim wrote:

 Really?  The claims that llvm has a cleaner codebase, is easier to use because
 it's all properly split up into different libraries, and introduces new
features
 like better error reporting: that's all "PR?"


It's my understanding from Iain's talks that the GCC backend is now much
cleaner 
and friendlier than it used to be.  I don't know how that compares to LLVM, but 
it may be that reports of the relative cleanliness of the two codebases are out 
of date.
Oct 28 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-10-28 19:33, Joseph Rushton Wakeling wrote:

 On 28/10/13 18:33, Joakim wrote:

 Do you have any evidence that they've exerted "proprietary control"
 over llvm,
 say by adding closed modules to their compiler?


 I understand how you could interpret it that way, but my email didn't
 actually suggest that Apple had any plans to close-source the compiler.

 My impression -- and I'm happy to be proven wrong -- is that Apple
 disliked the idea of a GPLv3-licensed compiler because its patent grants
 might have created problems for other parts of their software portfolio,
 which indeed _are_ proprietary.


Apple uses libclang in Xcode, that is, the dynamic library. They can't 
do that with GCC from a license perspective?

-- 
/Jacob Carlborg
Oct 28 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-28 16:49, Joseph Rushton Wakeling wrote:


 Surely, but we should have sympathy for Apple's desire to be able to
 exert proprietary control over their products because ... ? :-)

 Don't get me wrong, LLVM itself is a fantastic project, and as long as
 people contribute great code to great free software projects I don't
 really mind what their motivation is, but if Apple's goal is to avoid
 the patent-related provisions of GPLv3, we could be in for a nasty
 surprise at some point in the future if compiler-related patents Apple
 holds become part of the battleground of the computing market.

 From a purely technical point of view, Apple doesn't need a compiler
 that supports a wide range of platforms, so GCC's much broader range of
 hardware support is irrelevant to it.  But it's an advantage GCC
 continues to have in the bigger picture.


 From what I've heard and read (mostly from WWDC videos) Apple doesn't 
feel they can technically do what they want with a compiler with GCC.

I guess they technically can but it's too much work with the GCC code base.

-- 
/Jacob Carlborg
Oct 28 2013
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 28/10/13 18:48, Jacob Carlborg wrote:

  From what I've heard and read (mostly from WWDC videos) Apple doesn't feel
they
 can technically do what they want with a compiler with GCC.

 I guess they technically can but it's too much work with the GCC code base.


It certainly seems to be true that LLVM is moving faster innovation-wise.  I 
don't know how much of that is down to any architectural advantages, how much 
might be because they support less targets and so have a lower maintenance 
burden, and how much of it is just the scale of resources being put into it.
Oct 28 2013
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 28 October 2013 18:38, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:

 On 28/10/13 18:48, Jacob Carlborg wrote:

  From what I've heard and read (mostly from WWDC videos) Apple doesn't
 feel they
 can technically do what they want with a compiler with GCC.

 I guess they technically can but it's too much work with the GCC code
 base.



 It certainly seems to be true that LLVM is moving faster innovation-wise.  I
 don't know how much of that is down to any architectural advantages, how
 much might be because they support less targets and so have a lower
 maintenance burden, and how much of it is just the scale of resources being
 put into it.


I don't see it that way.  Up until now at least I haven't seen
anything they do that wasn't already do-able in GCC.  They just do a
better job at PR (which is what you expect from Apple anyway).


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 28 2013
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote:

 I don't see it that way.  Up until now at least I haven't seen
 anything they do that wasn't already do-able in GCC.


Have you looked at the quality of error messages in Clang or its 
explicitly designed tooling/IDE integration API?

The way I see it is that LLVM and Clang have certainly enriched 
the playing field, also pushing GCC forward in the process (and 
it is still in the lead in some areas – e.g. OpenMP, where even 
though Intel recently donated their code to LLVM, Clang still 
isn't quite there). You make it sound like GCC already did 
everything before that Clang/LLVM do now, and that's certainly 
not the case. ;)

David
Oct 28 2013
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 28/10/13 22:07, David Nadlinger wrote:

 Have you looked at the quality of error messages in Clang or its explicitly
 designed tooling/IDE integration API?


Yea, the quality of error messages with Clang is spectacular.  I still remember 
the first time I tried using it -- just on a whim -- and was shocked that code 
that compiled cleanly with GCC generated pages and pages of errors and
warnings. 
  But once I'd got past the shock and actually read them, I realized that they 
were actually telling me very explicitly what to do to fix the problem, and
that 
they were resolving unnecessary ambiguities in my source code.

But to be fair, we were talking about the backend, not the C/C++ compiler
frontend.
Oct 28 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-10-28 20:02, Iain Buclaw wrote:


 I don't see it that way.  Up until now at least I haven't seen
 anything they do that wasn't already do-able in GCC.  They just do a
 better job at PR (which is what you expect from Apple anyway).


I didn't say it wasn't doable. I can't say for sure since I haven't 
looked at the GCC code base and only looked briefly at the LLVM code 
base. But according to Apple it would be too much work to implement the 
features they wanted.

Also, Apple uses libclang in Xcode, that is, the dynamic library. They 
can't do that with GCC from a license perspective?

-- 
/Jacob Carlborg
Oct 28 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 28/10/13 20:02, Iain Buclaw wrote:

 I don't see it that way.  Up until now at least I haven't seen
 anything they do that wasn't already do-able in GCC.  They just do a
 better job at PR (which is what you expect from Apple anyway).


Ah, that was the option I overlooked :-)
Oct 28 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 28/10/13 20:02, Iain Buclaw wrote:

 I don't see it that way.  Up until now at least I haven't seen
 anything they do that wasn't already do-able in GCC.


I confess I may be biased here because recently I've been finding that D code 
compiled with LDC seems to typically run faster than stuff compiled with GDC -- 
particularly code which makes any kind of serious use of stuff from 
std.algorithm or any other strongly generic parts of the language.

I can't imagine there are any fundamental frontend glue-code differences that 
are responsible for that, so I was assuming LLVM had a few areas where its 
optimizations worked better than the GCC middle/backend for various language 
constructs.

I did test just now making sure that I used GDC with -march=native just in case 
that was the issue, but there's still a performance gap.  The only other guess
I 
have -- and it's a complete guess -- could it be inline-assembly related, that 
LDC gains a little here?
Oct 29 2013
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On Oct 29, 2013 7:16 AM, "Joseph Rushton Wakeling" <
joseph.wakeling webdrake.net> wrote:

 On 28/10/13 20:02, Iain Buclaw wrote:

 I don't see it that way.  Up until now at least I haven't seen
 anything they do that wasn't already do-able in GCC.



 I confess I may be biased here because recently I've been finding that D


code compiled with LDC seems to typically run faster than stuff compiled
with GDC -- particularly code which makes any kind of serious use of stuff
from std.algorithm or any other strongly generic parts of the language.

 I can't imagine there are any fundamental frontend glue-code differences


that are responsible for that, so I was assuming LLVM had a few areas where
its optimizations worked better than the GCC middle/backend for various
language constructs.

 I did test just now making sure that I used GDC with -march=native just


in case that was the issue, but there's still a performance gap.  The only
other guess I have -- and it's a complete guess -- could it be
inline-assembly related, that LDC gains a little here?

Inline assembler for dynamic array vector operations does improve speed by
20% over the generic loop that GDC uses (for small arrays at least).

LLVM certainly is making a name for itself in specialist benchmarks.  I'm
not sure how well it fares in general usage cases...

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 29 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 29 October 2013 at 07:37:05 UTC, Iain Buclaw wrote:

 LLVM certainly is making a name for itself in specialist 
 benchmarks.  I'm
 not sure how well it fares in general usage cases...


Google guy say it is typically 5% to 10% slower on their code 
than GCC. Which is pretty good, but probably not good enough 
considering google scale.
Oct 29 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 29/10/13 08:36, Iain Buclaw wrote:

 Inline assembler for dynamic array vector operations does improve speed by 20%
 over the generic loop that GDC uses (for small arrays at least).

 LLVM certainly is making a name for itself in specialist benchmarks.  I'm not
 sure how well it fares in general usage cases...


I've not really been following specialist benchmarks (actually, from what I
have 
seen, I thought the state of play was still, "Hey, LLVM has been improving 
really fast and is just about caught up with GCC now, but GCC is still slightly 
in front and stays that way with each new release").

But my own Dgraph's test benchmarks run consistently faster with LDC than with 
GDC: https://github.com/WebDrake/Dgraph
Oct 29 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On Oct 29, 2013 7:36 AM, "Iain Buclaw" <ibuclaw ubuntu.com> wrote:

 On Oct 29, 2013 7:16 AM, "Joseph Rushton Wakeling" <


joseph.wakeling webdrake.net> wrote:

 On 28/10/13 20:02, Iain Buclaw wrote:

 I don't see it that way.  Up until now at least I haven't seen
 anything they do that wasn't already do-able in GCC.



 I confess I may be biased here because recently I've been finding that




D code compiled with LDC seems to typically run faster than stuff compiled
with GDC -- particularly code which makes any kind of serious use of stuff
from std.algorithm or any other strongly generic parts of the language.

 I can't imagine there are any fundamental frontend glue-code




differences that are responsible for that, so I was assuming LLVM had a few
areas where its optimizations worked better than the GCC middle/backend for
various language constructs.

 I did test just now making sure that I used GDC with -march=native just




in case that was the issue, but there's still a performance gap.  The only
other guess I have -- and it's a complete guess -- could it be
inline-assembly related, that LDC gains a little here?

 Inline assembler for dynamic array vector operations does improve speed


by 20% over the generic loop that GDC uses (for small arrays at least).


Speaking of arrays, GDC up until recently allocated memory for every single
[array, literal] in D code. This would give a noticeable slowdown in such
code too.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 Oct 29 2013