This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Libjava failures status


Tom Tromey wrote:
> 
> Bryce> a = foo.a;
> Bryce> b = foo.b;
> 
> Bryce> Then obviously the second load from foo can not trap.
> 
> Unless foo is a field and is changed by another thread.
> Maybe this case is undefined if we haven't synchronized?

I'm not so sure about this case.  Chapter 17 of the JLS (and thus
chapter 8 of JVMS) is currently under revision,
http://jcp.org/jsr/detail/133.jsp, so multi-thread semantics are not
presently set in stone.  But my personal take on the matter is that the
compiler is allowed to assume foo.b cannot trap iff foo is not
volatile.  Without a synchronized block or volatile reference to force a
memory flush, the compiler is free to used a cached version of foo
rather than reloading the (possibly changed) field.

-- 
This signature intentionally left boring.

Eric Blake             ebb9@email.byu.edu
  BYU student, free software programmer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]