X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f NNTP-Posting-Date: Wed, 18 Apr 2007 02:30:10 -0500 From: "Alexei A. Frounze" Newsgroups: comp.os.msdos.djgpp References: Subject: Re: gcc bug? Date: Wed, 18 Apr 2007 00:26:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-ID: Lines: 96 NNTP-Posting-Host: 67.170.72.236 X-Trace: sv3-cM3+oktqFDuvB6zLFqlJL+Urcm9Ui4/nbAx91RHSQtDgDaXsKHFLwhbvrhn+KsCwG27JtFzfxpAmoIA!U4J2uFfJMbEgonNqUCwXHR5W8SnVyGmE1ZnwJ0drBI+5NmECi5SuCcIxxqmBVYY7Nfjk5+7kecZJ!Sc5yujSGnsHNWWmNKl3ZdAhHLGYr1A== X-Complaints-To: abuse AT comcast DOT net X-DMCA-Complaints-To: dmca AT comcast DOT net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.34 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Rod Pemberton wrote: > "Alexei A. Frounze" wrote in message > news:G-CdnfEDh5KKDLnbnZ2dnUVZ_jydnZ2d AT comcast DOT com... >> Rod Pemberton wrote: >>> "Alexei A. Frounze" wrote in message >>> news:LbadnVsa3_H-ornbnZ2dnUVZ_sudnZ2d AT comcast DOT com... > > Very sleepy now on a topic I'm not well versed on... This, from n1124 > 6.7.3, as I read it, seems to apply. (e.g., both the data _and_ > pointer need a volatile...) > > "5 If an attempt is made to modify an object defined with a > const-qualified type through use > of an lvalue with non-const-qualified type, the behavior is > undefined. If an attempt is > made to refer to an object defined with a volatile-qualified type > through use of an lvalue > with non-volatile-qualified type, the behavior is undefined.113)" > > > Anyway, let's ignore the spec. and see if I've got it the issues > straight: > > Volatile on the pointer works (i.e., f2). If the pointer is > volatile, then the data is volatile implicitly (i.e., new pointer > therefore new data). And, both optimized and unoptimized, we see the > pointer being reloaded from the stack and the data being reloaded > from the pointer. > > Volatile on the data doesn't work (i.e., f1) supposedly just for -O2. > If the pointer isn't volatile, but the data is, then just the data > should be reloaded. Unoptimized, the compiler treats both as > volatile (both are refreshed), i.e., incorrect. Optimized, the > compiler treats both as non-volatile (neither are reloaded), i.e, > (appears) incorrect. So, technically, both are incorrect. But, for > the unoptimized case, since the pointer isn't changing, it's > functionally correct. For the optimized case, it would appear that > it's incorrect unless the compiler can somehow determine that the > data isn't changing... > > Going to sleep... Consider this case: fxn() { #if 0 volatile int* px; // variant 1 #else int* volatile px; // variant 2 #endif ... px = ...; ... switch (*px) { case 0: break; case 1: break; default: break; } ... } On a different from GCC compiler variant 2 yielded this sort of asm code for the switch: cmp [eax], 0 je L0 cmp [eax], 1 je L1 ... It didn't treat the pointer as volatile (maybe because it was local a local var not passed to any functions as argument) but generated 2 accesses to the data. These 2 accesses are a bit unexpected. Well, they're OK for a non-volatile variable, but either volatile pointer doesn't necessarily imply volatiliness of the object it points to or something's wrong or indeed undefined. On the other hand for the variant 1 it generated this sort of code for the switch: mov ecx, [eax] cmp ecx, 0 je L0 cmp ecx, 1 je L1 which is what I wanted but screwed up. Even though the code's fixed, the incident now puzzles me. Alex