This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [4.3] Invalid code or invalid optimisation?
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Dave Korn <dave dot korn dot cygwin at googlemail dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 04 Jun 2009 10:34:30 +0100
- Subject: Re: [4.3] Invalid code or invalid optimisation?
- References: <4A2728AA.3010205@gmail.com> <4A27857D.50708@redhat.com>
Andrew Haley wrote:
> Dave Korn wrote:
>
>> Adding a "memory" clobber to the inline asm works around the problem,
>> causing 4.3 series to generate the same assembly as head, but I think it's a
>> sledgehammer approach. Am I asking too much of GCC to not sink the store, or
>> is 4.3 doing something wrong? I /think/ that the fact that there's a volatile
>> store in ilockcmpexch means the earlier store shouldn't be moved past it, and
>> that GCC is perhaps missing that the asm's output operand effectively
>> represents a volatile write through *t, but I could be misunderstanding the
>> rules about volatile. Anyone got their language lawyer's hat on at the moment?
>
> You could just look at the standard, y'know.
I did but I get as far as all that stuff about "The party of the third part
shall be known herein as the party of the third part" and find it very
difficult to know whether what it looks like it says actually is what it is
trying to say.
> Volatile stores only block other
> volatile stores: they don't block *all* stores. If you really want a complete
> memory barrier, which in a mutex you surely do, then you're going to have to
> clobber memory.
Ah. That suggests that HEAD is in fact _missing_ an optimisation that 4.3
gets right. Maybe I should file a PR after all.
cheers,
DaveK