LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: yuan cooper <yuanxjtu@hotmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	dmitry.torokhov@gmail.com
Subject: Re: About GCC4 Optimization
Date: Sat, 24 Mar 2007 21:28:06 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0703242123310.6730@woody.linux-foundation.org> (raw)
In-Reply-To: <BAY144-F24481F006CCA5D5D74D6F4DF680@phx.gbl>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=gb2312, Size: 1345 bytes --]



On Sun, 25 Mar 2007, yuan cooper wrote:
>  
> during my work, I found there is a bug with GCC4 O2 optimization.

Technically, it's a misfeature fo gcc4, not a bug.

The C language allows for type-based alias detection, and gcc notices that 
a "float *" cannot ever alias with a "unsigned long *", so it decides to 
not even do the loads and stores..

Now, there's two things wrong with this picture:

 - gcc is being an ass. type-based alias detection should happen only as a 
   last resort, and gcc should know and notice that *despite* the types 
   being different, they definitely alias.

   So what gcc does may be technically legal, but it's still a horribly 
   bad thing to do. Sadly, some gcc people seem to care more about "letter 
   of the law" than "sanity and quality of implementation".

 - as a result, you should always compile any kernel stuff with 
   "-fno-strict-aliasing", which should turn this off. If it *still* 
   happens with that flag, then it is indeed a compiler bug.

> float ftmp;
> unsigned long tmp;
> ftmp = 1.0/1024.0;
> tmp  = *(unsigned long *)(&ftmp);
> tmp  = (tmp >> 11) && 0xFFF;
>  
> if optimization level is O2, gcc will MOV eax to tmp, but current eax has a random value.
> -O is ok and gcc3 with O2 is ok too.

That said, you really _really_ shouldn't be doing FP in the kernel anyway.

		Linus

  parent reply	other threads:[~2007-03-25  4:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-25  3:32 keyboard.c: Stop flooding dmesg with useless warnings Parag Warudkar
2007-03-25  3:38 ` Parag Warudkar
     [not found]   ` <BAY144-F24481F006CCA5D5D74D6F4DF680@phx.gbl>
2007-03-25  4:28     ` Linus Torvalds [this message]
2007-03-25  5:07       ` About GCC4 Optimization David Schwartz
2007-03-25  4:31     ` Andrew Morton
2007-03-25  5:15   ` keyboard.c: Stop flooding dmesg with useless warnings Dmitry Torokhov
2007-03-25  5:27     ` Parag Warudkar
2007-03-25  5:29       ` Dmitry Torokhov
2007-03-25  5:35         ` Parag Warudkar
2007-03-25  9:16           ` Jiri Kosina
2007-03-25 14:32             ` Parag Warudkar

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=Pine.LNX.4.64.0703242123310.6730@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yuanxjtu@hotmail.com \
    --subject='Re: About GCC4 Optimization' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).