[M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg?

Jay K jay.krell at cornell.edu
Wed Jul 3 03:56:05 CEST 2013


  Yes, there is just one copy of the directory.  
  Look in m3cc/src/m3makefile.  
  Sometimes maybe a prefix is copied followed by the rest of the file, e.g.  
 
 
  #define GCC47  
   ... contents of parse.c ...   
 
 
  The #defines have a mix of meanings.  
  GCC12 might mean exactly GCC 1.2, or it might mean 1.2 or newer.  
  And there is GCC_APPLE, which goes along with gcc 4.2.
 

  I'm sorry about that.  
  It could/should be cleaned up.  
 

  If you really want, consider some things:  
 

 1) make entire copies of the file 
 2) split the file up and copy some of them, while keeping others identical 
 

Most of the code is indeed identical.  
  So I don't like #1.  
  In the case of #2, the bulk of the content would remain where it is, in the one parse.c,  
  so history would be reasonable.  
 

  Preserving history is of some concern,  
  but CVS works poorly enough, and perhaps we renamed the directories in the past,  
  so I'd be ok with having to jump around to trace history accurately.  
 

  Or leave things mostly asis.  
 

  And/or cleanup the meanings or "granularity" of the #defines.  
  And/or drop support for all but the latest?  
 

  I didn't get around to moving every target forward.  
  Mainline gcc does not support OpenBSD for example, so I/we always have    
  to do at least a tiny bit of work there.  
  The OpenBSD ports/packages system does maintain patches for gcc.  
  Many are outside the backend, and they are all trivial, stuff like picking size_t  
  and pre-#definining __OpenBSD__ or such.  
   Interix also requires moving small non-Modula-3 patches forward.
  iPhone/ARM_DARWIN would remain at 4.2 also, probably.
  I got as far there as starting up the compiler, which is pretty far.
 

  I have a number of times edited the wrong file only to have it overwritten by m3makefile.  
  That is an unfortunate fallout of this scheme.  
  

  But, as I said, most of the contents of the file are portable across several gcc versions.  

 
  Hopefully I'll back to the C backend and moot this.. :(
 

 Anyway, if you look at the source and CVS, it should be /reasonably/ clear.
 I don't know/remember what m3cc-old is.
 
 
There is some pain around "GTY".
The syntax for it changed across gcc versions, like GTY struct foo vs. struct GTY foo or struct foo GTY.
This is the annotation you put on types for the gcc garbage collector.
So for that I did split a little bit of content into a different file.
 

 - Jay




 
> Date: Tue, 2 Jul 2013 09:31:26 -0500
> From: rodney_bates at lcwb.coop
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg?
> 
> OK. Is it the one in m3-sys/m3cc/gcc/gcc/m3cg?  This has a CVS directory, while
> gcc-4.5 and gcc-4.7 do not, and m3-sys/m3cc-old doesn't sound promising.
> 
> Does it work the same way for all the files in m3cg?
> 
> On 07/01/2013 08:48 PM, Jay K wrote:
> > There is one parse.c for several gcc forks. It is copied or linked by m3makefile.
> >
> > - Jay
> >
> >  > Date: Mon, 1 Jul 2013 17:40:41 -0500
> >  > From: rodney_bates at lcwb.coop
> >  > To: m3devel at elegosoft.com
> >  > Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg?
> >  >
> >  >
> >  > After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see
> >  >
> >  > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll
> >  > total 792
> >  > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in
> >  > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt
> >  > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h
> >  > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h
> >  > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h
> >  > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h
> >  > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h
> >  > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h
> >  > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in
> >  > -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c
> >  > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~
> >  > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~
> >  > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp
> >  >
> >  > where parse.c is changed.
> >  >
> >  > When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and
> >  >
> >  > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l
> >  > total 1944
> >  > -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o
> >  > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c
> >  > ../../gcc-4.7/gcc/m3cg/parse.c
> >  >
> >  > But parse.o has not changed (I can verify this by running gdb on cm3cg), and:
> >  >
> >  > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll
> >  > total 792
> >  > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in
> >  > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt
> >  > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h
> >  > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h
> >  > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h
> >  > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h
> >  > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h
> >  > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h
> >  > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in
> >  > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c
> >  > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~
> >  > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~
> >  > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp
> >  >
> >  > My edits to parse.c have been undone! If I recreate the edited parse.c,
> >  > then chmod 444 parse.c and recompile, it has no effect. parse.c still
> >  > gets changed back to the unedited version.
> >  >
> >  > Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory
> >  > (I have no idea how long this has been the case), and I have not been able
> >  > to get cvs to admit to having any awareness of this directory or anything in it,
> >  > using cvs log, cvs update or cvs checkout. I even tried manually creating a
> >  > CVS subdirectory, but without getting cvs to tell me something about its current
> >  > version number of parse.c, I can't create a line in CVS/Entries for it, and cvs
> >  > continues to claim total ignorance of this file.
> >  >
> >  > What is going on here? Is parse.c (and all of m3cg) being automatically created?
> >  > From where?
> >  >
> >  > cvs update -P does not remove m3cg, BTW.
> >  >
> >  >
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130703/dc419210/attachment-0002.html>


More information about the M3devel mailing list