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