digitalmars.D.ldc - LDC 1.2.0-beta1 has been released!
- Kai Nacke (35/35) Mar 18 2017 Hi everyone!
- Joakim (2/7) Mar 20 2017 Great to see this coming so fast! Btw, OS X is now called macOS.
- David Nadlinger via digitalmars-d-ldc (3/4) Mar 21 2017 Well, we still support pre-Sierra, so _technically_… ;)
- Johan Engelen (5/14) Mar 21 2017 kinke has been working hard on it, and.... LDC master is at 2.073
- Radu (30/68) Mar 23 2017 I tested a bit 1.2.0-beta1 as a cross compiler for ARM. Good news
- kinke (3/6) Mar 23 2017 Thanks for testing. Joakim also encountered this error during his
- Joakim (9/40) Mar 23 2017 I have no problem when either cross-compiling or natively
Hi everyone! On behalf of the LDC team I announce the new 1.2.0-beta1 release! It is based on the 2.072.2 front-end and supports LLVM 3.5-4.0. Beside the new front-end there are some more fixes to increase robustness of the compiler. Be sure to read the change log at the GitHub release page for details. The packages are available for download at the same page. https://github.com/ldc-developers/ldc/releases/tag/v1.2.0-beta1 MD5 checksums for the release packages: f6fe3a09ca6593bdb0ceefd9ae4052ca ldc-1.2.0-beta1-src.tar.gz 3262f003d0aa06780bd172cf4bc56a75 ldc2-1.2.0-beta1-freebsd-x86_64.tar.xz 54c6bfafdd7ea8900479c588e7215e9b ldc2-1.2.0-beta1-linux-x86.tar.xz b02aafa9ab888c5392da50dd5f4bb959 ldc2-1.2.0-beta1-linux-x86_64.tar.xz 3dbf34ffd3d38cf44181638a4dc4a65f ldc2-1.2.0-beta1-osx-x86_64.tar.xz 13ffbc95d827eb33a6a7b7e714c542eb ldc2-1.2.0-beta1-win32-msvc.zip a075b10608c641b88f2aeb75cfbfe913 ldc2-1.2.0-beta1-win64-msvc.zip Regarding the binaries: The Linux x86/x86_64 binaries are built on Ubuntu 12.04 LTS with gcc 4.8.x, ldc2 1.2.0-beta1 and LLVM 4.0.0. They work on Ubuntu 12.04 LTS (or later) without installing additional software. The OS X binaries and the FreeBSD binaries are built with LLVM 4.0.0. The Win32 and Win64 MSVC versions are built with VS2015 and LLVM 3.9.1 (due to a regression in LLVM 4.0). Please be sure to report any bugs at https://github.com/ldc-developers/ldc/issues, and feel free to drop by at the digitalmars.D.ldc forums (http://forum.dlang.org/group/digitalmars.D.ldc) for any questions or comments. Thanks to everybody involved in making this happen! Regards, Kai
Mar 18 2017
On Saturday, 18 March 2017 at 08:39:31 UTC, Kai Nacke wrote:Hi everyone! On behalf of the LDC team I announce the new 1.2.0-beta1 release! It is based on the 2.072.2 front-end and supports LLVM 3.5-4.0. [...]Great to see this coming so fast! Btw, OS X is now called macOS.
Mar 20 2017
David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> On 21 Mar 2017, at 7:45, Joakim via digitalmars-d-ldc wrote:Great to see this coming so fast! Btw, OS X is now called macOS.Well, we still support pre-Sierra, so _technically_… ;) — David
Mar 21 2017
On Tuesday, 21 March 2017 at 06:45:28 UTC, Joakim wrote:On Saturday, 18 March 2017 at 08:39:31 UTC, Kai Nacke wrote:kinke has been working hard on it, and.... LDC master is at 2.073 already! :)) JohanHi everyone! On behalf of the LDC team I announce the new 1.2.0-beta1 release! It is based on the 2.072.2 front-end and supports LLVM 3.5-4.0. [...]Great to see this coming so fast!
Mar 21 2017
On Saturday, 18 March 2017 at 08:39:31 UTC, Kai Nacke wrote:Hi everyone! On behalf of the LDC team I announce the new 1.2.0-beta1 release! It is based on the 2.072.2 front-end and supports LLVM 3.5-4.0. Beside the new front-end there are some more fixes to increase robustness of the compiler. Be sure to read the change log at the GitHub release page for details. The packages are available for download at the same page. https://github.com/ldc-developers/ldc/releases/tag/v1.2.0-beta1 MD5 checksums for the release packages: f6fe3a09ca6593bdb0ceefd9ae4052ca ldc-1.2.0-beta1-src.tar.gz 3262f003d0aa06780bd172cf4bc56a75 ldc2-1.2.0-beta1-freebsd-x86_64.tar.xz 54c6bfafdd7ea8900479c588e7215e9b ldc2-1.2.0-beta1-linux-x86.tar.xz b02aafa9ab888c5392da50dd5f4bb959 ldc2-1.2.0-beta1-linux-x86_64.tar.xz 3dbf34ffd3d38cf44181638a4dc4a65f ldc2-1.2.0-beta1-osx-x86_64.tar.xz 13ffbc95d827eb33a6a7b7e714c542eb ldc2-1.2.0-beta1-win32-msvc.zip a075b10608c641b88f2aeb75cfbfe913 ldc2-1.2.0-beta1-win64-msvc.zip Regarding the binaries: The Linux x86/x86_64 binaries are built on Ubuntu 12.04 LTS with gcc 4.8.x, ldc2 1.2.0-beta1 and LLVM 4.0.0. They work on Ubuntu 12.04 LTS (or later) without installing additional software. The OS X binaries and the FreeBSD binaries are built with LLVM 4.0.0. The Win32 and Win64 MSVC versions are built with VS2015 and LLVM 3.9.1 (due to a regression in LLVM 4.0). Please be sure to report any bugs at https://github.com/ldc-developers/ldc/issues, and feel free to drop by at the digitalmars.D.ldc forums (http://forum.dlang.org/group/digitalmars.D.ldc) for any questions or comments. Thanks to everybody involved in making this happen! Regards, KaiI tested a bit 1.2.0-beta1 as a cross compiler for ARM. Good news is that basic stuff like "hello world" works. Really good news, at least for me, is that all this was done on Windows Linux Subsystem [1]. Unfortunately all good news ends as soon I try something more involved, like: ======================================= import std.stdio; void main() { try { throw new Exception("darn!"); } catch(Exception e) { writeln(e.msg); } writeln("Hello world!"); } ======================================= I get: Fatal error in EH code: _Unwind_RaiseException failed with reason code: 9 Aborted The machine I'm running this on is an ARM926EJ-S rev 5, and the ABI used is ARM, EABI5 version 1 soft float. Any idea what might be wrong here? [1] https://msdn.microsoft.com/en-us/commandline/wsl/about
Mar 23 2017
On Thursday, 23 March 2017 at 16:05:55 UTC, Radu wrote:Fatal error in EH code: _Unwind_RaiseException failed with reason code: 9 AbortedThanks for testing. Joakim also encountered this error during his ARM tests, see https://github.com/ldc-developers/ldc/issues/2024.
Mar 23 2017
On Thursday, 23 March 2017 at 16:05:55 UTC, Radu wrote:On Saturday, 18 March 2017 at 08:39:31 UTC, Kai Nacke wrote:I have no problem when either cross-compiling or natively compiling that code for Android/ARM, by using the llvm triple armv7-none-linux-android with ldc 1.2. What llvm triple are you using? It could be that the ARM exception-handling code isn't right for your ARM platform/ABI, as we had similar issues on other ARM platforms till Dan fixed them: https://github.com/ldc-developers/ldc/issues/1283[...]I tested a bit 1.2.0-beta1 as a cross compiler for ARM. Good news is that basic stuff like "hello world" works. Really good news, at least for me, is that all this was done on Windows Linux Subsystem [1]. Unfortunately all good news ends as soon I try something more involved, like: ======================================= import std.stdio; void main() { try { throw new Exception("darn!"); } catch(Exception e) { writeln(e.msg); } writeln("Hello world!"); } ======================================= I get: Fatal error in EH code: _Unwind_RaiseException failed with reason code: 9 Aborted The machine I'm running this on is an ARM926EJ-S rev 5, and the ABI used is ARM, EABI5 version 1 soft float. Any idea what might be wrong here? [1] https://msdn.microsoft.com/en-us/commandline/wsl/about
Mar 23 2017
On Friday, 24 March 2017 at 06:19:34 UTC, Joakim wrote:On Thursday, 23 March 2017 at 16:05:55 UTC, Radu wrote:I tried a couple of things ldc2 -mtriple=arm-none-linux-gnueabi -gcc=arm-linux-gnueabi-gcc Then something closer to my config ldc2 -mtriple=armv4t-none-linux-gnueabi -mcpu=arm9tdmi -gcc=arm-linux-gnueabi-gcc The problem I think is that the system I'm targeting uses ARM, EABI4 version 1 (SYSV), as bellow: readelf -A libc-2.9.so Attribute Section: aeabi File Attributes Tag_CPU_name: "ARM9TDMI" Tag_CPU_arch: v4T Tag_ARM_ISA_use: Yes Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_align_preserved: 8-byte, except leaf SP Tag_ABI_enum_size: int But the app I build uses ARM, EABI5 version 1 (SYSV) Attribute Section: aeabi File Attributes Tag_CPU_name: "5T" Tag_CPU_arch: v5T Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-1 Tag_ABI_PCS_GOT_use: GOT-indirect Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_rounding: Needed Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_enum_size: int Tag_CPU_unaligned_access: v6 Tag_ABI_FP_16bit_format: IEEE 754On Saturday, 18 March 2017 at 08:39:31 UTC, Kai Nacke wrote:I have no problem when either cross-compiling or natively compiling that code for Android/ARM, by using the llvm triple armv7-none-linux-android with ldc 1.2. What llvm triple are you using? It could be that the ARM exception-handling code isn't right for your ARM platform/ABI, as we had similar issues on other ARM platforms till Dan fixed them: https://github.com/ldc-developers/ldc/issues/1283[...]I tested a bit 1.2.0-beta1 as a cross compiler for ARM. Good news is that basic stuff like "hello world" works. Really good news, at least for me, is that all this was done on Windows Linux Subsystem [1]. Unfortunately all good news ends as soon I try something more involved, like: ======================================= import std.stdio; void main() { try { throw new Exception("darn!"); } catch(Exception e) { writeln(e.msg); } writeln("Hello world!"); } ======================================= I get: Fatal error in EH code: _Unwind_RaiseException failed with reason code: 9 Aborted The machine I'm running this on is an ARM926EJ-S rev 5, and the ABI used is ARM, EABI5 version 1 soft float. Any idea what might be wrong here? [1] https://msdn.microsoft.com/en-us/commandline/wsl/about
Mar 24 2017
On Friday, 24 March 2017 at 07:30:58 UTC, Radu wrote:On Friday, 24 March 2017 at 06:19:34 UTC, Joakim wrote:Did a small test in C++ using the gcc cross compiler and exceptions are working with the same ABI and cpu name and arch as the ones I got with ldc. So eabi version is not an issue here.[...]I tried a couple of things ldc2 -mtriple=arm-none-linux-gnueabi -gcc=arm-linux-gnueabi-gcc [...]
Mar 24 2017
On Friday, 24 March 2017 at 08:11:15 UTC, Radu wrote:On Friday, 24 March 2017 at 07:30:58 UTC, Radu wrote:OK, looking up that CPU now, it's an old ARMv5 core, whereas we've tested on ARMv6 at best. If you want to use ldc for that, you may need to help port ldc/druntime to those older embedded cores.On Friday, 24 March 2017 at 06:19:34 UTC, Joakim wrote:Did a small test in C++ using the gcc cross compiler and exceptions are working with the same ABI and cpu name and arch as the ones I got with ldc. So eabi version is not an issue here.[...]I tried a couple of things ldc2 -mtriple=arm-none-linux-gnueabi -gcc=arm-linux-gnueabi-gcc [...]
Mar 24 2017
On Friday, 24 March 2017 at 17:22:31 UTC, Joakim wrote:On Friday, 24 March 2017 at 08:11:15 UTC, Radu wrote:Yes, I would very much like to get ldc to run on those cores - they are used on a lot of industrial controllers. My goal is to put D based software on those controllers. Good news is that some basic stuff works so there is some incentive to try to get the rest of the missing parts running. Please let me know how I can help, mind that I'm not versed in LLVM/LDC nor ARM low-level stuff - but if instructed on where/how to do stuff I can hack around my way. Also, I added a bunch of useful details on the bug you posted https://github.com/ldc-developers/ldc/issues/2024 Cheers, RaduOn Friday, 24 March 2017 at 07:30:58 UTC, Radu wrote:OK, looking up that CPU now, it's an old ARMv5 core, whereas we've tested on ARMv6 at best. If you want to use ldc for that, you may need to help port ldc/druntime to those older embedded cores.On Friday, 24 March 2017 at 06:19:34 UTC, Joakim wrote:Did a small test in C++ using the gcc cross compiler and exceptions are working with the same ABI and cpu name and arch as the ones I got with ldc. So eabi version is not an issue here.[...]I tried a couple of things ldc2 -mtriple=arm-none-linux-gnueabi -gcc=arm-linux-gnueabi-gcc [...]
Mar 24 2017
On Friday, 24 March 2017 at 18:36:32 UTC, Radu wrote:On Friday, 24 March 2017 at 17:22:31 UTC, Joakim wrote:Take a look at my instructions on how to get going for Android here: http://wiki.dlang.org/Build_LDC_for_Android Ignore the section on modifying and compiling llvm if your platform has native Thread-Local Storage (TLS). If so, you can just use a prebuilt llvm, assuming it comes with the ARM backend, as llvm usually does. Here is my small patch for cross-compiling with ldc 1.2, which I just posted online: https://gist.github.com/joakim-noah/ac35132fd2cd0283c45961312d91e214 Use it instead of the larger one linked from the wiki, after modifying it for your platform. In particular, you probably won't need the tgmath exclusion, set the C compiler and other flags as needed for your platform, and you only need look at the stuff for the test-runner custom target, as the test-runner-apk target is particular to Android. Also, you will need to set the llvm triple for cross-compiling, by modifying D_FLAGS, ie change "-w" to "-w;-mtriple=armv5tej-none-linux-gnueabi;-float-abi=soft" and whatever other flags you need. I didn't need to do this because I changed the default target of my custom llvm to Android/ARM, but you need it if using a standard llvm. You won't need to modify druntime and phobos with my Android patches, so follow the rest of the wiki instructions to build a test runner _without_ applying my stdlib patches, and see what modules' tests pass with the resulting test runner. A lot of modules don't deal with exception-handling, particularly in druntime, so you can see the extent of the platform support this way. Compile without any optimizations at first, ie change -O3 to -O0, as those might be screwing things up. If the problem is really only exception-handling, compare the definitions in the druntime/src/ldc/eh modules to those for your platform. It could be something as simple as those basic structs are defined differently. If not, turn on all the debug output there, which you already found, and try to step through with a debugger and see where it's going wrong.On Friday, 24 March 2017 at 08:11:15 UTC, Radu wrote:Yes, I would very much like to get ldc to run on those cores - they are used on a lot of industrial controllers. My goal is to put D based software on those controllers. Good news is that some basic stuff works so there is some incentive to try to get the rest of the missing parts running. Please let me know how I can help, mind that I'm not versed in LLVM/LDC nor ARM low-level stuff - but if instructed on where/how to do stuff I can hack around my way.On Friday, 24 March 2017 at 07:30:58 UTC, Radu wrote:OK, looking up that CPU now, it's an old ARMv5 core, whereas we've tested on ARMv6 at best. If you want to use ldc for that, you may need to help port ldc/druntime to those older embedded cores.On Friday, 24 March 2017 at 06:19:34 UTC, Joakim wrote:Did a small test in C++ using the gcc cross compiler and exceptions are working with the same ABI and cpu name and arch as the ones I got with ldc. So eabi version is not an issue here.[...]I tried a couple of things ldc2 -mtriple=arm-none-linux-gnueabi -gcc=arm-linux-gnueabi-gcc [...]Also, I added a bunch of useful details on the bug you posted https://github.com/ldc-developers/ldc/issues/2024That issue is more about Android and ARMv7, I suggest you open your own issue and apprise us of your progress there.
Mar 24 2017
On Saturday, 25 March 2017 at 04:51:59 UTC, Joakim wrote:On Friday, 24 March 2017 at 18:36:32 UTC, Radu wrote:Thanks for the instruction! Got some time to looks at this again and reported my findings in https://github.com/ldc-developers/ldc/issues/2058[...]Take a look at my instructions on how to get going for Android here: [...]
Apr 03 2017