Cryptic bug for DMD v2.087.x

[Peter Jacobs]

On Monday, 12 August 2019 at 04:01:28 UTC, Nicholas Wilson wrote:
> On Monday, 12 August 2019 at 01:45:24 UTC, Peter Jacobs wrote:
>> We have a flow simulation code 
>> (http://cfcfd.mechmining.uq.edu.au/eilmer/) that fails to 
>> build optimized with DMD v2.087.0 or v2.087.1.  The cryptic 
>> message at the end of the attempt to build is:
>>   tym = x14
>>   makefile:414: recipe for target 'e4shared' failed
>>   make: *** [e4shared] Illegal instruction (core dumped)
>> and the compiler flags are:
>>   dmd -w -O -release -inline -boundscheck=off -dip1008 ...
>>
>> The build is successful if we omit the -O flag.
>>
>> In contrast, we have successful optimized builds for DMD 
>> 2.086.1 and LDC 1.17.0-beta1.
>>
>> I can provide more details but I was thinking that the "tym = 
>> x14" might already mean something to someone familiar with the 
>> insides of DMD.
>>
>> Best regards,
>> Peter J.
>
> That looks like 
> https://github.com/dlang/dmd/blob/eda232a9f72b482c92cefb27a4321afc0aedbb5c/src/dmd/backend/cgxmm.d#L816-L817 or https://github.com/dlang/dmd/blob/eda232a9f72b482c92cefb27a4321afc0aedbb5c/src/dmd/backend/cgxmm.d#L716-L717 (or maybe https://github.com/dlang/dmd/blob/8623bbbebe35b9a320ba20e521a6c0ee51a780ac/src/dmd/backend/evalu8.d#L905 )
>
> Can you run it in a debugger and provide a stack trace to 
> confirm?
>
> tym = 0x14 corresponds to real (== 80 bit fp), which is best 
> avoided if possible as it is very slow.
>
> Also, silly question, why would you use DMD, with 
> optimisations, for cfd? surely your productivity is runtime 
> bottlenecked?

Nicholas,
Not a silly question.  Yes, the run time is dominated by 
crunching numbers but most of the core of the code is @nogc and 
we find that there is little run-time difference between DMD64 
and LDC generated executables.  It turns out that, for the 
complex-numbers plus optimized flavour of the code, we need to 
use the ldc compiler because of another (longer term) bug.  I 
thought that I would report the recent change in compiler 
behaviour while it was fresh.  For development runs, which is 
mostly what I do, I generally find the debug build and profiling 
provided by dmd to be convenient.  The other members of our CFD 
group who do large parallel calculations mainly build with ldmd2.

As for the 80-bit FP nature of the problem, I don't deliberately 
use 80-bit variables.  Is there a way to easily identify where I 
force the use of 80-bit variables upon the compiler?  I expect 
that operations with temporary results that stay within the 
floating-point registers will probably use 80-bit values but I 
cannot think of any places where I have wanted to retain 80-bits 
when storing data in my variables.

Peter J.