Re: [fpc-devel] certain divisions in single precision only

Am 08.12.2019 um 18:41 schrieb Florian Klämpfl: > As the delphi behavior is very i386/x86-64 specific, FPC deviates from > it (not to mention that the non-i386 behavior was implemented years > before a non-i386 delphi was available). Jup, that's what I meant with "made runtime and compile time

Re: [fpc-devel] certain divisions in single precision only

> Indeed, this is by design. See > https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants for > how to explicitly specify a different precision. That was long before the change Tomas discovered. The gotcha here is about your fix to

Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

Am 27.10.2019 um 17:48 schrieb Florian Klämpfl: >> I guess the main difference is whether one prefers side-by-side >> diffs or udiffs. > > In particular partial commits as well as conflict resolution work much > better with TortoiseGit for me. Oh yeah, conflict resolution is the thing nobody rea

Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

> cover one single topic. Today, using e.g. TortoiseGit on Windows (sorry, > on Linux there is no tool which comes close) such patches can be > re-arranged without too much hazzle. Just plain ol' git-gui can also do it. SmartGit is cross-platform and also pretty nice. I guess the main difference

Re: [fpc-devel] Minor debate with ISO standard on case blocks

email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > Virus-free. www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

> If you want to nitpick, the compiler will perform 1/2/4 byte writes for > enums of those sizes, so the full reserved data is in fact > used/initialised. Again: the only relevant part in this discussion is > the valid values. The reserved/used/accessed/written/... storage size is > unrelated to th

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

he beginning of > the thread: > https://forum.lazarus.freepascal.org/index.php/topic,45507.msg322059.html#msg322059 As I wrote in the last message, those points would be fully addressed by this proposal. Choosing at declaration time is the only valid solution, all modes will beh

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

else (including the intrinsics this is about) is just a hacky workaround to the difference Jonas summarised above, IMHO. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

absolute aEnum; begin if Read(aEnum, SizeOf(aEnum)) <> SizeOf(aEnum) then Exit(False) else begin Result := (tmp >= Ord(Low(T))) and (tmp <= Ord(High(T))); end; end; This *could* be optimized out by FPC, but not by a Borland compiler. -- Regards, Martok Ceterum censeo

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

types. Unless the optimizer removes the typeconvnodes... Of course, this needs to be done everywhere a subrange is passed anywhere that is not FPC, so it can't really fix anything. -- Regards, Martok ___ fpc-devel maillist - fpc-

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

tack this onto a particular stream implementation but instead provide a general marshaller for it. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

no particular philosophy at all is what got this interpretation of the language into this mess in the first place. FPC is in dire need of a language specification effort. But I don't think anyone who would be willing to drive it cares enough at

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

y. > So, in my book, an intrinsic to check for a correct value in the places where > an > invalid value can enter the system is a welcome language feature. In my book it's absolutely insane that this is needed *just because* FPC wants to be different, but yes, it is required. -- R

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

rom outside. Then you're not using them *in* the interface ;-) -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

x27;s better than Delphi, nice :) -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

of 'communication': calling non-FPC APIs or even just FPC libraries of possibly different version (see: Run-Time Packages!) Anything that even looks like a subrange cannot be used for these interfaces. -- Regards, Martok Ceterum censeo b32079 esse sanandam. _

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

e system. That got left out when they rewrote the content for Delphi Help. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

mber if your patch handles those correctly as well? That probably needs a few test cases? -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] When will the next version of FPC be released?

ah, that's just core having a different opinion of code duplication than I do. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] When will the next version of FPC be released?

r overload mess is already completely unpredictable and super buggy. Based on a specificity approach, the answer to your question would be obvious: The latter if a is (a descendant of) TObject, a new specialization otherwise. -- Regards, Martok ___

Re: [fpc-devel] Compiler picks wrong overload

" the most hilarious "weight 1" autoconversion (see 0031215, which is also an overload bug). -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Case statement does not handle all possible cases" Warning

n platforms. I would prefer literally any other solution (such as the two-line-patch my Windows trunk builds have contained for two years now), but this is the one that gets merged. Go figure. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

solution order, typeconv order, ...) with as few implementation quirks as possible and then align the compiler to it (not the other way around). Having less corner cases to juggle in one's mind may make things easier, and a formal spec is also a good reference for future extensions to see if i

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

not involved in development there." was actually true and I haven't looked at it since, because it "just works" ;-) Although, that *is* true again, so it's 50/50 if I would report it today. -- Regards, Martok ___ fpc-devel ma

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

e and *will not currently work with fppkg*. But you will get a working compiler. I used '-o "%CD%\fpc.cfg"' exactly because fpcmkcfg does not handle relative paths well. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@

Re: [fpc-devel] Successful implementation of inline support forpure assembler routines on x86

maintain, as there wouldn't be the need for new inlinennodes or entirely different node types. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TRegistry and Unicode

t away from UTF8 anyways. String codepages are not stable, there is almost never a point in explicitly setting one... -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong floating point Currency calculations

> Is this a known bug? > > (Btw. I tested on win32.) Maybe this? https://bugs.freepascal.org/view.php?id=33963 -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/lis

Re: [fpc-devel] Fppkg

rm of package manager, so my opinions very much *should* be void.) -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Fppkg

reepascal\fppkg\config), hence break any time the compiler path changes. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Sorry for poor testing

Am 14.01.2019 um 15:01 schrieb J. Gareth Moreton: > Martok mentioned doing some checks differently in the bug report in question, > such as 6 comparisons being faster than a jump table.  Are there any others > worth mentioning? Not neccessarily faster, but in that code definitely smaller.

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

; end; begin writeln(GetString(42)); end. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

r will do something that is *very likely* unintended. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

ot;, and now its provably wrong. No warning. This seems wrong, considering what we just talked about on fpc-pascal. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

t makes case-based regular language parsing quite noisy. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

previous, since it is now possible to discover forgotten items or later additions by the other warning, removing these 'safety' else-clauses would improve code quality. What do you think? -- Regards, Martok From e32addb6583c8b752c168fe221385566499625bb Mon Sep 17 00:00:00 2001 From: Mart

Re: [fpc-devel] TDef mode question

Am 27.12.2018 um 20:48 schrieb Jonas Maebe: > No, there is not. If a def needs to be different depending on the > language mode, you have to store it in the def. Thought so. Thank you for confirming! Cheers, Martok ___ fpc-devel maillist

[fpc-devel] TDef mode question

ed in. Cheers, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Case block optimisation

at still works everywhere? Bug 0032115 provides a "nice" test case for things that can go wrong with different word sizes, and is also a good test for the true label count. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freep

Re: [fpc-devel] x86_64 Optimizer Overhaul

FPC-builtin was done after 10 seconds. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] x86_64 Optimizer Overhaul

tickcount; for i := 0 to COUNT - 1 do begin for j := 0 to high(objs) do objs[j]:= TObject.Create; for j := 0 to high(objs) do objs[j].Free; end; t2:= Gettickcount; writeln((t2-t1)/COUNT:10:3, 'ms'); Readln; end. -- Regards, Martok

Re: [fpc-devel] x86_64 Optimizer Overhaul

’s not clear where to begin looking. Checking out the memory manager(s) could be useful as well - there are a lot of small allocations, that generally tends to put much stress on it. And any improvement there would also directly benefit user applications. -- Reg

Re: [fpc-devel] Case code pattern

s of the type of x, it is omitted. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Case code pattern

ed is not technically a jump table, but a typed dispatch table. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Why/how does the compiler have a non-trivial number ofmemory leaks after over two decades of development?

Am 30.07.2018 um 14:24 schrieb Marcos Douglas B. Santos: > Is performance more important than being correct?  :| In this project, the answer is always taken to be yes. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org h

Re: [fpc-devel] Compile time functions

s not inlined" message. > The final issue is that while a function might be pure, you might not want to > inline it because of its complexity, especially if it's called multiple times > with variable arguments. That is very true. Should the "interpretation complexity"

Re: [fpc-devel] Compile time functions

on is pure, what I did with constexpr() would basically be guaranteed to work. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Compile time functions

ing branch here <https://github.com/martok/freepascal/compare/master...dev_inlining>. Instead of marking a function as 'pure' at declaration, I took another way: make normal inlining firstpass flexible enough that any "accidentally" pure function can be collapsed at the c

Re: [fpc-devel] Progress of pure function research

alized optimizations after inlining and before simplifying. I'll have a look into that later - this would be useful for many cases regardless of pure functions. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org htt

Re: [fpc-devel] Progress of pure function research

or certain recursive functions. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Issue #32913

statements are allowed in an EXCEPT block. Come to think of it, didn't we have another TRY/FINALLY/EXCEPT nesting issue that might have something to do with that? -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Managed Types, Undefined Bhaviour

ly don't understand how interfaces are > implemented. Thank you for the explanation! Saved for future reference. I was thinking too much in terms of C++ pure virtual classes and their VMT and forgot about the self translation trampoline functions. -- Regards, Martok

Re: [fpc-devel] Managed Types, Undefined Bhaviour

from my example has always worked (for me!) in FPC. I am confused. Which sorta ties in to the whole "surprises" thing from before we hijacked this thread... -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http:

Re: [fpc-devel] Managed Types, Undefined Bhaviour

a lot by itself, but since we're counting single-digit cycles in other places... -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Managed Types, Undefined Bhaviour

ith the generated code, but it is not nearly as efficient as it could be. See also Ryan's comments about slow Interlocked*-calls a few weeks ago. Delphi's output for the same example is better, giving the expected output. Because of the tempvars, it is also not exactly what one m

Re: [fpc-devel] Managed Types, Undefined Bhaviour

avoid the interfaces here with ARC records, but either I'm missing something or the scope lifetime of tempvars there is even worse. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Managed Types, Undefined Bhaviour

esult:= nil; SetLength (result,len); // whatever end; For managed types, as far as I can tell: - locals are initialized (even if there is a warning telling you they are not) - tempvars are initialized *once* - Result is never initialized (there is no warning telling you it

Re: [fpc-devel] Possible internal corruption

gn_abstract(hp).aligntype=119" and check what the actual type of hp is? It could be that at some point a node gets its typ changed in an invalid way? aligntype should be either one of 2^[0..5], never something else... This is where AddressSanitizer support would be *nice*. -- Regards, Martok C

Re: [fpc-devel] Debugging Loop Unroll Optimization

that probably prohibits most useful cases as well... I'd say that closures + AST-level inlining + some dead store eliminations would fix a lot of issues that currently have special case handling. -- Regards, Martok ___ fpc-devel mail

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 21.05.2018 um 17:44 schrieb Florian Klämpfl: > I added raise, exit, goto and label as well. Oh, label, right. I'd say #0033614 can be resolved as "fixed in 39083" and #0033753 as "no change required" then. -- Regards, Martok _

Re: [fpc-devel] Debugging Loop Unroll Optimization

hes. The "Optimized IDE" profile is usable again. I'll post the patch to the bug tracker, as we seem to have decided it is not a hack ;-) -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepas

Re: [fpc-devel] Debugging Loop Unroll Optimization

defined when the loop is left with break or exit, that's the point. The ISO is not a very good reference for modern-ish Pascal. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Debugging Loop Unroll Optimization

7;s snapshot, see if anything else remains. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Debugging Loop Unroll Optimization

of time on once already, no intention to do that again. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Debugging Loop Unroll Optimization

alects handle them. It's been 28 years, there's probably consensus on some out there. Could be useful as a guide for porting code as well. Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Debugging Loop Unroll Optimization

> Can you report that to the bugtracker of Lazarus? Sure. Done as https://bugs.freepascal.org/view.php?id=33753 Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Debugging Loop Unroll Optimization

arning, and does indeed display it for the test case. There is no indication anything might be wrong from FPC? This kind of code is used even more than "that other thing", makes me wonder if it's a good idea to break this at O3... -- Regards, Martok

Re: [fpc-devel] Debugging Loop Unroll Optimization

then halt(1); i:= tfun(); if i <> 10 then halt(2); if s <> 12 then halt(3); writeln('ok'); end. - I would very much expect that to be the main cause of the observed crashes. -- Regards, Martok __

[fpc-devel] Debugging Loop Unroll Optimization

oducible. Does anyone have more complete test cases, or maybe smaller affected projects? -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

ic type OrdinalType = type Word; Otherwise this is the same. I hope this clears things up a bit. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

s that really need it, in Delphi mode, nothing should break on invalid enum values anyway (if it does, it is a compiler error). -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Type Compatibility: dynarray <=> Pointer

owing does in D10.2? var arr: array of byte; begin arr:= Pointer(0); end. What I'd like to know: do they check the "nil" literal, or pointers of value nil? -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Type Compatibility: dynarray <=> Pointer

Am 17.04.2018 um 01:51 schrieb Thorsten Engler: > And the nil assignment variant is pretty much ubiquitous in any code > involving dynamic arrays that I'm aware of. Yes. I know ;-) >> only the reserved/constant "nil" is compatible, and handled elsewhere I asked specifically about assigning arbit

[fpc-devel] Type Compatibility: dynarray <=> Pointer

dynarrays? It does seem to be Delphi compatible, but I couldn't find any mention in either documentation that this is possible - only the reserved/constant "nil" is compatible, and handled elsewhere. -- Regards, Martok ___ fpc-

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

t;var is class" handles nil values as "not an instance of class". -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

tter how dd ends up in v v:= succ(v); // always invalid, no need for {$R+}! end. All this is not quite as easy to get right as it seems on the surface. But I do like the the "v is TEnum" operator from the other side of this thread, regardless of where this goes.

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

o work with assigned values), but if we want to go there, something like this feature is absolutely required (Ada has it). In that case, off the top of my head, succ/pred, for, bitsizeof and maybe sizeof need to be fixed as well. -- Regards, Martok Ceterum censeo b32079 es

Re: [fpc-devel] Wrong docs: not initialized global variables

losophy of > strongly preferring abstract purity to concrete user experience. If it at least was consistent purity! Sorry. Needed to be said. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.free

Re: [fpc-devel] Redundant compiler hints

The hint was added in response to <https://bugs.freepascal.org/view.php?id=31717>. Not very useful, other than to demonstrate 'inline' is rarely respected. However, it probably wasn't the intention to generate it for intrinsics as well? -- Regards, Martok Ceterum censeo

Re: [fpc-devel] End of support for Win XP?

support also drops ReactOS support. I'm not sure if we ever officially had it, but it is on the Wiki. Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Question about $OPTIMIZATION LEVELn

e the flags alone (should) have no use b) it's always been documented that way c) it's used as if that was true in live code Rough patch attached... -- Regards, Martok Ceterum censeo b32079 esse sanandam. Index: scandir.pas ==

Re: [fpc-devel] Question about $OPTIMIZATION LEVELn

new flags are introduced. Is there even a use case for the current behaviour? I.e., when would one actually mean -Oolevel3 instead of -O3? -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepa

[fpc-devel] Question about $OPTIMIZATION LEVELn

org/docs-html/prog/progsu58.html> claims {$OPTIMIZATION ON} is equivalent to {$OPTIMIZATION LEVEL2}, which it never was since that directive was introduced. Slightly related, the Programmer's Guide lists ancient optimization switches in 11.3. Bug report coming in shortly. -- Regards, Martok

Re: [fpc-devel] FillWord, FillDWord and FillQWord are very poorly optimised on Win64 (not sure about x86-64 on Linux)

it being slower on modern platforms than it used to be? -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] x86_64.inc CompareByte

(10) do buf2[j]:=buf1[j]; for j:=1 to 1 do CompareBytePatch(buf1,buf2,len); // or System.CompareByte -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://list

Re: [fpc-devel] rdtscp

ranch prediction at work. I can also validate Agner Fog's Instruction Timing Tables with it, so it can't be that bad ;-) -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http:/

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

probably didn't mean security as much as "my room-sized mainframe crashes", but the point stands... -- Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Use of Enumerations in header translations

httpd22 httpd24 libcurl libenet libusb libvlc libxml2 mad mysql nvapi oracle winunits-base winunits-jedi zorba -- Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

Am 25.07.2017 um 19:31 schrieb Martok: > As has just been pointed out to me, we all misdiagnosed that example. Turns out this is not a new question, there is actually a very thorough treatment of that very issue on SO: <https://stackoverflow.com/questions/18195312/what-happens-if-you-stati

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

must be Low-Level. QED. > "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)" = Invalid opcode > (memory dump written). > Why? Because it does not range check before entering the jump table. I really should have noticed that.

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

r) do begin arr[v]:=1; end; end. Still no RC code, but now we can be wrong on both sides. Also the loop happily iterates over the invalid values 1 and 2. 5) {$r+} var a: TEnum; b: TSubEnum; begin a:=tenum(5); b:=a; end; That should include RC code, and be

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

igns explicit enums with Delphi. Having the range functions like that means we don't have to touch any optimizer code at all - it gets the correct bounds. Same for range checking code. Subranges continue to be strict (as the "convex hull" of the enumerati

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

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

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 li

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 wa

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

y do that in all of the *ToStr-functions, instead of executing the else-blocks. That code is completely unambiguous and well-defined if we assume Low-Level Enumerations (which, coming from BP, I obviously always have). Martok ___ fpc-devel maillist - fpc

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

#x27;s a lot of (future) work and care to deal with what I > still consider to be bad programming. Delphi optimizes always based on the full-range base type: type TB = (a,b,c,d,e); // Sizeof(TB)=1 TT = a..e; var t: TT; begin t:= TT(2); if t <= e then // does not get remove

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

. Note that FPC doesn't accept this code in mode (Obj)FPC, but correctly does so in DELPHI, with the same result as Delphi. Added after Ondrej's message 20:52: Borland appears to have taken the route of what he called a 'LOW-LEVEL enumeration' from the very beginning. Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

Am 15.07.2017 um 12:40 schrieb Jonas Maebe: > On 14/07/17 02:40, Martok wrote: >> There is a fundamental difference in the type system between a somewhat >> sensible (if unexpected) assumption in FPC and a more practical documented >> definition in every other Pascal compile

  1   2   >