<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'> Yes, there is just one copy of the directory. <br> Look in m3cc/src/m3makefile. <br> Sometimes maybe a prefix is copied followed by the rest of the file, e.g. <BR> <BR> <BR> #define GCC47 <br> ... contents of parse.c ... <BR> <BR> <BR> The #defines have a mix of meanings. <br> GCC12 might mean exactly GCC 1.2, or it might mean 1.2 or newer. <br> And there is GCC_APPLE, which goes along with gcc 4.2.<BR> <BR><br> I'm sorry about that. <br> It could/should be cleaned up. <BR> <BR><br> If you really want, consider some things: <BR> <BR><br> 1) make entire copies of the file <br> 2) split the file up and copy some of them, while keeping others identical <BR> <BR><br>Most of the code is indeed identical. <br> So I don't like #1. <br> In the case of #2, the bulk of the content would remain where it is, in the one parse.c, <br> so history would be reasonable. <BR> <BR><br> Preserving history is of some concern, <br> but CVS works poorly enough, and perhaps we renamed the directories in the past, <br> so I'd be ok with having to jump around to trace history accurately. <BR> <BR><br> Or leave things mostly asis. <BR> <BR><br> And/or cleanup the meanings or "granularity" of the #defines. <br> And/or drop support for all but the latest? <BR> <BR><br> I didn't get around to moving every target forward. <br> Mainline gcc does not support OpenBSD for example, so I/we always have <br> to do at least a tiny bit of work there. <br> The OpenBSD ports/packages system does maintain patches for gcc. <br> Many are outside the backend, and they are all trivial, stuff like picking size_t <br> and pre-#definining __OpenBSD__ or such. <br> Interix also requires moving small non-Modula-3 patches forward.<br> iPhone/ARM_DARWIN would remain at 4.2 also, probably.<br> I got as far there as starting up the compiler, which is pretty far.<BR> <BR><br> I have a number of times edited the wrong file only to have it overwritten by m3makefile. <br> That is an unfortunate fallout of this scheme. <BR> <BR><br> But, as I said, most of the contents of the file are portable across several gcc versions. <BR><br> <BR> Hopefully I'll back to the C backend and moot this.. :(<BR> <BR><br> Anyway, if you look at the source and CVS, it should be /reasonably/ clear.<br> I don't know/remember what m3cc-old is.<BR> <BR> <BR>There is some pain around "GTY".<BR>The syntax for it changed across gcc versions, like GTY struct foo vs. struct GTY foo or struct foo GTY.<BR>This is the annotation you put on types for the gcc garbage collector.<BR>So for that I did split a little bit of content into a different file.<BR> <BR><br> - Jay<br><br><br><br><br> <BR><div>> Date: Tue, 2 Jul 2013 09:31:26 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: jay.krell@cornell.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg?<br>> <br>> OK. Is it the one in m3-sys/m3cc/gcc/gcc/m3cg? This has a CVS directory, while<br>> gcc-4.5 and gcc-4.7 do not, and m3-sys/m3cc-old doesn't sound promising.<br>> <br>> Does it work the same way for all the files in m3cg?<br>> <br>> On 07/01/2013 08:48 PM, Jay K wrote:<br>> > There is one parse.c for several gcc forks. It is copied or linked by m3makefile.<br>> ><br>> > - Jay<br>> ><br>> > > Date: Mon, 1 Jul 2013 17:40:41 -0500<br>> > > From: rodney_bates@lcwb.coop<br>> > > To: m3devel@elegosoft.com<br>> > > Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg?<br>> > ><br>> > ><br>> > > After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see<br>> > ><br>> > > rodney@allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll<br>> > > total 792<br>> > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in<br>> > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt<br>> > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h<br>> > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h<br>> > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h<br>> > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h<br>> > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h<br>> > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h<br>> > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in<br>> > > -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c<br>> > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~<br>> > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~<br>> > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp<br>> > ><br>> > > where parse.c is changed.<br>> > ><br>> > > When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and<br>> > ><br>> > > rodney@allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l<br>> > > total 1944<br>> > > -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o<br>> > > rodney@allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c<br>> > > ../../gcc-4.7/gcc/m3cg/parse.c<br>> > ><br>> > > But parse.o has not changed (I can verify this by running gdb on cm3cg), and:<br>> > ><br>> > > rodney@allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll<br>> > > total 792<br>> > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in<br>> > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt<br>> > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h<br>> > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h<br>> > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h<br>> > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h<br>> > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h<br>> > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h<br>> > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in<br>> > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c<br>> > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~<br>> > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~<br>> > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp<br>> > ><br>> > > My edits to parse.c have been undone! If I recreate the edited parse.c,<br>> > > then chmod 444 parse.c and recompile, it has no effect. parse.c still<br>> > > gets changed back to the unedited version.<br>> > ><br>> > > Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory<br>> > > (I have no idea how long this has been the case), and I have not been able<br>> > > to get cvs to admit to having any awareness of this directory or anything in it,<br>> > > using cvs log, cvs update or cvs checkout. I even tried manually creating a<br>> > > CVS subdirectory, but without getting cvs to tell me something about its current<br>> > > version number of parse.c, I can't create a line in CVS/Entries for it, and cvs<br>> > > continues to claim total ignorance of this file.<br>> > ><br>> > > What is going on here? Is parse.c (and all of m3cg) being automatically created?<br>> > > From where?<br>> > ><br>> > > cvs update -P does not remove m3cg, BTW.<br>> > ><br>> > ><br>> <br></div> </div></body>
</html>