RE: [fpc-devel] Optimization error causes pyacc and plex to fail
Know that there have been problems with some optimisations (Jonas has fixed some), so maybe this is reason. Regards John -Original Message- From: [EMAIL PROTECTED] To: fpc-devel@lists.freepascal.org Sent: 01/01/2005 06:49 p.m. Subject: [fpc-devel] Optimization error causes pyacc and plex to fail Can't seem to get bug submission to work so I'm sending this here. The 1.9.x distributed binaries of plex and pyacc both fail, as well as any created from a 1.9.5 source snapshot. plex ends normally but only creates 2 states. pyacc fails with a RTE 216 on a move in procedure setunion of yaccbase. The makefile compiles these programs with the -OG2p3 option. Changing this to either -Og2p3 or -OG1p3 and they both work correctly. I am using unmodified versions of both programs so am only attaching the output of each scenario. Feel free to contact me if you need anything else. <> <> This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Optimization error causes pyacc and plex to fail
Can't seem to get bug submission to work so I'm sending this here. The 1.9.x distributed binaries of plex and pyacc both fail, as well as any created from a 1.9.5 source snapshot. plex ends normally but only creates 2 states. pyacc fails with a RTE 216 on a move in procedure setunion of yaccbase. The makefile compiles these programs with the -OG2p3 option. Changing this to either -Og2p3 or -OG1p3 and they both work correctly. I am using unmodified versions of both programs so am only attaching the output of each scenario. Feel free to contact me if you need anything else. (* plex compiled with -OG2p3 *) >plex -v -o xrlex.l TP Lex Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef parse ... DFA construction ... DFA optimization ... code generation ... DONE 169 lines, 44 rules, 173/1200 p, 2/600 s, 0/1200 t. (see xrlex.lst for more information) (* plex compiled with -Og2p3 or -OG1p3 *) >plex -v -o xrlex.l TP Lex Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef parse ... DFA construction ... DFA optimization ... code generation ... DONE 169 lines, 44 rules, 173/1200 p, 61/600 s, 102/1200 t. (see xrlex.lst for more information) (* pyacc compiled with -OG2p3 *) >pyacc -v xrpars.y TP Yacc Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef parse ... sort ... closures ... Runtime error 216 at $0040CA1C $0040CA1C MOVE, line 76 of F:/FPCDevel/SrcCVS123104/fpc/rtl/i386/i386.inc $00407FA5 SETUNION, line 349 of YaccBase.pas $0040208B CLOSURES, line 94 of YaccClos.pas $00407452 GENERATE_PARSER, line 580 of YaccSem.pas $00409B20 YYACTION, line 250 of pyacc.pas $00409716 YYPARSE, line 2079 of pyacc.pas $0040B5F5 main, line 2479 of pyacc.pas (* pyacc compiled with -Og2p3 or -OG1p3 *) >pyacc -v xrpars.y TP Yacc Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef parse ... sort ... closures ... first sets ... LR0 set ... lookaheads ... code generation ... DONE 1396 lines, 433/900 rules, 691/1200 s, 3334/9600 i, 3138/9600 t, 487/1200 r. 1 shift/reduce conflicts. (see xrpars.lst for more information) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
[merged responses to two messages] El Sábado, 1 de Enero de 2005 06:54, DrDiettrich escribiste: > > ¡Serás melón! > > Could you please help me to improve my rudimentary Spanish? ;-) http://hotel.jp-guide.net/job/point/melon.jpg > (Eierkopf? ;-) My rudimentary... I meant my non-existent... whatever :-) > > ¡Feliz año, torpedo! :-) > > (Blindgänger? ;-) It's the same in English. > Feliz año, Bonne Année, Happy New Year, Gelukkige Nieuwe Jaar, und ein > Gutes Neues Jahr allerseits! All of that! :-) * El Sábado, 1 de Enero de 2005 06:29, DrDiettrich escribiste: > Nico Aragón wrote: > > > > IIRC, any non-zero value is evaluated as "True" for a Boolean > > > > variable. > > > > > > You should not guess about any implementation. > > > > I don't. Do I? > > Yes, you do. No, I don't. Maybe you're confusing me with Jesús? If you read my last answer to José Manuel, you'll see that I say exactly the opposite. So I can't agree more with the rest of your post. -- saludos, Nico Aragón http://espira.net/nico/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
Nico Aragón wrote: > > > IIRC, any non-zero value is evaluated as "True" for a Boolean variable. > > > > You should not guess about any implementation. > > I don't. Do I? Yes, you do. How can you know what bit pattern is stored in a boolean variable? Using typecasts may result in silent type conversion, returning something different from the really stored pattern. The boolean data type is distinct from other data types, so that it's wild guessing that every compiler and compiler version will treat boolean values and variables in the same way, as observed when using a specific version of an specific compiler. For completeness: Many people also consider ByteBool etc. as being "boolean". These types have been made compatible with boolean *intentionally*, with the documented behaviour that any non-zero value will evaluate to True, under circumstances. But you may test yourself what will happen when you compare such a variable with an non-boolean value - it's not perfectly specified when the nonzero=true evaluation will be effective. Try this with various compilers: var b: ByteBool; ... case b of True: ... False: ... 42: ... else ... end; It's unspecified which compiler will accept the True and False constants here at all... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
Nico Aragón wrote: > ¡Serás melón! Could you please help me to improve my rudimentary Spanish? ;-) (Eierkopf? ;-) > ¡Feliz año, torpedo! :-) (Blindgänger? ;-) Feliz año, Bonne Année, Happy New Year, Gelukkige Nieuwe Jaar, und ein Gutes Neues Jahr allerseits! DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Portability Standards
In the meantime I downloaded the Abbrevia package from SourceForge, and came across several unpleasent constructs. Please let me introduce my preferred programming model for portable code. 1) Target Dependencies I don't accept any OS or machine specific conditional compilation in code, except in dedicated units. In Abbrevia the same fixes occur in various places in the code, instead of in a dedicated OS specific procedure. Such a procedure exists, but unfortunately only in the unpatched form :-( Also compiler specific conditionals should be used only where absolutely necessary (local options, syntax differences...). 2) Code Checks It should be possible to check code for compilation on other platforms. This requires that target specific code can be compiled on any host, somehow. Consequently it must be possible to override the compiler generated symbols that describe the environment. 3) Standard Units Portable code shall use standard procedures and units for target specific actions. This requires the definition, implementation, and consequential use of one or more standard units for: - Machine specific data types and procedures (endianness...) - OS specific data types and procedures - C and POSIX specific data types (for code ported from GNU/C) Then it should be clear which portable data types and procedures should be taken from which unit. It also should be easier to determine which procedures need special considerations in portable code, from the defined data types and procedures in these units. It's not necessary that everybody follows these principles, but I will do so in my own published portable code. Otherwise I can continue to write my code for Delphi, and let it to somebody else to port that code to e.g. FPC. In the simplest case these units will have an unconditional interface part, the target specific data type declarations and the implementation part can be included conditionally from the appropriate locations. For testing purposes fake units or code sections can contain the OS specific procedure declarations, with empty bodies. This way I could verify that my changes to the main stream code would not break the code for other environments, due to the use of not yet ported constants or data types etc. This model has one disadvantage, in so far as complex procedures with small embedded platform specific code could no more be checked, because it often was impossible to determine the impact of changes to local variables etc. in the conditionally excluded code. It also was and is impossible to automatically verify that the conditional sections really are implemented for every target! In another implementation of a target independent library I defined portable classes with standardized methods. These virtual methods were almost abstract in the base class, so that they had to be overridden in every derived class. In the initialization section of the unit the appropriate class was created and assigned to the according variable, based on the actual or desired target environment. Of course this approach has the disadvantage of increasing runtime (how much?), due to the virtual method calls. Nonetheless I think that in many cases the difference from the traditional method will not be noticeable, due to the (unknown, long?) runtime spent in the embedded OS calls. The best compromise might be a mix of both methods. The interface can be fully procedural, and objects with virtual methods are used only in the implementation part, and only when this approach makes sense. Perhaps somebody finds another way to achieve the same goal, with less disadvantages? I'm willing to demonstrate my ideas in a redesign and extension of Abbrevia, so that we have a concreter base for further discussions. But before starting with that work I would like to hear some encouraging opinions or suggestions. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Interface to compressed files and archives
[EMAIL PROTECTED] wrote: > > E.g.: gzip.xyz, is this based on a gzip unit or a gzip variable or... > > Does this matter to you ? > > Normally one never uses a fully qualified identifier. And that can become a problem, when a variable and a unit has the same name. That's why I do not only prefer to prefix type names with "T", but also unit names with "u", form (unit) names with "f" etc. As prefixes for specific kinds of units seem to be in use by other people as well, why not prefix all units? > Only when a possible name conflict exists, which > - Should be very rare, and avoided in the first place. > - In such cases it will be obvious from the context. Okay, name clashes between unit and variable names should be detectable easily. But then a decision has to be made, which of both names should stay unchanged, and which one to decorate. My preference then is to decorate the unit names, because these occur less frequently in source code, and almost only in obvious Uses clauses. I know that my private prefix style is a bit uncommon, as is my coding style (indentation...). In shareable contributions I'm willing to follow the more widely accepted standards, of course :-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
El Sábado, 1 de Enero de 2005 09:06, Jose Manuel escribiste: > So i think. I think Ord(TRUE), Succ(FALSE), etc. are valid Standard and > Extended Pascal expressions, as well as the behaviour of a declarion of As far as I know: Ord(True) > Ord(False) = True Succ(False) = True ...are not only legal but also mandatory in the standard. But that doesn't mean anything. You can implement Ord and Succ to return that values for booleans no matter how you implemented the type. > type TBoolArray = array[boolean] of ... is neatly defined in the very > language. (At least in Modula-2, that enumeration is part of the standard, > so it's a language feature and not compiler implementation dependant). It's possible to implement the boolean type as an enumeration and still implement the boolean evaluation as "<> 0". I'm pretty sure to have seen this in some specification, I just can't remember in which right now :-) -- saludos, Nico Aragón http://espira.net/nico/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
> 3: the PASCAL way > boolean is a totally seperate type from integer types so the compiler > knows whether you mean logial or bitwise operations. I don't know if false That's the point. :-) > and true having ordinal values of 0 and 1 is part of a standard or a > borlandism but im pretty sure its what all pascal compilers anyone cares > about do. So i think. I think Ord(TRUE), Succ(FALSE), etc. are valid Standard and Extended Pascal expressions, as well as the behaviour of a declarion of type TBoolArray = array[boolean] of ... is neatly defined in the very language. (At least in Modula-2, that enumeration is part of the standard, so it's a language feature and not compiler implementation dependant). JMR ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
