[M3devel] gcc 4.5 status

[Jay K]

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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>