All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] fixes for building kernel using Intel compiler
@ 2002-10-18 23:48 Nakajima, Jun
  2002-10-19  0:08 ` Greg KH
  2002-10-21 12:48 ` Alan Cox
  0 siblings, 2 replies; 17+ messages in thread
From: Nakajima, Jun @ 2002-10-18 23:48 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Mallick, Asit K, Saxena, Sunil

[-- Attachment #1: Type: text/plain, Size: 6625 bytes --]

Hi Linus,

Attached is the patch that resolves some of the redundant code and casting
that are required to build the Linux kernel usning Intel compiler. We would
like to get this patch incorporated to allow the kernel built with Intel
Compiler.

Thanks,
Jun Nakajima

============================================================================
=================diff -ur linux-2.5.43.orig/arch/i386/kernel/ioport.c
linux-2.5.43/arch/i386/kern
el/ioport.c
--- linux-2.5.43.orig/arch/i386/kernel/ioport.c Fri Oct 18 15:19:35 2002
+++ linux-2.5.43/arch/i386/kernel/ioport.c      Fri Oct 18 16:10:13 2002
@@ -108,9 +108,8 @@
  * code.
  */

-asmlinkage int sys_iopl(unsigned long unused)
+asmlinkage int sys_iopl(struct pt_regs * regs)
 {
-       struct pt_regs * regs = (struct pt_regs *) &unused;
        unsigned int level = regs->ebx;
        unsigned int old = (regs->eflags >> 12) & 3;

diff -ur linux-2.5.43.orig/drivers/net/wireless/airo.c
linux-2.5.43/drivers/net/
wireless/airo.c
--- linux-2.5.43.orig/drivers/net/wireless/airo.c       Fri Oct 18 15:19:35
2002
+++ linux-2.5.43/drivers/net/wireless/airo.c    Fri Oct 18 15:28:06 2002
@@ -97,12 +97,12 @@
    infront of the label, that statistic will not be included in the list
    of statistics in the /proc filesystem */

-#define IGNLABEL 0&(int)
+#define IGNLABEL (0,)
 static char *statsLabels[] = {
        "RxOverrun",
-       IGNLABEL "RxPlcpCrcErr",
-       IGNLABEL "RxPlcpFormatErr",
-       IGNLABEL "RxPlcpLengthErr",
+       IGNLABEL /* "RxPlcpCrcErr", */
+       IGNLABEL /* "RxPlcpFormatErr", */
+       IGNLABEL /* "RxPlcpLengthErr", */
        "RxMacCrcErr",
        "RxMacCrcOk",
        "RxWepErr",
@@ -146,15 +146,15 @@
        "HostRxBc",
        "HostRxUc",
        "HostRxDiscard",
-       IGNLABEL "HmacTxMc",
-       IGNLABEL "HmacTxBc",
-       IGNLABEL "HmacTxUc",
-       IGNLABEL "HmacTxFail",
-       IGNLABEL "HmacRxMc",
-       IGNLABEL "HmacRxBc",
-       IGNLABEL "HmacRxUc",
-       IGNLABEL "HmacRxDiscard",
-       IGNLABEL "HmacRxAccepted",
+       IGNLABEL /* "HmacTxMc", */
+       IGNLABEL /* "HmacTxBc", */
+       IGNLABEL /* "HmacTxUc", */
+       IGNLABEL /* "HmacTxFail", */
+       IGNLABEL /* "HmacRxMc", */
+       IGNLABEL /* "HmacRxBc", */
+       IGNLABEL /* "HmacRxUc", */
+       IGNLABEL /* "HmacRxDiscard", */
+       IGNLABEL /* "HmacRxAccepted", */
        "SsidMismatch",
        "ApMismatch",
        "RatesMismatch",
@@ -162,26 +162,26 @@
        "AuthTimeout",
        "AssocReject",
        "AssocTimeout",
-       IGNLABEL "ReasonOutsideTable",
-       IGNLABEL "ReasonStatus1",
-       IGNLABEL "ReasonStatus2",
-       IGNLABEL "ReasonStatus3",
-       IGNLABEL "ReasonStatus4",
-       IGNLABEL "ReasonStatus5",
-       IGNLABEL "ReasonStatus6",
-       IGNLABEL "ReasonStatus7",
-       IGNLABEL "ReasonStatus8",
-       IGNLABEL "ReasonStatus9",
-       IGNLABEL "ReasonStatus10",
-       IGNLABEL "ReasonStatus11",
-       IGNLABEL "ReasonStatus12",
-       IGNLABEL "ReasonStatus13",
-       IGNLABEL "ReasonStatus14",
-       IGNLABEL "ReasonStatus15",
-       IGNLABEL "ReasonStatus16",
-       IGNLABEL "ReasonStatus17",
-       IGNLABEL "ReasonStatus18",
-       IGNLABEL "ReasonStatus19",
+       IGNLABEL /* "ReasonOutsideTable", */
+       IGNLABEL /* "ReasonStatus1", */
+       IGNLABEL /* "ReasonStatus2", */
+       IGNLABEL /* "ReasonStatus3", */
+       IGNLABEL /* "ReasonStatus4", */
+       IGNLABEL /* "ReasonStatus5", */
+       IGNLABEL /* "ReasonStatus6", */
+       IGNLABEL /* "ReasonStatus7", */
+       IGNLABEL /* "ReasonStatus8", */
+       IGNLABEL /* "ReasonStatus9", */
+       IGNLABEL /* "ReasonStatus10", */
+       IGNLABEL /* "ReasonStatus11", */
+       IGNLABEL /* "ReasonStatus12", */
+       IGNLABEL /* "ReasonStatus13", */
+       IGNLABEL /* "ReasonStatus14", */
+       IGNLABEL /* "ReasonStatus15", */
+       IGNLABEL /* "ReasonStatus16", */
+       IGNLABEL /* "ReasonStatus17", */
+       IGNLABEL /* "ReasonStatus18", */
+       IGNLABEL /* "ReasonStatus19", */
        "RxMan",
        "TxMan",
        "RxRefresh",
diff -ur linux-2.5.43.orig/include/asm-i386/bugs.h
linux-2.5.43/include/asm-i386
/bugs.h
--- linux-2.5.43.orig/include/asm-i386/bugs.h   Fri Sep 27 14:49:09 2002
+++ linux-2.5.43/include/asm-i386/bugs.h        Fri Oct 18 16:11:56 2002
@@ -76,14 +76,6 @@
                return;
        }

-/* Enable FXSR and company _before_ testing for FP problems. */
-       /*
-        * Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
-        */
-       if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
-               extern void __buggy_fxsr_alignment(void);
-               __buggy_fxsr_alignment();
-       }
        if (cpu_has_fxsr) {
                printk(KERN_INFO "Enabling fast FPU save and restore... ");
                set_in_cr4(X86_CR4_OSFXSR);
diff -ur linux-2.5.43.orig/include/linux/mtd/compatmac.h
linux-2.5.43/include/li
nux/mtd/compatmac.h
--- linux-2.5.43.orig/include/linux/mtd/compatmac.h     Fri Sep 27 14:50:29
2002
+++ linux-2.5.43/include/linux/mtd/compatmac.h  Fri Oct 18 15:28:06 2002
@@ -193,6 +193,7 @@
 #define spin_lock_bh(lock) do {start_bh_atomic();spin_lock(lock);} while(0)
 #define spin_unlock_bh(lock) do {spin_unlock(lock);end_bh_atomic();}
while(0)
 #else
+#include <linux/interrupt.h>
 #include <asm/softirq.h>
 #include <linux/spinlock.h>
 #endif
diff -ur linux-2.5.43.orig/kernel/module.c linux-2.5.43/kernel/module.c
--- linux-2.5.43.orig/kernel/module.c   Fri Sep 27 14:49:13 2002
+++ linux-2.5.43/kernel/module.c        Fri Oct 18 15:28:06 2002
@@ -425,11 +425,11 @@
                printk(KERN_ERR "init_module: mod->deps out of bounds.\n");
                goto err2;
        }
-       if (mod->init && !mod_bound(mod->init, 0, mod)) {
+       if (mod->init && !mod_bound((unsigned long)mod->init, 0, mod)) {
                printk(KERN_ERR "init_module: mod->init out of bounds.\n");
                goto err2;
        }
-       if (mod->cleanup && !mod_bound(mod->cleanup, 0, mod)) {
+       if (mod->cleanup && !mod_bound((unsigned long)mod->cleanup, 0, mod))
{
                printk(KERN_ERR "init_module: mod->cleanup out of
bounds.\n");
                goto err2;
        }
@@ -449,7 +449,7 @@
                goto err2;
        }
        if (mod_member_present(mod, can_unload)
-           && mod->can_unload && !mod_bound(mod->can_unload, 0, mod)) {
+           && mod->can_unload && !mod_bound((unsigned long)mod->can_unload,
0,
mod)) {
              printk(KERN_ERR "init_module: mod->can_unload out of
bounds.\n")
;
                goto err2;
        }



[-- Attachment #2: icc-build-2.5.43.ZIP --]
[-- Type: application/octet-stream, Size: 1644 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread
[parent not found: <F2DBA543B89AD51184B600508B68D4000E6ADE5B@fmsmsx103.fm.intel.com.suse.lists.linux.kernel>]
* RE: [PATCH] fixes for building kernel using Intel compiler
@ 2002-10-19  0:45 Nakajima, Jun
  2002-10-19  1:02 ` Andi Kleen
  0 siblings, 1 reply; 17+ messages in thread
From: Nakajima, Jun @ 2002-10-19  0:45 UTC (permalink / raw)
  To: Andi Kleen, David S. Miller
  Cc: Nakajima, Jun, torvalds, linux-kernel, Mallick, Asit K,
	Saxena, Sunil

No, it removes most of such cases. It happens only for a general boolean
controlling expression, and this is the only spot as far as we tested. But
our argument is that the checking code is not required because
thread.i387.fxsave is __attribute__ ((aligned (16))). If __attribute__
((aligned (...))) is broken, we should see more problems.

Thanks,
Jun

-----Original Message-----
From: Andi Kleen [mailto:ak@suse.de]
Sent: Friday, October 18, 2002 5:25 PM
To: David S. Miller
Cc: ak@suse.de; jun.nakajima@intel.com; torvalds@transmeta.com;
linux-kernel@vger.kernel.org; asit.k.mallick@intel.com;
sunil.saxena@intel.com
Subject: Re: [PATCH] fixes for building kernel using Intel compiler


On Fri, Oct 18, 2002 at 05:15:04PM -0700, David S. Miller wrote:
>    From: Andi Kleen <ak@suse.de>
>    Date: 19 Oct 2002 02:07:41 +0200
>    
>    > -/* Enable FXSR and company _before_ testing for FP problems. */
>    > -       /*
>    > -        * Verify that the FXSAVE/FXRSTOR data will be 16-byte
aligned.
>    > -        */
>    > -       if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
>    > -               extern void __buggy_fxsr_alignment(void);
>    > -               __buggy_fxsr_alignment();
>    > -       }
>    
>    Why does that not work? IMHO it is legal ISO-C
> 
> Depending upon the compiler to optimize away the non-existent function
> reference is not ISO-C :-)  Although the fact the Intel compiler isn't
> doing this is amusing.

True :-)

Well it should. There are tons of similar patterns all over the kernel
which use the same trick.
If it didn't optimize  all of these, there would be many more problems.

-Andi

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: [PATCH] fixes for building kernel using Intel compiler
@ 2002-10-19  1:16 Nakajima, Jun
  0 siblings, 0 replies; 17+ messages in thread
From: Nakajima, Jun @ 2002-10-19  1:16 UTC (permalink / raw)
  To: Greg KH
  Cc: Linus Torvalds, Linux Kernel Mailing List, Mallick, Asit K,
	Saxena, Sunil

The one we used was 7.0, and it will be available late November or early
December. It's not 6.0 version, which requires more changes.

Looks like I need to resend another patch.

Thanks,
Jun

-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Friday, October 18, 2002 5:08 PM
To: Nakajima, Jun
Cc: Linus Torvalds; Linux Kernel Mailing List; Mallick, Asit K; Saxena,
Sunil
Subject: Re: [PATCH] fixes for building kernel using Intel compiler


On Fri, Oct 18, 2002 at 04:48:34PM -0700, Nakajima, Jun wrote:
> Hi Linus,
> 
> Attached is the patch that resolves some of the redundant code and casting
> that are required to build the Linux kernel usning Intel compiler. We
would
> like to get this patch incorporated to allow the kernel built with Intel
> Compiler.

The patch is wrapped, and can't apply.

And what version of the Intel compiler is this for?  I tried to get a
previous version to build a kernel, but I had to change a lot more
things than you did (like build flags, etc.)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: [PATCH] fixes for building kernel using Intel compiler
@ 2002-10-19  2:17 Nakajima, Jun
  2002-10-19  2:29 ` Andi Kleen
  0 siblings, 1 reply; 17+ messages in thread
From: Nakajima, Jun @ 2002-10-19  2:17 UTC (permalink / raw)
  To: Andi Kleen
  Cc: David S. Miller, torvalds, linux-kernel, Mallick, Asit K,
	Saxena, Sunil

Thanks, Andi.

No, because of (size_t) (it's typedef) from offsetof() and &.  But
	if ( (int) offsetof(struct task_struct, thread.i387.fxsave) % 16) {
would be optiminzed away. So I'll change the patch like that. 

Thanks,
Jun
-----Original Message-----
From: Andi Kleen [mailto:ak@suse.de]
Sent: Friday, October 18, 2002 6:02 PM
To: Nakajima, Jun
Cc: Andi Kleen; David S. Miller; torvalds@transmeta.com;
linux-kernel@vger.kernel.org; Mallick, Asit K; Saxena, Sunil
Subject: Re: [PATCH] fixes for building kernel using Intel compiler


On Fri, Oct 18, 2002 at 05:45:08PM -0700, Nakajima, Jun wrote:
> No, it removes most of such cases. It happens only for a general boolean
> controlling expression, and this is the only spot as far as we tested. But

	So it would be optimized away if changed to 

	if ((offsetof(struct task_struct, thread.i387.fxsave) & 15) != 0) {

	?

> our argument is that the checking code is not required because
> thread.i387.fxsave is __attribute__ ((aligned (16))). If __attribute__
> ((aligned (...))) is broken, we should see more problems.

I think it would be better to keep the check, even with attribute aligned.
These bugs
are nasty to debug when they happen.

-Andi

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: [PATCH] fixes for building kernel using Intel compiler
@ 2002-10-21 18:28 Ulrich Weigand
  0 siblings, 0 replies; 17+ messages in thread
From: Ulrich Weigand @ 2002-10-21 18:28 UTC (permalink / raw)
  To: jun.nakajima; +Cc: linux-kernel

Jun Nakajima wrote:

>Having said that, one occasion where people might be surprised by gcc (this
>might be a known issue, though) is: typedef + __attribute__; it ignores
>__attribute__. For example,
>#include <stdio.h>
>
>struct foo_16 {
>        char xxx[3];
>        short yyy;
>} __attribute__ ((aligned (16)));
>
>typedef struct bar_16 {
>        char xxx[3];
>        short yyy;
>} bar_16_t __attribute__ ((aligned (16)));

This is a user error (sort of); you're supposed to write:

typedef struct bar_16 {
        char xxx[3];
        short yyy;
} __attribute__ ((aligned (16))) bar_16_t;

[The attribute modifies the original struct type, which gets then
assigned the typedef name.  This is similar to the case where a
variable definition follows:

struct { ... } __attribute__() var;
vs.
struct { ... ] var __attribute__();

In the first case, the attribute modifies the struct type itself,
while in the second case the attribute applies only to the one
instance var.]

A warning would still be nice; we got bitten by that one a couple
of times ...

>In the kernel, there are several device drivers (ftape-bsm.h, e100.h, for
>example) are doing this kind of thing (i.e. typedef + attribute).

Well, I guess in those files the attribute((packed)) is a no-op
anyway as the structs are already packed according to the default
rules, so it doesn't really matter.  It should probably still be
fixed ...


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com


^ permalink raw reply	[flat|nested] 17+ messages in thread
[parent not found: <A9EA4AD6F6B9D511BBED00508B66C69A04B37747@fmsmsx111.fm.intel.com>]

end of thread, other threads:[~2002-10-26 10:26 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-18 23:48 [PATCH] fixes for building kernel using Intel compiler Nakajima, Jun
2002-10-19  0:08 ` Greg KH
2002-10-21 12:48 ` Alan Cox
2002-10-21 15:56   ` Nakajima, Jun
2002-10-21 17:06     ` Brian Gerst
2002-10-22  6:09     ` Greg KH
     [not found] <F2DBA543B89AD51184B600508B68D4000E6ADE5B@fmsmsx103.fm.intel.com.suse.lists.linux.kernel>
2002-10-19  0:07 ` Andi Kleen
2002-10-19  0:15   ` David S. Miller
2002-10-19  0:25     ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2002-10-19  0:45 Nakajima, Jun
2002-10-19  1:02 ` Andi Kleen
2002-10-19  1:16 Nakajima, Jun
2002-10-19  2:17 Nakajima, Jun
2002-10-19  2:29 ` Andi Kleen
2002-10-21  9:21   ` Pavel Machek
2002-10-21 18:28 Ulrich Weigand
     [not found] <A9EA4AD6F6B9D511BBED00508B66C69A04B37747@fmsmsx111.fm.intel.com>
2002-10-22 22:41 ` Suresh Siddha

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.