Re: Removal of ICC (intel compiler) bits from mk
Quoting David Schultz (from Tue, 26 Apr 2011 11:46:45 -0400): On Wed, Aug 18, 2010, Rui Paulo wrote: Hi, I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. If there's anyone against this, speak now or forever be silent. :-) For what it's worth, I still occasionally use icc for simple tasks-- mainly as a reference for code generation, since it produces reasonable output in many cases where gcc does not. As I recall, making it work required minimal changes... possibly just making sure __va_list gets defined in _types.h. I have the following in one of my trees, although this is obviously not the right fix. It depends if you want to hide the problem on all other compilers or not. I would prefer to not hide the problem. Bye, Alexander. -- Volley Theory: It is better to have lobbed and lost than never to have lobbed at all. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
On Wed, Aug 18, 2010, Rui Paulo wrote: > Hi, > I've been chatting with the ICC ex-users and they seem to be ok with the > removal of the ICC bits from share/mk and other places. > The reason is that it doesn't work and no one has volunteered to fix it for > many years. This seems to indicate that the interest in ICC is low. > If there's anyone against this, speak now or forever be silent. :-) For what it's worth, I still occasionally use icc for simple tasks-- mainly as a reference for code generation, since it produces reasonable output in many cases where gcc does not. As I recall, making it work required minimal changes... possibly just making sure __va_list gets defined in _types.h. I have the following in one of my trees, although this is obviously not the right fix. Index: _types.h === --- _types.h(revision 219357) +++ _types.h(working copy) @@ -105,7 +105,7 @@ */ #ifdef __GNUCLIKE_BUILTIN_VARARGS typedef__builtin_va_list __va_list; /* internally known to gcc */ -#elif defined(lint) +#else typedefchar * __va_list; /* pretend */ #endif #if defined(__GNUC_VA_LIST_COMPATIBILITY) && !defined(__GNUC_VA_LIST) \ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
Quoting Dimitry Andric (from Tue, 19 Apr 2011 19:51:48 +0200): On 2011-04-19 13:21, Alexander Leidinger wrote: ... You probably also want to remove the code that uses __INTEL_COMPILER in source tree if you want to be really thorough. Ok, new patch attached. Some of the contributed sources also contain instances of __INTEL_COMPILER, but these are all from upstream, so I left them in. Is it really necessary to remove them from cdefs.h? If someone takes parts of our source and wants to compile them on linux or windows with icc, the icc parts in cdefs.h are a valuable part to have. Isn't that the case for the other headers too? Except the in_cksum.[ch] files, where the 'fix' for ICC is apparently not needed at all anymore. The stdbool header is somewhat tied to our system I would say. The math one is AFAIK about building the math lib itself. Just from reading the diff I would assume this could manifest itself by compile errors (duplicate definition). I do not know how valuable it is to build this somewhere else. IMO they can stay in or they can be removed. Both should be easy to debug/redo in case of problems. The cdefs header is differntly in this regard, only for some parts you will get easy to debug error cases, other cases are silent (you don't know where it happens) corruption or bad performance. Bye, Alexander. -- Coming together is a beginning; keeping together is progress; working together is success. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
On 2011-04-19 13:21, Alexander Leidinger wrote: ... You probably also want to remove the code that uses __INTEL_COMPILER in source tree if you want to be really thorough. Ok, new patch attached. Some of the contributed sources also contain instances of __INTEL_COMPILER, but these are all from upstream, so I left them in. Is it really necessary to remove them from cdefs.h? If someone takes parts of our source and wants to compile them on linux or windows with icc, the icc parts in cdefs.h are a valuable part to have. Isn't that the case for the other headers too? Except the in_cksum.[ch] files, where the 'fix' for ICC is apparently not needed at all anymore. Info: AFAIR I didn't add icc stuff to csup, and AFAIR csup was added when our icc in the ports collection was outdated, so I assume someone tested csup with icc on linux and addid this stuff there. Removing it from csup seems to be a step backwards to me in this case. It used to be in contrib, but was moved to the base system recently. If csup is also ported to e.g. Linux, then it won't make much sense to remove the ICC ifdefs. Regarding the build infrastructure part I just skimmed over it, and the math/std* headers and 1s-complement-checksum part looks ok to me. For now, I will just commit the Makefile/*.mk part, and leave most headers as they are. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
Quoting Dimitry Andric (from Mon, 18 Apr 2011 21:47:00 +0200): On 2011-04-18 16:34, Alexander Kabaev wrote: ... Please review the attached patch, which cleans up the ICC bits. You probably also want to remove the code that uses __INTEL_COMPILER in source tree if you want to be really thorough. Ok, new patch attached. Some of the contributed sources also contain instances of __INTEL_COMPILER, but these are all from upstream, so I left them in. Is it really necessary to remove them from cdefs.h? If someone takes parts of our source and wants to compile them on linux or windows with icc, the icc parts in cdefs.h are a valuable part to have. Info: AFAIR I didn't add icc stuff to csup, and AFAIR csup was added when our icc in the ports collection was outdated, so I assume someone tested csup with icc on linux and addid this stuff there. Removing it from csup seems to be a step backwards to me in this case. Regarding the build infrastructure part I just skimmed over it, and the math/std* headers and 1s-complement-checksum part looks ok to me. Bye, Alexander. -- Intel CPUs are not defective, they just act that way. -- Henry Spencer http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
On 2011-04-18 16:34, Alexander Kabaev wrote:
...
Please review the attached patch, which cleans up the ICC bits.
You probably also want to remove the code that uses __INTEL_COMPILER
in source tree if you want to be really thorough.
Ok, new patch attached. Some of the contributed sources also contain
instances of __INTEL_COMPILER, but these are all from upstream, so I
left them in.
diff --git a/include/stdbool.h b/include/stdbool.h
index c0d6459..c0ce8bb 100644
--- a/include/stdbool.h
+++ b/include/stdbool.h
@@ -37,7 +37,7 @@
#definetrue1
#definebool_Bool
-#if __STDC_VERSION__ < 199901L && __GNUC__ < 3 && !defined(__INTEL_COMPILER)
+#if __STDC_VERSION__ < 199901L && __GNUC__ < 3
typedefint _Bool;
#endif
diff --git a/include/stdlib.h b/include/stdlib.h
index 3c48f17..c212cde 100644
--- a/include/stdlib.h
+++ b/include/stdlib.h
@@ -228,7 +228,7 @@ extern void (*_malloc_message)(const char *, const char *,
const char *,
* programs which use it will fail to link when compiled with non-GNU
* compilers.
*/
-#if __GNUC__ >= 2 || defined(__INTEL_COMPILER)
+#if __GNUC__ >= 2
#undef alloca /* some GNU bits try to get cute and define this on their own */
#define alloca(sz) __builtin_alloca(sz)
#elif defined(lint)
diff --git a/lib/msun/src/math.h b/lib/msun/src/math.h
index 8ad13ed..8c229e5 100644
--- a/lib/msun/src/math.h
+++ b/lib/msun/src/math.h
@@ -34,11 +34,11 @@ extern const union __nan_un {
float __uf;
} __nan;
-#if __GNUC_PREREQ__(3, 3) || (defined(__INTEL_COMPILER) && __INTEL_COMPILER >=
800)
+#if __GNUC_PREREQ__(3, 3)
#define__MATH_BUILTIN_CONSTANTS
#endif
-#if __GNUC_PREREQ__(3, 0) && !defined(__INTEL_COMPILER)
+#if __GNUC_PREREQ__(3, 0)
#define__MATH_BUILTIN_RELOPS
#endif
diff --git a/share/mk/bsd.cpu.mk b/share/mk/bsd.cpu.mk
index 99c28aa..0670bff 100644
--- a/share/mk/bsd.cpu.mk
+++ b/share/mk/bsd.cpu.mk
@@ -91,31 +91,6 @@ _CPUCFLAGS = -march=prescott
. else
_CPUCFLAGS = -march=${CPUTYPE}
. endif # GCC on 'i386'
-. if ${CPUTYPE} == "crusoe"
-_ICC_CPUCFLAGS = -tpp6 -xiM
-. elif ${CPUTYPE} == "athlon-mp" || ${CPUTYPE} == "athlon-xp" || \
-${CPUTYPE} == "athlon-4"
-_ICC_CPUCFLAGS = -tpp6 -xiMK
-. elif ${CPUTYPE} == "athlon-tbird" || ${CPUTYPE} == "athlon"
-_ICC_CPUCFLAGS = -tpp6 -xiM
-. elif ${CPUTYPE} == "k6-3" || ${CPUTYPE} == "k6-2" || ${CPUTYPE} == "k6"
-_ICC_CPUCFLAGS = -tpp6 -xi
-. elif ${CPUTYPE} == "k5"
-_ICC_CPUCFLAGS = -tpp5
-. elif ${CPUTYPE} == "pentium4" || ${CPUTYPE} == "pentium4m"
-_ICC_CPUCFLAGS = -tpp7 -xiMKW
-. elif ${CPUTYPE} == "pentium3" || ${CPUTYPE} == "pentium3m" || \
- ${CPUTYPE} == "pentium-m"
-_ICC_CPUCFLAGS = -tpp6 -xiMK
-. elif ${CPUTYPE} == "pentium2" || ${CPUTYPE} == "pentiumpro"
-_ICC_CPUCFLAGS = -tpp6 -xiM
-. elif ${CPUTYPE} == "pentium-mmx"
-_ICC_CPUCFLAGS = -tpp5 -xM
-. elif ${CPUTYPE} == "pentium"
-_ICC_CPUCFLAGS = -tpp5
-. else
-_ICC_CPUCFLAGS =
-. endif # ICC on 'i386'
. elif ${MACHINE_CPUARCH} == "amd64"
_CPUCFLAGS = -march=${CPUTYPE}
. elif ${MACHINE_CPUARCH} == "arm"
@@ -242,9 +217,5 @@ CFLAGS += -G0
# NB: COPTFLAGS is handled in /usr/src/sys/conf/kern.pre.mk
.if !defined(NO_CPU_CFLAGS)
-. if ${CC} == "icc"
-CFLAGS += ${_ICC_CPUCFLAGS}
-. else
CFLAGS += ${_CPUCFLAGS}
-. endif
.endif
diff --git a/share/mk/bsd.dep.mk b/share/mk/bsd.dep.mk
index 459a9c3..c452528 100644
--- a/share/mk/bsd.dep.mk
+++ b/share/mk/bsd.dep.mk
@@ -125,13 +125,8 @@ depend: beforedepend ${DEPENDFILE} afterdepend
# Different types of sources are compiled with slightly different flags.
# Split up the sources, and filter out headers and non-applicable flags.
-.if ${CC:T:Micc} == "icc"
-MKDEP_CFLAGS= ${CFLAGS:M-X*} ${CFLAGS:M-[BIDU]*}
-MKDEP_CXXFLAGS=${CXXFLAGS:M-X*} ${CXXFLAGS:M-[BIDU]*}
-.else
MKDEP_CFLAGS= ${CFLAGS:M-nostdinc*} ${CFLAGS:M-[BIDU]*}
MKDEP_CXXFLAGS=${CXXFLAGS:M-nostdinc*} ${CXXFLAGS:M-[BIDU]*}
-.endif
DPSRCS+= ${SRCS}
${DEPENDFILE}: ${DPSRCS}
diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk
index 9d655b6..943010c 100644
--- a/share/mk/bsd.lib.mk
+++ b/share/mk/bsd.lib.mk
@@ -65,11 +65,7 @@ PICFLAG=-fpic
.endif
.endif
-.if ${CC:T:Micc} == "icc"
-PO_FLAG=-p
-.else
PO_FLAG=-pg
-.endif
.c.po:
${CC} ${PO_FLAG} ${PO_CFLAGS} -c ${.IMPSRC} -o ${.TARGET}
diff --git a/share/mk/bsd.sys.mk b/share/mk/bsd.sys.mk
index fc5ec40..796d169 100644
--- a/share/mk/bsd.sys.mk
+++ b/share/mk/bsd.sys.mk
@@ -11,20 +11,18 @@
# the default is gnu99 for now
CSTD ?= gnu99
-.if ${CC:T:Micc} != "icc"
-. if ${CSTD} == "k&r"
+.if ${CSTD} == "k&r"
CFLAGS += -traditional
-. elif ${CSTD} == "c89" || ${CSTD} == "c90"
+.elif ${CSTD} == "c89" || ${CSTD} == "c90"
CFLAGS += -std=iso9899:1990
-. elif ${CSTD} == "c94" || ${CSTD} == "c95"
+.elif ${CSTD} == "c94" || ${CSTD} == "c95"
CFLAGS += -std=iso9899:199409
-. elif ${CSTD} == "c99"
+.elif ${CSTD} == "c99"
CFLAGS += -std=iso9899:1999
-.
Re: Removal of ICC (intel compiler) bits from mk
On Mon, 18 Apr 2011 15:42:49 +0200 Dimitry Andric wrote: > Reviving an old thread(*), I would like to propose to finally remove > the Intel C Compiler support from share/mk and other places. As > mentioned in that thread, the ICC bits simply do not work anymore, > and no one has volunteered to fix it for many years. > > Please review the attached patch, which cleans up the ICC bits. > > > *) > http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019179.html You probably also want to remove the code that uses __INTEL_COMPILER in source tree if you want to be really thorough. -- Alexander Kabaev signature.asc Description: PGP signature
Removal of ICC (intel compiler) bits from mk
Reviving an old thread(*), I would like to propose to finally remove the
Intel C Compiler support from share/mk and other places. As mentioned
in that thread, the ICC bits simply do not work anymore, and no one has
volunteered to fix it for many years.
Please review the attached patch, which cleans up the ICC bits.
*) http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019179.html
diff --git a/share/mk/bsd.cpu.mk b/share/mk/bsd.cpu.mk
index 99c28aa..0670bff 100644
--- a/share/mk/bsd.cpu.mk
+++ b/share/mk/bsd.cpu.mk
@@ -91,31 +91,6 @@ _CPUCFLAGS = -march=prescott
. else
_CPUCFLAGS = -march=${CPUTYPE}
. endif # GCC on 'i386'
-. if ${CPUTYPE} == "crusoe"
-_ICC_CPUCFLAGS = -tpp6 -xiM
-. elif ${CPUTYPE} == "athlon-mp" || ${CPUTYPE} == "athlon-xp" || \
-${CPUTYPE} == "athlon-4"
-_ICC_CPUCFLAGS = -tpp6 -xiMK
-. elif ${CPUTYPE} == "athlon-tbird" || ${CPUTYPE} == "athlon"
-_ICC_CPUCFLAGS = -tpp6 -xiM
-. elif ${CPUTYPE} == "k6-3" || ${CPUTYPE} == "k6-2" || ${CPUTYPE} == "k6"
-_ICC_CPUCFLAGS = -tpp6 -xi
-. elif ${CPUTYPE} == "k5"
-_ICC_CPUCFLAGS = -tpp5
-. elif ${CPUTYPE} == "pentium4" || ${CPUTYPE} == "pentium4m"
-_ICC_CPUCFLAGS = -tpp7 -xiMKW
-. elif ${CPUTYPE} == "pentium3" || ${CPUTYPE} == "pentium3m" || \
- ${CPUTYPE} == "pentium-m"
-_ICC_CPUCFLAGS = -tpp6 -xiMK
-. elif ${CPUTYPE} == "pentium2" || ${CPUTYPE} == "pentiumpro"
-_ICC_CPUCFLAGS = -tpp6 -xiM
-. elif ${CPUTYPE} == "pentium-mmx"
-_ICC_CPUCFLAGS = -tpp5 -xM
-. elif ${CPUTYPE} == "pentium"
-_ICC_CPUCFLAGS = -tpp5
-. else
-_ICC_CPUCFLAGS =
-. endif # ICC on 'i386'
. elif ${MACHINE_CPUARCH} == "amd64"
_CPUCFLAGS = -march=${CPUTYPE}
. elif ${MACHINE_CPUARCH} == "arm"
@@ -242,9 +217,5 @@ CFLAGS += -G0
# NB: COPTFLAGS is handled in /usr/src/sys/conf/kern.pre.mk
.if !defined(NO_CPU_CFLAGS)
-. if ${CC} == "icc"
-CFLAGS += ${_ICC_CPUCFLAGS}
-. else
CFLAGS += ${_CPUCFLAGS}
-. endif
.endif
diff --git a/share/mk/bsd.dep.mk b/share/mk/bsd.dep.mk
index 459a9c3..c452528 100644
--- a/share/mk/bsd.dep.mk
+++ b/share/mk/bsd.dep.mk
@@ -125,13 +125,8 @@ depend: beforedepend ${DEPENDFILE} afterdepend
# Different types of sources are compiled with slightly different flags.
# Split up the sources, and filter out headers and non-applicable flags.
-.if ${CC:T:Micc} == "icc"
-MKDEP_CFLAGS= ${CFLAGS:M-X*} ${CFLAGS:M-[BIDU]*}
-MKDEP_CXXFLAGS=${CXXFLAGS:M-X*} ${CXXFLAGS:M-[BIDU]*}
-.else
MKDEP_CFLAGS= ${CFLAGS:M-nostdinc*} ${CFLAGS:M-[BIDU]*}
MKDEP_CXXFLAGS=${CXXFLAGS:M-nostdinc*} ${CXXFLAGS:M-[BIDU]*}
-.endif
DPSRCS+= ${SRCS}
${DEPENDFILE}: ${DPSRCS}
diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk
index 9d655b6..943010c 100644
--- a/share/mk/bsd.lib.mk
+++ b/share/mk/bsd.lib.mk
@@ -65,11 +65,7 @@ PICFLAG=-fpic
.endif
.endif
-.if ${CC:T:Micc} == "icc"
-PO_FLAG=-p
-.else
PO_FLAG=-pg
-.endif
.c.po:
${CC} ${PO_FLAG} ${PO_CFLAGS} -c ${.IMPSRC} -o ${.TARGET}
diff --git a/share/mk/bsd.sys.mk b/share/mk/bsd.sys.mk
index fc5ec40..796d169 100644
--- a/share/mk/bsd.sys.mk
+++ b/share/mk/bsd.sys.mk
@@ -11,20 +11,18 @@
# the default is gnu99 for now
CSTD ?= gnu99
-.if ${CC:T:Micc} != "icc"
-. if ${CSTD} == "k&r"
+.if ${CSTD} == "k&r"
CFLAGS += -traditional
-. elif ${CSTD} == "c89" || ${CSTD} == "c90"
+.elif ${CSTD} == "c89" || ${CSTD} == "c90"
CFLAGS += -std=iso9899:1990
-. elif ${CSTD} == "c94" || ${CSTD} == "c95"
+.elif ${CSTD} == "c94" || ${CSTD} == "c95"
CFLAGS += -std=iso9899:199409
-. elif ${CSTD} == "c99"
+.elif ${CSTD} == "c99"
CFLAGS += -std=iso9899:1999
-. else
+.else
CFLAGS += -std=${CSTD}
-. endif
.endif
-.if !defined(NO_WARNS) && ${CC:T:Micc} != "icc"
+.if !defined(NO_WARNS)
# -pedantic is problematic because it also imposes namespace restrictions
#CFLAGS+= -pedantic
. if defined(WARNS)
@@ -82,9 +80,8 @@ CWARNFLAGS+= -Wno-format
CWARNFLAGS += -Wno-unknown-pragmas
.endif
-.if ${MK_SSP} != "no" && ${CC:T:Micc} != "icc" && \
- ${MACHINE_CPUARCH} != "ia64" && \
- ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips"
+.if ${MK_SSP} != "no" && ${MACHINE_CPUARCH} != "ia64" && \
+${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips"
# Don't use -Wstack-protector as it breaks world with -Werror.
SSP_CFLAGS ?= -fstack-protector
CFLAGS += ${SSP_CFLAGS}
diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
index 01b1438..1e58378 100644
--- a/sys/conf/kern.mk
+++ b/sys/conf/kern.mk
@@ -6,14 +6,9 @@
# Note that the newly added -Wcast-qual is responsible for generating
# most of the remaining warnings. Warnings introduced with -Wall will
# also pop up, but are easier to fix.
-.if ${CC:T:Micc} == "icc"
-#CWARNFLAGS= -w2 # use this if you are terribly bored
-CWARNFLAGS=
-.else
CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
Re: Removal of ICC (intel compiler) bits from mk
Anton Shterenlikht writes: >> 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 one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, Not "FreeBSD clusters", but "*the* FreeBSD cluster", i.e. the .f.o machines hosted by Y!. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
HPC/CUDA on FreeBSD (was: Re: Removal of ICC (intel compiler) bits from mk)
Hi, I'm taking out arch and some people from the CC and only keep curr...@. This is getting off topic for the initial thread. Quoting Anton Shterenlikht (from Thu, 19 Aug 2010 21:10:24 +0100): On Thu, Aug 19, 2010 at 11:35:48AM +0200, Alexander Leidinger wrote: Quoting Dag-Erling SmÃ??rgrav (from Thu, 19 Aug 2010 11:16:23 +0200): > Alexander Leidinger 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). If one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, then this becomes a somewhat different discussion. One of the stubmling blocks for HPC on FreeBSD (just one of many, perhaps not even the major one) is a complete lack of good quality commercial compilers. All weÃ'got is gcc or clang. Both are not really that great, and definitely inferior to commercial compilers, e.g. Intel. What IÃ'm saying is that it would be great if Intel sold a compiler for FreeBSD. I'd ve bought a copy. But from what others have said, my impression is that the ICC port is unlikely to fill this void. After I (and other people which provided patches) ported icc to FreeBSD someone from IIRC Asia took the port as an example and ported Intels Fortran compiler to FreeBSD in the same way (he was able to use a lot of the icc port, only some minor modifications where necessary). I had the impression that this was used for HPC. P.S. My interests and expertise are in computational mechanics, not in compilers, so feel free to correct me if IÃ'm wrong. In general: The resulting code (for icc and ifc) was working. The application binary code itself was/is the same (modulo differences in system headers), the "only" things which need to be changed are the startup code and the libs. We managed to do that. P.P.S. Regarding FreeBSD HPC see also this thead: http://lists.freebsd.org/pipermail/freebsd-questions/2010-August/220264.html (FreeBSD, GPGPU and OpenCL/CUDA) That's not the way we would like it to be, but at least it is possible: http://blogs.freebsdish.org/jhb/2010/07/20/using-cuda-with-the-native-freebsdamd64-nvidia-driver/ When I was working on icc, I had an idea about a liblinux2freebsd which would provide common linux-symbols and map them to FreeBSD-equivalents (together with some predefined objdump/objcopy/... scripts to modify linux libs) so that you can take a linux lib and use it to create native FreeBSD programs. Sort of like the NDIS layer in the kernel to run Windows binary drivers. Unfortunately I never got the time to work on this. Something like this could have maybe been used to "mangle" the linux cuda libs to be used on FreeBSD natively. Bye, Alexander. -- Neither spread the germs of gossip nor encourage others to do so. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
On Thu, Aug 19, 2010 at 11:35:48AM +0200, Alexander Leidinger wrote: > > Quoting Dag-Erling SmÃ??rgrav (from Thu, 19 Aug 2010 > 11:16:23 +0200): > > > Alexander Leidinger 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). If one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, then this becomes a somewhat different discussion. One of the stubmling blocks for HPC on FreeBSD (just one of many, perhaps not even the major one) is a complete lack of good quality commercial compilers. All weÃ'got is gcc or clang. Both are not really that great, and definitely inferior to commercial compilers, e.g. Intel. What IÃ'm saying is that it would be great if Intel sold a compiler for FreeBSD. I'd ve bought a copy. But from what others have said, my impression is that the ICC port is unlikely to fill this void. P.S. My interests and expertise are in computational mechanics, not in compilers, so feel free to correct me if IÃ'm wrong. P.P.S. Regarding FreeBSD HPC see also this thead: http://lists.freebsd.org/pipermail/freebsd-questions/2010-August/220264.html (FreeBSD, GPGPU and OpenCL/CUDA) -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
I think sometimes we act as if code that is removed from the tree is gone forever, with no possibility of it ever returning. I don't understand this attitude. :) If something is unsupported it should be removed, Q.E.D. There is no reason to think of possible reasons that we might want it to stay. Meanwhile, FYI, ports/lang/icc7 has been marked DEPRECATED since 8/8 with removal scheduled for 2010-09-01 based on the distinfo not containing a SHA256 line and (AFAICS) no distfiles available. If and only if someone wants to actively develop a newer version the old port will remain in the repo and can still be used as the basis of a repo copy to a newer version if that is necessary and/or desirable. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
Am 19.08.2010 11:35, schrieb Alexander Leidinger: > > Quoting Dag-Erling Smørgrav (from Thu, 19 Aug 2010 > 11:16:23 +0200): > >> Alexander Leidinger 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
Quoting "V. T. Mueller, Continum" (from Thu, 19 Aug 2010 11:15:19 +0200): Alexander Leidinger wrote: Alexander Leidinger wrote: 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. A while ago it was stated by MySQL AB, that their dbms performs about 20% better when compiled with icc instead of gcc. Is this (still) true? This looks overly simplified. "It runs better on CPU X with benchmark Y on Mainboard Z when you use gcc A.B.C with options D and compare it to icc E.F.G with options H." is something you can use in such cases, but it doesn't tell you if it will be the case on your machines with your workload. If you want to know if it is faster on your machines with your workload, then there is only one way to find it out: try it (be warned, due to the amount of optimization options available in gcc/icc, something like this will take a lot of time, as there are a lot of combinations to try). Sounds reasonable. But doesn't that mean, that there is no need to (take the hassle to) support icc in the future? Especially while folks are being keen on abandon gcc for clang? It may matter in the HPC community where optimization to a specific CPU matters (it doesn't matter that much for MySQL). There it does not matter much to have the kernel compiled with icc, but a icc port would be handy for them. Bye, Alexander. -- I hold it, that a little rebellion, now and then, is a good thing... -- Thomas Jefferson http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
Quoting Dag-Erling Smørgrav (from Thu, 19 Aug 2010 11:16:23 +0200): Alexander Leidinger 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). Bye, Alexander. -- Fry: I'm not a robot like you. I don't like having disks crammed into me... unless they're Oreos, and then only in the mouth. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
Alexander Leidinger 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? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
Alexander Leidinger wrote: Alexander Leidinger wrote: 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. A while ago it was stated by MySQL AB, that their dbms performs about 20% better when compiled with icc instead of gcc. Is this (still) true? This looks overly simplified. "It runs better on CPU X with benchmark Y on Mainboard Z when you use gcc A.B.C with options D and compare it to icc E.F.G with options H." is something you can use in such cases, but it doesn't tell you if it will be the case on your machines with your workload. If you want to know if it is faster on your machines with your workload, then there is only one way to find it out: try it (be warned, due to the amount of optimization options available in gcc/icc, something like this will take a lot of time, as there are a lot of combinations to try). Sounds reasonable. But doesn't that mean, that there is no need to (take the hassle to) support icc in the future? Especially while folks are being keen on abandon gcc for clang? Cheers vt -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
Quoting "V. T. Mueller, Continum" (from Thu, 19 Aug 2010 09:20:26 +0200): Hello, Alexander Leidinger wrote: 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. A while ago it was stated by MySQL AB, that their dbms performs about 20% better when compiled with icc instead of gcc. Is this (still) true? This looks overly simplified. "It runs better on CPU X with benchmark Y on Mainboard Z when you use gcc A.B.C with options D and compare it to icc E.F.G with options H." is something you can use in such cases, but it doesn't tell you if it will be the case on your machines with your workload. If you want to know if it is faster on your machines with your workload, then there is only one way to find it out: try it (be warned, due to the amount of optimization options available in gcc/icc, something like this will take a lot of time, as there are a lot of combinations to try). Bye, Alexander. -- Today is the first day of the rest of your life. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
Hello, Alexander Leidinger wrote: 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. A while ago it was stated by MySQL AB, that their dbms performs about 20% better when compiled with icc instead of gcc. Is this (still) true? Cheers, -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
Quoting Dimitry Andric (from Wed, 18 Aug 2010 19:56:44 +0200): Updating that port to icc 11.1 is probably not a trivial task, and making sure it compiles programs properly is even trickier... :) It is not as trivial as a normal "configure;make;make install" port, but with the existing ports already having sorted out a lot of the big problems I think it is more a question of time, interest, and lack of fear for doing it (I'm available to answer questions -- as far as I remember -- regarding the things being done in the old icc ports, in case someone has time, interest... and no fear). Bye, Alexander. -- Alimony is like buying oats for a dead horse. -- Arthur Baer http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
Quoting Gabor Kovesdan (from Wed, 18 Aug 2010 19:56:01 +0200): Em 2010.08.18. 19:37, Rui Paulo escreveu: On 18 Aug 2010, at 18:18, Garrett Cooper wrote: On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: Hi, I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. If there's anyone against this, speak now or forever be silent. :-) Later versions of icc are more gcc compliant aren't they? If so, wouldn't this also be a non-issue to remove the bits, or are there still some incompatibilities between gcc and icc that are worth noting? I really don't know how compatible is the latest icc because no one ever updated the ports version. This is actually a hint that no one really uses this anymore. IIRC, apart from the low interest, the problem was that because of ICC's license using ICC to test this mk stuff requires a commercial license because somehow it is considered a derivative work. It has If we wanted to ship binaries, we would have to compile them with the commercial license. also prevented us from providing better support. In 2006, I wanted to do some progress as part of my SoC project because that time there was more interest. Alexander (CC'd) may comment on this. I think he has a license for FreeBSD work but he is not allowed to give it out to a third party. At some point I got a license (IIRC for 2-users) which could have been installed in the cluster, but this would have meant to install a license server somewhere. The license was also the only commercial license I had which would have allowed to run the amd64... ehrm... em64t version of icc. This was for icc 9.x and I have some doubts this license will work with icc 11.x. 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. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 The happiest time in any man's life is just after the first divorce. -- J. K. Galbraith ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
On Wed, Aug 18, 2010 at 10:56 AM, Dimitry Andric wrote: > On 2010-08-18 19:37, Rui Paulo wrote: >> I really don't know how compatible is the latest icc because no one >> ever updated the ports version. This is actually a hint that no one >> really uses this anymore. > > I recently installed the port, which has icc 8.1, but it fails to > compile even simple C++ programs, because it cannot cope with the > libstdc++ headers from g++ 4.2.1. > > You have to do all kinds of tricks, such as installing the gcc 3.4.x > port, and pointing the Intel compiler to its libstdc++ headers and > libraries, or nothing will work. > > Updating that port to icc 11.1 is probably not a trivial task, and > making sure it compiles programs properly is even trickier... :) Yeah... I was referring to icc 11.x because of work that my old group was looking at doing back when I was working on Linux. Anything older than that probably has compatibility issues :). Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
On 2010-08-18 19:37, Rui Paulo wrote: > I really don't know how compatible is the latest icc because no one > ever updated the ports version. This is actually a hint that no one > really uses this anymore. I recently installed the port, which has icc 8.1, but it fails to compile even simple C++ programs, because it cannot cope with the libstdc++ headers from g++ 4.2.1. You have to do all kinds of tricks, such as installing the gcc 3.4.x port, and pointing the Intel compiler to its libstdc++ headers and libraries, or nothing will work. Updating that port to icc 11.1 is probably not a trivial task, and making sure it compiles programs properly is even trickier... :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
Em 2010.08.18. 19:37, Rui Paulo escreveu: On 18 Aug 2010, at 18:18, Garrett Cooper wrote: On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: Hi, I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. If there's anyone against this, speak now or forever be silent. :-) Later versions of icc are more gcc compliant aren't they? If so, wouldn't this also be a non-issue to remove the bits, or are there still some incompatibilities between gcc and icc that are worth noting? I really don't know how compatible is the latest icc because no one ever updated the ports version. This is actually a hint that no one really uses this anymore. IIRC, apart from the low interest, the problem was that because of ICC's license using ICC to test this mk stuff requires a commercial license because somehow it is considered a derivative work. It has also prevented us from providing better support. In 2006, I wanted to do some progress as part of my SoC project because that time there was more interest. Alexander (CC'd) may comment on this. I think he has a license for FreeBSD work but he is not allowed to give it out to a third party. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
On Wed, Aug 18, 2010 at 10:18 AM, Garrett Cooper wrote: > On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: >> Hi, >> I've been chatting with the ICC ex-users and they seem to be ok with the >> removal of the ICC bits from share/mk and other places. >> The reason is that it doesn't work and no one has volunteered to fix it for >> many years. This seems to indicate that the interest in ICC is low. >> If there's anyone against this, speak now or forever be silent. :-) > > Later versions of icc are more gcc compliant aren't they? If so, Sorry -- wrong term. s/compliant/compatible/ :). > wouldn't this also be a non-issue to remove the bits, or are there > still some incompatibilities between gcc and icc that are worth > noting? > Thanks, > -Garrett > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: > Hi, > I've been chatting with the ICC ex-users and they seem to be ok with the > removal of the ICC bits from share/mk and other places. > The reason is that it doesn't work and no one has volunteered to fix it for > many years. This seems to indicate that the interest in ICC is low. > If there's anyone against this, speak now or forever be silent. :-) Later versions of icc are more gcc compliant aren't they? If so, wouldn't this also be a non-issue to remove the bits, or are there still some incompatibilities between gcc and icc that are worth noting? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of ICC (intel compiler) bits from mk
On 18 Aug 2010, at 18:18, Garrett Cooper wrote: > On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: >> Hi, >> I've been chatting with the ICC ex-users and they seem to be ok with the >> removal of the ICC bits from share/mk and other places. >> The reason is that it doesn't work and no one has volunteered to fix it for >> many years. This seems to indicate that the interest in ICC is low. >> If there's anyone against this, speak now or forever be silent. :-) > >Later versions of icc are more gcc compliant aren't they? If so, > wouldn't this also be a non-issue to remove the bits, or are there > still some incompatibilities between gcc and icc that are worth > noting? I really don't know how compatible is the latest icc because no one ever updated the ports version. This is actually a hint that no one really uses this anymore. Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Removal of ICC (intel compiler) bits from mk
Hi, I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. If there's anyone against this, speak now or forever be silent. :-) -- Rui Paulo___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
