[erlang-bugs] HiPe compiler FP inlining crashing

[Björn-Egil Dahlberg]

snarky ..

Before anyone goes on a wild-goose chase, there exists another sample code,
without maps, that also crashes the HiPE compiler on,
- 18.1
- 17.5.6
- OTP_R16B03-1
- OTP_R15B03-1
- stopped testing here .. perhaps the bug is in the original implementation
..

f(A, C, D, E, L) ->
    lists:foldl(fun (X, P) ->
                        AVar = case A of
                                   0 -> 1 / D;
                                   N -> N / C
                               end,
                        BVar = case E of
                                   atom1 -> 1.0;
                                   atom2 -> 0.8;
                                   _ -> E
                               end,
                        CVar = case X of
                                   atom1 -> 0.1 * AVar;
                                   _ -> 1.0
                               end,
                        P * BVar * CVar
                end, 1, L).

Not necessarily the same bug as above but it has the same symptoms, i.e.
function clause on hipe_icode_fp assert_assigned and no_inline_fp compiles
fine.



2015-11-25 22:20 GMT+01:00 Kostis Sagonas <kostis@REDACTED>:

> On 11/25/2015 08:46 PM, Mikael Pettersson wrote:
>
>>   > The code compiles without problem if running the compiler without the
>> +native flag. With the flag, the compiler will crash.
>>   > If compiling with the no_inline_fp flag enabled, the compiler does
>> not crash.
>>
>> I can reproduce the compiler crash with OTP 18.1 on Linux/x86_64, but not
>> with OTP 17.5.
>> The crash is in a sanity check (hipe_icode_fp:assert_assigned/1) at the
>> ICode level, well
>> before any target-dependent code is generated.
>>
>> This could be caused by changes in the BEAM compiler's output, or by some
>> change in HiPE.
>> Presumably a git bisect ought to identify it; care to try that?
>>
>
> I've also looked at this one this afternoon.  I am willing to bet this is
> related to the presence of maps in the code -- most likely due to their
> "better" compilation by BEAM in 18.x.
>
> Given that the code that propagates floating point values in ICode was
> written back in 2003 or so and practically not much changed since then,
> it's not surprising that this code breaks as new types and instructions are
> introduced to the BEAM compiler.
>
> I'll try to find some time to look into this, but would not mind if
> somebody else beats me to it.
>
> Kostis
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20151125/a900f5d8/attachment.htm>