Florian wrote at http://bugs.freepascal.org/view.php?id=20907

FPC has a good enough dfa, however it is only activated when compiling with -Oodfa: c:\fpc\svn\compiler>fpc ..\tw20907 -vw -Oodfa

Is that documented somewhere ? Is that production read or beta?

fpc -i only lists:

Beta. I'am not aware of any missing stuff, but it's mainly untested.

Maybe add a nightly testsuite run for it?

Micha

In our previous episode, Florian Kl?mpfl said:

I tried yesterday, and couldn't cycle with it.

Florian Klämpfl wrote

Beta. I'am not aware of any missing stuff, but it's mainly untested.

I tried to activate by default it during the development of the JVM port (since the JVM will abort if it detects an uninitialized read), but it caused compiler crashes. I'll see if I can create isolated test cases.

Jonas

30.12.2011 14:42, Jonas Maebe пишет:

The present DFA doesn't work for code which uses exceptions, including implicit exception handling (read: a good 50% of all codebase).
In the meantime I tried adapting DFA, or more precisely, definite assignment analyzer, from Mono compiler (Mantis #15523). It uses a different approach, which works fine with exceptions, but is not suited well (if at all) for determining live range of variables. See notes on Mantis #15523 for details. With #15523 applied, the compiler can be cycled, but it emits hundreds of warnings which have to be fixed because cycling is done with -Sew these days. In particular, we have to solve the FillChar() issue before any DFA is enabled by default.

Sergei

Indeed, I can fix this.

15523 has different aims than optdfa.

With #15523 applied, the compiler can be cycled, but it emits hundreds of warnings which have to be fixed because cycling is done with -Sew these days. In particular, we have to solve the FillChar() issue before any DFA is enabled by default.

I played with this yesterday and what about extended Initialize to support unmanaged types? In case of an unmanaged type it just calls fillchar.

Sergei Gorelkin wrote

With #15523 applied, the compiler can be cycled, but it emits hundreds of warnings which have to be fixed because cycling is done with -Sew these days.

Passing an uninitialized variable to a var-parameter should cause a hint, not a warning.

Jonas

30.12.2011 15:18, Florian Klämpfl пишет:

I played with this yesterday and what about extended Initialize to support unmanaged types? In case of an unmanaged type it just calls fillchar.

I was rather thinking about 'varout' (or so) parameter type, which was suggested already several times in the past.
Extending Initialize is a) different from Delphi (Delphi ignores initialize(unmanaged_type)), b) does not affect already existing code, c) not applicable to all cases where FillChar is used (e.g. FillChar(x, sizeof(foo)+n*sizeof(bar))

Sergei

My concern about varout is that it is a rather big change of the language ...

I thought a little bit more about it and I'am even unsure how varout should be handled for managed types. Should it be allowed at all?
- just overwriting a previous value will lead easily to memory leaks
- handling like var won't work either because it's perfectly valid to pass an completly uninitialized memory location
Any thoughts?