Good day, let me first apologize if this is the wrong group, gcc.devel might have been a better choice. I'm writing a library for fixed-point arithmetic using expression templates. I have properties of expressions that sometimes can be computed completely at compile time. GCC builds the expression in memory (on the stack). Values are correctly computed at compile time and the code for building the expression is completely inlined (somewhat to my surprise, given the complexity of the machinery behind it). What baffles me is why GCC (and the Intel compiler) doesn't recognize that the expression is totally dead. Without going into to many details (I can add info once people steer me in the direction they need to go for understanding the issue), what I get from the following fragment: typedef typename number_of_trait<target_traits>::type target_number; typedef typename number_of_trait<source_traits>::type source_number; MARK ("B meta"); int shift = meta_eval (q_shift, target_number(target), source_number(source)); MARK ("E meta"); std:: cout << "shift would be " << shift << "\n"; [q_shift is an expression defined elsewhere as right(_2)-right(_1) where _1 would be bound to target and _2 bound to source] The resulting assembly is: #### B meta #NO_APP movl (%r13), %eax movq %rsp, (%rsp) movl %eax, 144(%rsp) movl %eax, 128(%rsp) movl %eax, 160(%rsp) movzwl (%r15), %eax movw %ax, 192(%rsp) movw %ax, 176(%rsp) movw %ax, 208(%rsp) leaq 208(%rsp), %rax movq %rax, 8(%rsp) leaq 160(%rsp), %rax movq %rax, 16(%rsp) #APP #### E meta #NO_APP movl $.LC339, %esi movl $_ZSt4cout, %edi call _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc movl $.LC340, %esi movl $_ZSt4cout, %edi call _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc movl $1, %esi #<== compile time result of q_shift = right(_2)-right(_1) movq %rax, %rdi call _ZNSolsEi The entire portion between '#### B meta' and '#### E meta' is the building of the expression. At least at the C++ source level everything in there is dead. Can somebody shed some light on this and hint at why GCC (and the Intel compiler) decide that they cannot remove that code? I remember a few years ago GCC had problems with liveness analysis w/ stack slots. Is that still the case? Thanks a lot, Maurizio