On Thu, 3 Jul 2003, William Lee Irwin III wrote:
> On Thu, Jul 03, 2003 at 02:15:08PM -0700, Andrew Morton wrote:
> > ok. If you're feeling keen could you please revert the cpumask_t patch.
> > And please send the .config, thanks.
>
> Zwane reproduced this and when I compiled an identical kernel for him
> it went away; the only difference wsa the compiler version.
This is definitely a compiler issue, i rebuilt with;
zwane@montezuma linux-2.5.74-cpumask {0:0} gcc296 -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux7/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-118)
And that works with NR_CPUS = 3 (it also explains why my 8way test box
with RH7.3 worked)
Also i ended up writing a userspace test case. I then narrowed it down to
-O2 with gcc 3.2 (native RH9 compiler) which causes failure;
e.g.
zwane@montezuma linux-2.5.74-cpumask {0:0} gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
zwane@montezuma linux-2.5.74-cpumask {0:0} gcc -O2 test.c -o test-gcc3.2
zwane@montezuma linux-2.5.74-cpumask {0:0} ./test-gcc3.2
main: tmp 1
main: phys_cpu_present_map before 0
main: phys_cpu_present_map after 0
main: tmp 8
main: phys_cpu_present_map before 0
main: phys_cpu_present_map after 0
main: tmp 10
main: phys_cpu_present_map before 0
main: phys_cpu_present_map after 0
zwane@montezuma linux-2.5.74-cpumask {0:0} gcc -O1 test.c -o test-gcc3.2
zwane@montezuma linux-2.5.74-cpumask {0:0} ./test-gcc3.2
main: tmp 1
main: phys_cpu_present_map before 0
main: phys_cpu_present_map after 1
main: tmp 8
main: phys_cpu_present_map before 1
main: phys_cpu_present_map after 9
main: tmp 10
main: phys_cpu_present_map before 9
main: phys_cpu_present_map after 19
The second one is correct. So one definite failing piece of code was in
the cpus_or() path, i'm not so sure about the others. I have attached the
test case. Bill says his gcc 3.3 works...
Andrew?
-- function.linuxpower.ca
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:22 EST