Re: [fpc-devel] Minor debate with ISO standard on case blocks
Il 31/07/2019 08:37, thaddy ha scritto: On 2019-07-31 08:26, Marco Borsari via fpc-devel wrote: What needs to be detected if all *used* labels are within the confines of the used ordinal, but a selector without label should throw an error. In the case of my patch it behaves like extended pascal mode and throws a run-time error in that case. That is debatable in some cases, because if the selector has no label and the compiler can resolve that at compile time it should in my opinion and how I read ISO 10206 throw a compile-time error. See my remarks and test code. Maybe you can evaluate those conclusions I made. I read your code examples and I have to admit I was a little bit confused about the actual discussion: I was concerned only for the situation in which the value of variable does not match the case statement list, irrespectively of the ordinal type of the variable. For the latter I have no idea about what should be desiderable to do nor knowledge about standards. > I just compiled pascal-s (Moore's iso version, because that's the > relevant one) but did not run it yet with my patch. It fails at > run-time or compile-time? > It is an interpreter/p-code system, so has a greater level of freedom. > Note iso7158 is based on Wirth's but Wirth's version is not > iso compliant. For the situation I intended before, it raises an error when it executes the object code, please consider this code fragment of the procedure interpret: 12: begin (* switch *) h1 := s[t].i; t := t-1; h2 := ir.y; h3 := 0; repeat if code[h2].f <> 13 then begin h3 := 1; ps := caschk end else if code[h2].y = h1 then begin h3 := 1; pc := code[h2+1].y end else h2 := h2 + 2 until h3 <> 0 end; ps is set to caschk when all labels are been processed without a match and the processor reaches code 13, i.e. the end of case. I hope to be more near to the point this time, Marco ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-30 12:12, Marco Borsari via fpc-devel wrote: On Tue, 30 Jul 2019 06:38:56 +0200 thaddy wrote: According to what I found there is no smoking gun: I could not find any implementation or reference from any reputable source that implements the case statement in the way that is implemented in trunk: compile time error when not all of the ordinal range for the case are processed. It simply does not exist as far as I am concerned, unless someone can convince be by a reputable source that such implementation exists elsewhere. Pascal-S of Wirth does it. Marco Borsari I just compiled pascal-s (Moore's iso version, because that's the relevant one) but did not run it yet with my patch. It fails at run-time or compile-time? It is an interpreter/p-code system, so has a greater level of freedom. Note iso7158 is based on Wirth's but Wirth's version is not iso compliant. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-30 12:26, Paul Breneman wrote: This message thread has been interesting to read. I just realized today that I dealt with similar issues in Delphi 19 years ago. This is discussed in the good Microsoft Press book *Code Complete* by Steve McConnell. Using the default else block of a case statement to show a program error message is exactly what is recommended on pages 319-320 (and the same thing for repeated if statements on page 316). I don't know if this directly applies, but it was fun to renew a few brain cells by looking at old emails. If I add an enumerated type and forget to update some of my code, I'd like to get an error message when the unchanged code is run. Regards, Paul www.ControlPascal.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel I actually hope Scott Franco reads this (a.k.a Scott Moore). He knows a lot about the standards and developed several iso compliant interpreters/p-code compilers. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-30 11:18, J. Gareth Moreton wrote: Yeah, I don't find that description clear either. One shouldn't have to be a lawyer in order to decrypt such standards! Of course, FPC can follow its own standard, but it should be one that everyone agrees on. While I think we shouldn't live in the shadow of Delphi or be jammed in the realm of backwards compatibility, I'm a bit wary if there are quirks or errors that might otherwise cause people to back away from FPC rather than adapt their code to conform to it. But just from a practicality point of view, I think a run-time error is better in this instance because you may be able to justify a particular input value not being possible, and so not need to add code for it in your case block, but if such a value ends up reaching the case block anyway, then you deserve to endure a run-time error because it means you haven't covered it properly. Speaking of books and documentation, what's out there for Free Pascal in particular? Gareth aka. Kit P.S. I like to think my own design specs are a lot clearer than that ISO! Efforts to try and be exact often fail. Natural language is way to expressive for human beings to achieve exactness. Otherwise we would have a compiler for it ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-30 10:23, Michael Van Canneyt wrote: Just interpreting the standard, I think that the error should be run-time, not compile-time (although definitely keep the warning). That's just my take on it though. If it is to be changed, it should be simple enough by configuring the 'elselabel' field to point to an error-raising routine rather than 'endlabel' (which occurs if there's no else block). I tend to agree with your reading of the spec. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel I solved it by having iso use the same codepath as extended pascal ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-31 08:26, Marco Borsari via fpc-devel wrote:
On Wed, 31 Jul 2019 01:26:23 +0200
Martok wrote:
Of course, if you wanted a run-time error you would need to insert a
run-time
check, and 'some people' seemed to be hell-bent on saving these 2
cycles at any
cost.
The patch to switch from option a1) to a2) would be straightforward,
fix 32079
and insert a default otherwise clause that raises a RunError in -Miso.
But the
question is again, does Freepascal actually aim to be compliant with
anything,
or just have a compatible syntax and do its own thing from there?
It seems to me that the problem of a lack of correspondence in a case
statement list should be of the same level of attention of the index
limits of an array, except there is no memory corruption risk. The
solution could be to insert a run time check in presence of the
switch {$R+}, if the latter is allowed in iso mode.
Greetings, Marco Borsari
No, that is not allowed in the context of the standards, but the
compiler solves that already earlier in the code path and if the code is
compiled with {$rangechecks on} an out of bounds will be detected. What
needs to be detected if all *used* labels are within the confines of the
used ordinal, but a selector without label should throw an error.
In the case of my patch it behaves like extended pascal mode and throws
a run-time error in that case. That is debatable in some cases, because
if the selector has no label and the compiler can resolve that at
compile time it should in my opinion and how I read ISO 10206 throw a
compile-time error. See my remarks and test code.
Maybe you can evaluate those conclusions I made.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] x86-64 Optimizer Overhaul Testing
So as of yet I've still been unable to reproduce the internal error that's being described, and everything else so far has been working successfully. Wait... that SHOULD be a good thing! Still, bugs I can't reproduce are frustrating. This might be a lot to ask, but testing still needs to be done on i386-linux and x86_64-darwin, the former because I haven't been able to get around the configuration issues on my Linux virtual machine (I wish I was more adept with the OS) and the latter because I don't have a Mac system to test it on. So far though, at least from what I have been able to extensively test, there are no glaring issues and there's noticeable improvement in speed performance, while size improvements are slight, but definitely there (and are really more of a side-effect than anything else). Gareth aka. Kit --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On Wed, 31 Jul 2019 01:26:23 +0200
Martok wrote:
> Of course, if you wanted a run-time error you would need to insert a run-time
> check, and 'some people' seemed to be hell-bent on saving these 2 cycles at
> any
> cost.
>
> The patch to switch from option a1) to a2) would be straightforward, fix 32079
> and insert a default otherwise clause that raises a RunError in -Miso. But the
> question is again, does Freepascal actually aim to be compliant with anything,
> or just have a compatible syntax and do its own thing from there?
It seems to me that the problem of a lack of correspondence in a case
statement list should be of the same level of attention of the index
limits of an array, except there is no memory corruption risk. The
solution could be to insert a run time check in presence of the
switch {$R+}, if the latter is allowed in iso mode.
Greetings, Marco Borsari
--
Simplex sigillum veri
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
I submitted a patch so that iso mode behaves like extended pascal mode. i.e. The compile time error is gone (also in the case I showed to be a true bug) And a run-time error is issued as per extendedpascal. Solves most problems I have with the "feature" and existing code written in iso mode compiles again. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
I have the faint suspicion that the case chapter in the extended pascal standard is a deliberate rephrasing of the one in iso 7185:1990. Specifically adding the wording "dynamic" with regard to the error type. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
Indeed the wording between 7185 and 10206 has changed little, but important: dynamic. Therefor note I still think the patch is acceptable. I studied some more on the subject and here I will try and explain what the actual behavior needs to be when one want to interpret the ISO 7185 case very strict. In that case we need a different patch to solve the issue that is more complex: suppose ISO 7185 is interpreted very strict, then one should read it as I illustrate with three examples. The current ISO implementation has bugs anyway. If one has to keep the *compile time* error a patch needs to solve this type of code *without* an error or warning: program testisocase1(infile,outfile); // If compile time for iso 7185 errors are correct: // this code currently throws a compile-time error // and that's a bug. // It should give no error at all and no warning at all // After the patch there is still a- spurious - warning (small bug in extendedpascal!) type operator = 3..5; var x:integer; o:operator = 4; begin x:=1; case o of 3 : x := x;// all 4 : x := x;// possible 5 : x := x;// cases end; end. --- And if ISO 7185 is interpreted to throw a compile time error, this code should throw a compile time error: --- program testisocase2(infile,outfile); // If compile time for iso 7185 errors are correct: // This code should throw a compile time error with the current interpretation // and it does. // But after my after the patch it throws a run-time error // not a compile time error. type operator = 3..5; var x:integer; o:operator = 4; // here it is an invalid value begin x:=1; case o of 3 : x := x; // 4 : x := x;// this label removed! 5 : x := x; end; end. - And this code should issue just a warning: - program testisocase3(infile,outfile); // If compile time for iso 7185 errors are correct: // This code should issue a warning and not a compile time error // since the labels are in the ordinal range. // My patch handles this case correct. type operator = 3..5; var x:integer; o:operator = 3; begin x:=1; case o of 3 : x := x;// valid 5 : x := x;// labels end; end. --- Summary: if current interpretation is correct, then to the best of my knowledge: case 1 is a big bug:throws compile error on good code. Needs to be fixed anyway. case 2 handles correct throws compile error on value without label case 3 is a bug throws compile error, but should issue a warning, not an error if ISO 10206 behavior is acceptable (which I think it is!): case 1 handles correct, but issues a spurious warning case 2 issues a run-time error case 3 handles correct and issues a correct warning The above is the exact behavior as in extendedpascal. Note that here this code proves that that code is also not fully correct because of the spurious warning. On 2019-07-31 01:26, Martok wrote: If you want something a bit more clear, try ISO/IEC 10206 (Extended Pascal). They split up errors and dynamic violations, which helps make the point clearer. The patch to switch from option a1) to a2) would be straightforward, fix 32079 and insert a default otherwise clause that raises a RunError in -Miso. But the question is again, does Freepascal actually aim to be compliant with anything, or just have a compatible syntax and do its own thing from there? Best, Sebastian ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
I might add to my previous post that case(2) is open for discussion after the patch: One might argue that also in the case of ISO 10206 the compiler should throw a compile-time error in that particular case, because it is already obvious that the value has no label. Therefor I left out a correctness evaluation. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
The C case block differs from Pascal's case block in that it falls through if no return is specified. That means a single value can trigger multiple case labels. In Pascal it can only trigger one case label. Because of the fall-through a default: has greater purpose than in Pascal. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
Scott Franco a.k.a. Moore says this, what makes sense, in his manual "Rules of ISO 7185": == Case statement The case statement defines an action to be executed on each of the values of an ordinal: case x of c1: statement; c2: statement; ... end; The "selector" is an expression that must result in an ordinal type. Each of the "case labels" must be type compatible with the selector. The case statement will execute one, and only one, statement that matches the current selector value. If the selector matches none of the cases, then an error results. It is NOT possible to assume that execution simply continues if none of the cases are matched. A case label MUST match the value of the selector. == So the core is that his interpretation is: selector - on use - *must* match an existing label. Ergo not the ordinal type but its value determines if it is an error or not. FPC currently has it the other way around: if the case has insufficient processing for ALL possible values for the selector it already throws a compile-time error. That's in my opinion the wrong interpretation. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-30 14:04, Sven Barth via fpc-devel wrote:
thaddy schrieb am Di., 30. Juli 2019, 10:04:
On 2019-07-30 01:43, J. Gareth Moreton wrote:
As someone on the issue pointed out... on page 2, section 3.1:
3.1 Error
I have added this to the bug report. Consider that here all possible
case labels are implemented, the compiler still throws a compile
time
error.
That means the implementation is wrong anyway.
{$mode ISO}
program isobug(infile,outfile);
type
operator = (plus, minus, times);
var
x:integer;
o:operator = plus;
begin
x:=1;
case o of
plus : x := x; // all
minus : x := x; // possible
times : x := x; // cases
end;
end.
The easy way out seems to revert to the 3.0.4 implementation given
the
section mentioned.
Gareth's suggestion would be nice to have, though.
That's definitely a bug, cause the same code (with "operator" changed
to "op") compiles in mode ObjFPC without any warning or error.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Yes, it is a bug, but note the case handling in mode objfpc (all modes
except macpas, iso and extended) differs.
It should only error out if the selector value has no case label.
Extended Pascal then throws a run-time error.
The other modes, like objfpc, silently continue.
It should not error out at all at compile time.
I provided a patch that makes the iso behavior equal to the extended
pascal behavior.
This solves both the above issue and the compile time vs run time error.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AVR - redundant mov followed by ldi instruction
On Tue, Jul 23, 2019 at 9:49 PM Christo Crause wrote: > The following test code generates a redundant mov instruction which seems > to be related to a situation with an unused procedure parameter and the > inc() procedure: > > program testRegAlloc; > var > a, b: byte; > procedure testDummyParam(var x: byte); > begin > inc(a); > end; > begin > testDummyParam(b); > end. > > The generated code for testDummyParam: > mov r18, r24 > ldi r18, 0x00 ; 0 > ldi r19, 0x01 ; 1 > movw r30, r18 > ld r20, Z > inc r20 > movw r30, r18 > st Z, r20 > ret > > Moving r24 to r18 is redundant since it will be overwritten by the next > ldi instruction. Attached is a patch that can identify this situation and > eliminate the redundant mov. Is it the correct approach to fix this in the > peephole optimizer, or can it be fixed at an earlier stage? > After some more testing i think my approach to fixing this is completely backwards. The issue (of redundant code generation) is probably better addressed upstream (at node level?) by identifying that the parameter is unused and hence code should not be generated in the first place. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
