> Either way, benchmarks like these are rarely representative of real-world 
> performance in *[y]our* workloads. My own experience over the years has been 
> that GCC gives measurably better performance and that in cases where every 
> last 
> drop doesn't count you were better off using clang because it compiled so 
> much 
> faster. The differences have been disappearing but clang still doesn't win 
> across the board with a clear advance.
> That's enough for me in itself as an argument to try to make GCC integrate 
> and 
> perform as well as possible on Mac, because some users might benefit. Hence 
> my 
> interest in support for the AVX (and newer) instruction sets.

Funny how the same data can lead to very different conclusions with different 

My reading is there is, on average across the board, there is no clear 
advantage/disadvantage to either gcc or clang, such that I am not really sure 
its warranted to expend a lot of effort to keep gcc alive on OSX, when upstream 
have clearly placed themselves 100% in the clang boat. That said, you are of 
course completely free to experiment yourself but I would say we should not 
accept any patches into MacPorts for this unless they a) do not require 
significant patching of the gcc builds that upstream does not accept and b) 
provides a rock solid gcc build that works in all cases without any nasty 
nuances (such as the library linkage changes you recently posted). If you can 
do both of these, great, but I admit I am quite dubious.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

macports-dev mailing list

Reply via email to