Re: Removal of ICC (intel compiler) bits from mk

Am 19.08.2010 11:35, schrieb Alexander Leidinger:
> 
> Quoting Dag-Erling Smørgrav <des_at_des.no> (from Thu, 19 Aug 2010  
> 11:16:23 +0200):
> 
>> Alexander Leidinger <Alexander_at_Leidinger.net> writes:
>>> If someone would get icc 11.x up and runnig as a port (similar to what
>>> we have for outdated icc version in the ports collection), I would
>>> have a look if my contact at Intel is still working there in a
>>> position which allows him to get a commercial license for us.
>>
>> Does that really matter?  We're not going to start building releases
>> with icc, are we?
> 
> It could matter for ports, I do not know if it matters for parts in  
> src. The commercial license is also the only way that we could get icc  
> installed on machines in the FreeBSD cluster (if there's interest to  
> have another compiler *for FreeBSD development* to check the source  
> against... the warnng and error messages are better that those of gcc,  
> I do not know how they compare to clang).

Clang is a mixed experience. I've used it only for C so far, and there are some
code issues that it doesn't check at all yet; issues that GCC or ICC would
complain about. ICC11 warnings (I've only used it on Linux for the software
where I'm upstream maintainer) seem plentiful if you request remarks, too.

However, clang diagnostics are easier to understand than GCCs and usually more
helpful - which was a design goal.

Note that devel/clang ships with a static analyzer that should now finally work,
as of clang-2.7_2. It can trace call trees back and pinpoint how, for instance,
your code forgets to check NULL dereference, where there are dead
initializations or assignments, or similar.  I found it to be a bit more solid
than GCC in my use cases, but note it's advertised as work-in-progress.
Details/Usage: http://clang-analyzer.llvm.org/scan-build.html

-- 
Matthias Andree