[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20070220135046.GE3945@ucw.cz>
Date: Tue, 20 Feb 2007 13:50:46 +0000
From: Pavel Machek <pavel@....cz>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Ralf Baechle <ralf@...ux-mips.org>,
Atsushi Nemoto <anemo@....ocn.ne.jp>,
linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations.
Hi!
> > > hm. So if I have
> > >
> > > struct bar {
> > > unsigned long b;
> > > } __attribute__((packed));
> > >
> > > struct foo {
> > > unsigned long u;
> > > struct bar b;
> > > };
> > >
> > > then the compiler can see that foo.b.b is well-aligned, regardless of the
> > > packedness.
> > >
> > > Plus some crazy people compile the kernel with icc (or at least they used
> > > to). What happens there?
> >
> > A quick grep for __attribute__((packed)) and __packed find around 900 hits,
> > I'd probably find more if I'd look for syntactical variations. Some hits
> > are in arch/{i386,x86_64,ia64}. At a glance it seems hard to configure a
> > useful x86 kernel that doesn't involve any packed attribute. I take that
> > as statistical proof that icc either has doesn't really work for building
> > the kernel or groks packing. Any compiler not implementing gcc extensions
> > is lost at building the kernel but that's old news.
> >
>
> No, icc surely supports attribute(packed). My point is that we shouldn't
> rely upon the gcc info file for this, because other compilers can (or
> could) be used to build the kernel.
Well, icc should be gcc compatible. If it is not, it is icc bug.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists