Gpc May 2020

gpc@gnu.de

9 participants
5 discussions

Plan to Update GPC
by Kevan Hashemi 13 Aug '20

13 Aug '20

Dear GPC Collaborators, PROBLEM: MacOS 10.15 does not run 32-bit binaries. My application uses 30k lines of GPC code. The MacOS GPC is 32-bit only. MY FAILURE ON MACOS: The current GPC is compatible with the back-end of GCC 3.4.6 only. The procedure on all platforms is to compile gcc3.4.6 with the GPC sources. With a variety of C-compilers on MacOS (CLANG, GCC-4.9, GCC-5, and GCC-8), I can produce the two cross-compiler executables xgcc and xgpc. These are x86_64 executables. They both compile "Hello World", but they produce only 32-bit objects. When I pass "-m64", they say "Sorry: 64-bit not compiled in". I try building GCC 3.4.6 alone with: config --target=x86_64-apple-darwin make But I get, "Configuration x86_64-apple-darwin16.7.0 not supported". When I apply the same procedure to the GCC 4.9.4 sources, the build proceeds. The GCC 3.4.6 sources support 64-bit targets on Linux, so I was hoping it could do the same on MacOS. I have examined the GCC literature and the contents of gcc/config, but I still don't know what file should be present to provide x86_64 support on apple-darwin. Unless someone tells me otherwise, I'm going to assume that getting the 64-bit MacOS GPC out of GCC 3.4.6 is impossible. Translating all my beautiful, reliable GPC code into another language does not sound like fun. Porting GPC to a newer version of GCC, such as GCC 8, is a possibility, but I understand that the GCC back-end team has a history of being uncooperative with the GPC team. Another solution is to port GPC to LVVM so we can use the CLANG compilers. The LVVM strategy seem like a good one to me: produce platform-independent code that then gets compiled and assembled. If I understand correctly, a CLANG front-end will work on any platform. I would like to hear your advice. I have to solve this problem. I have allocated one thousand hours of my time to get it done. If there is a way to revive GPC with that amount of labor, I'll do it. Best, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://www.bndhep.net

13 34

Re: Plan to Update GPC
by Kevan Hashemi 17 May '20

17 May '20

Dear Waldek, I'm copying the list here, because John Ries is working on the same compile. I have not made any progress in the last week. I spent some time marvelling at magnitude of the changes made by the GCC maintainers in the GCC generic trees code between GCC 4.3.5 and 4.9.4. Attempting to compile GPC in GCC-4.3.5 with a GCC 4.9.4 host compiler, I reported: >> I get 859 duplicate symbol errors like this while compiling gpc1 >> object: >> >> duplicate symbol _default_binds_local_p_1 in: p/varasm.o >> libbackend.a(varasm.o) >> >> They are all of the same form: libbackend.a(xxx.o) conflicts with >> p/xxx.o I remove libbackend.a from the step and get missing >> symbols. To which you replied: > That seems to be incompatible behaviour of linker. 'libbackend.a' is > a library and objects provided by GPC are supposed to effectively > replace corresponding library objects. In other words linker is > supposed to take object from command line and ignore corresponding > object from 'libbackend.a'. On Linux with GNU linker it works as > intended. The default linker on MacOS is the clang linker. There is no binutils port of "as" or "ld" to MacOS. There's that old CTools "as" and "ld" available. I don't know how to force the build to use the CTools linker. > One possible workaround is to tell linker that libbackend.a is a > library replacing 'libbackend.a' by something like '-L. -lbackend'. > Another possiblity is to make unconditional modification to backend > files and skip GPC versions. I have spent a few hours looking at the configure and makefile scripts, trying various flags and options, but my experiments don't work, which has served to show me how little I understand. I edit a makefile and it will be re-written, because I edited the wrong file. My greatest achievement was to persuade the entire build to use the CTools "as", only to find that this assembler won't compile the 64-bit code generated by GCC 4+. >> I remove the duplicating p/xxx.o files and the step works. I >> re-start the build, and it proceeds farther, until xgcc is >> compiling fibheap.c, which aborts with; >> ../../../gcc-4.3.5/libiberty/fibheap.c:258: error: ‘LONG_MIN’ >> undeclared (first use in this function). In that file there is a >> line: >> #define FIBHEAPKEY_MIN LONG_MIN You asked: > So important question is which compilation > works and which fails? Consulting my notes above, the error occurs when xgcc is building fibheap.c. > Second, LONG_MIN comes from standard header > "limits.h". So this looks like typical example of confusion with > location of header files. That would not surprize me. I have 99 copies of limits.h on my hard drive, between various versions of GCC that I have installed, and the SDKs. Best, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://www.bndhep.net

1 0

Failure to build GPC under Linux
by John Ries 16 May '20

16 May '20

The error messages are: ../../gcc-4.3.5/gcc/toplev.c:545:1: error: redefinition of ‘floor_log2’ 545 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:177:1: note: previous definition of ‘floor_log2’ wa s here 177 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ ../../gcc-4.3.5/gcc/toplev.c:580:1: error: redefinition of ‘exact_log2’ 580 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:183:1: note: previous definition of ‘exact_log2’ wa s here 183 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ There is probably a GCC flag to allow such duplicate definitions, but I haven't found it yet (apparently, it isn't -Wnoduplicate-decl-specifier). I'm using the GCC 4.3.5 codebase and building with GCC 9.3.1 under Fedora 31 (x86_64). I'm running configure as follows: SRCDIR=../gcc-4.3.5 export CFLAGS ="-fkeep-inline-functions -W -Wall -Wwrite-strings \ -Wstrict-prototypes -Wmissing-prototypes \ -Wold-style-definition -Wmissing-format-attribute \ -pedantic -Wno-long-long -Wno-variadic-macros \ -Wno-overlength-strings -fno-common \ -Wnoduplicate-decl-specifier" $SRCDIR/configure --program-suffix=-4.3.5 --disable-shared \ --enable-languages=pascal The definition of CFLAGS was my attempt to allow the code to compile. It made no difference. Any ideas as to how to proceed would be greatly appreciated. John L. Ries 26215 197th Ave. SE Covington, WA 98042 (435) 867-8885

3 6

GPC with GCC 4.9.4
by Kevan Hashemi 08 May '20

08 May '20

Dear Waldek, > with GCC-4.3.5. Look at README, for 4.3.5 you need to use '--disable-mapped-location'. I can't get GCC-4.3.5 to compile on MacOS without figuring out a bunch of small modifications. I have GCC-4.9.4 from Home Brew, and that installation applies patches automatically before building. So I started with GCC 4.9.4. The patches for GCC-4.3.5 mostly work, but I had to skip half of them. The patch appears to be Makefile.def and Makefile.in edits. The build proceeds well, with correct identification of the host, build, and target as x86_64-apple-darwin16.7.0. In the libiberty directory, I have 64-bit objects. First error is when going through gpc.h, where it says several times: ../.././gcc/p/gpc.h:290: parse error: GTY must be specified before identifier That's because the newer GCC requires that you provide an "identifier" for each GTY type definitions. The existing "tree_inn" structure is: struct tree_inn GTY(()) I add the identifier "tree_in_gty" like this: struct tree_inn GTY(()) tree_in_gty And do so for all other instances in gpc.h, declarations.c, module.c, and plant.c. Now compilation proceeds to: ../.././gcc/p/plant.c:47: undefined type `varray_type' There is a missing file "varray.h", which appears in GCC-3.4.6, but not in GCC-4.9.4. I'll look into the varray.h problem. Best, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://www.bndhep.net

1 0

Re: Plan to Update GPC
by Kevan Hashemi 08 May '20

08 May '20

Dear Waldek, Thanks for your letter. Somehow I did not get it directly, but found it on-line after Paul mentioned it to me. >> MY FAILURE ON MACOS: The current GPC is compatible with the >> back-end of GCC 3.4.6 only. > No. While little used GCC 4.1.2 port is finished and should work > well. That must have been a fair amount of work, moving from 3.4.6 to 4.1.2. I understand the GCC middle end changed dramatically between 3 and 4. > First step would be to find out earliest GCC which supports 64-bit > Mac OS as target. How can I tell that it supports MacOS 64-bit? > It is possible that GCC-4.3.5 will do, attempting to build gets > beyond "Configuration x86_64-apple-darwin16.7.0 not supported" Ah, so that's the way you tell. You try it and see. > (full build requires Apple tools so I can not check if it works). I have the Command Line Tools (CLT). ASIDE ON CLT (NOT PARTICULARLY IMPORTANT): Building on MacOS, the clang assembler will perform the first build, which produces the xgcc and xgpc compilers. After that, the clang assembler fails because it does not recognise the ".stabs" debug directives produced by xgcc, which is GCC 3.4.6. All the xgcc compilation is done with the debug "-g" flag. The "-g" option is so deeply embedded into the GPC build that I could not get rid of it, even after removing the string "-g" from every file I could find it in. I must have missed the one critical, originating occurance. If I instead use the CTools version of the GNU Assmbler that is provided with CLT, that assembler fails to compile xgcc in the first place, because it cannot compile 64-bit instructions like "movq %xmm0,%rax", where a 128-bit register is moved into a 64-bit register (it complains when it should take the top or bottom 64 bits). So we need one assembler for the host and one for the target. I tried all manner of messing about with environment variables, but could not persuade the build to use two different assemblers for the xgcp and gpc builds. In the end, I let the build fail, edited the gcc makefile, re-configured the gcc makefile, and re-started. But the code produced by the second stage was 32-bit and could not be linked to the 64-bit libraries. If we build on GCC-4, I will be able to use the same assembler, the CLANG assembler, for the entire build. > Anyway, I would suggenst trying http://github.com/hebisch/gpc with GCC-4.3.5. Look at README, for 4.3.5 you need to use '--disable-mapped-location'. Thank you. I have the zip archive. Will start on it soon. Best, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://www.bndhep.net

1 0

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 May 2020