From: Grzegorz Kulewski <kangur@polcom.net>
To: Valdis.Kletnieks@vt.edu
Cc: Chuck Ebbert <76306.1226@compuserve.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Andi Kleen <ak@suse.de>, Andrew Morton <akpm@osdl.org>,
Ingo Molnar <mingo@redhat.com>,
Linus Torvalds <torvalds@osdl.org>
Subject: Re: set_bit() is broken on i386?
Date: Sat, 21 Jan 2006 03:01:10 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.63.0601210245280.8060@alpha.polcom.net> (raw)
In-Reply-To: <200601210132.k0L1WbIP006348@turing-police.cc.vt.edu>
On Fri, 20 Jan 2006, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 20 Jan 2006 19:53:14 EST, Chuck Ebbert said:
>> /*
>> * setbit.c -- test the Linux set_bit() function
>> *
>> * Compare the output of this program with and without the
>> * -finline-functions option to GCC.
>> *
>> * If they are not the same, set_bit is broken.
>> *
>> * Result on i386 with gcc 3.3.2 (Fedora Core 2):
>> *
>> * [me@d2 t]$ gcc -O2 -o setbit.ex setbit.c ; ./setbit.ex
>> * 00010001
>> * [me@d2 t]$ gcc -O2 -o setbit.ex -finline-functions setbit.c ; ./setbit.ex
>> * 00000001
>
> It certainly seems to be gcc version dependent (and I'd not be surprised if the
> exact combo of -O2, -Os, and -mfoo and -fwhatever flags as well). Trond is
> probably right that a memory clobber will force gcc to DTIT (Do The Intended
> Thing, which may be different from a DTRT) regardless of what gcc's code generator
> decides to do....
>
> % gcc -v
> Using built-in specs.
> Target: i386-redhat-linux
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux
> Thread model: posix
> gcc version 4.1.0 20060117 (Red Hat 4.1.0-0.15)
> % gcc -O2 -o setbit.ex setbit.c ; ./setbit.ex
> 00000001
> % gcc -O2 -o setbit.ex -finline-functions setbit.c ; ./setbit.ex
> 00000001
>
> Fedora Core -devel tree as of this morning (so sort-of FC5 test2).
This is what I am getting under Gentoo with different gcc's:
$ export CC=gcc-3.4.5; $CC --version; rm ./setbit.ex; $CC -O2 -o setbit.ex
setbit.c ; ./setbit.ex; rm ./setbit.ex; $CC -O2 -o setbit.ex
-finline-functions setbit.c ; ./setbit.ex
gcc-3.4.5 (GCC) 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
00000001
00000001
$ export CC=gcc-4.0.2; $CC --version; rm ./setbit.ex; $CC -O2 -o setbit.ex
setbit.c ; ./setbit.ex; rm ./setbit.ex; $CC -O2 -o setbit.ex
-finline-functions setbit.c ; ./setbit.ex
gcc-4.0.2 (GCC) 4.0.2 (Gentoo 4.0.2-r3, pie-8.7.8)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
00000001
00000001
$ export CC=gcc-4.1.0-beta20060113; $CC --version; rm ./setbit.ex; $CC -O2
-o setbit.ex setbit.c ; ./setbit.ex; rm ./setbit.ex; $CC -O2 -o setbit.ex
-finline-functions setbit.c ; ./setbit.ex
gcc-4.1.0-beta20060113 (GCC) 4.1.0-beta20060113 (prerelease)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
00000001
00000001
And on some really old and not upgraded server (with Gentoo too of
course):
$ export CC=gcc32; $CC --version; rm ./setbit.ex; $CC -O2 -o setbit.ex
setbit.c ; ./setbit.ex; rm ./setbit.ex; $CC -O2 -o setbit.ex
-finline-functions setbit.c ; ./setbit.ex
gcc (GCC) 3.3.5-20050130 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1,
pie-8.7.7.1)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
00010001
00000001
So either this problem is present only on gcc < 3.4 or Gentoo patched it
somehow in newer versions...
Thanks,
Grzegorz Kulewski
next prev parent reply other threads:[~2006-01-21 2:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-21 0:53 Chuck Ebbert
2006-01-21 1:15 ` Trond Myklebust
2006-01-21 1:49 ` Andreas Schwab
2006-01-21 2:38 ` Andrew Morton
2006-01-21 19:26 ` Trond Myklebust
2006-01-21 1:32 ` Valdis.Kletnieks
2006-01-21 2:01 ` Grzegorz Kulewski [this message]
2006-01-21 1:48 ` Andrew Morton
2006-01-21 1:38 Kenny Simpson
2006-01-21 1:46 Kenny Simpson
2006-01-21 2:07 Kenny Simpson
2006-01-21 7:43 Chuck Ebbert
2006-01-21 20:49 Chuck Ebbert
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.63.0601210245280.8060@alpha.polcom.net \
--to=kangur@polcom.net \
--cc=76306.1226@compuserve.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome