Date: Thu, 19 Aug 2010 15:27:24 +0200 From: Matthias Andree <matthias.andree@gmx.de> To: freebsd-current@freebsd.org Subject: Re: Removal of ICC (intel compiler) bits from mk Message-ID: <4C6D313C.8000501@gmx.de> In-Reply-To: <20100819113548.72614imi2zxx9log@webmail.leidinger.net> References: <E604222D-A731-4F0E-BF21-FF7F4306A899@gmail.com> <AANLkTimCdcBvgBt1sr2y1_=6fOEGWFFxa=hRwQ5vzyhT@mail.gmail.com> <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <86fwybdkt4.fsf@ds4.des.no> <20100819113548.72614imi2zxx9log@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 19.08.2010 11:35, schrieb Alexander Leidinger: > > Quoting Dag-Erling Smørgrav <des@des.no> (from Thu, 19 Aug 2010 > 11:16:23 +0200): > >> Alexander Leidinger <Alexander@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C6D313C.8000501>