[M3commit] CVS Update: cm3

[Jay]

ps: We load/store everything as a bitfield as I understand..I wonder if that is a problem, like, given that bitfields aren't addressible..

(which is not to say that they can't be volatile, and bitfields are often used to "map to hardware interfaces" so maybe this is irrelevant)

 

Tony -- your change..is it reasonable/useful in light of larger related -O3 breakage?

 

 - Jay
 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3commit at elegosoft.com
Subject: RE: [M3commit] CVS Update: cm3
Date: Mon, 11 May 2009 07:39:16 +0000



ah. Notice that m3_load/m3_store mark a lot of things volatile.
I'm trying out a wild guess and marking "v" volatile before the offseting in those functions..
 
I guess though you've revealed the answer -- strive for like I said -- mark anything volatile referenced in finally or such. Er, anything referenced both in try and finally, something like that. Initial lameness would be all locals in a function with try/finally/lock. And, gosh, I hope they don't enregister globals. :(
You'd want some volatile on globals too.
Only the uses in a try where the function also references them in a finally.
 
Maybe the old behavior is easy to restore??
 
 - Jay

 
> From: hosking at cs.purdue.edu
> To: hosking at cs.purdue.edu
> Date: Mon, 11 May 2009 17:32:54 +1000
> CC: m3commit at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Looks like gcc used to do the "right thing" for locals in functions 
> that called setjmp. I suppose that hurt performance so they got rid 
> of it and put the warnings in instead.
> 
> On 11 May 2009, at 17:22, Tony Hosking wrote:
> 
> > Yeah, I just don't understand that it apparently used to work...
> >
> > On 11 May 2009, at 17:15, Jay wrote:
> >
> >>
> >> Hey, this warning seems to be pretty important.
> >>
> >>
> >>
> >> I have on birch a cm3 built with, I think, -O3, and it is very broken
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20090511/7cce49c4/attachment-0002.html>