In order to investigate the CSiBE compilation time regressions observed
in December when my cross-jumping patches were installed, I set out to
compare the timings of current mainline with and without the patches
reinstated. However, unmodified mainline (r109325) fails to compile the
linux benchmark with an sh-elf targeted compiler:
while [ $((I--)) -gt 0 ] ; do \
/usr/bin/time -a -o signal.o.time -f "%U"
/mnt/scratch/base-20060104/bin/sh-elf-gcc -c -D__linux__ -D__KERNEL__
-DCONFIG_ARCH_S390X -DCONFIG_ARCH_S390 -U__i386__ -U__x86_64__
-I/mnt/scratch/CSiBE/base-20060104/linux-2.4.23-pre3-testplatform/include
-w -Os -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe
-fno-strength-reduce -nostdinc -iwithprefix include
-DKBUILD_BASENAME=signal -c -o signal.o signal.c ; \
done
signal.c: In function ‘do_sigaltstack’:
signal.c:1148: error: assignment of read-only variable ‘__x’
signal.c:1149: error: assignment of read-only variable ‘__x’
signal.c:1150: error: assignment of read-only variable ‘__x’
signal.c: In function ‘do_sigaltstack’:
signal.c:1148: error: assignment of read-only variable ‘__x’
signal.c:1149: error: assignment of read-only variable ‘__x’
signal.c:1150: error: assignment of read-only variable ‘__x’
signal.c: In function ‘do_sigaltstack’:
signal.c:1148: error: assignment of read-only variable ‘__x’
signal.c:1149: error: assignment of read-only variable ‘__x’
signal.c:1150: error: assignment of read-only variable ‘__x’
make[4]: *** [signal.o] Error 1
make[4]: Leaving directory
`/mnt/scratch/CSiBE/base-20060104/linux-2.4.23-pre3-testplatform/kernel'
make[3]: *** [first_rule] Error 2
make[3]: Leaving directory
`/mnt/scratch/CSiBE/base-20060104/linux-2.4.23-pre3-testplatform/kernel'
make[2]: *** [_dir_kernel] Error 2
make[2]: Leaving directory
`/mnt/scratch/CSiBE/base-20060104/linux-2.4.23-pre3-testplatform'
make[1]: *** [time.txt] Error 2
make[1]: Leaving directory
`/mnt/scratch/CSiBE/base-20060104/linux-2.4.23-pre3-testplatform'
make: *** [linux-2.4.23-pre3-testplatform/result-time.csv] Error 2
The failure occurs when the include/asm/uaccess.h:get_user macro called
from kernel/signal.c:do_signalstack with a const source.
The testcase can also be condensed to:
typedef struct s
{
void *p;
} stack_t;
void
do_sigaltstack (const stack_t *uss)
{
__typeof__ (*(&uss->p)) x;
x = 0;
}
Apparently, the const-qualification of uss->p carries over to x. When
the '*' and '&' are removed from the typeof expression, it doesn't.
I can't find anyting in the documentation that explicitly says if we
should strip const-qualification or not. However, there are a number of
examples in extend.texi - although not in the typeof entry - that also
declare temporary varaibles that are assigned to later, and thus would
be prone to error when a const value is passed in, if const is
propagated by typeof.
I think typeof should ignore toplevel const qualifiers, and that this
should be documented. If we consider this a requirement, then we have a
regression somewhere between
GNU C version 4.0.0 20050126 (experimental) (sh-elf) and
GNU C version 4.1.0 20050922 .
What puzzles me is that we have recent CSiBE results.
