Gpc

gpc@gnu.de

5400 discussions

Fwd: Short Strings
by Frank Heckenbach 06 Jul '06

06 Jul '06

Forwarded from: marcov(a)stack.nl (Marco van de Voort) In gmane.comp.compilers.gpc, you wrote: >> FPC is a like Delphi, but since it supports the TP libs (Delphi doesn't), >> there is some use, also in the textmode IDE. Also the compiler and utils >> itself originally used shortstrings. However we are moving away from that >> for some time now (already since 2000). > > Well, I used BP myself long time ago, ......... > was nothing much to be changed (except for sometimes declaring a > bigger maximum size :-). I had similar experiences with my own codebases, because they were already abstracted for string usage since they were ported back from Modula2 before. However in my experience, there only is a small fraction of existing codebases that is that clean. See e.g. the average level of filth in SWAG. >> In time, only the core compiler >> itself (symbol tables etc) will be the only non legacy code using >> shortstrings. This because the size limit is no problem for >> identifiers/tokens etc, and it is quite a bit faster. >> >> This could be because the static nature allocates them together with the >> objects, while dynamic strings would be an allocation extra, > > I suppose you're talking about Delphi's string variant which is only > dynamic AFAIR. Correct, and specifically inside the FPC compiler core. The FPC compiler is speedwise mostly dependant on the memory manager and lexing. In plain Delphi (and FPC in de delphi mode), "String" means ansistring. While in TP and (FPC in TP modes) the identifier "String" means shortstring. This makes switching easy, provided the shortstring code is cleaned up (no write beyond the range 1..length(s) and no s[0] use). > However, Extended Pascal's strings can be static or (explicitly) dynamic, > just like other types, so you can use them mostly the same way as short > strings, and there is no extra overhead, except for a few bytes more to > store the bigger length field and the capacity. If the statical variant is instantiated with the class/object, yes then it would. But as said, there is no real reason to clean shortstring out of the compiler core. Maybe except if we switch to unicode (or UTF8) mangled names and identifiers, that will be a major rewrite anyway. > I think for some cases, limited strings are still useful, for other > cases, unlimited strings are preferable. Correct. However EP now has this static type. And FPC also has one, reasonably transparant. The point is more that it is not worth to invest in a second one unless there are very good reasons (and the current mac pascal discussion is one for GPC IMHO) >> Correct. And it is not just the interfaces, but also demoes, documentation >> and a nearly all Pascal code available on the Mac. > > As I said WRT BP above, I think such code, as long as it doesn't use > external short-string interfaces, can probably convert to (EP) long > strings with minimal effort. It is a barrier. And to a programmer that comes from a all-hands-held commercial compiler, it is yet another one over the already existing ones (the change of IDE, project system, misc units and language changes). That's what Peter tries to point out. For a new developer everything is new, and _every_ change that forces him to inspect every line in the whole source is a major pain and a risk. Even if every change for itself is negiable. I learned this the hard way during FPC Delphi compability convergence. You quickly port and fix heaps of all those little issues, and then when it finalyl compiles it turns out the program doesn't work anymore. The littler the changes the less chance on such scenario. However you and me and probably the rest on this list can handle decent debuggers and if necessary probably even GDB down to assembler level if we have to. Most of the Apple newbies can't though. >> In practice this means auto conversion by assignment and passing to value >> parameters. FPC/Delphi do this already. > > We do that for CStrings, so most of the time we can avoid using > CStrings in Pascal code this way. An automatic back-conversion > (e.g., for function results) also seems possible, though we don't do > that yet. Real reference parameters would be a problem, both they > are rarely needed (I suppose, also WRT short strings in Mac OS). Similarly with FPC/Delphi and ansistrings <->pchars. Btw, function results are handled by the conversion? > So this might indeed be an option for short strings (i.e., no direct > support, but automatic conversions). It will certainly be easier to > implement, but it lacks some features (such as bianry > compatibility), so I might go for the full support anyway, if it > doesn't present unsurmountable problems ... I meant these conversions as additional to the BP featureset, to interoperate with your own string type. And afaik they already have some workarounds like that using the records and some operator overloading? (Peter?) I don't think you can do without full support. Specially the "open array" string compat is too important to leave out (more important than the ref thing), because this is the main way to have generic shortstring string routines. >> The shortstring implementation is simply something >> like >> >> procedure setlength(var s:shortstring;x:integer); >> >> begin >> if x>255 then x:=255; >> s[0]:=chr(x); >> end; > > This only works for strings of capacity 255. Correct, my shortstringese is a bit rusty. Subst 255 with high(s) for a general TP compatible solution. >> This is not a problem in general. A hybrid system always has penalties, and >> people _choose_ to use it. Mostly subsystems are internally one string type, >> and only the interfaces between the subsystems aren't. > > I hope so. OTOH, I've seen in the past a lot of BP programmers use > CStrings (i.e., "PChar") throughout in their Pascal code, after they > were added to BP (version 6 or 7), probably also because of > Borland's marketing them as the next big thing. I think more that it was the only way to get around the size limits. Also the TP/BP windows compat was directer on the API than the VCL based Delphi. But there certainly was a bit of a myth in TP times that pchars were faster, partially also because they were from "C". There was some truth in that (shortstrings copy too much), and carefully crafted code could be better, but the speed advantage was vastly exagerated, specially compared with the fact that it was way easier to do anything wrong with pchars, and complex string code was way more work. The problems were that the emerging 32-bit C compilers BP was compared to were simply faster because they optimized and were 32-bit (using a 32-bit move() routine for their copies), and BP was a codegenerator from yesteryear. > (I admit I almost fell for it myself, but when I saw the drawbacks, I > converted back to short strings what I had changed to CStrings already, > fortunately, so I could easily convert the code to EP strings with GPC > later.) I mostly used shortstrings in that time and pchars only to break that limit if needed. However when that really got important, because the path sizes exploded, I was already using FPC and ansistrings were stable. >> Copying conversions are required for literals anyway, but they can't be >> avoided, since shortstrings are not lazily assigned. > > I'm not sure if that's required. We could probably also emit the > literals as short strings when needed (like we do with literals used > as CStrings). We'll see which will be easier in the end. I meant the following situation: procedure x; var s : string; begin s:='bolalalallala'; end; On the assignment some copy must follow from where the const is stored to the stack.

1 1

Fwd: Re: Short Strings
by Frank Heckenbach 04 Jul '06

04 Jul '06

Forwarded from: marcov(a)stack.nl (Marco van de Voort) In gmane.comp.compilers.gpc, you wrote: (a summary from a Mac outsider. Peter, Adriaan, feel free to correct) >> ... snip ... >> > >> > So basically, I'm just saying that the lack of short strings is >> > seriously hindering GPC adoption on the Mac, and that that should >> > probably be taken in to account when pondering the priority of their >> > implementation. > > I see. When I have more than a few days to work at GPC (currently, > I'm stilly busy with other work, you know, the paying kind ...), > I'll see if I can do it. Unless Waldek beats me to it ... (Besides Mac it also helps TP/Delphi compat a bit, though I can't quickly remember a single place where Delphi uses them. In 32-bit Delphi it is nearly fully legacy) FPC is a like Delphi, but since it supports the TP libs (Delphi doesn't), there is some use, also in the textmode IDE. Also the compiler and utils itself originally used shortstrings. However we are moving away from that for some time now (already since 2000). In time, only the core compiler itself (symbol tables etc) will be the only non legacy code using shortstrings. This because the size limit is no problem for identifiers/tokens etc, and it is quite a bit faster. This could be because the static nature allocates them together with the objects, while dynamic strings would be an allocation extra, but IIRC the compiler uses pointers to shortstring. > On a tangent, what do you think is the future of short strings > anyway? Dodo. Note that FPC also advises to use the ansistring type as much as possible. Dynamic string types are the future, static types with larger boundaries will perish also. This because more and more libraries (under influence of GNU policy) specify their maximal string sizes quite high. Putting very large strings on the stack will gigantically inflate stack size. Also more and more OSes allow really deep dir structures and long dir names. We already have had complaints about a forgotten 1024 char limitation in filenames in some routine. > Does Mac OS support those at all, with a different interface, or what? The base libs under OS X are so *nix that we pretty much use the *BSD rtl also for Darwin. Carbon has shortstrings mostly (and not just [255] afaik), and Cocoa is objective C. > Secondly, charsets. When 16-bit charsets (i.e., Unicode) become common (or > are already), will/should there be a 16-bit "short" string (i.e., max. > 65535 characters)? Don't think so. Don't bother, unless there is something that needs them. Shortstrings are Carbon and TP. Nearly all of that code is not unicode safe anyway, and if there is a major investment that will go in the direction of dynamic strings. > Or else, if the interfaces will/do use UTF-8, we'll > need conversions (automatic and/or manual) between Unicode and UTF-8 > anyway? Yes. > (As discussed before, UTF-8 doesn't make for a string type in > Pascal.) _some_ routines must be adapted for UTF-8. However most routines keep on working, due to the properties of the encoding. > Just to figure out if supporting short strings will only be a > short-lived solution and more work in this area will be required soon > anyway ... As far as I see it the problem is that Apple expected more Cocoa uptake (keep in mind that Apple comes with Java as major subsystem). However that system is not very friendly for external use, at least from our viewpoint. While a Cocoa capable GPC would be cool, this will probably be significant amount of work, and because you'd be the first pascal compiler to do so to my knowledge, that would mean a slow process, lots of additional work (converting demo programs etc, document GPC/Pascal specific workarounds etc) So for now and for some time to come, Pascal on Mac is Carbon, mainly because the barrier to use Cocoa on a large scale is probably very significant. > This is true on a high-level, when no external interfaces are a > concern. When it comes to binary file formats (as you mentioned), or > network protocols, or external binary interfaces (libraries or, like > here, the OS), things such as storage size, alignment and byte order > matter, and those are not described in Pascal. Correct. And it is not just the interfaces, but also demoes, documentation and a nearly all Pascal code available on the Mac. > BTW, in the case of short strings, they're better described as an > array, starting from 0, with the Ord of the 0'th element > representing the length, as e.g. BP does explicitly. A record would > need an Integer field for the length, and, apart from alignment > etc., it's not at all certain this is of the same size as a Char, > even if declared as a subrange (e.g., in GPC it wouldn't be -- > except for a packed record, which in turn wouldn't e.g. allow > passing the elements by reference which e.g. BP short strings do > allow). Also keep in mind that for BP (and the Mac Pascal compilers) the UCSD type was pretty much the only one. While BP had a few pchar helper kludges, these were mostly standalone. However FPC and GPC have other automated first tier stringtypes. This means that besides the stuff that TP can do, additional conversions to the native stringtypes are at least an option. This makes the interface between Carbon UI code or TP legacy code to other parts that use native strings easier. (and avoids that people stick with shortstrings for the rest of their app because of legacy) In practice this means auto conversion by assignment and passing to value parameters. FPC/Delphi do this already. I believe I mentioned this before, but for FPC/Delphi compat it would be absolutely great btw if setlength(stringtype,newlength) was implemented for all string types as opposite of length(). This allows to keep new string code somewhat type (and compiler) independant. The shortstring implementation is simply something like procedure setlength(var s:shortstring;x:integer); begin if x>255 then x:=255; s[0]:=chr(x); end; > -- don't know if that's required). This would generally require > copying the whole string. This is not a problem in general. A hybrid system always has penalties, and people _choose_ to use it. Mostly subsystems are internally one string type, and only the interfaces between the subsystems aren't. Copying conversions are required for literals anyway, but they can't be avoided, since shortstrings are not lazily assigned. > Ironically, converting to C-Strings (input parameters only, as long as the > strings do not contain Chr (0)) is easier, since one can keep the string > in place and only has to add a Chr (0) if space is reserved in advance (as > GPC does). That's why we have less of such problems with C-string based OS > interfaces (POSIX, Dos, Windows, ...), as most strings parameters are > input, and extra work is only required for the few other cases. Delphi/FPC Ansistring does the same. But I believe I described it into detail before already.

3 5

Short Strings
by Peter N Lewis 04 Jul '06

04 Jul '06

Hi all, I know short strings (255 character limit, 0 index containing the length) have been discussed to death, and I'm not going to discuss them further, but I did want to point out for those of you not on the MacPascal mailing list that everyone asking "Which should I use, FPC or GPC?" is basically ending up with FPC primarily because of lack of short string support. I have nothing against FPC, and indeed the developers have been great at supporting Mac compatibility and so forth. But since I use GPC, and since GPC has lots of really cool other features (like long Strings for example ;-), I'd love to encourage people to use GPC. I personally believe the little extra work required to use wrappers for when short strings are needed is no big deal, but it's hard to argue that "its just a little more work" to a developer who is already faced with making a big change in their environment and code. So basically, I'm just saying that the lack of short strings is seriously hindering GPC adoption on the Mac, and that that should probably be taken in to account when pondering the priority of their implementation. Thanks, Peter. -- Check out Interarchy 8.1, just released, now with Amazon S3 support. <http://www.stairways.com/> <http://download.stairways.com/>

3 4

Short String Support
by Joseph Ayers 04 Jul '06

04 Jul '06

> >>May I put in a vote for short (UCSD Pascal) string support. I'm >>trying to revive several legacy programs based on the Think Pascal, >>Codewarrior development environments. See: > >http://rsb.info.nih.gov/nih-image/ for an example. > >Based on my experience so far, I'd say that 80% of the conversion >effort has been dealing with lack of short string support. Concat >being a prime culprit with variable argument lists requiring major >hand coded efforts.. The legacy code base in these environments is >legion in the academic arena. > >Joseph Ayers > >>(BCC to "Jon" who asked basically the same in PM, perhaps related. >>BCC as I don't know if you want your address publicly known, but >>this way you won't get further replies, unless you subscribe to the >>list or read the archives.) >> >>CBFalconer wrote: >> >>> Peter N Lewis wrote: >>> > >>> ... snip ... >>> > >>> > So basically, I'm just saying that the lack of short strings is >>> > seriously hindering GPC adoption on the Mac, and that that should >>> > probably be taken in to account when pondering the priority of their >>> > implementation. >> >>I see. When I have more than a few days to work at GPC (currently, >>I'm stilly busy with other work, you know, the paying kind ...), >>I'll see if I can do it. Unless Waldek beats me to it ... >> >>On a tangent, what do you think is the future of short strings >>anyway? For one, there's the 255 chars limitation. While still >>enough for many purposes, it might not be for some, e.g. file names >>with several long directories etc. could get longer. Does Mac OS >>support those at all, with a different interface, or what? Secondly, >>charsets. When 16-bit charsets (i.e., Unicode) become common (or are >>already), will/should there be a 16-bit "short" string (i.e., max. >>65535 characters)? Or else, if the interfaces will/do use UTF-8, >>we'll need conversions (automatic and/or manual) between Unicode and >>UTF-8 anyway? (As discussed before, UTF-8 doesn't make for a string >>type in Pascal.) Just to figure out if supporting short strings will >>only be a short-lived solution and more work in this area will be >>required soon anyway ... >> >>> You should be using the standard functions for access to the length >>> parameter, after which you don't care how strings are implemented. >>> The so-called short strings are implementable as records if >>> compatibility with existing binaries or files is required. >>> >>> One of the major points of Pascal is simply to eliminate machine >>> dependence, and rely on abstractions. Thus integers are fully >>> described by maxint, and smaller ranges should be typed as >>> subranges, etc. >> >>This is true on a high-level, when no external interfaces are a >>concern. When it comes to binary file formats (as you mentioned), or >>network protocols, or external binary interfaces (libraries or, like >>here, the OS), things such as storage size, alignment and byte order >>matter, and those are not described in Pascal. >> >>BTW, in the case of short strings, they're better described as an >>array, starting from 0, with the Ord of the 0'th element >>representing the length, as e.g. BP does explicitly. A record would >>need an Integer field for the length, and, apart from alignment >>etc., it's not at all certain this is of the same size as a Char, >>even if declared as a subrange (e.g., in GPC it wouldn't be -- >>except for a packed record, which in turn wouldn't e.g. allow >>passing the elements by reference which e.g. BP short strings do >>allow). >> >>AIUI, the Mac Pascal interfaces make heavy use of such short >>strings. One option would be conversion to/from them for every >>input/output parameter (wouldn't work for true reference parameters >>-- don't know if that's required). This would generally require >>copying the whole string. Ironically, converting to C-Strings (input >>parameters only, as long as the strings do not contain Chr (0)) is >>easier, since one can keep the string in place and only has to add a >>Chr (0) if space is reserved in advance (as GPC does). That's why we >>have less of such problems with C-string based OS interfaces (POSIX, >>Dos, Windows, ...), as most strings parameters are input, and extra >>work is only required for the few other cases. >> >>Frank >> >>-- >>Frank Heckenbach, f.heckenbach(a)fh-soft.de, http://fjf.gnu.de/, 7977168E >>GPC To-Do list, latest features, fixed bugs: >>http://www.gnu-pascal.de/todo.html >>GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8 >>(BCC to "Jon" who asked basically the same in PM, perhaps related. >>BCC as I don't know if you want your address publicly known, but >>this way you won't get further replies, unless you subscribe to the >>list or read the archives.) >> >>CBFalconer wrote: >> >>> Peter N Lewis wrote: >>> > >>> ... snip ... >>> > >>> > So basically, I'm just saying that the lack of short strings is >>> > seriously hindering GPC adoption on the Mac, and that that should >>> > probably be taken in to account when pondering the priority of their >>> > implementation. >> >>I see. When I have more than a few days to work at GPC (currently, >>I'm stilly busy with other work, you know, the paying kind ...), >>I'll see if I can do it. Unless Waldek beats me to it ... >> >>On a tangent, what do you think is the future of short strings >>anyway? For one, there's the 255 chars limitation. While still >>enough for many purposes, it might not be for some, e.g. file names >>with several long directories etc. could get longer. Does Mac OS >>support those at all, with a different interface, or what? Secondly, >>charsets. When 16-bit charsets (i.e., Unicode) become common (or are >>already), will/should there be a 16-bit "short" string (i.e., max. >>65535 characters)? Or else, if the interfaces will/do use UTF-8, >>we'll need conversions (automatic and/or manual) between Unicode and >>UTF-8 anyway? (As discussed before, UTF-8 doesn't make for a string >>type in Pascal.) Just to figure out if supporting short strings will >>only be a short-lived solution and more work in this area will be >>required soon anyway ... >> >>> You should be using the standard functions for access to the length >>> parameter, after which you don't care how strings are implemented. >>> The so-called short strings are implementable as records if >>> compatibility with existing binaries or files is required. >>> >>> One of the major points of Pascal is simply to eliminate machine >>> dependence, and rely on abstractions. Thus integers are fully >>> described by maxint, and smaller ranges should be typed as >>> subranges, etc. >> >>This is true on a high-level, when no external interfaces are a >>concern. When it comes to binary file formats (as you mentioned), or >>network protocols, or external binary interfaces (libraries or, like >>here, the OS), things such as storage size, alignment and byte order >>matter, and those are not described in Pascal. >> >>BTW, in the case of short strings, they're better described as an >>array, starting from 0, with the Ord of the 0'th element >>representing the length, as e.g. BP does explicitly. A record would >>need an Integer field for the length, and, apart from alignment >>etc., it's not at all certain this is of the same size as a Char, >>even if declared as a subrange (e.g., in GPC it wouldn't be -- >>except for a packed record, which in turn wouldn't e.g. allow >>passing the elements by reference which e.g. BP short strings do >>allow). >> >>AIUI, the Mac Pascal interfaces make heavy use of such short >>strings. One option would be conversion to/from them for every >>input/output parameter (wouldn't work for true reference parameters >>-- don't know if that's required). This would generally require >>copying the whole string. Ironically, converting to C-Strings (input >>parameters only, as long as the strings do not contain Chr (0)) is >>easier, since one can keep the string in place and only has to add a >>Chr (0) if space is reserved in advance (as GPC does). That's why we >>have less of such problems with C-string based OS interfaces (POSIX, >>Dos, Windows, ...), as most strings parameters are input, and extra >>work is only required for the few other cases. >> >>Frank >> >>-- >>Frank Heckenbach, f.heckenbach(a)fh-soft.de, http://fjf.gnu.de/, 7977168E >>GPC To-Do list, latest features, fixed bugs: >>http://www.gnu-pascal.de/todo.html >>GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8 > > -- Joseph Ayers, Department of Biology and Marine Science Center Northeastern University East Point, Nahant, MA 01908 Phone (781) 581-7370 x309(office), x335(lab) Cellular (617) 755-7523, FAX: (781) 581-6076 eMail: lobster(a)neu.edu AIM: roboplasm SKYPE: cyberplasm http://www.neurotechnology.neu.edu/ http://inls.ucsd.edu/neurobots.html

1 0

Re: Hacking "method variables"
by Frank Heckenbach 21 Jun '06

21 Jun '06

Forwarded from marcov(a)stack.nl (Marco van de Voort): In gmane.comp.compilers.gpc, you wrote: >> Forwarded from marcov(a)stack.nl (Marco van de Voort): >> >> A slight advantage of the delphi method is that it requires dirty syntax to >> do dirty things. That could be seen as a deterrent. > > As a general principle, I agree -- though some (optional) warnings > would also be fine. However, AIUI, what Markus want to do isn't > actually dirty stuff, i.e. all type-safe. One could argue that this leads to partial initialisation(method inited, instantiation not). However that is just a detail. I'd have doubts because I don't think it really is worth inventing new syntax that is marginally cleaner (typesafe), since this form of usage is probably rare, and usually limited to the innerworkings of frameworks anyway. (at least that is the only place I have ever seen such code in Delphi, e.g. central dispatch routines deep in the classes framework) >> Not this moment. But IMHO it should, though we would probably call it a >> "hint" (something that is not _always_ wrong). > > Doesn't this apply to most warnings? No. E.g. portability warnings are not a problem if you are writing a non-portable app. But the compiler doesn't know this intention. Solution, put it on a different level. Also compiletime warnings about possible range problems (e.g. assigning integer to byte) can be very handy to track if you have problems, but generate a lot of noise. All old hat probably, since I assume GPC has a deep warning system? So my remark was more a musing where I would put it in our three level warning system (the three types have names; warnings, hints, notes). IIRC the difference between them, is likeliness of being correct, and frequency, but I noticed that the manual misses a formal description of these levels, I'll make a note about that.

1 1

Compiling GCC+GPC on 64 bit Athlon
by Silvio a Beccara 20 Jun '06

20 Jun '06

Dear list friends, I think this might have been asked already, but I can't find the correct answer in the archives. How does one go about compiling GCC 3.4.3 together with GCC on a 64 bit dual-core Athlon? Here's my cpuinfo information: processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 35 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping : 2 cpu MHz : 2211.354 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext f xsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy bogomips : 4430.51 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp I already tried, but without success, this configure setting: ./configure --enable-languages=pascal --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --enable-shared and I can attach, if needed, the make logfile. I hope you can help me. Kind regards Silvio a Beccara -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Refill s.r.l. - Cartucce compatibili e kit di ricarica per tutti i modelli di stampante. Acquista al telefono o online: consegna in tutta Italia in 48 ore! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5190&d=20-6

2 1

Free Pascal Meeting
by Adriaan van Os 19 Jun '06

19 Jun '06

This weekend, I attended an international meeting of the Free Pascal Development team, hosted by Marco van de Voort in Eindhoven, which happens to be just a few miles from my home. This was an informal meeting with barbecue et al (and Marco trying hard to set his house and garden on fire). A topic that I should mention here, is the many units that FPC has to interface with external packages. For many packages, there are no GPC alternatives being actively maintained. For Mac OS X however, a common set of Pascal interfaces to system software is maintained by a small team, from which interfaces are auto-generated for GPC, FPC and MW Pascal. So, in general, I think working together with the FPC team is a good idea (and for Mac OS X, we already do so actively). Anyway, the FPC team accepts {$ifdef __GPC__} patches to their interfaces and are open to discussions on other solutions. I don't have much time now to look into this, but this may change in say two or three months. Of course, volunteers are welcome. Regards, Adriaan van Os

1 0

Internal compiler error when building on AIX
by Marcus Wirth 16 Jun '06

16 Jun '06

Hi, I'm trying to build GPC (using the sources gpc-20050331.tar.bz2 and gcc-core-3.4.4.tar.bz2) on AIX 5.3. After working for a while the compiler crashes with an "Internal compiler error" (see below). Did anyone succeed building GPC on AIX using the recent sources? Thanks for your help! Marcus /opt/db2/db2bavpi/gpc/build/gcc/xgcc -B/opt/db2/db2bavpi/gpc/build/gcc/ -B/opt/d b2/db2bavpi/powerpc-ibm-aix5.3.0.0/bin/ -B/opt/db2/db2bavpi/powerpc-ibm-aix5.3.0 .0/lib/ -isystem /opt/db2/db2bavpi/powerpc-ibm-aix5.3.0.0/include -isystem /opt/ db2/db2bavpi/powerpc-ibm-aix5.3.0.0/sys-include -O2 -DIN_GCC -W -Wall -Wwrit e-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isys tem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I . -I. -I../../gcc-3.4.3/gcc -I../../gcc-3.4.3/gcc/. -I../../gcc-3.4.3/gcc/../inc lude -I../intl -DL_fixunsdfsi -c ../../gcc-3.4.3/gcc/libgcc2.c -o libgcc/./_fix unsdfsi.o ../../gcc-3.4.3/gcc/libgcc2.c: In function `__fixunsdfsi': ../../gcc-3.4.3/gcc/libgcc2.c:1384: error: unrecognizable insn: (insn:HI 11 10 12 0 ../../gcc-3.4.3/gcc/libgcc2.c:1381 (set (reg:CCEQ 122) (compare:CCEQ (ior:SI (gt:SI (reg:CCFP 121) (const_int 0 [0x0])) (eq:SI (reg:CCFP 121) (const_int 0 [0x0]))) (const_int 1 [0x1]))) -1 (insn_list 10 (nil)) (expr_list:REG_DEAD (reg:CCFP 121) (nil))) ../../gcc-3.4.3/gcc/libgcc2.c:1384: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. gmake[2]: *** [libgcc/./_fixunsdfsi.o] Error 1 gmake[2]: Leaving directory `/opt/db2/db2bavpi/gpc/build/gcc' gmake[1]: *** [libgcc.a] Error 2 gmake[1]: Leaving directory `/opt/db2/db2bavpi/gpc/build/gcc' gmake: *** [all-gcc] Error 2

2 1

Error building GPC on MinGW
by Markus Gerwinski 14 Jun '06

14 Jun '06

Hi Folks, I'm trying to build gpc-20050331 (with the patch from 20050411) in a MinGW/MSys environment on Windows XP. I'm doing ./configure --enable-languages=pascal make ... and `make' then aborts with the error message below. What am I doing wrong? Regards, Markus -- LOG -- make[2]: Entering directory `/mysoftware/gcc-3.4.3/gcc/p/rts' make[2]: Nothing to be done for `generated-files'. make[2]: Leaving directory `/mysoftware/gcc-3.4.3/gcc/p/rts' rm -rf p/docdemos ./p/script/mkdir-p p/docdemos ./p/script/extract-doc-demos -o p/docdemos ./p/doc/*.texi ./p/doc/generated/*.texi ./p/doc/en/*.texi echo timestamp > "p/stamp-docdemos" make[1]: Circular libgcc.a <- pascal dependency dropped. if [ -f specs.ready ] ; then \ true; \ else \ echo timestamp > specs.ready; \ fi (MAKE="make"; srcdir=`cd ./fixinc && ${PWDCMD-pwd}` ; \ CC="gcc"; CFLAGS=" -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE"; LDFLAGS=""; \ WARN_CFLAGS="-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-error"; LIBERTY=`${PWDCMD-pwd}`/"../libiberty/libiberty.a"; \ export MAKE srcdir CC CFLAGS LDFLAGS WARN_CFLAGS LIBERTY; \ cd ./fixinc && \ /bin/sh ${srcdir}/mkfixinc.sh i686-pc-mingw32 i686-pc-mingw32) constructing ../fixinc.sh for i686-pc-mingw32 to run on i686-pc-mingw32 The directory that should contain system headers does not exist: /usr/include make[1]: *** [stmp-fixinc] Error 1 make[1]: Leaving directory `/mysoftware/gcc-3.4.3/gcc' make: *** [all-gcc] Error 2

3 4

Re: Hacking "method variables"
by Frank Heckenbach 13 Jun '06

13 Jun '06

Forwarded from marcov(a)stack.nl (Marco van de Voort): In gmane.comp.compilers.gpc, you wrote: >> It works though with >> uninitialised objects too as long as you don't actually "use" (dereference) >> self: > > I see. But I suppose Markus also wants to call the method via the > procedural variable later and apply it to a certain object instance > (selected at call time), something like (depending on the syntax > chosen): Not possible directly, however messing with the internals (via the tmethod record typecast) is "supported". IOW, people expect it to work on Delphi. procedure test; var localx : somemethodvar; begin localx:=globalmethodvarref; // local copy, avoid global mod of complex constant. tmethod(localx).data:=otherinstance; // maybe typecast to pointer end; the problem is of course that the assignment is not safe. However usually code that messes with instances of procvars is typically framework internal, and not in normal user code, so I don't have a particular problem with it. (at least not enough to invent new syntax) A slight advantage of the delphi method is that it requires dirty syntax to do dirty things. That could be seen as a deterrent. > Of course, that can be a problem -- as always if not carefully used. > BTW, do you warn if taking the address (@) of a normal (non-object) > variable on the stack? Not this moment. But IMHO it should, though we would probably call it a "hint" (something that is not _always_ wrong).

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc