I'm trying to get the Ada gcc front-end to work with LLVM. This series of patches gets things to the point where the Ada compiler builds, though it fails to build itself or the runtime. While I was there I resurrected fortran and java: as with Ada, the compilers build but not the runtimes. Also, I've replaced the gcc 4.0 Ada front-end with a back-port of the Ada front-end from FSF gcc head, since the 4.0 version is known to be weak. All testing done on x86-linux-gnu. No attempt was made to build for other targets. Patch description: 1-usehooks.diff Apple made some backend changes that assume a C-like front-end (C, C++ or ObjC): calls are made to decl_constant_value, iasm_build_bracket and similar routines that mostly aren't defined by the Ada, fortran and java front-ends. However two of the calls, to c_common_type_for_mode and pushdecl, could equivalently be made to a langhook. This patch switches these to langhook calls. 2-stubs.diff This adds a new file that provides dummy implementations for all the routines mentioned in (1) that can't be turned into langhook calls. Putting these in one place means that Ada, java and fortran can be made to compile by simply linking with this file, and no longer need to individually define dummy routines. I made the dummys be weak symbols because java does define some of them. 3-fortran.diff Get fortran to compile: use the common stubs and rip out the incomplete collection of dummy routines someone already put in. With this patch, the fortran build dies at this point: cc1: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:367: void llvm::ScheduleDAG::AddOperand(llvm: :MachineInstr*, llvm::SDOperand, unsigned int, const llvm::TargetInstrDescriptor*, std::map<llvm::SDNode*, unsign ed int, std::less<llvm::SDNode*>, std::allocator<std::pair<llvm::SDNode* const, unsigned int> > >&): Assertion `R egMap->getRegClass(VReg) == RC && "Register class of operand and regclass of use don't agree!"' failed. ../../../gcc.llvm.master/libgfortran/runtime/environ.c:619: internal compiler error: Aborted 4-java.diff Get java to compile: use the common stubs and rip out the incomplete collection of dummy routines someone already put in. With this patch, the java build dies at this point: libffi/src/x86/ffi.c: In function 'ffi_prep_cif_machdep': libffi/src/x86/ffi.c:130: error: duplicate case value libffi/src/x86/ffi.c:129: error: previously used here 5-ada-4.3.diff Replace the ada subdirectory with the one from gcc 4.3. I haven't attached this patch to the email, since even compressed it weighs in at 2.5MB. If it is agreed that this patch series should go in, I will mail it to the appropriate person. The remaining patches make the adjustments needed to get the 4.3 Ada front-end working with the 4.0 infrastructure and with LLVM. 6-build.diff Ada Makefile fixes. 7-vec.diff Ada fixes due to VEC changes. 8-langhooks.diff Ada fixes due to langhook changes. 9-misc.diff Grab-bag of small Ada fixes. 10-fold_build2.diff Convert fold_build2 to fold+build2. 11-tree_invariant.diff Backport recompute_tree_invariant_for_addr_expr from 4.3. 12-optimize.diff The Ada front-end makes use of the optimization level (-O1 etc), however the level is not available in gcc-llvm4. Pretend the optimization level is 2, until a better solution is found. 13-optabs.diff Remove all uses of optabs by Ada. These seem to be left-over from older gcc versions: while optabs are initialized, they are not actually used. 14-decl_rtl.diff Use the LLVM version of make_decl_rtl when compiling for LLVM. 15-gimplifier.diff Backport some gimplifier fixes from 4.3. These almost certainly will have no effect on languages other than Ada. With these patches, the Ada build dies at this point: Unhandled expression! <floor_mod_expr 0x40310c08... The Ada bootstrap dies at this point: <view_convert_expr 0x403c6320... llvm-convert.cpp:4248: static llvm::Constant* TreeConstantToLLVM::Convert(tree_node*): Assertion `0 && "Unknown constant to convert!"' failed. Enjoy! Duncan. -------------- next part -------------- A non-text attachment was scrubbed... Name: 1-usehooks.diff Type: text/x-diff Size: 710 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 2-stubs.diff Type: text/x-diff Size: 4915 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0001.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 3-fortran.diff Type: text/x-diff Size: 2485 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0002.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 4-java.diff Type: text/x-diff Size: 1748 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0003.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 6-build.diff Type: text/x-diff Size: 8670 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0004.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 7-vec.diff Type: text/x-diff Size: 6714 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0005.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 8-langhooks.diff Type: text/x-diff Size: 2251 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0006.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 9-misc.diff Type: text/x-diff Size: 4128 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0007.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 10-fold_build2.diff Type: text/x-diff Size: 1462 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0008.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 11-tree_invariant.diff Type: text/x-diff Size: 3812 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0009.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 12-optimize.diff Type: text/x-diff Size: 979 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0010.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 13-optabs.diff Type: text/x-diff Size: 6091 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0011.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 14-decl_rtl.diff Type: text/x-diff Size: 637 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0012.diff> -------------- next part -------------- A non-text attachment was scrubbed... Name: 15-gimplifier.diff Type: text/x-diff Size: 1127 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/86812888/attachment-0013.diff>
Duncan, It would be useful to know what motivated this work -- in particular, is some organization (company, open source project team, research group, any other kind) interested in having an Ada front-end? Thanks, --Vikram ---------------------------------------------------------------------- VIKRAM S. ADVE Associate Professor, Computer Science E-MAIL: vadve at cs.uiuc.edu Siebel Center for Computer Science PHONE: (217) 244-2016 Univ. of Illinois at Urbana-Champaign FAX: (217) 265-6582 201 N. Goodwin Ave. http://www.cs.uiuc.edu/~vadve Urbana IL 61801-2302. http://llvm.cs.uiuc.edu/ ---------------------------------------------------------------------- On Jan 11, 2007, at 11:43 AM, Duncan Sands wrote:> I'm trying to get the Ada gcc front-end to work with LLVM. > This series of patches gets things to the point where the > Ada compiler builds, though it fails to build itself or the > runtime. While I was there I resurrected fortran and > java: as with Ada, the compilers build but not the runtimes. > Also, I've replaced the gcc 4.0 Ada front-end with a back-port > of the Ada front-end from FSF gcc head, since the 4.0 version > is known to be weak. > > All testing done on x86-linux-gnu. No attempt was made to build > for other targets. > > Patch description: > > 1-usehooks.diff > Apple made some backend changes that assume a C-like > front-end (C, C++ or ObjC): calls are made to decl_constant_value, > iasm_build_bracket and similar routines that mostly aren't defined > by the Ada, fortran and java front-ends. However two of the calls, > to c_common_type_for_mode and pushdecl, could equivalently be made > to a langhook. This patch switches these to langhook calls. > > 2-stubs.diff > This adds a new file that provides dummy implementations > for all the routines mentioned in (1) that can't be turned into > langhook calls. Putting these in one place means that Ada, java > and fortran can be made to compile by simply linking with this > file, and no longer need to individually define dummy routines. > I made the dummys be weak symbols because java does define some > of them. > > 3-fortran.diff > Get fortran to compile: use the common stubs and rip out > the incomplete collection of dummy routines someone already put in. > With this patch, the fortran build dies at this point: > > cc1: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:367: void > llvm::ScheduleDAG::AddOperand(llvm: > :MachineInstr*, llvm::SDOperand, unsigned int, const > llvm::TargetInstrDescriptor*, std::map<llvm::SDNode*, unsign > ed int, std::less<llvm::SDNode*>, > std::allocator<std::pair<llvm::SDNode* const, unsigned int> > >&): > Assertion `R > egMap->getRegClass(VReg) == RC && "Register class of operand and > regclass of use don't agree!"' failed. > ../../../gcc.llvm.master/libgfortran/runtime/environ.c:619: > internal compiler error: Aborted > > > 4-java.diff > Get java to compile: use the common stubs and rip out > the incomplete collection of dummy routines someone already put in. > With this patch, the java build dies at this point: > libffi/src/x86/ffi.c: In function 'ffi_prep_cif_machdep': > libffi/src/x86/ffi.c:130: error: duplicate case value > libffi/src/x86/ffi.c:129: error: previously used here > > 5-ada-4.3.diff > Replace the ada subdirectory with the one from gcc 4.3. > I haven't attached this patch to the email, since even compressed > it weighs in at 2.5MB. If it is agreed that this patch series should > go in, I will mail it to the appropriate person. > > The remaining patches make the adjustments needed to get the 4.3 Ada > front-end working with the 4.0 infrastructure and with LLVM. > > 6-build.diff > Ada Makefile fixes. > > 7-vec.diff > Ada fixes due to VEC changes. > > 8-langhooks.diff > Ada fixes due to langhook changes. > > 9-misc.diff > Grab-bag of small Ada fixes. > > 10-fold_build2.diff > Convert fold_build2 to fold+build2. > > 11-tree_invariant.diff > Backport recompute_tree_invariant_for_addr_expr from 4.3. > > 12-optimize.diff > The Ada front-end makes use of the optimization level (-O1 etc), > however the level is not available in gcc-llvm4. Pretend the > optimization > level is 2, until a better solution is found. > > 13-optabs.diff > Remove all uses of optabs by Ada. These seem to be left-over from > older gcc versions: while optabs are initialized, they are not > actually > used. > > 14-decl_rtl.diff > Use the LLVM version of make_decl_rtl when compiling for LLVM. > > 15-gimplifier.diff > Backport some gimplifier fixes from 4.3. These almost certainly > will have no effect on languages other than Ada. > > With these patches, the Ada build dies at this point: > Unhandled expression! > <floor_mod_expr 0x40310c08... > > The Ada bootstrap dies at this point: > <view_convert_expr 0x403c6320... > llvm-convert.cpp:4248: static llvm::Constant* > TreeConstantToLLVM::Convert(tree_node*): Assertion `0 && "Unknown > constant to convert!"' failed. > > > Enjoy! > > Duncan. > <1-usehooks.diff> > <2-stubs.diff> > <3-fortran.diff> > <4-java.diff> > <6-build.diff> > <7-vec.diff> > <8-langhooks.diff> > <9-misc.diff> > <10-fold_build2.diff> > <11-tree_invariant.diff> > <12-optimize.diff> > <13-optabs.diff> > <14-decl_rtl.diff> > <15-gimplifier.diff> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070111/594084b3/attachment.html>
> It would be useful to know what motivated this work -- in particular, > is some organization (company, open source project team, research > group, any other kind) interested in having an Ada front-end? Thanks,Hi Vikram, I'm doing this on my own time, for fun. If, however, it proves to be successful, I suppose ACT (Ada Core Technologies, the company that maintains the Ada front-end) might become interested (they have already ported the Ada front-end to a number of different backends, most recently .net). A number of open-source Ada guys I know have expressed an interest in playing with it. And lurking around in the back of my mind is the possibility that my own company (which has a lot of Ada code) might find it useful. But for the moment I'm just testing the water. Best wishes, Duncan.
On Thu, 11 Jan 2007, Duncan Sands wrote:> I'm trying to get the Ada gcc front-end to work with LLVM. > This series of patches gets things to the point where the > Ada compiler builds, though it fails to build itself or the > runtime. While I was there I resurrected fortran and > java: as with Ada, the compilers build but not the runtimes. > Also, I've replaced the gcc 4.0 Ada front-end with a back-port > of the Ada front-end from FSF gcc head, since the 4.0 version > is known to be weak.Cool. Can you post these patches individually to llvm-commits in an order that is easiest to review? For example, obvious makefile changes and target independent things we can apply now. Replacing the entire Ada front-end should wait until it works better. Nice work, -Chris> All testing done on x86-linux-gnu. No attempt was made to build > for other targets. > > Patch description: > > 1-usehooks.diff > Apple made some backend changes that assume a C-like > front-end (C, C++ or ObjC): calls are made to decl_constant_value, > iasm_build_bracket and similar routines that mostly aren't defined > by the Ada, fortran and java front-ends. However two of the calls, > to c_common_type_for_mode and pushdecl, could equivalently be made > to a langhook. This patch switches these to langhook calls. > > 2-stubs.diff > This adds a new file that provides dummy implementations > for all the routines mentioned in (1) that can't be turned into > langhook calls. Putting these in one place means that Ada, java > and fortran can be made to compile by simply linking with this > file, and no longer need to individually define dummy routines. > I made the dummys be weak symbols because java does define some > of them. > > 3-fortran.diff > Get fortran to compile: use the common stubs and rip out > the incomplete collection of dummy routines someone already put in. > With this patch, the fortran build dies at this point: > > cc1: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:367: void llvm::ScheduleDAG::AddOperand(llvm: > :MachineInstr*, llvm::SDOperand, unsigned int, const llvm::TargetInstrDescriptor*, std::map<llvm::SDNode*, unsign > ed int, std::less<llvm::SDNode*>, std::allocator<std::pair<llvm::SDNode* const, unsigned int> > >&): Assertion `R > egMap->getRegClass(VReg) == RC && "Register class of operand and regclass of use don't agree!"' failed. > ../../../gcc.llvm.master/libgfortran/runtime/environ.c:619: internal compiler error: Aborted > > > 4-java.diff > Get java to compile: use the common stubs and rip out > the incomplete collection of dummy routines someone already put in. > With this patch, the java build dies at this point: > libffi/src/x86/ffi.c: In function 'ffi_prep_cif_machdep': > libffi/src/x86/ffi.c:130: error: duplicate case value > libffi/src/x86/ffi.c:129: error: previously used here > > 5-ada-4.3.diff > Replace the ada subdirectory with the one from gcc 4.3. > I haven't attached this patch to the email, since even compressed > it weighs in at 2.5MB. If it is agreed that this patch series should > go in, I will mail it to the appropriate person. > > The remaining patches make the adjustments needed to get the 4.3 Ada > front-end working with the 4.0 infrastructure and with LLVM. > > 6-build.diff > Ada Makefile fixes. > > 7-vec.diff > Ada fixes due to VEC changes. > > 8-langhooks.diff > Ada fixes due to langhook changes. > > 9-misc.diff > Grab-bag of small Ada fixes. > > 10-fold_build2.diff > Convert fold_build2 to fold+build2. > > 11-tree_invariant.diff > Backport recompute_tree_invariant_for_addr_expr from 4.3. > > 12-optimize.diff > The Ada front-end makes use of the optimization level (-O1 etc), > however the level is not available in gcc-llvm4. Pretend the optimization > level is 2, until a better solution is found. > > 13-optabs.diff > Remove all uses of optabs by Ada. These seem to be left-over from > older gcc versions: while optabs are initialized, they are not actually > used. > > 14-decl_rtl.diff > Use the LLVM version of make_decl_rtl when compiling for LLVM. > > 15-gimplifier.diff > Backport some gimplifier fixes from 4.3. These almost certainly > will have no effect on languages other than Ada. > > With these patches, the Ada build dies at this point: > Unhandled expression! > <floor_mod_expr 0x40310c08... > > The Ada bootstrap dies at this point: > <view_convert_expr 0x403c6320... > llvm-convert.cpp:4248: static llvm::Constant* TreeConstantToLLVM::Convert(tree_node*): Assertion `0 && "Unknown constant to convert!"' failed. > > > Enjoy! > > Duncan. >-Chris -- http://nondot.org/sabre/ http://llvm.org/