Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 07/06/2017 15:18, Juha Manninen wrote: The compiler trusts that data in an enum variable is legal, within the range. It should trust the same way when doing DFA. It is logical and consistent. I understand your reasons now and agree that DFA should cover only logical (according to the

Re: [fpc-devel] non volatile registers.

In our previous episode, Marco van de Voort said: > I can remember somebody (Sven?) explaining how to save non volatile > (xmm) registers callee side on win64. (equivalent to Delphi .savenv) > > I searched for that post (some mantis comment?) but can't find it. A quick > test seems to indicate

[fpc-devel] non volatile registers.

I can remember somebody (Sven?) explaining how to save non volatile (xmm) registers callee side on win64. (equivalent to Delphi .savenv) I searched for that post (some mantis comment?) but can't find it. A quick test seems to indicate that simply adding it to the registers list doesn't work. (or

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On Wed, Jun 7, 2017 at 2:04 AM, Denis Kozlov wrote: > You suggest that only Convert3 function should raise "uninitialized result" > warning, while Convert1 and Convert2 should not. I find this less useful, > and, again, you can rightfully disagree, but it won't change the fact

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 07/06/2017 00:04, Denis Kozlov wrote: Consider the code fragment below. Currently, FCP 3.0.2 with -O3 shows "uninitialized result" warning for Convert2 and Convert3 functions, but not for Convert1. I find this perfect as is, and, of course, you can rightfully disagree. You suggest that