public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: java/1305: GCJ ignores volatile modifier
@ 2003-05-12 18:19 Dara Hazeghi
  0 siblings, 0 replies; 3+ messages in thread
From: Dara Hazeghi @ 2003-05-12 18:19 UTC (permalink / raw)
  To: apbianco; +Cc: gcc-prs

The following reply was made to PR java/1305; it has been noted by GNATS.

From: Dara Hazeghi <dhazeghi@yahoo.com>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: java/1305: GCJ ignores volatile modifier
Date: Mon, 12 May 2003 11:02:16 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=1305
 
 Hans Boehm says:
 
 "I think 1305 still needs to remain open.  It's not clear that this can
 be fixed completely until JSR133 finishes its job, and it becomes clear
 what the Java memory model really is.  (I'm one of the participants,
 and we have been trying.  It's not easy.)"
 
 So this PR should stay open.
 
 Dara
 


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: java/1305: GCJ ignores volatile modifier
@ 2003-05-12  3:06 Dara Hazeghi
  0 siblings, 0 replies; 3+ messages in thread
From: Dara Hazeghi @ 2003-05-12  3:06 UTC (permalink / raw)
  To: apbianco; +Cc: gcc-prs

The following reply was made to PR java/1305; it has been noted by GNATS.

From: Dara Hazeghi <dhazeghi@yahoo.com>
To: apbianco@gcc.gnu.org, gcc-gnats@gcc.gnu.org, jeff.sturm@appnet.com
Cc:  
Subject: Re: java/1305: GCJ ignores volatile modifier
Date: Sun, 11 May 2003 20:04:19 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=1305
 
 Hello,
 
 this problem was reported against gcc cvs (20000730). Would it be  
 possible to determine if it is still present in current 3.3 branch or  
 mainline, and update this report accordingly? Thanks,
 
 Dara
 


^ permalink raw reply	[flat|nested] 3+ messages in thread

* java/1305: GCJ ignores volatile modifier
@ 2000-12-20 12:24 jeff.sturm
  0 siblings, 0 replies; 3+ messages in thread
From: jeff.sturm @ 2000-12-20 12:24 UTC (permalink / raw)
  To: java-gnats

>Number:         1305
>Category:       java
>Synopsis:       GCJ ignores volatile modifier
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    apbianco
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 20 12:18:51 PST 2000
>Closed-Date:    
>Last-Modified:  
>Originator:     jeff.sturm@appnet.com
>Release:        CVS trunk (071300)
>Organization:
>Environment:
Linux 2.2 SMP
>Description:
GCJ doesn't implement volatile behavior as outlined in
JLS ch. 17 (or at all, evidently).

Ch. 17 specifies that loads and stores of volatile variables
must be consistent, atomic and sequential.  On some
multiprocessors, gcj-compiled code fails all tests.

Bill Pugh and Doug Lea are credited with discovering this
disrepancy between the JLS and existing JVMs (all current
VMs including those from Sun fail some of the tests.)  This
test case and others are available on Bill's site:

http://www.cs.umd.edu/~pugh/java/memoryModel
>How-To-Repeat:
Run the attached program on a multiprocessor (SMP) host.
It will test for proper sequential access to volatile
variables.  Any inconsistencies will be reported to stdout.

I tested ReadAfterWrite on a quad-PPro running a Linux 2.2
SMP kernel.
>Fix:
Insert a store barrier instruction before and after volatile
loads and stores.

Note that atomic loads and stores of volatile doubles and
longs will be difficult to implement correctly on many
32-bit architectures, including x86.
>Release-Note:
>Audit-Trail:

Formerly PR gcj/284

>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="ReadAfterWrite.java"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ReadAfterWrite.java"

Ci8vIENoZWNrIHRvIHNlZSBpZiBKVk0gZW5mb3JjZXMgb3JkZXIgb2YKLy8gUmVhZHMgYWZ0ZXIg
V3JpdGVzIG9mIHZvbGF0aWxlIHZhcmlhYmxlcy4KLy8gQWxsIG1lbW9yeSBvcGVyYXRpb25zIG9u
IHZvbGF0aWxlIHZhcmlhYmxlcwovLyBzaG91bGQgYmUgc2VxdWVudGlhbGx5IGNvbnNpc3RlbnQg
KGFjY29yZGluZwovLyB0byBleGlzdGluZyBzZW1hbnRpY3MpLgoKLy8gT24gbWFueSBwcm9jZXNz
b3JzLCBhIHdyaXRlIGFuZCBhIGZvbGxvd2luZyByZWFkCi8vIGNhbiBiZSBlZmZlY3RpdmVseSBy
ZW9yZGVyIGR1ZSB0byB0aGUgd3JpdGUgYnVmZmVyLgovLyBFdmVuIHVuZGVyIFNwYXJjIFRTTyB0
aGlzIGNhbiBiZSByZW9yZGVyZWQuCi8vIFRoZXkgY2FuIGFsc28gYmUgcmVvcmRlcmVkIHVuZGVy
IEludGVsIElBLTY0LCBJbnRlbAovLyBJQS0zMiwgQWxwaGEgYW5kIFBvd2VyUEMuCgovLyBUaHVz
LCBiZXR3ZWVuIGEgd3JpdGUgdG8gYSB2b2xhdGlsZSB2YXJpYWJsZSBhbmQgCi8vIGEgcmVhZCBv
ZiBhIHZvbGF0aWxlIHZhcmlhYmxlLCBhIG1lbW9yeSBiYXJyaWVyIGluc3RydWN0aW9uCi8vIGlz
IHJlcXVpcmVkLgoKLy8gRnJvbSBEb3VnIExlYSdzOiBGSlRhc2tSdW5uZXIuamF2YQovLyAgKiAo
VGhpcyByZWxpZXMgb24gdGhlIEpWTSBwcm9wZXJseSBkZWFsaW5nIHdpdGggcmVhZC1hZnRlci13
cml0ZQovLyAgKiBvZiB0d28gdm9sYXRpbGVzLikKCi8vIEluIG15IHRlc3RzLCBJIGhhdmVuJ3Qg
Zm91bmQgYW55IEpWTSB0aGF0IGNvcnJlY3RseSBpbXBsZW1lbnRzCi8vIHJlYWQtYWZ0ZXItd3Jp
dGUgb24gdm9sYXRpbGVzLiBJIHRlc3RlZCBIb3RTcG90IGFuZCBFeGFjdFZNIG9uCi8vIFNwYXJj
IFNvbGFyaWMsIEhvdFNwb3QsIElCTSdzIEpWTSBhbmQgTWljcm9zb2Z0J3MgSlZNIG9uIFdpbmRv
d3MKLy8gTlQuCgoKcHVibGljIGNsYXNzIFJlYWRBZnRlcldyaXRlIHsKCiAgc3RhdGljIHZvbGF0
aWxlIGludCBhOwogIHN0YXRpYyBmaW5hbCBpbnQgbiA9IDEwMDAwMDA7CiAgc3RhdGljIGZpbmFs
IGludFtdIEFBID0gbmV3IGludFtuXTsKICBzdGF0aWMgZmluYWwgaW50W10gQkIgPSBuZXcgaW50
W25dOwogIC8vIEZvcmNlIGEgYW5kIGIgdG8gYmUgb24gZGlmZmVyZW50IGNhY2hlIGxpbmVzCiAg
Ly8gZG9uJ3Qga25vdyBpZiB0aGlzIG1hdHRlcnMKICBzdGF0aWMgaW50IHRtcDEsdG1wMix0bXAz
LHRtcDQsdG1wNSx0bXA2LHRtcDcsdG1wODsKICBzdGF0aWMgdm9sYXRpbGUgaW50IGI7CgogIHN0
YXRpYyBjbGFzcyBXcml0ZUEgZXh0ZW5kcyBUaHJlYWQgewoJcHVibGljIHZvaWQgcnVuKCkgewoJ
ICB5aWVsZCgpOwoJICBmaW5hbCBpbnQgW10gbWVtID0gQkI7CgkgIGZvcihpbnQgaSA9IDA7IGkg
PCBuOyBpKyspIHsKCQlhID0gaTsKCQltZW1baV0gPSBiOwoJCX0KCX0KCX0KICBzdGF0aWMgY2xh
c3MgV3JpdGVCIGV4dGVuZHMgVGhyZWFkIHsKCXB1YmxpYyB2b2lkIHJ1bigpIHsKCSAgZmluYWwg
aW50IFtdIG1lbSA9IEFBOwoJICBmb3IoaW50IGkgPSAwOyBpIDwgbjsgaSsrKSB7CgkJYiA9IGk7
CgkJbWVtW2ldID0gYTsKCQl9Cgl9Cgl9CgogIHB1YmxpYyBzdGF0aWMgdm9pZCBtYWluKFN0cmlu
ZyBhcmdzW10pIHRocm93cyBFeGNlcHRpb24gewoJdGVzdCgpOwoJZm9yKGludCBpID0gMDsgaSA8
IG47IGkrKykgewoJCUFBW2ldID0gMDsKCQlCQltpXSA9IDA7CgkJfQoJYSA9IDA7CgliID0gMDsK
CVN5c3RlbS5vdXQucHJpbnRsbigpOwoJdGVzdCgpOwoJfQoKICBwdWJsaWMgc3RhdGljIHZvaWQg
ZHVtcChTdHJpbmcgbmFtZSwgU3RyaW5nIG5hbWUyLCBpbnQgW10gbWVtLCBpbnQgaSkgewoJaW50
IGogPSBpOwoJaW50IGNvdW50ID0gMDsKCXdoaWxlIChqID4gMSAmJiBjb3VudCA8IDQpIHsKCQlp
ZiAobWVtW2otMV0gIT0gbWVtW2pdKSBjb3VudCsrOwoJCWotLTsKCQl9Cgljb3VudCA9IDA7Cgl3
aGlsZSAoaiA8IG4gJiYgY291bnQgPCA4KSB7CgkgICAgaWYgKGogPT0gaSkgU3lzdGVtLm91dC5w
cmludCgiKiAiKTsKCSAgICBqKys7CgkgICAgaWYgKG1lbVtqXSAhPSBtZW1bai0xXSkgewoJCSBT
eXN0ZW0ub3V0LnByaW50bG4oIkFmdGVyIHdyaXRpbmcgIiArIAoJCQkJCShqLTEpCgkJCQkJKyAi
IHRvICIgKyBuYW1lCgkJCQkJKyAiLCByZWFkICIgCgkJCQkJKyBtZW1bai0xXQoJCQkJCSsgIiBm
cm9tICIgKyBuYW1lMik7CgkJIGNvdW50Kys7CgkJIH0KCSAgIH0KCX0KCQkKICBwdWJsaWMgc3Rh
dGljIHZvaWQgdGVzdCgpIHRocm93cyBFeGNlcHRpb24gewoJVGhyZWFkIHQxID0gbmV3IFdyaXRl
QSgpOwoJVGhyZWFkIHQyID0gbmV3IFdyaXRlQigpOwoJdDEuc3RhcnQoKTsKCXQyLnN0YXJ0KCk7
Cgl0MS5qb2luKCk7Cgl0Mi5qb2luKCk7Cglmb3IoaW50IGkgPSAxMDA7IGkgPCBuOyBpKyspIHsK
CQlpbnQgaiA9IEFBW2ldKzE7CgkJaWYgKCAxMDAgPCBqICYmIGogPCBuICYmIEJCW2pdIDwgaSkg
ewoJCQlTeXN0ZW0ub3V0LnByaW50bG4oIlRocmVhZCAxIik7CgkJCWR1bXAoImEiLCJiIiwgQkIs
aik7CgkJCVN5c3RlbS5vdXQucHJpbnRsbigiVGhyZWFkIDIiKTsKCQkJZHVtcCgiYiIsImEiLEFB
LGkpOwoJCQlyZXR1cm47CgkJCX0KCX0KCX0KCX0K


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-05-12 18:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-12 18:19 java/1305: GCJ ignores volatile modifier Dara Hazeghi
  -- strict thread matches above, loose matches on Subject: below --
2003-05-12  3:06 Dara Hazeghi
2000-12-20 12:24 jeff.sturm

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).