libgcc2.c troubles with volatile

[Dan Nicolaescu <dann at godzilla dot ics dot uci dot edu>]

This one was a lot harder to track down:

It looks like asm volatile is not obeyed, code it's still moved
around. 

(the egcs version used here is the egcs-19992401 shapshot, on
sparc-sun-solaris2.5.1) 


I want to look at the code generated for 
__bb_trace_func because I get some segmentation faults there when
runing programs compiled with -g -ax

The function starts like this:

void
__bb_trace_func ()
{
  struct bb_edge *bucket;

  MACHINE_STATE_SAVE("1")


The macro is defined as: 

#define MACHINE_STATE_SAVE(ID)				\
  extern char flgtab[] __asm__(".LMSS"ID);		\
  unsigned long int ms_flags, ms_saveret;		\
  asm volatile("ta	0x20\n\t"			\
	       "mov	%%g1, %0\n\t"			\
	       "mov	%%g2, %1\n\t"			\
	       : "=r" (ms_flags), "=r" (ms_saveret));


I look at the assembly code by extracting _bb.o from libgcc2.a 
ar x libgcc2.a _bb.o
dis _bb.o > _bb.s

In _bb.s 
__bb_trace_func()
        1228:  9d e3 bf 90         save         %sp, -112, %sp
        122c:  2f 00 00 00         sethi        %hi(0x0), %l7
        1230:  7f ff fc 0d         call         0x264
                                 ^^^^^^^^^^^^^^^^^
                                 this call was moved here, before the 
				asm volatile
        1234:  ae 05 e0 00         add          %l7, 0, %l7
        1238:  91 d0 20 20         ta           0x20
        123c:  ac 10 00 01         mov          %g1, %l6
        1240:  b0 10 00 02         mov          %g2, %i0
        1244:  11 00 00 00         sethi        %hi(bb_src), %o0
        1248:  90 12 20 00         or           %o0, bb_src, %o0        ! bb_src




the mentioned call defeats the purpose of the
MACHINE_STATE_SAVE macro, to allow the  __bb_trace_func leave the
processor in exactly the same state as it was before being called....

libgcc2.a is compiled with -O2

If I compile it with no optimization that call does not appear there
anymore and everything works fine. 

Is this a known bug? 

Is there any other method to determine the compiler to not insert
anything between the starting of the function and that asm ? 

--dan