<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'>Using a type with smaller alignment seems probably correct.<br><br> 1) The original authors were pretty good.<br> 2) So try to come up with a rationale that fits the existing code instead thinking through how we might write it from scratch. (Is this what people call "back filling"?) Really, I can't figure it out either from scratch, but I can maybe guess the thinking behind the existing code.<br>     Here is my guess: For example: I want to load a 32bit size 32bit aligned datum.<br>     I have available the ability to do load operation against a 32bit size 8 bit aligned datum.<br>     I can use that load operation on the more aligned data, as long as 32 mod 8 == 0.<br><br><br>For all I care, we could remove bitfields from the language entirely.<br>Make people use sets or bit operations with Word.<br>I don't like that I can't predict the layout of bitfields.<br>They currently introduce endian-dependentness, but we can fix that.<br><br><br>But I know the garbage collection runtime uses them for compactness.<br><br><br> - Jay<br><br><br><div>> Date: Wed, 25 Sep 2013 11:04:09 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] EXT:RE:  [M3commit] CVS Update: cm3<br>> <br>> I can reproduce this symptom on a LINUXLIBC6 system and got a small example<br>> constructed.  It does not happen on AMD64_LINUX, so is apparently word-size<br>> dependent.<br>> <br>> Jay's revert in CG.ScanTypes makes the problem go away here and elsewhere,<br>> so should help Randy get past this one.  But it does reintroduce the same<br>> symptom on different cases, involving packed fields with bit counts other<br>> than 8, 16, 32, and 64.<br>> <br>> Something seems very wrong, as ScanTypes is, as originally coded, looking<br>> for a type whose alignment is <= the requested alignment, not >=.  At least<br>> some of the requested alignment values are coming from a field commented as<br>> "(* minimum alignment in bits *)".  But then there are places that ask for<br>> 64-bit alignment on all targets.  Impossible to satisfy.<br>> <br>> I will keep my changes local until I get both groups of cases working on both<br>> word sizes.<br>> <br>> On 09/23/2013 06:03 PM, Coleburn, Randy wrote:<br>> > *Things go fine until I get to m3core.  I get an internal code generator error. *See error below:<br>> ><br>> > --- processing package "m3-libs\m3core" ---<br>> ><br>> > --- purging derived files from NT386 ---<br>> ><br>> > --- cleaning NT386 ---<br>> ><br>> > ignoring ..\src\m3overrides<br>> ><br>> > --- building in NT386 ---<br>> ><br>> > ignoring ..\src\m3overrides<br>> ><br>> > new source -> compiling RTHooks.i3<br>> ><br>> > new source -> compiling RT0.i3<br>> ><br>> > new source -> compiling RuntimeError.i3<br>> ><br>> > new source -> compiling WordRep.i3<br>> ><br>> > new source -> compiling Word.i3<br>> ><br>> > new source -> compiling RTException.i3<br>> ><br>> > new source -> compiling RTHooks.m3<br>> ><br>> > new source -> compiling RT0.m3<br>> ><br>> > new source -> compiling Compiler.i3<br>> ><br>> > new source -> compiling RuntimeError.m3<br>> ><br>> > new source -> compiling Compiler.m3<br>> ><br>> > new source -> compiling RTAllocator.i3<br>> ><br>> > new source -> compiling RTType.i3<br>> ><br>> > new source -> compiling RTHeapRep.i3<br>> ><br>> > new source -> compiling FloatMode.i3<br>> ><br>> > new source -> compiling RTThread.i3<br>> ><br>> > new source -> compiling Scheduler.i3<br>> ><br>> > new source -> compiling RTOS.i3<br>> ><br>> > new source -> compiling RTMisc.i3<br>> ><br>> > new source -> compiling Cstdlib.i3<br>> ><br>> > new source -> compiling Cstddef.i3<br>> ><br>> > new source -> compiling LongRep.i3<br>> ><br>> > new source -> compiling Long.i3<br>> ><br>> > new source -> compiling BasicCtypes.i3<br>> ><br>> > new source -> compiling Ctypes.i3<br>> ><br>> > new source -> compiling RTAllocCnts.i3<br>> ><br>> > new source -> compiling RTAllocator.m3<br>> ><br>> > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32  s/o/a=8/416/64<br>> ><br>> > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR *** unable to find integer type?  type=Word.32  s/o/a=8/416/64<br>> ><br>> > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR *** unable to find integer type?  type=Word.32  s/o/a=8/416/64<br>> ><br>> > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR *** unable to find integer type?  type=Word.32  s/o/a=8/416/64<br>> ><br>> > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR *** unable to find integer type?  type=Word.32  s/o/a=8/416/64<br>> ><br>> > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR *** unable to find integer type?  type=Word.32  s/o/a=8/416/64<br>> ><br>> > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR *** unable to find integer type?  type=Word.32  s/o/a=8/416/64<br>> ><br>> > 7 errors encountered<br>> ><br></div>                                       </div></body>
</html>