[ltt-dev] [PATCH] fix the "unknown" case

Paul E. McKenney paulmck at linux.vnet.ibm.com
Tue Jun 15 10:57:12 EDT 2010


On Tue, Jun 15, 2010 at 10:52:23AM +0200, Paolo Bonzini wrote:
> On 06/14/2010 08:25 PM, Paul E. McKenney wrote:
> >>Anyway, a simple configure test is to compile this with -fdump-rtl-expand:
> >>
> >>	int
> >>	f()
> >>	{
> >>	  __sync_synchronize();
> >>	}
> >>
> >>If the assembly output includes "__sync_synchronize", or the dump
> >>file includes the text "unspec:BLK", it should be fine.  In
> >>particular, ia64, mips, and Alpha are ok.  Else you can use the
> >>pthreads trick.  I can try to make a patch if you're interested.
> >>Or, more simply, it's possible to hardcode the above three platforms
> >>since it's unlikely that others will be added soon.
> >
> >And I attached the input file, the .expand file, and the .s file.
> >
> >I see neither __sync_synchronize in the .s file nor "unspec" in the
> >.expand file.  Or was I confused about what to look for?
> 
> No, the __sync_synchronize instruction is optimized out.  I think
> I'll make GCC 4.6+ give a warning.

Thank you for looking into this!

Hmmm...  One mistake I made last time was to forget the "-mcpu=cortex-a9
-mtune=cortex-a9" -- but adding this does not change the result.

If I have other code in the function, I do get the following in
the .s file:

	@ 10 "gcc_sync.c" 1
		#__sync_synchronize

But still no meaningful code.

So for the moment I am using my own asm to generate a dmb instruction.

Which raises the question as to whether I can really trust the other
__sync_ instructions.  They -seem- to be working for me, but one cannot
prove them correct by testing.  :-(

							Thanx, Paul




More information about the lttng-dev mailing list