<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I tried getting C to error this way, and failed.<BR>
It looks like C uses COMPONENT_REF here, which will send it down different paths I didn't follow.<BR>
COMPONENT_REF makes sense for it and only somewhat sense for us.<BR>
That would involve declaring all of a module's globals a struct, which I don't believe we currently do but might be good. I think there's a basic disconnect in that in C, bitfields are always fields, never freestanding. Modula-3 rather violates that. Seems a little dangerous therefore to be using them this way?<BR>
<BR>
In terms of the inefficient option in parse.c, that would maybe go away, as all the offseting would be handled by the next level down, like, implementation of fields?<BR>
Well..that is assuming the only use offset != 0 in m3_load is for accessing module globals. I don't know if that is true.<BR>
<BR>
Maybe another option, should be easy to implement but might compile slowly, is to cons up a field decl right there in m3_load/store? That would lead to a lot of extra nodes -- per access instead of declared once. I can try that out.<BR>
<BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<BR>
From: jay.krell@cornell.edu<BR>To: hosking@cs.purdue.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: RE: [M3devel] m3_load/m3_store/bit_field_ref lose offset??<BR>Date: Sat, 13 Dec 2008 18:03:08 +0000<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
I've just spent a few hours debugging this.<BR> <BR>The problem is strongly related to the declaration that the global segment is of size BIGGEST_ALIGNMENT.<BR>gcc decides they can fit in a register..so then it doesn't bother adding the offset to the address, something like that.<BR> <BR>When things work, it goes here:<BR> op0 = adjust_address (op0, mode1, offset); <BR>in expr.c. When things don't work, that line is skipped and then shortly below that:<BR> <BR> if (mode1 != mode)<BR> return convert_to_mode (tmode, op0, unsignedp);<BR> return op0; << <BR><BR>On systems where BIGGEST_ALIGNMENT fits in a register, e.g. apparently MIPS, counter-e.g. apparently many others, but not clearly all others. This determines whether the mode of the segment is SImode (32bit integer), DImode (64bit integer) or BLKmode (larger than any machine type?). BLKmode works. It works on 32bit MIPS because between mode1 and mode, one of them is SImode, one is DImode. On x86/AMD64/PowerPC systems, I expect it is BLKmode, since biggest alignment is set very large -- 128. I don't know why it works for SPARC.<BR> <BR>PERHAPS I can put together a C or treelang example and get more (gcc developers) eyes on it, but I doubt it.<BR> <BR>The following hack works around it:<BR> <BR>C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\m3cg>cvs -z3 diff parse.c<BR>Index: parse.c<BR>===================================================================<BR>RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v<BR>retrieving revision 1.77<BR>diff -r1.77 parse.c<BR>2865c2865<BR>< = m3_build_type (T_struct, BIGGEST_ALIGNMENT, BIGGEST_ALIGNMENT);<BR>---<BR>> = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT);<BR> <BR>The repro is very easy.<BR>Just add this to m3core:<BR> <BR>MODULE Main2 EXPORTS Main;<BR>IMPORT RTIO;<BR>VAR a := "a";<BR>BEGIN<BR> RTIO.PutText(a);<BR>END Main2.<BR><BR>The load of a will be from MM_Main2 offset 0, instead of 104 or thereabouts.<BR> <BR>I'll commit this shortly.<BR> <BR> - Jay<BR><BR><BR>
<HR id=EC_stopSpelling>
<BR>
<BR>From: jay.krell@cornell.edu<BR>To: hosking@cs.purdue.edu<BR>Date: Thu, 13 Nov 2008 00:04:32 +0000<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] m3_load/m3_store/bit_field_ref lose offset??<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
> Jay, do you have access to an AMD64_DARWIN box?<BR> <BR>No, sorry, I don't yet and not sure when I will.<BR>Unless it is easy enough to run on non-Apple hardware.<BR>I'll have to debug it (m3cg) then.<BR> <BR> - Jay<BR><BR><BR><BR><BR>
<HR id=EC_EC_stopSpelling>
<BR>
<BR><BR>CC: m3devel@elegosoft.com<BR>From: hosking@cs.purdue.edu<BR>To: jay.krell@cornell.edu<BR>Subject: Re: [M3devel] m3_load/m3_store/bit_field_ref lose offset??<BR>Date: Wed, 12 Nov 2008 20:46:53 +0000<BR><BR>Jay, do you have access to an AMD64_DARWIN box? I did get things working on that 64-bit platform. Or is it an endianness issue you are dealing with. In any case, I will not have a lot of bandwidth for doing much in the way of tackling this unless it becomes critical path for me soon.<BR><BR><BR>
<DIV><BR>
<DIV>
<DIV><SPAN class=EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word"><SPAN class=EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV><FONT class=EC_EC_EC_Apple-style-span color=#0000ff><FONT class=EC_EC_EC_Apple-style-span face="Gill Sans"><SPAN class=EC_EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans"><SPAN class=EC_EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans">Antony Hosking</SPAN></SPAN></FONT></FONT><FONT class=EC_EC_EC_Apple-style-span face="Gill Sans"><SPAN class=EC_EC_EC_Apple-style-span style="FONT-FAMILY: Gill Sans"><SPAN class=EC_EC_EC_Apple-style-span style="FONT-FAMILY: Gill Sans"> | </SPAN></SPAN><SPAN class=EC_EC_EC_Apple-style-span style="FONT-FAMILY: Gill Sans"><SPAN class=EC_EC_EC_Apple-style-span style="FONT-FAMILY: Gill Sans">Associate Professor</SPAN></SPAN><SPAN class=EC_EC_EC_Apple-style-span style="FONT-FAMILY: Gill Sans"><SPAN class=EC_EC_EC_Apple-style-span style="FONT-FAMILY: Gill Sans"> | Computer Science | Purdue University</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=EC_EC_EC_Apple-style-span face=GillSans-Light><SPAN class=EC_EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light">305 N. University Street | West Lafayette | IN 47907 | USA</SPAN></FONT></DIV>
<DIV><FONT class=EC_EC_EC_Apple-style-span face="Gill Sans" color=#0000ff><SPAN class=EC_EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans"><SPAN class=EC_EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans">Office</SPAN></SPAN></FONT><FONT class=EC_EC_EC_Apple-style-span face=GillSans-Light><SPAN class=EC_EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"><SPAN class=EC_EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"> +1 765 494 6001 | </SPAN></SPAN></FONT><FONT class=EC_EC_EC_Apple-style-span face="Gill Sans" color=#0000ff><SPAN class=EC_EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans"><SPAN class=EC_EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans">Mobile</SPAN></SPAN></FONT><FONT class=EC_EC_EC_Apple-style-span face=GillSans-Light><SPAN class=EC_EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"><SPAN class=EC_EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"> +1 765 427 5484</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=EC_EC_EC_Apple-style-span face=GillSans-Light><BR class=EC_EC_EC_khtml-block-placeholder></FONT></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN><BR class=EC_EC_EC_Apple-interchange-newline></SPAN></DIV></SPAN></DIV><BR>
<DIV>
<DIV>On 12 Nov 2008, at 07:57, Jay wrote:</DIV><BR class=EC_EC_EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_EC_EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Target.Little_endian is used to drive some target-specificity in the IR.<BR> I guess, after all, that is why you have to specify it.<BR> <BR>The IR for RTLinker.m3 is identical for MIPS64_OPENBSD and SPARC64_SOLARIS, once I set them both to unaligned_procedures, which they both need. (Tangent, I ran m3cgcat on the .ms file a few times instead of the .mc file; that makes it crash.)<BR> <BR>I can't claim SPARC64_SOLARIS is any paragon of working and correct though, by far.<BR>I should also be able to compare with SPARC64_OPENBSD, I forgot about that, and didn't have an m3cg.<BR>I only ran SPARC64_SOLARIS far enough to discover it needed unaligned procedures.<BR>I think I should fork linux-common and solaris-common off of the minimal 29k openbsd-common, rather than worry about all the stuff in solaris-2-x and linux-libc, over 100k each. Then SPARC64_SOLARIS could/would be in better shape probably.<BR> <BR>MIPS64_OPENBSD cm3 gets further with unaligned_procedures, along with the parse.c fix -- it gets to a bus error in RunMainBody.<BR>Again an alignment problem, though I think maybe memory memory trashing.<BR>The fault occurs here:<BR> <BR> desc_offset := init_depth * ADRSIZE (InitDesc);<BR><BR> desc := init_stack + desc_offset;<BR> init_depth := desc.low_link; <<<SPAN class=EC_EC_EC_Apple-converted-space> </SPAN><BR><BR> InitDesc = RECORD<BR> module : RT0.ModulePtr;<BR> low_link : INTEGER;<BR> END;<BR><BR>desc_offset appears to not be a multiple of 4.<BR> <BR>I will look into that.<BR> <BR>Long story short -- consider again the parse.c change?<BR>I admit I still haven't debugged it (or rather, the code that consumes the data produced by it).<BR> <BR> - Jay<BR><BR><BR>
<HR id=EC_EC_EC_stopSpelling>
<BR>From:<SPAN class=EC_EC_EC_Apple-converted-space> </SPAN><A href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</A><BR>To:<SPAN class=EC_EC_EC_Apple-converted-space> </SPAN><A href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</A><BR>CC:<SPAN class=EC_EC_EC_Apple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>Subject: RE: [M3devel] m3_load/m3_store/bit_field_ref lose offset??<BR>Date: Sun, 9 Nov 2008 11:10:54 +0000<BR><BR>I agree. I am suspicious too. I will investigate more. Thanks.<BR> <BR> - Jay<BR><BR><BR>
<HR id=EC_EC_EC_EC_stopSpelling>
<BR><BR>From:<SPAN class=EC_EC_EC_Apple-converted-space> </SPAN><A href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</A><BR>To:<SPAN class=EC_EC_EC_Apple-converted-space> </SPAN><A href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</A><BR>Date: Sun, 9 Nov 2008 10:01:58 +0000<BR>CC:<SPAN class=EC_EC_EC_Apple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>Subject: Re: [M3devel] m3_load/m3_store/bit_field_ref lose offset??<BR><BR><BR><BR>
<DIV>Aren't the integer values supposed to be written endian-independently in the IR? I am suspicious about these differences.</DIV>
<DIV><SPAN class=EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word"><SPAN class=EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV><BR></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></DIV>
<DIV>
<DIV>On 9 Nov 2008, at 01:25, Jay wrote:</DIV><BR class=EC_EC_EC_EC_EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_EC_EC_EC_EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Thanks for the tip/direction.<BR> <BR>Uncertain -- m3cgcat between AMD64_LINUX and MIPS64_OPENBSD are "the same" but for two systematic diffs:<BR> <BR> - AMD64_LINUX has a bunch of added calls to check_nil.<BR> This is a "bug" in it, inoptimal but ok code, because "first readable address" is 0. It should probably be 4k. I should write a program that iterates starting at 0 to find the value.<BR> (or better yet, cm3 should have a -configure option that does this? -- for configuration values for which there is a safe default; in general, imho, the targets should be auto configured via C, assuming there is a native development environment available).<BR> <BR> - some integers are different (again, systematically)<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN><BR> <BR>AMD64_LINUX:<BR> init_int 656 13 Int.64<BR> init_chars 664 " typecode "<BR> init_int 680 2 Int.64<BR> init_var 688 v.1 0<BR> init_int 696 13 Int.64<BR> init_chars 704 " typeid "<BR> init_int 720 2 Int.64<BR> init_var 728 v.1 0<BR> init_int 736 13 Int.64<BR> init_chars 744 "RunMainBody: "<BR> init_int 760 2 Int.64<BR> init_var 768 v.1 0<BR> init_int 776 19 Int.64<BR> init_chars 784 "RunMainBody: exec: "<BR> init_int 808 2 Int.64<BR> init_var 816 v.1 0<BR> init_int 824 17 Int.64<BR> init_chars 832 "ExpandInitStack: "<BR><BR>MIPS64_OPENBSD:<BR> <BR> init_chars 664 " typecode "<BR> init_int 680 8796093022208 Int.64<BR> init_var 688 v.1 0<BR> init_int 696 13 Int.64<BR> init_chars 704 " typeid "<BR> init_int 720 8796093022208 Int.64<BR> init_var 728 v.1 0<BR> init_int 736 13 Int.64<BR> init_chars 744 "RunMainBody: "<BR> init_int 760 8796093022208 Int.64<BR> init_var 768 v.1 0<BR> init_int 776 19 Int.64<BR> init_chars 784 "RunMainBody: exec: "<BR> init_int 808 8796093022208 Int.64<BR> init_var 816 v.1 0<BR><BR>This 8796093022208 is 80000000000 aka 0000_0800_0000_0000, where little endian has 2.<BR> <BR>I don't know what these numbers represent.<BR>I should look at other systems -- preferably a working 64 bit big endian system, if there are any.<BR> <BR>Could be flags/type with text literals?<BR> <BR>(Btw, I always leave the TextLiteral.i3 change on my system, lowering the maximum literal length to around 4gig even on 64 bit targets, so 32 bit can bootstrap 64 bit...need to fix the compiler here to do target arithmetic instead of host arithmetic...)<BR> <BR>Thanks,<BR> - Jay<BR><BR>
<HR id=EC_EC_EC_EC_EC_stopSpelling>
<BR>From:<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN><A href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</A><BR>To:<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN><A href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</A><BR>Date: Sat, 8 Nov 2008 22:55:54 +0000<BR>CC:<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>Subject: Re: [M3devel] m3_load/m3_store/bit_field_ref lose offset??<BR><BR>Have you checked to make sure that the pre-gcc IR makes sense? Does it see these values as 32-bit or 64-bit? The reason I ask is that there may be something wrong in your m3middle target specs that cause bad IR. Once we know the IR looks right then we can try and fix the problem.<BR>
<DIV><BR>
<DIV><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV><FONT class=EC_EC_EC_EC_EC_EC_Apple-style-span color=#0000ff><FONT class=EC_EC_EC_EC_EC_EC_Apple-style-span face="Gill Sans"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: 'Gill Sans'"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: 'Gill Sans'">Antony Hosking</SPAN></SPAN></FONT></FONT><FONT class=EC_EC_EC_EC_EC_EC_Apple-style-span face="Gill Sans"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="FONT-FAMILY: 'Gill Sans'"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="FONT-FAMILY: 'Gill Sans'"><SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN>|<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN></SPAN></SPAN><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="FONT-FAMILY: 'Gill Sans'"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="FONT-FAMILY: 'Gill Sans'">Associate Professor</SPAN></SPAN><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="FONT-FAMILY: 'Gill Sans'"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="FONT-FAMILY: 'Gill Sans'"> | Computer Science | Purdue University</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=EC_EC_EC_EC_EC_EC_Apple-style-span face=GillSans-Light><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light">305 N. University Street | West Lafayette | IN 47907 | USA</SPAN></FONT></DIV>
<DIV><FONT class=EC_EC_EC_EC_EC_EC_Apple-style-span face="Gill Sans" color=#0000ff><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: 'Gill Sans'"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: 'Gill Sans'">Office</SPAN></SPAN></FONT><FONT class=EC_EC_EC_EC_EC_EC_Apple-style-span face=GillSans-Light><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"> +1 765 494 6001 |<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN></SPAN></SPAN></FONT><FONT class=EC_EC_EC_EC_EC_EC_Apple-style-span face="Gill Sans" color=#0000ff><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: 'Gill Sans'"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: 'Gill Sans'">Mobile</SPAN></SPAN></FONT><FONT class=EC_EC_EC_EC_EC_EC_Apple-style-span face=GillSans-Light><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"><SPAN class=EC_EC_EC_EC_EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"><SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN>+1 765 427 5484</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=EC_EC_EC_EC_EC_EC_Apple-style-span face=GillSans-Light><BR class=EC_EC_EC_EC_EC_EC_khtml-block-placeholder></FONT></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN><BR class=EC_EC_EC_EC_EC_EC_Apple-interchange-newline></SPAN></DIV></SPAN></DIV><BR>
<DIV>
<DIV>On 8 Nov 2008, at 15:45, Jay wrote:</DIV><BR class=EC_EC_EC_EC_EC_EC_Apple-interchange-newline>
<BLOCKQUOTE>
<DIV><BR>truncated as usual...along with losing a lot of whitespace..<BR>Let's see...<BR><BR><BR>Tony, how about switching these #if's?<BR>I explain some of why below.<BR><BR>static void<BR>m3_store (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T)<BR>{<BR> tree val;<BR>#if 0<BR> if (o != 0 || TREE_TYPE (v) != dst_t) {<BR> v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),<BR> bitsize_int (o));<BR> }<BR>#else<BR> /* failsafe, but inefficient */<BR> if (o != 0 || TREE_TYPE (v) != dst_t) {<BR> v = m3_build1 (ADDR_EXPR, t_addr, v);<BR> v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));<BR> v = m3_build1 (INDIRECT_REF, dst_t,<BR> m3_cast (build_pointer_type (dst_t), v));<BR> }<BR>#endif<BR> TREE_THIS_VOLATILE (v) = 1; /* force this to avoid aliasing problems */<BR> val = m3_cast (src_t, EXPR_REF (-1));<BR> if (src_T != dst_T) {<BR> val = m3_build1 (CONVERT_EXPR, dst_t, val);<BR> }<BR> add_stmt (build2 (MODIFY_EXPR, dst_t, v, val));<BR> EXPR_POP ();<BR>}<BR>m3_load (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T)<BR>{<BR>#if 0<BR> if (o != 0 || TREE_TYPE (v) != src_t) {<BR> v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),<BR> bitsize_int (o));<BR> }<BR>#else<BR> /* failsafe, but inefficient */<BR> if (o != 0 || TREE_TYPE (v) != src_t) {<BR> v = m3_build1 (ADDR_EXPR, t_addr, v);<BR> v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));<BR> v = m3_build1 (INDIRECT_REF, src_t,<BR> m3_cast (build_pointer_type (src_t), v));<BR> }<BR>#endif<BR> TREE_THIS_VOLATILE (v) = 1; /* force this to avoid aliasing problems */<BR> if (src_T != dst_T) {<BR> v = m3_build1 (CONVERT_EXPR, dst_t, v);<BR> }<BR> EXPR_PUSH (v);<BR>}<BR><BR>I'm working on MIPS64_OPENBSD (OpenBSD on an SGI O2).<BR>In an early version it seems that many loads/stores of global variables is wrong.<BR>The "first" code affected is RTLinker_ExpandModuleTable.<BR><BR>PROCEDURE ExpandModuleTable () =<BR> CONST InitialTableSize = 500;<BR> VAR new_mods: ADDRESS; n_bytes: INTEGER;<BR> BEGIN<BR> IF (modules = NIL) THEN<BR> (* first time... *)<BR> max_modules := InitialTableSize;<BR> modules := Cstdlib.malloc (InitialTableSize * BYTESIZE (RT0.ModulePtr));<BR> IF (modules = NIL) THEN Cstdlib.abort (); END;<BR> ELSE<BR> n_bytes := max_modules * BYTESIZE (RT0.ModulePtr);<BR> new_mods := Cstdlib.malloc (n_bytes + n_bytes);<BR> IF (new_mods = NIL) THEN Cstdlib.abort (); END;<BR> EVAL Cstring.memcpy (new_mods, modules, n_bytes);<BR> Cstdlib.free (modules);<BR> modules := new_mods;<BR> INC (max_modules, max_modules);<BR> END;<BR> END ExpandModuleTable;<BR><BR>It should read back modules as NIL.<BR>What happens is it reads back modules as not NIL,<BR>and then max_modules should also be zero, but is "large", leading to malloc to fail,<BR>and abort called.<BR><BR>The output of cm3cg -y is reasonable.<BR>It indicates offset loads.<BR><BR>What is incorrect is that in many loads and stores, but not all, the<BR>offsets are lost.<BR><BR>(923) begin_procedure<BR> procedure RTLinker__ExpandModuleTable<BR>RTLinker__ExpandModuleTable(924) set_source_line<BR> source line 208<BR>(925) load_nil<BR>(926) store<BR> store (M3_AJWxb1_new_mods) offset 0x0 src_t 0xb dst_t 0xb<BR>(927) set_source_line<BR> source line 207<BR>(928) set_source_line<BR> source line 210<BR>(929) load_nil<BR>(930) load<BR> m3cg_load (MM_RTLinker): offset 0x440, convert 0xb -> 0xb<BR><BR>Here is the incorrect code:<BR><BR>.globl RTLinker__ExpandModuleTable<BR>.stabd 46,0,0<BR>.stabn 68,0,206,.LM108<BR>.LM108:<BR>.LFBB8:<BR>.set nomips16<BR>.ent RTLinker__ExpandModuleTable<BR>RTLinker__ExpandModuleTable:<BR>.frame $fp,64,$31 # vars= 32, regs= 3/0, args= 0, gp= 0<BR>.mask 0xd0000000,-8<BR>.fmask 0x00000000,0<BR>daddiu $sp,$sp,-64<BR>sd $31,56($sp)<BR>sd $fp,48($sp)<BR>sd $28,40($sp)<BR>move $fp,$sp<BR>lui $28,%hi(%neg(%gp_rel(RTLinker__ExpandModuleTable)))<BR>daddu $28,$28,$25<BR>daddiu $28,$28,%lo(%neg(%gp_rel(RTLinker__ExpandModuleTable)))<BR>.LBB9:<BR>.stabn 68,0,208,.LM109<BR>.LM109:<BR>sd $0,16($fp)<BR>.stabn 68,0,210,.LM110<BR>.LM110:<BR>dla $2,MM_RTLinker<BR>ld $2,0($2) << WRONG<BR>bne $2,$0,.L61<BR>.stabn 68,0,212,.LM111<BR>.LM111:<BR>dla $3,MM_RTLinker<BR>ld $2,128($3)<BR>andi $2,$2,0x0<BR>ori $2,$2,0x1f4<BR>sd $2,128($3)<BR>.stabn 68,0,213,.LM112<BR>.LM112:<BR>li $4,4000 # 0xfa0<BR>jal malloc<BR>sd $2,0($fp)<BR>ld $4,0($fp)<BR>dla $3,MM_RTLinker<BR>ld $2,136($3)<BR>andi $2,$2,0x0<BR>or $2,$4,$2<BR>sd $2,136($3) << OK, offset seems low, but it agrees with elsewhere<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>.stabn 68,0,214,.LM113<BR>.LM113:<BR>dla $2,MM_RTLinker<BR>ld $2,0($2) << WRONG<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>bne $2,$0,.L65<BR>jal abort<BR>b .L65<BR>.L61:<BR>.stabn 68,0,216,.LM114<BR>.LM114:<BR>dla $2,MM_RTLinker<BR>ld $2,0($2) << WRONG<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>dsll $2,$2,3<BR>sd $2,8($fp)<BR>.stabn 68,0,217,.LM115<BR>.LM115:<BR>ld $3,8($fp)<BR>ld $2,8($fp)<BR>daddu $2,$3,$2<BR>move $4,$2<BR>jal malloc<BR>sd $2,0($fp)<BR>ld $2,0($fp)<BR>sd $2,16($fp)<BR>.stabn 68,0,218,.LM116<BR>.LM116:<BR>ld $2,16($fp)<BR>bne $2,$0,.L64<BR>jal abort<BR>.L64:<BR>.stabn 68,0,219,.LM117<BR>.LM117:<BR>ld $4,16($fp)<BR>dla $2,MM_RTLinker<BR>ld $2,0($2) << WRONG<BR>ld $3,8($fp)<BR>move $5,$2<BR>move $6,$3<BR>jal memcpy<BR>sd $2,0($fp)<BR>.stabn 68,0,220,.LM118<BR>.LM118:<BR>dla $2,MM_RTLinker<BR>ld $2,0($2) << WRONG<BR>move $4,$2<BR>jal free<BR>.stabn 68,0,221,.LM119<BR>.LM119:<BR>ld $4,16($fp)<BR>dla $3,MM_RTLinker<BR>ld $2,136($3) << OK<BR>andi $2,$2,0x0<BR>or $2,$4,$2<BR>sd $2,136($3) << OK<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>.stabn 68,0,222,.LM120<BR>.LM120:<BR>dla $2,MM_RTLinker<BR>ld $3,0($2) << WRONG<BR>dla $2,MM_RTLinker<BR>ld $2,0($2) << WRONG<BR>daddu $4,$3,$2<BR>dla $3,MM_RTLinker<BR>ld $2,128($3) << OK<BR>andi $2,$2,0x0<BR>or $2,$2,$4<BR>sd $2,128($3) << OK<BR>.L65:<BR>.LBE9:<BR>.stabn 68,0,224,.LM121<BR>.LM121:<BR>move $sp,$fp<BR>ld $31,56($sp)<BR>ld $fp,48($sp)<BR>ld $28,40($sp)<BR>daddiu $sp,$sp,64<BR>j $31<BR>.end RTLinker__ExpandModuleTable<BR><BR>Here is corrected code:<BR><BR>RTLinker__ExpandModuleTable:<BR>.frame $fp,64,$31 # vars= 32, regs= 3/0, args= 0, gp= 0<BR>.mask 0xd0000000,-8<BR>.fmask 0x00000000,0<BR>daddiu $sp,$sp,-64<BR>sd $31,56($sp)<BR>sd $fp,48($sp)<BR>sd $28,40($sp)<BR>move $fp,$sp<BR>lui $28,%hi(%neg(%gp_rel(RTLinker__ExpandModuleTable)))<BR>daddu $28,$28,$25<BR>daddiu $28,$28,%lo(%neg(%gp_rel(RTLinker__ExpandModuleTable)))<BR>.LBB9:<BR>.stabn 68,0,208,.LM109<BR>.LM109:<BR>sd $0,16($fp)<BR>.stabn 68,0,210,.LM110<BR>.LM110:<BR>dla $2,MM_RTLinker<BR>daddiu $2,$2,136 << CORRECT (offset seems low, but at least it isn't zero)<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>ld $2,0($2)<BR>bne $2,$0,.L61<BR>.stabn 68,0,212,.LM111<BR>.LM111:<BR>dla $2,MM_RTLinker<BR>daddiu $3,$2,128 << CORRECT<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>li $2,500 # 0x1f4<BR>sd $2,0($3)<BR>.stabn 68,0,213,.LM112<BR>.LM112:<BR>li $4,4000 # 0xfa0<BR>jal malloc<BR>sd $2,0($fp)<BR>dla $2,MM_RTLinker<BR>daddiu $3,$2,136 << CORRECT<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>ld $2,0($fp)<BR>sd $2,0($3)<BR>.stabn 68,0,214,.LM113<BR>.LM113:<BR>dla $2,MM_RTLinker<BR>daddiu $2,$2,136 << CORRECT<SPAN class=EC_EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>ld $2,0($2)<BR>bne $2,$0,.L65<BR>jal abort<BR>b .L65<BR>.L61:<BR><BR>I still dump core with this change, but I get much further.<BR>I have not tested this change at all otherwise -- i.e. on working platforms.<BR><BR>I have not debugged through the gcc/m3cg code to see why<BR>the offsets are only sometimes lost, or why other platforms<BR>have no problem. Is MIPS's "global pointer" unusual these days?<BR>I know SPARC has similar, and all the non-x86, non-AMD64 NT platforms<BR>had similar, but that's essentially nothing now (I'm not counting IA64).<BR>I know Linux has PLT (procedure linkage table) and GOT (global offset table).<BR>Same thing?<BR>I haven't looked much at other MIPS ports yet.<BR><BR><A href="http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.7;r2=1.8">http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.7;r2=1.8</A><BR><BR>is what made it look about like it does -- in particularing using BIT_FIELD_REF.<BR><BR>1.7:<BR><BR>static void m3_load (v, o, src_t, src_T, dest_t, dest_T) /* GCC32OK */<BR> tree v;<BR> int o;<BR> tree src_t, dest_t;<BR> m3_type src_T, dest_T;<BR>{<BR> if (o == 0 && TREE_TYPE (v) == src_t) {<BR> EXPR_PUSH (v);<BR> } else {<BR> tree adr = m3_build1 (ADDR_EXPR, t_addr, v);<BR> if (o != 0) {<BR> adr = m3_build2 (PLUS_EXPR, t_addr, adr, size_int (o / BITS_PER_UNIT));<BR> }<BR> EXPR_PUSH (m3_build1 (INDIRECT_REF, src_t,<BR> m3_cast (build_pointer_type (src_t), adr)));<BR> }<BR>#if 1<BR> if (src_T != dest_T) {<BR> EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, dest_t, EXPR_REF (-1));<BR> }<BR> if (debug_vars) {<BR> const char *name = "noname";<BR> if (v != 0 && DECL_NAME(v) != 0) {<BR> name = IDENTIFIER_POINTER(DECL_NAME(v));<BR> }<BR> fprintf(stderr, " m3_load (%s): offset %d, convert %d -> %d\n", name,<BR> o, src_T, dest_T);<BR> }<BR>#else<BR> if (src_T != dest_T) {<BR> if (IS_INTEGER_TYPE(dest_T) && dest_t != t_int) {<BR> EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t_int, EXPR_REF (-1));<BR> } else if (IS_WORD_TYPE(dest_T) && dest_t != t_word) {<BR> EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t_word, EXPR_REF (-1));<BR> } else if (IS_INTEGER_TYPE(dest_T) || IS_WORD_TYPE(dest_T)) {<BR> /* okay */<BR> } else {<BR> fatal_error("m3load: cannot convert types: src_t %d dest_t %d\n",<BR> src_T, dest_T);<BR> }<BR> }<BR>#endif<BR>}<BR>static void<BR>m3_store (v, o, src_t, dest_t) /* GCC32OK */<BR> tree v;<BR> int o;<BR> tree src_t, dest_t;<BR>{<BR> tree lhs, rhs;<BR> if (TREE_TYPE (EXPR_REF (-1)) == src_t) {<BR> rhs = EXPR_REF (-1);<BR> } else {<BR> rhs = m3_cast (src_t, EXPR_REF (-1));<BR> }<BR> if (o == 0 && TREE_TYPE (v) == dest_t) {<BR> lhs = v;<BR> } else {<BR> tree f = make_node (FIELD_DECL);<BR> TREE_TYPE (f) = dest_t;<BR> DECL_ALIGN (f) = TYPE_ALIGN (dest_t);<BR> DECL_SIZE (f) = TYPE_SIZE (dest_t);<BR> DECL_MODE (f) = TYPE_MODE (dest_t);<BR> DECL_FIELD_OFFSET (f) = size_int (o / BITS_PER_UNIT);<BR> DECL_FIELD_BIT_OFFSET (f) = bitsize_int (o % BITS_PER_UNIT);<BR> DECL_FIELD_CONTEXT (f) = TREE_TYPE (v);<BR> lhs = m3_build2 (COMPONENT_REF, dest_t, v, f);<BR> }<BR>#if 1<BR> expand_assignment (lhs, m3_build1 (CONVERT_EXPR, dest_t, rhs), 0, 0);<BR>#else<BR> if (dest_t == NULL) {<BR> expand_assignment (lhs, rhs, 0, 0);<BR> } else {<BR> expand_assignment (lhs, m3_build1 (CONVERT_EXPR, dest_t, rhs), 0, 0);<BR> }<BR>#endif<BR> EXPR_POP ();<BR>}<BR><BR>1.8:<BR>static void<BR>m3_load (tree v, int o,<BR> tree src_t, m3_type src_T,<BR> tree dst_t, m3_type dst_T) /* GCC32OK */<BR>{<BR> if (o == 0 && TREE_TYPE (v) == src_t) {<BR> EXPR_PUSH (v);<BR> } else {<BR> EXPR_PUSH (m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),<BR> bitsize_int (o)));<BR> }<BR> if (src_T != dst_T) {<BR> EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, dst_t, EXPR_REF (-1));<BR> }<BR> if (option_vars_trace) {<BR> const char *name = "noname";<BR> if (v != 0 && DECL_NAME(v) != 0) {<BR> name = IDENTIFIER_POINTER(DECL_NAME(v));<BR> }<BR> fprintf(stderr, " m3_load (%s): offset %d, convert %d -> %d\n", name,<BR> o, src_T, dst_T);<BR> }<BR>}<BR>static void<BR>m3_store (tree v, int o, tree src_t, tree dst_t) /* GCC32OK */<BR>{<BR> tree lhs, rhs;<BR> if (TREE_TYPE (EXPR_REF (-1)) == src_t) {<BR> rhs = EXPR_REF (-1);<BR> } else {<BR> rhs = m3_cast (src_t, EXPR_REF (-1));<BR> }<BR> if (o == 0 && TREE_TYPE (v) == dst_t) {<BR> lhs = v;<BR> } else {<BR> lhs = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),<BR> bitsize_int (o));<BR> }<BR> if (src_t != dst_t) {<BR> rhs = m3_build1 (CONVERT_EXPR, dst_t, rhs);<BR> }<BR> expand_assignment (lhs, rhs, 0, 0);<BR> EXPR_POP ();<BR>}<BR><BR>- Jay<BR></DIV></BLOCKQUOTE></DIV><BR><SPAN><AMD64_LINUX_RTLinker.mc></SPAN><SPAN><MIPS64_OPENBSD_RTLinker.mc></SPAN></DIV></DIV></SPAN></BLOCKQUOTE></DIV><BR></DIV></SPAN><BR class=EC_EC_EC_Apple-interchange-newline></BLOCKQUOTE></DIV><BR></DIV></DIV></body>
</html>