On 1/4/06, Joern RENNECKE <[EMAIL PROTECTED]> wrote:
> 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.This has been reported before and the kernel was fixed. typeof now always "returns" the effective type, including CV qualifiers in effect. Richard.
