All of lore.kernel.org
 help / color / mirror / Atom feed
From: Albert Cahalan <albert@users.sf.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Albert Cahalan <albert@users.sourceforge.net>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>,
	petero2@telia.com, Andrew Morton OSDL <akpm@osdl.org>
Subject: Re: Linux 2.6.7-rc2
Date: 31 May 2004 11:12:26 -0400	[thread overview]
Message-ID: <1086016346.8185.68.camel@cube> (raw)
In-Reply-To: <Pine.LNX.4.58.0405310948120.4573@ppc970.osdl.org>

On Mon, 2004-05-31 at 12:53, Linus Torvalds wrote:
> On Mon, 31 May 2004, Albert Cahalan wrote:
> > 
> > This would be required because of the -Wno-strict-aliasing
> > option. For the 2.7.xx kernels, how about we start off by
> > replacing -Wno-strict-aliasing with -std=gnu99 ? It's been
> > 5 years since 1999. The "restrict" keyword is useful too.
> 
> No can do.
> 
> Aliasing in gcc is so broken (_purely_ type-based and no way to avoid it
> sanely in older versions) that it's not going to happen.
> 
> When we can depend on everybody having gcc-3.3+ something, and that one
> properly supports the "may_alias" attribute, we may change that.

By the time Linux 2.8.0 is out, gcc-3.3+ should be
a perfectly reasonable requirement.

In the mean time, adding may_alias as needed would be
a good idea.

If all this were behind CONFIG_BROKEN, it sure wouldn't
hurt even today. People might as well get started.
The compiler will keep being pessimistic and dumb until
the -Wno-strict-aliasing option is dropped.

> "restrict" is pretty much useless. It just weakens the already too-weak
> alias rules of standard gcc.

It's easiest to use on function parameters. This helps
the optimizer without being a mind-warping excercise.



  reply	other threads:[~2004-05-31 17:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-31 12:20 Linux 2.6.7-rc2 Albert Cahalan
2004-05-31 16:53 ` Linus Torvalds
2004-05-31 15:12   ` Albert Cahalan [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-05-30  6:52 Linus Torvalds
2004-05-30  7:56 ` Danny ter Haar
2004-05-30 11:09   ` Francois Romieu
2004-05-30 13:16     ` Danny ter Haar
2004-05-30 13:24       ` Danny ter Haar
2004-05-30 16:26   ` Malte Schröder
2004-05-30 17:26   ` Jeff Garzik
2004-05-31  9:21 ` Peter Osterlund
2004-05-31  9:27   ` Andrew Morton
2004-05-31 16:58   ` Linus Torvalds
2004-05-31 22:04     ` Peter Osterlund
2004-06-03 20:01       ` Flavio Stanchina
2004-06-02 14:37 ` Thomas Zehetbauer
2004-06-04 14:06   ` Denis Vlasenko
2004-06-08 17:02     ` Bill Davidsen
2004-06-08 18:02       ` David Ford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1086016346.8185.68.camel@cube \
    --to=albert@users.sf.net \
    --cc=akpm@osdl.org \
    --cc=albert@users.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=petero2@telia.com \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.