I thought that this reliance on the compiler doing dead code
elimination at all optimization levels is all over the Linux
kernel code.

My recommendation would be to do this kind of dead code
elimination at -O0 in Open64. That will provide greater compatibility
with gcc.

- Suneel


On Fri, Feb 11, 2011 at 10:59 AM, Xiaohua Zhang <xiaohua_zh...@yahoo.com> wrote:
> Hello,
>
> Here is the code snippet which caused compile-time error in bug 588:
>
> typedef unsigned long int uintptr_t;
> struct Header
> {
>    int self;
>    uintptr_t stack_guard;
> };
> void foo(struct Header header, uintptr_t stack_chk_guard)
> {
>   if (sizeof (header.stack_guard) == 1)
>     asm volatile ("movb %b0,%%fs:%P1" : : "iq" (stack_chk_guard),
>                   "i" (__builtin_offsetof (struct Header, stack_guard)));
>   else if (sizeof (header.stack_guard) == 4)
>     asm volatile ("movl %0,%%fs:%P1" : : "ir" (stack_chk_guard),   // error
>                   "i" (__builtin_offsetof (struct Header, stack_guard)));
>   else
>   {
>     if (sizeof (header.stack_guard) !=8 )
>       abort ();
>     asm volatile ("movq %q0,%%fs:%P1" :
>                   : "ir" ((unsigned long int) stack_chk_guard),
>                   "i" (__builtin_offsetof (struct Header, stack_guard)));
>   }
> }
>
> In the case "sizeof (header.stack_guard) == 4", the operand constraint "ir"
> specifies an integer register which is a 64 bit "r" register under a 64 bit
> compilation, but a 64 bit register is not valid source operand for a "movl"
> instruction, so the open64 compiler reports compile time error at -O0 (it
> works fine at O1 and up).
>
> Gcc compiles this test case without any complain, it does dead code
> elimination at O0, so the offending code is NOT passed to code generation
> phase which checks the asmbly code constrains. Open64 does not perform this
> optimization at O0, so it finds the constrain illegal.
>
> We believe user should not depend on compiler optimizaiton removing illegal
> code to make it work, user is responsible for providing valid code to
> compiler, so in this case, I suggest to close the bug as user error.
>
> (The work around is add a cast: "ir" ((int)stack_chk_guard),   )
>
> What do you think?
>
> Thanks,
> -Xiaohua
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to