clang vs gcc 4.7

[Luis Garcia Alanis]

Hi,

I was reading that clang had support for ObjectiveC 2.0 and gcc didn't. However I also read that as of gcc 4.6 it also supports ObjectiveC 2.0.

Is there a reason clang should be used? 

Etoile seems to require clang. This makes me thing clang still doing something that gcc cant.

Thanks

Luis

[Tom Davie]

Clang runs faster in -O0 mode.
Clang produces faster code in -O3/-Os mode (especially for objc).
Clang produces better error messages.
Clang will be updated in the future with all of apple's changes to objective-c.
Clang is more friendlily licensed (not that I want to start a flamewar, and I realise this argument may not be strong on this particular list).
Clang's codebase is easier to work on.
Clang supports being used as a library, and hence can have other tools (e.g. google's refactored, or the static and (in early development) dynamic analysers) built upon it.
Clang's C++ support is better than gcc's.

Is there any reason gcc should be used over clang?

Thanks

Tom Davie

[Sebastian Reitenbach]

For example, on OpenBSD macppc, I have to use gcc to build
any GNUstep App, since clang produces garbage on it.
Using gcc 4.2.1 on macppc, which doesn't have objc-2 support,
haven't tried newer gccs yet.
Thought, it may only indirectly clangs fault.

Sebastian

>
> Thanks
>
> Tom Davie
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Richard Frith-Macdonald]

On 3 Mar 2013, at 11:51, Tom Davie wrote:

>
> On 3 Mar 2013, at 11:45, Luis Garcia Alanis <lu...@garcia.tv> wrote:
>
>> Hi,
>>
>> I was reading that clang had support for ObjectiveC 2.0 and gcc didn't. However I also read that as of gcc 4.6 it also supports ObjectiveC 2.0.
>>
>> Is there a reason clang should be used?
>>
>> Etoile seems to require clang. This makes me thing clang still doing something that gcc cant.
>
> Clang runs faster in -O0 mode.
> Clang produces faster code in -O3/-Os mode (especially for objc).
> Clang produces better error messages.
> Clang will be updated in the future with all of apple's changes to objective-c.
> Clang is more friendlily licensed (not that I want to start a flamewar, and I realise this argument may not be strong on this particular list).
> Clang's codebase is easier to work on.
> Clang supports being used as a library, and hence can have other tools (e.g. google's refactored, or the static and (in early development) dynamic analysers) built upon it.
> Clang's C++ support is better than gcc's.
>
> Is there any reason gcc should be used over clang?

I think this is rather debatable and you could probably find people to disagree with most of your points.
eg. I've heard that gcc produces faster code than clang ... so opinions certainly vary there, and from my own experience, while clang produces more readable error messages, it also produces more spurious error/warning messages ... so you can lose track of real errors amid the bogus ones (eg warnings about assigning a value of a subclass to a variable typed as its superclass).

My take on the relative merits is:

The advantages of gcc are that it's the de-facto standard (you generally don't have to install it, let alone build it yourself), is much more portable/ported (reliable on many more platforms), and has most of the good things that Apple has added to objc, and less of the the bloat such as 'blocks'.

but clang has two really nice things going for it:
1. the static analyser can spot quite a few coding errors, and that's great
2. clang has ARC support, which is really cool

Since I generally want high portability, I stick with code that builds in gcc, but I do use clang for the static analyser.

[Riccardo Mottola]

Hi,

On 03/03/13 12:51, Tom Davie wrote:
> Clang runs faster in -O0 mode.
> Clang produces faster code in -O3/-Os mode (especially for objc).
> Clang produces better error messages.
> Clang will be updated in the future with all of apple's changes to objective-c.
> Clang is more friendlily licensed (not that I want to start a flamewar, and I realise this argument may not be strong on this particular list).
> Clang's codebase is easier to work on.
> Clang supports being used as a library, and hence can have other tools (e.g. google's refactored, or the static and (in early development) dynamic analysers) built upon it.
> Clang's C++ support is better than gcc's.

This argument is a bit moot for one may not need or event want C++. I
did an attempt to build a while system without C++ at all! (sadly,
latest gcc versions are free to use C++ too). For my gnustep
environment, the only little thing that needs it is xpdf for PDFKit, all
the remaining applications and dependencies are pure C and Obj-C!

The average use doesn't poke inside the compiler, the compiler is a
system provided tool. So working on its innards is not a plus.

Since Etoilé people are also the clang people, they rely on it. But most
other GNUstep applications, including all core, user apps and all GAP
applications, work perfectly with gcc 4.x and most of them even with 3.x
Gcc is reliable for the needs I have, works fine, although its obj-c
compiler is not very fast. What will happen about obj-c in gcc I don't
know, Nicola may know better, since he worked on a great deal on it.

Clang has given me tons of headaches, but it was the only thing working
on x86-64 linux gentoo for me. David Chisnall however did a lot of great
work and everything is now much improved. On my development machines, I
have some with clang and some with gcc and I see no advantages or
disadvantages of one compared to the other, in the applications I work in.

Riccardo

[Riccardo Mottola]

Hi,

On 03/03/13 13:17, Richard Frith-Macdonald wrote:
> My take on the relative merits is:
>
> The advantages of gcc are that it's the de-facto standard (you generally don't have to install it, let alone build it yourself), is much more portable/ported (reliable on many more platforms), and has most of the good things that Apple has added to objc, and less of the the bloat such as 'blocks'.

+1 ! If yo udon't use something, why do you need support for it?

>
> but clang has two really nice things going for it:
> 1. the static analyser can spot quite a few coding errors, and that's great
> 2. clang has ARC support, which is really cool
>
> Since I generally want high portability, I stick with code that builds in gcc, but I do use clang for the static analyser.
>

Yes, the static analyser is great! It has helped to find some weird
errors in GAP applications ad even GWorkspace! However, it sometimes
gives false positive which are quite bad, so it is a great tool, but not
something to rely blindly on.
I also had code working on Clang and not GCC: the code was wrong, but
GCC optimized moer I guess so the memory error was caught (the latest
Example about this was in Gorm)
The best in my opinion to write code that works on both compiler, check
warnings on both, test on both and the result is stronger code.
I hope both will remain alive, since I like choice and diversity of tools.

Riccardo

[David Chisnall]

I am quite obviously biased in favour of clang, however, in the interests of fairness:

On 3 Mar 2013, at 11:51, Tom Davie <tom....@gmail.com> wrote:

> Clang runs faster in -O0 mode.

I believe this is still true, which helps with a fast compile-test-debug cycle.

> Clang produces faster code in -O3/-Os mode (especially for objc).

Usually there isn't much in it (under 10% often under 5%), however:

- Clang has no support for OpenMP, which means gcc can often compile code with OpenMP paths to run n times faster (where n is the number of CPUs in your system) than clang. I've not seen any ObjC code that uses OpenMP, but that doesn't mean there isn't any.

- As of last week, clang's autovectoriser is outperforms GCC's at linpack, however in the 3.2 release there is no autovectoriser. For certain mathematical code, this means that gcc 4.7 is 2-4 times faster than clang 3.2.

> Clang produces better error messages.

This is true, however gcc 4.8 has had a massive overhaul of the error reporting, so the difference is not as pronounced as it was.

> Clang will be updated in the future with all of apple's changes to objective-c.

Additionally, clang supports several things that gcc doesn't:

- The non-fragile ABI
- Using the faster message send mechanism in libobjc2 >= 1.6 (roughly 10% total code size reduction, approximately 50% faster message sending)
- ARC (this, for me, is a killer feature. Objective-C without ARC just feels painful. It took about 2 hours of using it to get to that stage)
- The ugly and braindead literal syntax that some idiots at Apple thought was a good idea.

Clang also includes things like the static analyser and the ARC migration tool.

> Clang is more friendlily licensed (not that I want to start a flamewar, and I realise this argument may not be strong on this particular list).

This is only useful for people embedding clang in other things, however the layering in clang is also cleaner, so it is easier, for example, to use clang's parser in other things. In Étoilé, we have SourceCodeKit, which uses the clang parser to cross-reference and syntax highlight Objective-C code.

> Clang's codebase is easier to work on.

Not relevant to most people on this list, but definitely true. This is why I got involved with clang in the first place - it was easier to completely implement Objective-C code generation support (for two Objective-C runtimes) in clang than it was to add support for declared properties to gcc, from a point of having no experience with either codebase.

> Clang supports being used as a library, and hence can have other tools (e.g. google's refactored, or the static and (in early development) dynamic analysers) built upon it.

It is also used for header parsing by LanguageKit, which allows easy calling of C code from Smalltalk.

> Clang's C++ support is better than gcc's.

This is especially relevant for Objective-C++, for two reasons:

- Clang has significantly better support for mixing Objective-C and C++ exceptions. When compiling with -fobjc-runtime=gnustep-1.7 and the trunk version of the runtime, all of the known corner cases work, including the one that causes a segfault in Apple's runtime. Most of them cause stack corruption or crashing with gcc.

- In Objective-C++11 mode, clang's return type inference interacts nicely with the auto keyword, so you can do things like:

auto foo = [NSMutableArray new];

And the type of foo will be inferred to be NSMutableArray*.

On the other hand, this is completely irrelevant to people not using [Objective-]C++.

In terms of cross-platform support:

- Clang's exception support is broken on ARM (on my to-do list, but not a high priority. Some Linaro folks are working on it though). Aside from that, clang generally generates better ARM code than GCC (ARM, Apple, Linaro, Qualcomm and so on are investing a lot in LLVM and Clang).

- Clang's PowerPC and MIPS support is relatively immature. I am actively working on MIPS, but I wouldn't yet recommend using it in production.

- Clang has no support for m68k or a number of other less-popular architectures. The SPARC support is pretty limited and largely unmaintained. IA64 support was recently dropped.

- Clang is the default system compiler in FreeBSD, gcc is the default system compiler on most Linux systems (although Android is in the process of switching).

David


-- Sent from my STANTEC-ZEBRA

[Wolfgang Lux]

Riccardo Mottola wrote:

> Hi,
>
> On 03/03/13 13:17, Richard Frith-Macdonald wrote:
>> My take on the relative merits is:
>>
>> The advantages of gcc are that it's the de-facto standard (you generally don't have to install it, let alone build it yourself), is much more portable/ported (reliable on many more platforms), and has most of the good things that Apple has added to objc, and less of the the bloat such as 'blocks'.
> +1 ! If yo udon't use something, why do you need support for it?

Gosh, what a gross misconception! Not blocks (aka closures aka lambdas) are bloat but the workarounds that had to be introduced in their absence. A typical example are all those callbacks for the AppKit methods presenting non-modal dialogs. Blocks are the natural concept for those callbacks. Passing around a selector and void * context argument instead of them is a poor workaround (and introduces code bloat as you have to create those context parameters, extract the components later, and must not forget to properly retain and release all your arguments, and I won't mention the loss of type safety by using a void * parameter together with type casts). It is really a pity that it took Apple so long to bring this essential Smalltalk concept over to Objective-C (and the only excuse is that it requires some form of automatic memory management -- be it full garbage collection or automatic reference counting -- to be manageable).

Saying blocks are bloat sounds to me like saying automatic reference counting is bloat because you can do the same with explicit retain/release calls.

Wolfgang

[Ivan Vučica]

On 4. 3. 2013., at 21:16, Wolfgang Lux <wolfga...@gmail.com> wrote:

> Saying blocks are bloat sounds to me like saying automatic reference counting is bloat because you can do the same with explicit retain/release calls.

*cough* Hm. Nope. :-)

ARC introduces C++-style "magic" into things that work in a C-style "obvious" way. Block, similarly, do "magic" with variables in function's scope. What magic? Large parts of STL, for example. Ability to override operators. Ability to very easily introduce ambiguousness e.g by providing overloads that accept both const char* and std::string. I could list many other things that I (and others) feel makes C++ a mess, but which are quite useful.

Anyway, I see uses for both ARC and blocks. Especially blocks. I can't get over their ugliness, however, and prefer using selector-based handling for all but simplest handlers. Do I like having blocks? Definitely. And ARC can help newcomers.

That doesn't mean I don't feel about them like some other people feel about dot-syntax of properties. Useful, but not for me.


Back on-topic: Right now, for Objective-C, gcc's upside is its ubiquitousness... And that's about it. Maybe that changes in the future. For now, I'm willing to spend a LOT of time (and disk space) building Clang; if for no other reason, then because more new code will build with it.

Regards,

Ivan Vučica
via phone