[M3devel] gcc 4.5 status

Mon Jun 28 13:31:36 CEST 2010

Hi:
ok, here is a good reference of type systems by Luca Cardelli, it is sort of familiar language with better conceptualization
http://lucacardelli.name/Papers/TypeSystems.pdf
Hope it helps and thanks for the answer let me know if the above paper is a proper clarification (I think it is, specially pages 1-4).
Thanks for the info, hope it helps 

--- El lun, 28/6/10, Jay K <jay.krell at cornell.edu> escribió:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] gcc 4.5 status
> Para: "Daniel (M3)" <dabenavidesd at yahoo.es>, "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de junio, 2010 03:08
> 
> Daniel, I'm afraid I generally don't understand much that
> you say.
> True, m3tools/m3tk should ideally follow the compiler's
> definition of ADR.
> Moving to gcc 4.5 has nothing to do with changing the
> meaning of ADR. Granted, I jump around a bit.
> 
> current/old ADR return ADDRESS, which is silently
> assignable to any UNTRACED REF type.
> new ADR(t) returns UNTRACED REF t.
> 
> Consider C.
> In C, void* is assignable to any pointer type. (not so in
> C++)
> In C, &T returns T*, not void*.
> So &T is NOT assignable to any pointer type, only T*
> and void*.
> 
> The idea here would be elevate unsafe Modula-3 to C's level
> of safety.
> Instead of being even less safe.
> 
> Despite the lack of safety, a certain amount of static
> checking is a good idea.
> 
> 
>  - Jay
> 
> ----------------------------------------
> > Date: Mon, 28 Jun 2010 02:37:11 +0000
> > From: dabenavidesd at yahoo.es
> > To: m3devel at elegosoft.com;
> jay.krell at cornell.edu
> > Subject: Re: [M3devel] gcc 4.5 status
> >
> > Hi all:
> > please let me investigate before you make the simple
> changes you are trying because as I understand the type of
> the ADR operator might be of an unsafe module but that
> doesn't mean you can hack it to do your program better
> compile (that would be like use an ill behaved program to
> make "well" behaved ones). I mean is good to discard that
> the type system (the set of sound type rules that make a
> program compile run and if safely guarded do its work
> flawlessly, that is, the set of safe and well behaved
> programs without ill behaved in there) is not "hacked" hard
> coded to expect the type of ADR to be ADDRESS instead of the
> UNTRACED REF T.
> > I would like to be pointed out the way you are trying
> to solve the initial problem, I mean it is easy to see that
> ADR operator might return ADDRESS but probably not in all
> cases (programs) to be UNTRACED REF T though your programs
> show yes, changes reveal there is a problem indeed with
> current tree.
> > Anyway this needs to confirm there is a change in the
> type rules a check of original m3tk as before had happened
> with the new types or type introductions rules.
> > I might need explanations about your rationale behind
> the new ADR type so if you don't mind just tell me what are
> the reasons to do the mentioned changes if you don't mind. I
> know there are this emails:
> > https://mail.elegosoft.com/pipermail/m3devel/2010-June/007241.html
> > and
> > https://mail.elegosoft.com/pipermail/m3devel/2010-June/007249.html
> > BTW are the m3-sys/cm3/m3test shipped to the source
> browser in Elego web pages, I might need to check this test
> cases before the actual code, see:
> > http://opencm3.net/doc/help/gen_html/INDEX.html
> > If not we better make some ones testing UNSAFE
> features if they aren't shipped and/or already done (just to
> proof well behaved programs properties in UNSAFE modules to
> see if they actually work and if not why do they fail, I
> know there might be less panic with them but is better to
> have them than nothing, we might make some directory of them
> if somebody can point out where I can put then I have Elego
> ssh keys so I can see what I can do about it).
> >
> > Thanks for your attention
> >
> >
> > --- El dom, 27/6/10, Jay K  escribió:
> >
> >> De: Jay K 
> >> Asunto: [M3devel] gcc 4.5 status
> >> Para: "m3devel" 
> >> Fecha: domingo, 27 de junio, 2010 20:39
> >>
> >> Gcc 4.5 complains about a few similar aspects of
> our
> >> trees.
> >> These would all be errors but I hacked the gcc
> source to
> >> make them warnings.
> >>
> >>
> >> Running cm3 build with gcc 4.5 crashes early in
> sysutils
> >> => PathReprCommon => Text.Length.
> >>
> >>
> >> I think I'll try to fix up these type issues
> first.
> >> You can see they aren't all that interesting,
> either
> >> widening an unsigned integer or
> >> changing the signedness but not the width of an
> integer.
> >>
> >> It's likely this checking isn't on by default, but
> that I
> >> enabled it, and that the errors/warnings are
> true,
> >> even though my enabling might have been by hacking
> the
> >> #idefs instead of the configure command.
> >>
> >>
> >> I assume upgrading to gcc 4.5 is considered
> fairly
> >> unilaterly uncontroversially good.
> >> I chose working on it for that reason.
> >>
> >>
> >> D.1401 = TextClass__GetChar (M3_Bd56fi_t.11,
> >> M3_Cwb5VA_i.10);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1408 = *D.1407;
> >>
> >> cm3cg: warning: verify_gimple failed
> >> ../src/cm3/TextUtils.m3: In function
> >> 'TextUtils__SkipRight':
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1481 = TextClass__GetChar (M3_Bd56fi_t.36,
> D.1479);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1488 = *D.1487;
> >>
> >> cm3cg: warning: verify_gimple failed
> >> ../src/cm3/TextUtils.m3: In function
> >> 'TextUtils__Compress':
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1553 = TextClass__GetChar (M3_Bd56fi_t.59,
> >> M3_Cwb5VA_i.58);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1560 = *D.1559;
> >>
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1591 = TextClass__GetChar (M3_Bd56fi_t.67,
> D.1589);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1598 = *D.1597;
> >>
> >> cm3cg: warning: verify_gimple failed
> >> ../src/cm3/TextUtils.m3: In function
> >> 'TextUtils__SubstChar':
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1683 = TextClass__GetChar (M3_Bd56fi_t.99,
> D.1681);
> >>
> >> cm3cg: warning: type mismatch in binary
> expression
> >> word_64
> >>
> >> int_64
> >>
> >> int_64
> >>
> >> D.1701 = D.1700 & 1;
> >>
> >> cm3cg: warning: type mismatch in binary
> expression
> >> word_64
> >>
> >> int_64
> >>
> >> int_64
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>     
>         
>           
>   