[M3commit] CVS Update: cm3

Jay K jay.krell at cornell.edu
Sat Sep 25 12:25:59 CEST 2010


indeed, release:

declare_segment
  name = M_Main
  fix_name => MM_Main
  +3 => Main

I fixed it, attached.
Thanks for the chiding.

 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: RE: [M3commit] CVS Update: cm3
> Date: Sat, 25 Sep 2010 00:44:57 +0000
>
>
> To be clear though, what I think I saw was:
>
> declare_segment(name = "_Main", typeid = NO_UID)
> => fix_name
>  => M_Main
>  => + 3
>  => "ain"
>
> If those are the parameters to declare_segment,
> then the rest seems to follow, in release. But I'll have to check it all.
>
>  - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: hosking at cs.purdue.edu; jkrell at elego.de
> > Date: Sat, 25 Sep 2010 00:40:18 +0000
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> >
> >
> > > This must have been a regression!
> >
> > Ok I'll have to see what the release branch did then.
> > Probably not just by reading the code, which I already did a bit.
> > Debugging it.
> >
> > - Jay
> > ----------------------------------------
> > > From: hosking at cs.purdue.edu
> > > Date: Fri, 24 Sep 2010 20:23:56 -0400
> > > To: jkrell at elego.de
> > > CC: m3commit at elegosoft.com
> > > Subject: Re: [M3commit] CVS Update: cm3
> > >
> > >
> > >
> > > On 25 Sep 2010, at 02:16, Jay Krell wrote:
> > >
> > > > CVSROOT: /usr/cvs
> > > > Changes by: jkrell at birch. 10/09/25 02:16:13
> > > >
> > > > Modified files:
> > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c
> > > >
> > > > Log message:
> > > > tighten up some asserts
> > > > size and align >= 1, not just >= 0
> > > > er, no, size can be 0, for empty records
> > > > or fields of their type, so leave it alone and align >= !!size
> > > >
> > > > work in progress
> > > > types/debugging for enums and typedefs
> > > > (when you say TYPE a = {b,c};
> > > > {b,c} is anonymous enum
> > > > and a is a typedef/typename for.
> > > > consider you can say:
> > > > TYPE a = {b,c};
> > > > TYPE a2 = {b,c};
> > > > it is equivalent to typedef enum {b,c} a, a2;)
> > > > not yet working, not yet enabled
> > > >
> > > > don't widen return types
> > > > leave the mechanism though because
> > > > this might be where we adjust struct vs. struct*, which
> > > > is another thing configure -enable-checking complains about,
> > > > though that is specific to module initializers I think,
> > > > not all functions in general
> > > >
> > > > set the alignment of bitfields 1 bit, other fields to BITS_PER_UNIT (8 bits)
> > > > part of attempted work in progress to generate decent trees
> > > > instead of obviously poor ones; aka to actually maybe finish
> > > > this backend instead of leaving it very incomplete for years
> > > > (not yet enabled)
> > > >
> > > > Do a better job of skipping the prefix of module/segment names.
> > > > M_Main => "Main" instead of "ain".
> > > > Instead of always skipping 3, skip up to the first
> > > > underscore, if it is at position 0, 1, or 2.
> > > > Right? Or did I regress this somewhere since release?
> > >
> > > This must have been a regression!
> > >
> > > >
> > > > layout_decl(var, 0)
> > > > => layout_decl(var, 1)
> > > > alignment = 0 is bad, causes divide by zero with plain -g
> > >
> >
>
 		 	   		  
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100925/82517bb6/attachment-0002.txt>


More information about the M3commit mailing list