Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 16:34 schrieb DaWorm: > Does the compiler optimize away the else clause in this case? Seems to me it > should not. At least that isn't the behavior I would expect as a user. At least it should not do that without telling me. The good thing about case statements is that they tell

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 15/07/17 21:34, Martok wrote: This will never generate a range check error, because the type information states that a tsubenum2 value is always a valid tsubenum value. Array indexing a special case of this, as semantically the expression you use to index the array is first assigned to the

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 19:24, Martok wrote: The good thing about case statements is that they tell me of every other programmer error: missing elements (if used without else) Off-topic: how can I enable this compiler hint? When compiling: program Project1; type TEnum = (one, two); var A: TEnum;

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16/07/17 09:12, Ondrej Pokorny wrote: On the one hand you say that the compiler can generate invalid values and on the other hand you say that the compiler can assume the enum holds only valid values. It can assume this because a program's behaviour is only defined if you initialise your

Re: [fpc-devel] Dangerous optimization in CASE..OF

> And you also have subranges of enum types. Can any assumptions made > about those in your opinion? > Does that mean that you would consider the same transformation of a > case-statement when using a subrange type as correct? And that putting a > value outside the range of a subrange into such

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 11:07, Michael Van Canneyt wrote: You are missing the point of an enumerated. The whole point of using an enumerated is that range checking *is not necessary*, because the values are 'by definition' correct. If the compiler cannot assume this, you're just using an integer with

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 20:25 schrieb Ondrej Pokorny: > For now, Pascal enumerated types work as aliases for underlying ordinal > values - a concept that is > exactly the same as C enums: > Very good point: florian@ubuntu64:~$ cat test.cc #include enum tenum { e1,e2,e3,e4,e5,e6,e7,e8 }; int f(tenum

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Sun, 16 Jul 2017 10:34:18 -0400 DaWorm wrote: > If the programmer builds a case statement on an enum, that includes all of > the possible enum values, and also includes an else clause, to me it seems > the programmer is implicitly telling the compiler that there is the >

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 22:15 schrieb Martok: > > However: > --- > {$mode objfpc} > type > TExplEnum = (a=1, b=3, c=5, d=7); > TSubEnum = a..d; > TEnArr = array[TSubEnum] of Byte; > > begin > WriteLn('SizeOf(TEnArr) = ', SizeOf(TEnArr)); > WriteLn('Low(TEnArr) = ',

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 23:11, Florian Klämpfl wrote: Am 16.07.2017 um 22:39 schrieb Florian Klämpfl: Am 16.07.2017 um 22:15 schrieb Martok: However: --- {$mode objfpc} type TExplEnum = (a=1, b=3, c=5, d=7); TSubEnum = a..d; TEnArr = array[TSubEnum] of Byte; begin

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 20:42, Florian Klämpfl wrote: "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)" = Invalid opcode (memory dump written). Why? Because it does not range check before entering the jump table. OK, I confess I am not a C guy (I hated it in the university even more than

Re: [fpc-devel] Dangerous optimization in CASE..OF

> OK, I see now: there is a difference between C enums and C++ enums. Your > example was about C++ enums. My example was about C enums. The C enums > are defined to allow any integer value, whereas C++ enums are strongly > typed. In the pages cited, there's no mention of valid ranges, only that

Re: [fpc-devel] Dangerous optimization in CASE..OF

You (Florian) do realize that it's almost impossible to write a C++ program that is not technically undefined? Their 'standards' are worse than our 'implementation-defined'. FWIW, GCC agrees with Low-Level Enums, and given that clang regularly catches hate when their 'optimizations' break stuff

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 22:39 schrieb Florian Klämpfl: > Am 16.07.2017 um 22:15 schrieb Martok: >> >> However: >> --- >> {$mode objfpc} >> type >> TExplEnum = (a=1, b=3, c=5, d=7); >> TSubEnum = a..d; >> TEnArr = array[TSubEnum] of Byte; >> >> begin >>

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 21:13, Florian Klaempfl wrote: Indeed. This proves the exactly point. Undefined behaviour. The code behaves randomly dependent on the compiler used and even the optimizer switches. OK, I see now: there is a difference between C enums and C++ enums. Your example was about C++

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 19:58 schrieb Ondrej Pokorny: > On 16.07.2017 19:24, Martok wrote: >> The good thing about case statements is that they tell me of every other >> programmer error: missing elements (if used without else) > Off-topic: how can I enable this compiler hint? Erm, I was referring to the

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 21:08 schrieb Ondrej Pokorny: > On 16.07.2017 20:42, Florian Klämpfl wrote: >> "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)" = Invalid >> opcode (memory dump written). >> Why? Because it does not range check before entering the jump table. > > OK, I confess I am not a

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 13:17 schrieb Jonas Maebe: > Does that mean that you would consider the same transformation of a > case-statement when using a subrange type as correct? And that putting a > value outside the range of a subrange into such a variable as a > programmer error? (as opposed to doing

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 15.07.2017 21:39, Jonas Maebe wrote: On 15/07/17 21:33, laza...@kluug.net wrote: Am Sa., Jul. 15, 2017 21:07 schrieb Jonas Maebe : I have said from the start that it is possible to store invalid values in variables through the use of a.o. pointers (which is

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Sun, 16 Jul 2017, Ondrej Pokorny wrote: On 15.07.2017 21:39, Jonas Maebe wrote: On 15/07/17 21:33, laza...@kluug.net wrote: Am Sa., Jul. 15, 2017 21:07 schrieb Jonas Maebe : I have said from the start that it is possible to store invalid values in variables