Matt Gamble wrote:
Ok, this has been submitted as a bug.
https://issues.dlang.org/show_bug.cgi?id=18573
thank you.
On Wednesday, 7 March 2018 at 21:39:58 UTC, ketmar wrote:
Matt Gamble wrote:
On Wednesday, 7 March 2018 at 21:02:30 UTC, ag0aep6g wrote:
On 03/07/2018 09:09 PM, ag0aep6g wrote:
[...]
With `real` instead of `double` x86_64 is also affected.
Wow. Good to know I'm not crazy. I was afk for a
Matt Gamble wrote:
On Wednesday, 7 March 2018 at 21:02:30 UTC, ag0aep6g wrote:
On 03/07/2018 09:09 PM, ag0aep6g wrote:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
On Wednesday, 7 March 2018 at 21:02:30 UTC, ag0aep6g wrote:
On 03/07/2018 09:09 PM, ag0aep6g wrote:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
ag0aep6g wrote:
On 03/07/2018 09:09 PM, ag0aep6g wrote:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
double b = 2;
assert(b == 2); /*
On 03/07/2018 09:09 PM, ag0aep6g wrote:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
double b = 2;
assert(b == 2); /* fails; should pass
H. S. Teoh wrote:
On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn
wrote:
[...]
it looks like ignoring `double` result causes FPU stack imbalance
('cause compiler doesn't insert "FPU pop" instruction), and that
affects the computations.
on 64 bit it doesn't matter,
H. S. Teoh wrote:
On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn
wrote:
[...]
it looks like ignoring `double` result causes FPU stack imbalance
('cause compiler doesn't insert "FPU pop" instruction), and that
affects the computations.
on 64 bit it doesn't matter,
On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn wrote:
[...]
> it looks like ignoring `double` result causes FPU stack imbalance
> ('cause compiler doesn't insert "FPU pop" instruction), and that
> affects the computations.
>
> on 64 bit it doesn't matter, 'cause no FPU
Steven Schveighoffer wrote:
it seems that the only difference between `void` and `double` lambda is one
asm instruction: `fldl (%edi)`. it is presend in `double` labmda, and
absent in `void` lambda.
it looks like ignoring `double` result causes FPU stack imbalance ('cause
compiler doesn't
On 3/7/18 3:09 PM, ag0aep6g wrote:
On 03/07/2018 08:54 PM, Steven Schveighoffer wrote:
Clearly there is some codegen issue here.
It's beautiful:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void)
On 03/07/2018 08:54 PM, Steven Schveighoffer wrote:
Looking at each, it looks like it does this:
cast(void) unaryFun!pred(r.front);
So I tried this:
auto pred = i => a[i] = a[i-1] + 2;
foreach(i; 1 .. a.length)
cast(void)pred(i);
And I see the -nan value. Remove the cast(void) and I
On 3/7/18 1:57 PM, Matt Gamble wrote:
This is a record for me with two 32bit vs 64bit issues in one day. Seems
to be a problem with using "each" under 32bit which can be fixed by
using foreach or switching to x64. Am I doing something wrong or is this
the second bug I've found today?
Below
On 03/07/2018 10:57 AM, Matt Gamble wrote:
This is a record for me with two 32bit vs 64bit issues in one day. Seems
to be a problem with using "each" under 32bit which can be fixed by
using foreach or switching to x64. Am I doing something wrong or is this
the second bug I've found today?
This is a record for me with two 32bit vs 64bit issues in one
day. Seems to be a problem with using "each" under 32bit which
can be fixed by using foreach or switching to x64. Am I doing
something wrong or is this the second bug I've found today?
Below is a silly case, that replicates an
15 matches
Mail list logo
