www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - LLVM 3.3 release testing

reply "David Nadlinger" <see klickverbot.at> writes:
LLVM 3.3 is scheduled to be released on June 5th, with RC 1 
already being out.

We should start making sure that there are no regressions 
affecting us ASAP.

There seems to be at least one issue regarding EH: 
https://github.com/ldc-developers/ldc/issues/328 (the std.array, 
std.container, and std.datetime tests fail in release mode, this 
is probably the culprit).

David
May 09 2013
next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
The std.digest failures turned out to be caused by 
TargetTransformInfo not being initialized – not sure whether 
actually requiring it to be present is an LLVM bug or not.

David
May 09 2013
next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 9 May 2013 at 17:56:21 UTC, David Nadlinger wrote:
 The std.digest failures turned out to be caused by 
 TargetTransformInfo not being initialized – not sure whether 
 actually requiring it to be present is an LLVM bug or not.
The druntime_src_rt_arraydouble_release_32 failure seems to be caused by _arraySliceSliceAddSliceAssign_d not being marked as noinline. No idea why this happens, will look into it. David
May 09 2013
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 9 May 2013 at 18:24:46 UTC, David Nadlinger wrote:
 The druntime_src_rt_arraydouble_release_32 failure seems to be 
 caused by _arraySliceSliceAddSliceAssign_d not being marked as 
 noinline.

 No idea why this happens, will look into it.
I really don't like the llvm::Atributes API – their immutable nature in combined with the function names suggesting mutation makes it really easy to write wrong, but perfectly innocent-looking code. Should be fixed in master. David
May 09 2013
parent "Kai Nacke" <kai redstar.de> writes:
On Thursday, 9 May 2013 at 21:02:58 UTC, David Nadlinger wrote:
 On Thursday, 9 May 2013 at 18:24:46 UTC, David Nadlinger wrote:
 The druntime_src_rt_arraydouble_release_32 failure seems to be 
 caused by _arraySliceSliceAddSliceAssign_d not being marked as 
 noinline.

 No idea why this happens, will look into it.
I really don't like the llvm::Atributes API – their immutable nature in combined with the function names suggesting mutation makes it really easy to write wrong, but perfectly innocent-looking code. Should be fixed in master. David
It is also an area with changes in each LLVM release. Kai
May 10 2013
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Thursday, 9 May 2013 at 17:56:21 UTC, David Nadlinger wrote:
 The std.digest failures turned out to be caused by 
 TargetTransformInfo not being initialized – not sure whether 
 actually requiring it to be present is an LLVM bug or not.

 David
I got a SIGSEV in llvm::SelectionDAG::getMemcpy() while compiling the unittest for std.digest.sha. Is this the same problem? Kai
May 09 2013
parent "Kai Nacke" <kai redstar.de> writes:
On Thursday, 9 May 2013 at 18:26:49 UTC, Kai Nacke wrote:
 On Thursday, 9 May 2013 at 17:56:21 UTC, David Nadlinger wrote:
 The std.digest failures turned out to be caused by 
 TargetTransformInfo not being initialized – not sure whether 
 actually requiring it to be present is an LLVM bug or not.

 David
I got a SIGSEV in llvm::SelectionDAG::getMemcpy() while compiling the unittest for std.digest.sha. Is this the same problem? Kai
Yes, it is. SIGSEV is gone with your latest commit. Kai
May 09 2013
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
Remaining failures:
---
         1348 - phobos_std_array_release_run (SEGFAULT)
         1352 - phobos_std_array_release_32_run (SEGFAULT)
         1444 - phobos_std_container_release_run (SEGFAULT)
         1448 - phobos_std_container_release_32_run (SEGFAULT)
         1509 - phobos_std_bigint_debug_32_build (Failed)
         1510 - phobos_std_bigint_debug_32_run (Not Run)
         1511 - phobos_std_bigint_release_32_build (Failed)
         1512 - phobos_std_bigint_release_32_run (Not Run)
         1620 - phobos_std_datetime_release_run (SEGFAULT)
         1624 - phobos_std_datetime_release_32_run (SEGFAULT)
         1845 - phobos_std_internal_math_biguintx86_debug_32_build 
(Failed)
         1846 - phobos_std_internal_math_biguintx86_debug_32_run 
(Not Run)
         1847 - 
phobos_std_internal_math_biguintx86_release_32_build (Failed)
         1848 - phobos_std_internal_math_biguintx86_release_32_run 
(Not Run)
         1853 - 
phobos_std_internal_math_biguintcore_debug_32_build (Failed)
         1854 - phobos_std_internal_math_biguintcore_debug_32_run 
(Not Run)
         1855 - 
phobos_std_internal_math_biguintcore_release_32_build (Failed)
         1856 - 
phobos_std_internal_math_biguintcore_release_32_run (Not Run)
---

None of the issues seems to be a 3.3 regression, but we 
definitely have to do something about 
https://github.com/ldc-developers/ldc/issues/328 if it turns out 
to be an LLVM issue.

David
May 09 2013
next sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Thursday, 9 May 2013 at 21:56:19 UTC, David Nadlinger wrote:
 Remaining failures:
 ---
         1348 - phobos_std_array_release_run (SEGFAULT)
         1352 - phobos_std_array_release_32_run (SEGFAULT)
         1444 - phobos_std_container_release_run (SEGFAULT)
         1448 - phobos_std_container_release_32_run (SEGFAULT)
         1509 - phobos_std_bigint_debug_32_build (Failed)
         1510 - phobos_std_bigint_debug_32_run (Not Run)
         1511 - phobos_std_bigint_release_32_build (Failed)
         1512 - phobos_std_bigint_release_32_run (Not Run)
         1620 - phobos_std_datetime_release_run (SEGFAULT)
         1624 - phobos_std_datetime_release_32_run (SEGFAULT)
         1845 - 
 phobos_std_internal_math_biguintx86_debug_32_build (Failed)
         1846 - phobos_std_internal_math_biguintx86_debug_32_run 
 (Not Run)
         1847 - 
 phobos_std_internal_math_biguintx86_release_32_build (Failed)
         1848 - 
 phobos_std_internal_math_biguintx86_release_32_run (Not Run)
         1853 - 
 phobos_std_internal_math_biguintcore_debug_32_build (Failed)
         1854 - 
 phobos_std_internal_math_biguintcore_debug_32_run (Not Run)
         1855 - 
 phobos_std_internal_math_biguintcore_release_32_build (Failed)
         1856 - 
 phobos_std_internal_math_biguintcore_release_32_run (Not Run)
 ---

 None of the issues seems to be a 3.3 regression, but we 
 definitely have to do something about 
 https://github.com/ldc-developers/ldc/issues/328 if it turns 
 out to be an LLVM issue.

 David
Now I know that I stumbled across some of the failure (std.array, std.container, std.datetime) while I did the Linux/PPC64 port. I did not pay attention to it because I thought it was a PPC64 problem only.... Kai
May 10 2013
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Friday, 10 May 2013 at 16:14:01 UTC, Kai Nacke wrote:
 Now I know that I stumbled across some of the failure 
 (std.array, std.container, std.datetime) while I did the 
 Linux/PPC64 port. I did not pay attention to it because I 
 thought it was a PPC64 problem only....
Without a closer look, it might or might not be the same issue, depending on whether the problem is in the IR-level transformations (unlikely), the LLVM EH codegen or our personality function. I didn't really look at the problem yet besides reducing it, will tackle #340 (std.bigint) first. For everyone just following this thread: The issue in its reduced form (see GitHub #328) occurs also with LLVM 3.2, but is triggered as part of normal testsuite runs with 3.3, likely because of the inliner being more aggressive. Kai, do you have time to look into this, or should I try to squeeze it in my schedule for tomorrow? I'd love to be able to release a beta on Sunday, so that we have a stable base to tackle the 2.063 merge (including shared libraries), DDMD, ARM, etc. from. David
May 10 2013
next sibling parent reply "Michael" <pr m1xa.com> writes:
Would be nice to try a windows build.
May 10 2013
next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Friday, 10 May 2013 at 20:37:27 UTC, Michael wrote:
 Would be nice to try a windows build.
Yep, I'm planning to provide a MinGW one as soon as the beta is out. Fixing Linux/OS X has priority now, though. David
May 10 2013
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Friday, 10 May 2013 at 20:37:27 UTC, Michael wrote:
 Would be nice to try a windows build.
If you like you can try this: http://www.redstar.de/ldc/LDC.zip. md5sum: f10de820f9d559b97433cceb0a090663 It is a build with current LDC head and LLVM 3.4 head for Windows 64bit. Issues: - No exception handling. (EH data is generated with --use-seh64, but this crashes often.) - No codeview symbol generation - Requires linker/MS CRT from VS2012 (at least if using zlib code) Kai
May 11 2013
parent "Michael" <pr m1xa.com> writes:
Nice!
 It is a build with current LDC head and LLVM 3.4 head for 
 Windows 64bit.

 Issues:
 - No exception handling. (EH data is generated with 
 --use-seh64, but this crashes often.)
 - No codeview symbol generation
 - Requires linker/MS CRT from VS2012 (at least if using zlib 
 code)

 Kai
ms stack is not issue)
May 11 2013
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Friday, 10 May 2013 at 19:45:18 UTC, David Nadlinger wrote:
 Kai, do you have time to look into this, or should I try to 
 squeeze it in my schedule for tomorrow? I'd love to be able to 
 release a beta on Sunday, so that we have a stable base to 
 tackle the 2.063 merge (including shared libraries), DDMD, ARM, 
 etc. from.

 David
I try. I already reduced the test case. Kai
May 11 2013
next sibling parent "Michael" <pr m1xa.com> writes:
In Hello world without switches:

d\std\math.d(67): Error: can only import from a
  module, not from a member of module ldc. Did you mean `import 
ldc : intrinsics`
?

d\std\math.d(68): Error: can only import from a
  module, not from a member of module ldc. Did you mean `import 
ldc : llvmasm`?


Win 8 64 bit.
May 11 2013
prev sibling parent "Michael" <pr m1xa.com> writes:
Never mind. It's conflict with source name.
May 11 2013
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 9 May 2013 at 21:56:19 UTC, David Nadlinger wrote:
 Remaining failures:
 ---
         1348 - phobos_std_array_release_run (SEGFAULT)
         1352 - phobos_std_array_release_32_run (SEGFAULT)
         1444 - phobos_std_container_release_run (SEGFAULT)
         1448 - phobos_std_container_release_32_run (SEGFAULT)
         1509 - phobos_std_bigint_debug_32_build (Failed)
         1510 - phobos_std_bigint_debug_32_run (Not Run)
         1511 - phobos_std_bigint_release_32_build (Failed)
         1512 - phobos_std_bigint_release_32_run (Not Run)
         1620 - phobos_std_datetime_release_run (SEGFAULT)
         1624 - phobos_std_datetime_release_32_run (SEGFAULT)
         1845 - 
 phobos_std_internal_math_biguintx86_debug_32_build (Failed)
         1846 - phobos_std_internal_math_biguintx86_debug_32_run 
 (Not Run)
         1847 - 
 phobos_std_internal_math_biguintx86_release_32_build (Failed)
         1848 - 
 phobos_std_internal_math_biguintx86_release_32_run (Not Run)
         1853 - 
 phobos_std_internal_math_biguintcore_debug_32_build (Failed)
         1854 - 
 phobos_std_internal_math_biguintcore_debug_32_run (Not Run)
         1855 - 
 phobos_std_internal_math_biguintcore_release_32_build (Failed)
         1856 - 
 phobos_std_internal_math_biguintcore_release_32_run (Not Run)
 ---
In theory all of these should be gone. Running the test suite on a Linux x86_64 multilib build right now, so we can hopefully tick this off the release checklist. David
May 11 2013
parent "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 11 May 2013 at 22:28:57 UTC, David Nadlinger wrote:
 In theory all of these should be gone. Running the test suite 
 on a Linux x86_64 multilib build right now, so we can hopefully 
 tick this off the release checklist.
Okay, the build is green now. GitHub took the file servers hosting our druntime fork down for maintenance, though, so the CI systems still have to catch up. David
May 11 2013