From owner-freebsd-arch@FreeBSD.ORG Tue Nov 6 20:59:17 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBCEB59C for ; Tue, 6 Nov 2012 20:59:17 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2DB648FC15 for ; Tue, 6 Nov 2012 20:59:16 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so975458lbd.13 for ; Tue, 06 Nov 2012 12:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=hgozJPWbO6qwUMU0hEu/c1oOzmF5emjjxhEIaZsvIeU=; b=GL+Zg+UE/reHttXbHMm+OWTaZOVYuNuOZbXPyIE1r4NmshEbMbvgtS6L82rE+5h71/ QcuJSBfxeoozQAZkvEvGzRfRlc8Y8Zrru65zOBc1tOhv5gNqCydCf5fnZ22xZ0Rp84hT vjFpFMubPokZjiGlQgNSgf/9sK/1/KK/USsn4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=hgozJPWbO6qwUMU0hEu/c1oOzmF5emjjxhEIaZsvIeU=; b=GZsePRcwTKtCf5aHubraU+m+B0bkF8FMhSI7MVUNEzmezBczvyg84MNQcnSf5joG1B eTDYfYpvYuR8rW9tEEYafZ3vT04PMlTmyciSIYzPqnufBFLeb2buSZwLN79lrxnCViu7 Zs3NZKDKjZCvXJ6lnhSrtqy3lVJKuGRxYqbwkoBJqoNFylvrtZi0TGX0p5Le3Xz5CW/I aWD99XDu1/ShpCZ3pLSH5ZGb/UIItcXCZaSkx04oRUNpYquoL9ox9gt77SjFGHDOwsU3 FhAoKc8oHBZz5wHYdPKJFtjIYUoRqS12nnjhWnGkrX1jq6RTG9A4MQiwPDdLpvonNLfD 0pOw== Received: by 10.112.100.102 with SMTP id ex6mr1053197lbb.130.1352235555673; Tue, 06 Nov 2012 12:59:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.166 with HTTP; Tue, 6 Nov 2012 12:58:45 -0800 (PST) From: Eitan Adler Date: Tue, 6 Nov 2012 15:58:45 -0500 Message-ID: Subject: removing support for ICC?? To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlsCc/IiSmcLZAkbV7aAT+IsKcVAdHGfeJsTylPCcROqLdKfiIWbs59iZHh4q6eGE92KBDB Cc: Alexander Leidinger , bde@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 20:59:18 -0000 Is there any reason to continue to keep the legacy __INTEL_COMPILER conditional includes around? Anyone have any objection against? I tested this and I found that only the following differed: -MD5 (/usr/obj/home/eitan/patchen/freebsd-head/sys/GENERIC/vers.o) = fb34ba12ae401a00dcdccf3614b6e1a5 +MD5 (/usr/obj/home/eitan/patchen/freebsd-head/sys/GENERIC/vers.o) = 4cead614a48701968fcc0e1e00b1538c -MD5 (/usr/obj/home/eitan/patchen/freebsd-head/sys/GENERIC/hpt27xx_config.o) = 3fc71ae3e198661796846eb68c3ef1b0 +MD5 (/usr/obj/home/eitan/patchen/freebsd-head/sys/GENERIC/hpt27xx_config.o) = e3b9f53df5c6d14e4be03ff750638bc5 The former due to changing git hashes. The latter due to a __TIME__ directive. commit 00c0798d3074b4ed81c703499ede577913b83ba9 Author: Eitan Adler Date: Tue Nov 6 15:00:48 2012 -0500 Remove references to __INTEL_COMPILER which has been been supported for some time. Reviewed by: scottl Approved by: cperciva MFC after: 1 month diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h index ad6aefc..a19cd46 100644 --- a/sys/sys/cdefs.h +++ b/sys/sys/cdefs.h @@ -50,9 +50,9 @@ * having a compiler-agnostic source tree. */ -#if defined(__GNUC__) || defined(__INTEL_COMPILER) +#if defined(__GNUC__) -#if __GNUC__ >= 3 || defined(__INTEL_COMPILER) +#if __GNUC__ >= 3 #define __GNUCLIKE_ASM 3 #define __GNUCLIKE_MATH_BUILTIN_CONSTANTS #else @@ -62,17 +62,11 @@ #define __GNUCLIKE___OFFSETOF 1 #define __GNUCLIKE___SECTION 1 -#ifndef __INTEL_COMPILER -# define __GNUCLIKE_CTOR_SECTION_HANDLING 1 -#endif +#define __GNUCLIKE_CTOR_SECTION_HANDLING 1 #define __GNUCLIKE_BUILTIN_CONSTANT_P 1 -# if defined(__INTEL_COMPILER) && defined(__cplusplus) \ - && __INTEL_COMPILER < 800 -# undef __GNUCLIKE_BUILTIN_CONSTANT_P -# endif -#if (__GNUC_MINOR__ > 95 || __GNUC__ >= 3) && !defined(__INTEL_COMPILER) +#if (__GNUC_MINOR__ > 95 || __GNUC__ >= 3) # define __GNUCLIKE_BUILTIN_VARARGS 1 # define __GNUCLIKE_BUILTIN_STDARG 1 # define __GNUCLIKE_BUILTIN_VAALIST 1 @@ -89,10 +83,8 @@ #define __compiler_membar() __asm __volatile(" " : : : "memory") #endif -#ifndef __INTEL_COMPILER -# define __GNUCLIKE_BUILTIN_NEXT_ARG 1 -# define __GNUCLIKE_MATH_BUILTIN_RELOPS -#endif +#define __GNUCLIKE_BUILTIN_NEXT_ARG 1 +#define __GNUCLIKE_MATH_BUILTIN_RELOPS #define __GNUCLIKE_BUILTIN_MEMCPY 1 @@ -108,12 +100,12 @@ #define __CC_SUPPORTS_DYNAMIC_ARRAY_INIT 1 -#endif /* __GNUC__ || __INTEL_COMPILER */ +#endif /* __GNUC__ */ /* * Macro to test if we're using a specific version of gcc or later. */ -#if defined(__GNUC__) && !defined(__INTEL_COMPILER) +#if defined(__GNUC__) #define __GNUC_PREREQ__(ma, mi) \ (__GNUC__ > (ma) || __GNUC__ == (ma) && __GNUC_MINOR__ >= (mi)) #else @@ -194,12 +186,12 @@ #define __aligned(x) #define __section(x) #else -#if !__GNUC_PREREQ__(2, 5) && !defined(__INTEL_COMPILER) +#if !__GNUC_PREREQ__(2, 5) #define __dead2 #define __pure2 #define __unused #endif -#if __GNUC__ == 2 && __GNUC_MINOR__ >= 5 && __GNUC_MINOR__ < 7 && !defined(__INTEL_COMPILER) +#if __GNUC__ == 2 && __GNUC_MINOR__ >= 5 && __GNUC_MINOR__ < 7 #define __dead2 __attribute__((__noreturn__)) #define __pure2 __attribute__((__const__)) #define __unused @@ -214,15 +206,6 @@ #define __aligned(x) __attribute__((__aligned__(x))) #define __section(x) __attribute__((__section__(x))) #endif -#if defined(__INTEL_COMPILER) -#define __dead2 __attribute__((__noreturn__)) -#define __pure2 __attribute__((__const__)) -#define __unused __attribute__((__unused__)) -#define __used __attribute__((__used__)) -#define __packed __attribute__((__packed__)) -#define __aligned(x) __attribute__((__aligned__(x))) -#define __section(x) __attribute__((__section__(x))) -#endif #endif #if !__GNUC_PREREQ__(2, 95) @@ -282,7 +265,7 @@ #define __pure #endif -#if __GNUC_PREREQ__(3, 1) || (defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 800) +#if __GNUC_PREREQ__(3, 1) #define __always_inline __attribute__((__always_inline__)) #else #define __always_inline @@ -312,12 +295,12 @@ #define __returns_twice #endif -/* XXX: should use `#if __STDC_VERSION__ < 199901'. */ +/* XXX: should use if __STDC_VERSION__ < 199901'. */ #if !__GNUC_PREREQ__(2, 7) && !defined(__INTEL_COMPILER) #define __func__ NULL #endif -#if (defined(__INTEL_COMPILER) || (defined(__GNUC__) && __GNUC__ >= 2)) && !defined(__STRICT_ANSI__) || __STDC_VERSION__ >= 199901 +#if (defined(__GNUC__) && __GNUC__ >= 2) && !defined(__STRICT_ANSI__) || __STDC_VERSION__ >= 199901 #define __LONG_LONG_SUPPORTED #endif @@ -432,7 +415,7 @@ * that are known to support the features properly (old versions of gcc-2 * didn't permit keeping the keywords out of the application namespace). */ -#if !__GNUC_PREREQ__(2, 7) && !defined(__INTEL_COMPILER) +#if !__GNUC_PREREQ__(2, 7) #define __printflike(fmtarg, firstvararg) #define __scanflike(fmtarg, firstvararg) #define __format_arg(fmtarg) @@ -452,18 +435,16 @@ /* Compiler-dependent macros that rely on FreeBSD-specific extensions. */ #if defined(__FreeBSD_cc_version) && __FreeBSD_cc_version >= 300001 && \ - defined(__GNUC__) && !defined(__INTEL_COMPILER) + defined(__GNUC__) #define __printf0like(fmtarg, firstvararg) \ __attribute__((__format__ (__printf0__, fmtarg, firstvararg))) #else #define __printf0like(fmtarg, firstvararg) #endif -#if defined(__GNUC__) || defined(__INTEL_COMPILER) -#ifndef __INTEL_COMPILER +#if defined(__GNUC__) #define __strong_reference(sym,aliassym) \ extern __typeof (sym) aliassym __attribute__ ((__alias__ (#sym))) -#endif #ifdef __STDC__ #define __weak_reference(sym,alias) \ __asm__(".weak " #alias); \ @@ -489,12 +470,12 @@ #define __sym_default(impl,sym,verid) \ __asm__(".symver impl, sym@@verid") #endif /* __STDC__ */ -#endif /* __GNUC__ || __INTEL_COMPILER */ +#endif /* __GNUC__*/ #define __GLOBL1(sym) __asm__(".globl " #sym) #define __GLOBL(sym) __GLOBL1(sym) -#if defined(__GNUC__) || defined(__INTEL_COMPILER) +#if defined(__GNUC__) #define __IDSTRING(name,string) __asm__(".ident\t\"" string "\"") #else /* -- Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Wed Nov 7 21:17:44 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DC5879D; Wed, 7 Nov 2012 21:17:44 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3F49A8FC0A; Wed, 7 Nov 2012 21:17:44 +0000 (UTC) Received: from outgoing.leidinger.net (p57A399A0.dip.t-dialin.net [87.163.153.160]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id E611984479F; Wed, 7 Nov 2012 22:17:31 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTPS id 5EB102415; Wed, 7 Nov 2012 22:17:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1352323049; bh=cT6dTZtUxtuzkJGz8P5sNPWRCnmJZ3XBK6bRfvsCxMU=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=3IJVgwPSXoQfDmEhyeEErH1y+QQPcyNcCOcwdYxdTGCtDuRenMlWpH26D+YBGdp5d mnzlOQk63p7+s79ZIN+8lYyWo/lVkzVhzF2+L+FFK0M8DtfKMnRiuF7j05ex0ciKQh xjo2/6ITDqTf5POUkUV+bKkIVV+c8jKgDpFYZQw3hmMBu5EQ6WggkziU+jB8TMjK4B si9LhiEZouXGImG2Mj6204lWyO5Y51a4viq3zF7qTJsygp1MQilXao8Tw/pBYwkztR uEa1q35Sj8mYn62ehpmykPqySgdWadSMnIQlrzeuGx99n339bMH82+/L1zcMqLwKqA J6T0fpebAdUTg== Date: Wed, 7 Nov 2012 22:17:30 +0100 From: Alexander Leidinger To: Eitan Adler Subject: Re: removing support for ICC?? Message-ID: <20121107221730.000017c1@unknown> In-Reply-To: References: X-Mailer: Claws Mail 3.8.0cvs30 (GTK+ 2.24.10; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: E611984479F.A049C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.455, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.56, DKIM_SIGNED 0.10, T_DKIM_INVALID 0.01, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1352927854.12768@w3zXcC3xsFLaqEYTlZc0bw X-EBL-Spam-Status: No Cc: bde@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 21:17:44 -0000 On Tue, 6 Nov 2012 15:58:45 -0500 Eitan Adler wrote: > Is there any reason to continue to keep the legacy __INTEL_COMPILER > conditional includes around? Is there a reason to remove them from cdefs.h? There aren't a lot of them, they don't obfuscate things, they are not in the way of improving things, they don't make the existing stuff harder to read. > Anyone have any objection against? The last time this came up I was OK to remove them from everywhere except for cdefs.h. If you want to remove them, please provide good reasons why to remove them (see also below). > I tested this and I found that only the following differed: > > -MD5 (/usr/obj/home/eitan/patchen/freebsd-head/sys/GENERIC/vers.o) = > fb34ba12ae401a00dcdccf3614b6e1a5 > +MD5 (/usr/obj/home/eitan/patchen/freebsd-head/sys/GENERIC/vers.o) = > 4cead614a48701968fcc0e1e00b1538c > -MD5 > (/usr/obj/home/eitan/patchen/freebsd-head/sys/GENERIC/hpt27xx_config.o) > = 3fc71ae3e198661796846eb68c3ef1b0 +MD5 > (/usr/obj/home/eitan/patchen/freebsd-head/sys/GENERIC/hpt27xx_config.o) > = e3b9f53df5c6d14e4be03ff750638bc5 cdefs.h is not only used in the kernel, but also in the userland. Anything from userland which includes cdefs.h and may also compile on other operating systems benefits from keeping this support in cdefs.h. > diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h > index ad6aefc..a19cd46 100644 > --- a/sys/sys/cdefs.h > +++ b/sys/sys/cdefs.h > @@ -312,12 +295,12 @@ > #define __returns_twice > #endif > > -/* XXX: should use `#if __STDC_VERSION__ < 199901'. */ > +/* XXX: should use if __STDC_VERSION__ < 199901'. */ > #if !__GNUC_PREREQ__(2, 7) && !defined(__INTEL_COMPILER) > #define __func__ NULL > #endif This is an unrelated change. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Thu Nov 8 00:46:13 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 910BB141 for ; Thu, 8 Nov 2012 00:46:13 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id F2CF18FC14 for ; Thu, 8 Nov 2012 00:46:12 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so2241231lbd.13 for ; Wed, 07 Nov 2012 16:46:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nL3llYO+xLKfddmePrIkViXUiBjZmGzhsaZgw6mTh+U=; b=dmijct6J0amEn90w8IpymZVwbiTEmfC2Us1PRN49Scb1V+TfofzKdXN13+L51q5pBx NFkXhawvTZnEMlMRwUAAUk+RgK1j9EX9NsYALdjSc1I5GL6lKjN0RrPSDQK6NeDAz6k7 s5yt2RJObTSwukxCkXFQ4O5uqN41mT65+5chE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=nL3llYO+xLKfddmePrIkViXUiBjZmGzhsaZgw6mTh+U=; b=Z8/Dw5Uqh02jNWGrBG/A2WxbSCFhq9fwfFiRDYUcaJmpqxjcriM97jNnfN+mBJWu2R ACKDh/XVgwa8gf9f+lRc+39wdOEORMMI5SvT3nNqnvICCYtIDgMDuyKj2YJHz2BYTFwl zuRxKQiO5GFRnfOoQNIw64GjS/vQ0W5ZlmP62SDOct5uH1yrnN0ToJcsx3a7P5q/JFgM k8rehqHSGLTxMgtNCRS4OElS6bFTScGJWvpS8yVZnYdmtLg5tFD4+ImiJbKDZMX3CMKd wQiD2+NcFYvZIWP7IInf0Cp379jwjY8to6b1TnMGJ6Jy9oP7zDPQfJuxyuR6PG644uVa QLWw== Received: by 10.112.100.102 with SMTP id ex6mr2636009lbb.130.1352335571875; Wed, 07 Nov 2012 16:46:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.166 with HTTP; Wed, 7 Nov 2012 16:45:41 -0800 (PST) In-Reply-To: <20121107221730.000017c1@unknown> References: <20121107221730.000017c1@unknown> From: Eitan Adler Date: Wed, 7 Nov 2012 19:45:41 -0500 Message-ID: Subject: Re: removing support for ICC?? To: Alexander Leidinger Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnQB7D73kLCGyOfCa6qbJ8nc+EuwlkW4RtBPDS0+STaD6CFmR3JhZuIQ3HwPD4RoETHgJ1W Cc: bde@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 00:46:13 -0000 On 7 November 2012 16:17, Alexander Leidinger wrote: > On Tue, 6 Nov 2012 15:58:45 -0500 Eitan Adler > wrote: > >> Is there any reason to continue to keep the legacy __INTEL_COMPILER >> conditional includes around? > > Is there a reason to remove them from cdefs.h? There aren't a lot of > them, they don't obfuscate things, they are not in the way of improving > things, they don't make the existing stuff harder to read. ... > cdefs.h is not only used in the kernel, but also in the userland. > Anything from userland which includes cdefs.h and may also compile on > other operating systems benefits from keeping this support in cdefs.h. I just noticed this ancient stuff in src and decided to clean it up. Since it is clearly needed, I'll drop it. -- Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Thu Nov 8 04:05:44 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC02C610; Thu, 8 Nov 2012 04:05:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE498FC15; Thu, 8 Nov 2012 04:05:43 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qA845TMS002866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 15:05:31 +1100 Date: Thu, 8 Nov 2012 15:05:29 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Eitan Adler Subject: Re: removing support for ICC?? In-Reply-To: Message-ID: <20121108145742.J1412@besplex.bde.org> References: <20121107221730.000017c1@unknown> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=I9g936cg c=1 sm=1 a=NhxvjbjkGPYA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=dPA7BKU8QQMA:10 a=jAMlq-imAAAA:8 a=uyavkMrdAAAA:8 a=T_iF5v_dfC5keXuwsoAA:9 a=CjuIK1q_8ugA:10 a=xraHq2XsALYA:10 a=JGX6LFFZUg8A:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: Alexander Leidinger , bde@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 04:05:44 -0000 On Wed, 7 Nov 2012, Eitan Adler wrote: > On 7 November 2012 16:17, Alexander Leidinger wrote: >> On Tue, 6 Nov 2012 15:58:45 -0500 Eitan Adler >> wrote: >> >>> Is there any reason to continue to keep the legacy __INTEL_COMPILER >>> conditional includes around? >> >> Is there a reason to remove them from cdefs.h? There aren't a lot of >> them, they don't obfuscate things, they are not in the way of improving >> things, they don't make the existing stuff harder to read. > > ... > >> cdefs.h is not only used in the kernel, but also in the userland. >> Anything from userland which includes cdefs.h and may also compile on >> other operating systems benefits from keeping this support in cdefs.h. > > I just noticed this ancient stuff in src and decided to clean it up. > > Since it is clearly needed, I'll drop it. Not ancient and not clearly needed, but has a mother. It is certainly unclean (has mounds of style bugs). There is lots of ancient stuff (to support pre-C90 compilers) in cdefs.h. This is really ancient, but more likely needed, since it is for not just 1 compiler. This is mostly cleaner (actually in KNF). Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Nov 8 14:04:45 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A66FD738; Thu, 8 Nov 2012 14:04:45 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C372D8FC14; Thu, 8 Nov 2012 14:04:44 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA17372; Thu, 08 Nov 2012 16:04:37 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <509BBBF4.9080305@FreeBSD.org> Date: Thu, 08 Nov 2012 16:04:36 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Alexander Leidinger Subject: Re: removing support for ICC?? References: <20121107221730.000017c1@unknown> In-Reply-To: <20121107221730.000017c1@unknown> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Eitan Adler , bde@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:04:45 -0000 on 07/11/2012 23:17 Alexander Leidinger said the following: > cdefs.h is not only used in the kernel, but also in the userland. > Anything from userland which includes cdefs.h and may also compile on > other operating systems benefits from keeping this support in cdefs.h. Do you _honestly_ believe in this? That somebody might compile something using our cdefs.h on other OS and might use the Intel compiler for that and the compilation might even work with the version of icc that they use? P.S. I am not questioning your statement, just really curios, because I have never heard about such things before. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Thu Nov 8 14:09:41 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6ECEC10; Thu, 8 Nov 2012 14:09:41 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8D1358FC16; Thu, 8 Nov 2012 14:09:41 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz17so439934pbc.13 for ; Thu, 08 Nov 2012 06:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nnFfmManiIxgrMo+y4u/j6pw1sSKHyJgTZmDWgHu+5g=; b=VhtiX+rr47LeMlBs4VfLfacVnjWVPb8qn8k65mkgrc/EAEz2qXb+mCjyEcaZHrhiFS C3E9AAuIkEC4ywilAXSzD9EJgvqsYEWJ07IUHKvimMBeXwwMNjNsQrE/qQ1O0hkuqbaL It0RUCkMzhK34doqEuT7J+4Zpg7JypNtM2nzU5MKrFcz4VJMIB2MjP/R6+Hh9hHb/dVO gexx2uQcbcn303hSgAFWBe33EH8fTcc+TV+naeMBdsMTSuyWyqmTKTyT8IuLul9Kn8bX 2WMOJyDSJ4AF3hMsRL6lVyP3/einpTVnP/CFbP+2vfvSr8Mpg0MIUEjpByglJ3yzeB6J sUyA== Received: by 10.68.216.73 with SMTP id oo9mr17646860pbc.80.1352383781138; Thu, 08 Nov 2012 06:09:41 -0800 (PST) Received: from [192.168.1.33] (adsl-99-61-74-22.dsl.pltn13.sbcglobal.net. [99.61.74.22]) by mx.google.com with ESMTPS id o10sm16181955paz.37.2012.11.08.06.09.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 06:09:40 -0800 (PST) Subject: Re: removing support for ICC?? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <509BBBF4.9080305@FreeBSD.org> Date: Thu, 8 Nov 2012 06:08:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <961DD948-6CDC-4678-9AD0-B4AD95548252@gmail.com> References: <20121107221730.000017c1@unknown> <509BBBF4.9080305@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1283) Cc: Alexander Leidinger , freebsd-arch@FreeBSD.org, bde@FreeBSD.org, Eitan Adler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:09:41 -0000 On Nov 8, 2012, at 6:04 AM, Andriy Gapon wrote: > on 07/11/2012 23:17 Alexander Leidinger said the following: >> cdefs.h is not only used in the kernel, but also in the userland. >> Anything from userland which includes cdefs.h and may also compile on >> other operating systems benefits from keeping this support in = cdefs.h. >=20 > Do you _honestly_ believe in this? > That somebody might compile something using our cdefs.h on other OS = and might use > the Intel compiler for that and the compilation might even work with = the version > of icc that they use? >=20 > P.S. I am not questioning your statement, just really curios, because = I have never > heard about such things before. = From owner-freebsd-arch@FreeBSD.ORG Fri Nov 9 07:28:40 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8CD9DA9 for ; Fri, 9 Nov 2012 07:28:40 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail3.transactionware.com [202.68.173.211]) by mx1.freebsd.org (Postfix) with SMTP id DFC3D8FC14 for ; Fri, 9 Nov 2012 07:28:39 +0000 (UTC) Received: (qmail 37251 invoked by uid 907); 9 Nov 2012 07:28:38 -0000 Received: from Unknown (HELO jmmacpro.tmst.com.au) (202.68.173.218) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Fri, 09 Nov 2012 18:28:38 +1100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: removing support for ICC?? From: Jan Mikkelsen In-Reply-To: <509BBBF4.9080305@FreeBSD.org> Date: Fri, 9 Nov 2012 18:28:37 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <8DE286D7-3187-4724-B4B8-5E06FE010F22@transactionware.com> References: <20121107221730.000017c1@unknown> <509BBBF4.9080305@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1499) Cc: Alexander Leidinger , freebsd-arch@FreeBSD.org, bde@FreeBSD.org, Eitan Adler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 07:28:40 -0000 Hi, On 09/11/2012, at 1:04 AM, Andriy Gapon wrote: > on 07/11/2012 23:17 Alexander Leidinger said the following: >> cdefs.h is not only used in the kernel, but also in the userland. >> Anything from userland which includes cdefs.h and may also compile on >> other operating systems benefits from keeping this support in = cdefs.h. >=20 > Do you _honestly_ believe in this? > That somebody might compile something using our cdefs.h on other OS = and might use > the Intel compiler for that and the compilation might even work with = the version > of icc that they use? >=20 > P.S. I am not questioning your statement, just really curios, because = I have never > heard about such things before. I occasionally use the Dignus C/C++ compiler to target IBM z/OS (aka = MVS). Its runtime library is a copy of FreeBSD's, and it includes cdefs.h. So, = yes, I compile code on a non-FreeBSD system to target a non-Unix system = with FreeBSD's cdefs.h. It does happen. Regards, Jan.