Problem running optimized IA64 code that invokes hand-coded assembly language function

[JCA <1 dot 41421 at gmail dot com>]

  I have a function F written in IA64 assembly language function. This
function is invoked from a C program P. If I compile P with gcc (version
3.2.3) under Linux, and with no optimization options, the resulting
executable runs flawlessly. If I compile P with -O then the resulting executable
fails. Interestingly, building P with the Intel compiler results in an
executable that runs perfectly, with or without optimization.

 The way the executable obtained with gcc and -O fails is as follows:

 I have an if-then-else construct to determine what function to invoke:

 if (x == OPERATION_ONE)
   f1() ;
 else
   f2() ;

 Both f1 and f2 invoke F.

 This portion of code is executed many times inside a for loop. The
value of x is set to OPERATION_ONE outside the loop (for my particular
run,) which implies that we should always invoke f1. This is what
happens the first two times this if block is executed. The third time,
mysteriously, it is f2 that gets invoked. Even more puzzling, it
happens so even if the value of x is set to OPERATION_ONE by hand with
the debugger, just before the conditional is executed. Also, if
immediately preceding the if block I insert the line

  x = OPERATION_ONE ;

and recompile (with or without -O,) then everything works fine.

  At this point I do not know if it is the case that F is buggy, but
happens to work without optimization for gcc, and in all cases for the
Intel compiler, or whether there is a bug in the gcc optimizer that is
tickled by F.

  It would be useful if somebody knowledgeable could tell me what
IA64 registers does gcc expect to be preserved on return of function
calls; I am familiar with the convention for IA64 assembly language
and C, but I do not know what gcc assumes in this respect.

	
  Reply