Gale Paeper wrote:
While trying to get a successful compilation of GPC on Mac OS X 10.11 using AppleâÂÂs LLVM based tool chain, I discovered what looks to be a couple of source code errors in p/statements.c in the expand_pascal_assignment2 functionâÂÂs code. That function is declared with a void return type so there shouldnâÂÂt be any return statements returning a value anywhere within the body of the function but there are two uses of the CHK_EM macro which does expand to a return statement that potentially returns a value (a tree type). Trying to potentially return something into the void of a non-existant return isnâÂÂt technically correct code and I havenâÂÂt found a way to get the LLVM based clang compiler to accept it.
IâÂÂll note that you can get a gnu gcc version 5.2.0 compiler to accept the code when compiling with the -std=gnu89 command line option.
The GPC source code version IâÂÂm trying to get compiling is the Adriaan van OsâÂÂs Mac OS X patched gcc 3.4.6 with the p directory replaced with Waldek HebischâÂÂs git repositoryâÂÂs (https://github.com/hebisch/gpc) p directory source code. The code fragment containing the error producing code starting around line 1231 in file p/statements.c (in expand_pascal_assignment2 functionâÂÂs body) is:
schema_source = undo_schema_dereference (source); schema_target = undo_schema_dereference (target); DEREFERENCE_SCHEMA (source); DEREFERENCE_SCHEMA (target); CHK_EM (source); CHK_EM (target);
The patch below should fix this:
diff --git a/p/statements.c b/p/statements.c index 4904834..e0026b7 100644 --- a/p/statements.c +++ b/p/statements.c @@ -1232,8 +1232,8 @@ expand_pascal_assignment2 (tree target, tree source, int is_init) schema_target = undo_schema_dereference (target); DEREFERENCE_SCHEMA (source); DEREFERENCE_SCHEMA (target); - CHK_EM (source); - CHK_EM (target); + if (EM (source)||EM (target)) + return;
/* Restricted types. @@@@ Maybe this needs further checking */ if (TREE_CODE (source) == CALL_EXPR && PASCAL_TYPE_RESTRICTED (TREE_TYPE (source)))
On Mar 9, 2016, at 6:33 AM, Waldek Hebisch hebisch@math.uni.wroc.pl wrote:
Gale Paeper wrote:
While trying to get a successful compilation of GPC on Mac OS X 10.11 using Appleâs LLVM based tool chain, I discovered what looks to be a couple of source code errors in p/statements.c in the expand_pascal_assignment2 functionâs code. That function is declared with a void return type so there shouldnât be any return statements returning a value anywhere within the body of the function but there are two uses of the CHK_EM macro which does expand to a return statement that potentially returns a value (a tree type). Trying to potentially return something into the void of a non-existant return isnât technically correct code and I havenât found a way to get the LLVM based clang compiler to accept it.
Iâll note that you can get a gnu gcc version 5.2.0 compiler to accept the code when compiling with the -std=gnu89 command line option.
The GPC source code version Iâm trying to get compiling is the Adriaan van Osâs Mac OS X patched gcc 3.4.6 with the p directory replaced with Waldek Hebischâs git repositoryâs (https://github.com/hebisch/gpc) p directory source code. The code fragment containing the error producing code starting around line 1231 in file p/statements.c (in expand_pascal_assignment2 functionâs body) is:
schema_source = undo_schema_dereference (source); schema_target = undo_schema_dereference (target); DEREFERENCE_SCHEMA (source); DEREFERENCE_SCHEMA (target); CHK_EM (source); CHK_EM (target);
The patch below should fix this:
diff --git a/p/statements.c b/p/statements.c index 4904834..e0026b7 100644 --- a/p/statements.c +++ b/p/statements.c @@ -1232,8 +1232,8 @@ expand_pascal_assignment2 (tree target, tree source, int is_init) schema_target = undo_schema_dereference (target); DEREFERENCE_SCHEMA (source); DEREFERENCE_SCHEMA (target);
- CHK_EM (source);
- CHK_EM (target);
if (EM (source)||EM (target))
return;
/* Restricted types. @@@@ Maybe this needs further checking */ if (TREE_CODE (source) == CALL_EXPR && PASCAL_TYPE_RESTRICTED (TREE_TYPE (source)))
For current version (i.e., 10.11) Mac OS X interested builders of gpc, that patch along with configuring to use a gnu based as assembler (to work around stabs based debugging issues) looks to allow compiling a gcc-3.4.6 based gpc with Apple's Xcode 7.x LLVM based clang compiler.
Still no success in getting a working gpc built. Quite a few bootstrapping problems remain; however, I think they are mostly related to linking issues arising from changes in Apple's linker and the continuing OS version dependent revamping of linking requirements. The major headache looks to be wrestling the decade old configure, build, and linker specs (and libraries) into working with Apple's latest linker's expectations.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
Still no success in getting a working gpc built. Quite a few bootstrapping problems remain; however, I think they are mostly related to linking issues arising from changes in Apple's linker and the continuing OS version dependent revamping of linking requirements. The major headache looks to be wrestling the decade old configure, build, and linker specs (and libraries) into working with Apple's latest linker's expectations.
FWIW, you should be able to get all information you need regarding what should or should not be linked depending on which OS X version you are targeting from TLinkerBSD.GetDarwinCrt1ObjName in http://svn.freepascal.org/svn/fpc/trunk/compiler/systems/t_bsd.pas
Also make sure you either install the Xcode command line tools package (sudo xcode-select --install), or specify an SDK to use (linker "-syslibroot XXX" parameter). This is mainly to find the crt1.o and related files (if you don't install the command line tools, they're not in /usr/lib).
Jonas
Dear Gale
Still no success in getting a working gpc built...
Thank you for working on this. It's a great relief to me to see that we have a chance of keeping GPC alive on MacOS for another decade, which I think you will achieve if you get the 10.10 compile going. I am still working on 10.7 because I feared GPC would fail to install on the new OS. If you need someone to test your makefiles and installation, I will buy a new Mac just for the purpose. If you want a place to serve your binaries in the future, I am happy to host them for you on our Pascal page. Okay: neither of those offers is worth much, I suppose, but I hope they show my appreciation.
Yours, Kevan
Kevan:
Still no success in getting a working gpc built...
Thank you for working on this.
I second that!
It's a great relief to me to see that we have a chance of keeping GPC alive on MacOS for another decade, which I think you will achieve if you get the 10.10 compile going. I am still working on 10.7 because I feared GPC would fail to install on the new OS.
It failed for me in 10.10.5. The installation also modified the system sed and that cause me a lot of trouble. Installation scripts must NEVER ever modify system programs!
If you need someone to test your makefiles and installation, I will buy a new Mac just for the purpose. If you want a place to serve your binaries in the future, I am happy to host them for you on our Pascal page. Okay: neither of those offers is worth much, I suppose, but I hope they show my appreciation.
Thanks. There are some not-as-nice alternatives. I have gotten the p2c translator going again under 10.10.5:
https://alum.mit.edu/www/toms/p2c/
FreePascal folks are working on standardizing their compiler so it may also be able to compile eventually. Another possibility is conversion to Ada and then compiling. However, getting GPC going again would be great.
Tom
Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)
Daer Tom,
It failed for me in 10.10.5. The installation also modified the system sed and that cause me a lot of trouble.
Gosh. I'm glad I didn't try.
FreePascal folks are working on standardizing their compiler...
Does that mean they will add support for dynamic schema types? I have considered FreePascal before, but it does not support schema types. All my code makes heavy use of schema types. I could translate to object-oriented, I suppose, but that means introducing new bugs, and none of our users are going to be excited about the prospect of new bugs.
Yours, Kevan
Kevan:
It failed for me in 10.10.5. The installation also modified the system sed and that cause me a lot of trouble.
Gosh. I'm glad I didn't try.
Lucky you!!!
FreePascal folks are working on standardizing their compiler...
Does that mean they will add support for dynamic schema types? I have considered FreePascal before, but it does not support schema types. All my code makes heavy use of schema types. I could translate to object-oriented, I suppose, but that means introducing new bugs, and none of our users are going to be excited about the prospect of new bugs.
I don't know, you could ask them. They were very nice about getting FreePascal to be standard - which was what blocked me previously. Also, I need access to the date and time and they were working out a method for that. Maybe they could accommodate your need.
Although I like GPC a lot I think it is a good idea to have multiple compilers available and running. Then one can cross check them for bugs.
Tom
Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)
Kevan Hashemi wrote:
Daer Tom,
FreePascal folks are working on standardizing their compiler...
Does that mean they will add support for dynamic schema types?
No work has been done on that yet. We have full support for plain ISO standard Pascal in FPC 3.0 (albeit with a bug regarding the program parameters). Extended Pascal support is still missing quite a few things, including schema types.
Jonas
Dear Jonas,
Extended Pascal support is still missing quite a few things, including schema types.
Well, in that case, in another ten years perhaps I'll be able to compile my code with FPC, which would be great. In the meantime, if we can keep GPC going, we could avoid translation.
Yours, Kevan
On Mar 10, 2016, at 8:04 AM, Schneider schneidt@mail.nih.gov wrote:
Kevan:
Still no success in getting a working gpc built...
Thank you for working on this.
I second that!
It's a great relief to me to see that we have a chance of keeping GPC alive on MacOS for another decade, which I think you will achieve if you get the 10.10 compile going. I am still working on 10.7 because I feared GPC would fail to install on the new OS.
It failed for me in 10.10.5. The installation also modified the system sed and that cause me a lot of trouble. Installation scripts must NEVER ever modify system programs!
At least for now, you need a gnu based sed to get GPC built and you need a gnu help2man installed for documentation building and installation. The other utility programs Adriaan's build script build, installs, and system link clobbers aren't necessary since useable versions of them have been part of the system and Xcode tools package for quite some time. (To temporarily workaround stabs debugging info in generated assembly code, I'm also using a separately installed, non-system clobbering gnu based as assembler.)
I'm not sure how to handle satisfying those needs but I definitely agree the base system configuration shouldn't be messed with. Right now as a working approach, I'm doing version specific separate installs in individual version directories in /usr/local/. Since gpc's build machinery can use a SED environment variable to find the sed version to use, I pass in to make a SED set to invoke the gnu based sed and avoid any alterations to the system PATH or system sed linkages. For help2man, I'm doing a temporary addition to PATH to add help2man's installed bin directory to the search PATH.
I'm not too sure how much automation and/or handholding is needed (or desired) for those utility program needs. They are fairly easy to get, build, and install with little or no help if they haven't already been installed for some other reason.
Gale Paeper gpaeper@empirenet.com