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

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

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

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

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

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

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

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

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

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