On Mon, Jul 22, 2019 at 5:13 PM Qian Cai <cai@xxxxxx> wrote: > > On Fri, 2019-07-19 at 17:47 -0400, Qian Cai wrote: > > On Thu, 2019-07-18 at 16:29 -0700, David Miller wrote: > > > From: Qian Cai <cai@xxxxxx> > > > Date: Thu, 18 Jul 2019 19:26:47 -0400 > > > > > > > > > > > > > > > > On Jul 18, 2019, at 5:21 PM, Bill Wendling <morbo@xxxxxxxxxx> wrote: > > > > > > > > > > [My previous response was marked as spam...] > > > > > > > > > > Top-of-tree clang says that it's const: > > > > > > > > > > $ gcc a.c -O2 && ./a.out > > > > > a is a const. > > > > > > > > > > $ clang a.c -O2 && ./a.out > > > > > a is a const. > > > > > > > > > > > > > > > > I used clang-7.0.1. So, this is getting worse where both GCC and clang > > > > will > > > > > > start to suffer the > > > > same problem. > > > > > > Then rewrite the module parameter macros such that the non-constness > > > is evident to all compilers regardless of version. > > > > > > That is the place to fix this, otherwise we will just be adding hacks > > > all over the place rather than in just one spot. > > > > The problem is that when the compiler is compiling be_main.o, it has no > > knowledge about what is going to happen in load_module(). The compiler can > > only > > see that a "const struct kernel_param_ops" "__param_ops_rx_frag_size" at the > > time with > > > > __param_ops_rx_frag_size.arg = &rx_frag_size > > > > but only in load_module()->parse_args()->parse_one()->param_set_ushort(), it > > changes "__param_ops_rx_frag_size.arg" which in-turn changes the value > > of "rx_frag_size". > > Even for an obvious case, the compilers still go ahead optimizing a variable as > a constant. Maybe it is best to revert the commit d66acc39c7ce ("bitops: > Optimise get_order()") unless some compiler experts could improve the situation. > > #include <stdio.h> > > int a = 1; > > int main(void) > { > int *p; > > p = &a; > *p = 2; > > if (__builtin_constant_p(a)) > printf("a is a const.\n"); > > printf("a = %d\n", a); > > return 0; > } > > # gcc -O2 const.c -o const > > # ./const > a is a const. > a = 2 This example (like the former) is showing correct behavior. At the point of invocation of __builtin_constant_p here, the compiler knows that 'a' is 2, because you've just assigned it (through 'p', but that indirection trivially disappears in optimization).