[Issue 15855] "a[{for" causes dmd to segfault

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15855

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||ice
 CC||ag0ae...@gmail.com

--

[Issue 15848] out doesn't call opAssign()

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15848

Alex Parrill  changed:

   What|Removed |Added

 CC||initrd...@gmail.com

--- Comment #3 from Alex Parrill  ---
I don't think opAssign should be called here. Default initialization is not
assignment; declaring a variable does not call opAssign with T.init, it just
copies over T.init.

So the real issue is that `t`'s destructor is not being called when `foo(t)` is
ran.

--

[Issue 15855] New: "a[{for" causes dmd to segfault

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15855

  Issue ID: 15855
   Summary: "a[{for" causes dmd to segfault
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: initrd...@gmail.com

Test file:

a[{for

The first character can be replaced with any valid identifier.

Compiling:

col@col-vm ~> dmd -c test.d
test.d(2): Error: found 'EOF' when expecting '('
test.d(2): Error: found 'EOF' instead of statement
test.d(2): Error: expression expected, not 'EOF'
test.d(2): Error: found 'EOF' when expecting ';' following for condition
test.d(2): Error: expression expected, not 'EOF'
test.d(2): Error: found 'EOF' when expecting ')'
test.d(2): Error: found 'EOF' instead of statement
test.d(2): Error: found 'EOF' when expecting '}' following compound statement
test.d(2): Error: found 'EOF' when expecting ']'
fish: “dmd -c test.d” terminated by signal SIGSEGV (Address boundary error)

Tested on Linux Mint x64 and a recent install of Arch x64, on DMD v2.070.2 and
v2.070.0. The above error uses the fish shell, which generates a slightly
different message than bash on a segfault.

Found by American Fuzzy Lop.

--

[Issue 15854] New: Intrinsic sin function uses buggy hardware fsin instruction

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15854

  Issue ID: 15854
   Summary: Intrinsic sin function uses buggy hardware fsin
instruction
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

It appears that std.math.sin on Intel platforms is compiled into basically a
wrapper around the hardware fsin instruction, which is unfortunately rather
inaccurate.

See:
https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/

Using the code adapted from the above article:

---
import std.math;
import std.stdio;

ulong representation(double d)
{
union U { double ud; ulong ul; }
auto u = U(d);
return u.ul;
}

void main() {
double pi_d = 3.14159265358979323846;
writefln("...0.12345678901234567890");
writefln("double.dig = %d", double.dig);
writefln("real.dig = %d", real.dig);
writefln("  pi = %.33f", pi_d);
writefln(" + %.33f", sin(pi_d));
writefln(" std.math.PI = %.33f", PI);
writefln("actual value = 3.141592653589793238462643383279502(8)...");
writefln("sin(pi_d) = 0x%X", sin(pi_d).representation);
}
---

(The actual value line is obtained from
http://www.math.com/tables/constants/pi.htm, which can be cross-checked with
other online sources for the digits of pi.)

Here's the output:
---
...0.12345678901234567890
double.dig = 15
real.dig = 18
  pi = 3.141592653589793115997963468544185
 + 0.000122460635382237726
 std.math.PI = 3.141592653589793238512808959406186
actual value = 3.141592653589793238462643383279502(8)...
sin(pi_d) = 0x3CA1A600
---

The first line of the output is basically a convenient ruler for easy reference
for digit position.

The equivalent C program, as a comparison:

#include 
#include 

union U { double ud; unsigned long ul; };

unsigned long representation(double d)
{
union U u = { d };
return u.ul;
}

int main() {
double pi_d = 3.14159265358979323846;
printf("...0.1234567890123456789012345678901234567890\n");
printf("  pi = %.33f\n", pi_d);
printf(" + %.33f\n", sin(pi_d));
printf("M_PI = %.33f\n", M_PI);
printf("actual value = 3.141592653589793238462643383279502(8)...\n");
printf("sin(pi_d) = 0x%lX\n", representation(sin(pi_d)));
}


The output (compiled with gcc 5.3.1, glibc 2.22) is:

...0.1234567890123456789012345678901234567890
  pi = 3.141592653589793115997963468544185
 + 0.000122464679914735321
M_PI = 3.141592653589793115997963468544185
actual value = 3.141592653589793238462643383279502(8)...
sin(pi_d) = 0x3CA1A62633145C07


Comparing the output of the C program vs. the D program, we see that in the D
program sin(pi_d) is truncated after 6 hex digits, just as the above linked
article says, as the result of the inaccuracy of the fsin instruction
(disassembly of the executable confirms that fsin is being used).  The
equivalent C code gives the value as 0x3CA1A62633145C07 instead, which is more
like the value of a transcendental function.

Manually adding the digits above (because this is beyond the precision of
double or even real) shows that the C output correctly adds up to 33 digits of
pi, whereas the D output adds up to only 19 correct digits (20 including the
first '3').

As an aside, M_PI as defined by C's math.h gives 15 correct digits of pi
because it uses double precision, whereas std.math.PI gives 18 correct digits
because it uses real (80-bit) precision.

Shouldn't we be using the C library version of sin() (esp. since glibc seems to
have fixed the problem by using a software implementation of sin) instead of
the faulty fsin instruction?

--

[Issue 15836] [REG 2.071-b1] memory error when a class is not implicitly destructed and constructed with new

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15836

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #1 from b2.t...@gmx.com ---
still present in 2.071-b2

--

[Issue 15845] Windows console cannot read properly UTF-8 lines

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15845

--- Comment #3 from ag0ae...@gmail.com ---
(In reply to ag0aep6g from comment #2)
> For -m32 (DIGITAL_MARS_STDIO) it seems to come down to this (with `chcp
> 65001` in the console):
[...]
> That is, Digital Mars's FGETC (_fgetc_nlock) returns -1 for non-ASCII
> characters.
> 
> The issue does not manifest with a pipe: `echo ä | test` works.

The same happens with -m64, and with a simple C++ program (just `printf("%d\n",
fgetc(stdin));`). So apparently `chcp 65001` is not enough to make UTF-8 input
work from the console. I'm not much of a Windows programmer, though, so I have
no idea what's missing.

--

[Issue 1180] the GC failes to handle large allocation requests propperly

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=1180

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||pull
 CC||r.sagita...@gmx.de

--- Comment #3 from Rainer Schuetze  ---
This is unlikely a recent regression, it's already in dmd 2.067.

https://github.com/D-Programming-Language/druntime/pull/1528

--

[Issue 15853] [std.random] save method must be immutable

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15853

--- Comment #1 from Stepan Rogonov  ---
Possible solution(IMHO):

@property typeof(this) save() @safe pure nothrow immutable
{
return this;
}

--

[Issue 15853] New: [std.random] save method must be immutable

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15853

  Issue ID: 15853
   Summary: [std.random] save method must be immutable
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/phobos/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: rogonovste...@gmail.com

Created attachment 1593
  --> https://issues.dlang.org/attachment.cgi?id=1593=edit
definition save method in phobos library on 2016-03-30

can't call save method for immutable Mt19937.
this method must be immutable because it possible to create mutable copy of
immutable object

--

[Issue 15827] std.variant.Variant can not be initialized with some struct

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15827

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/f9aa6f6efc503aacf704dbd677f63b29e37cb63e
Fix Issue 15827. Avoid explicit use of parameter in delegate.

https://github.com/D-Programming-Language/phobos/commit/2f5a8bb99cc821e69c9fbf9d2d4f5f63c76179a4
Merge pull request #4118 from MaksimZh/fix-15827

Fix Issue 15827 -  std.variant.Variant can not be initialized with some struct

--

[Issue 7625] inlining only works with explicit else branch

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=7625

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from hst...@quickfur.ath.cx ---
The fix was incomplete. Here's a test case for which dmd fails to inline a
function that's basically identical to another inlined function, the only
difference being the omission of `else`:

--
int tembo(int x, int y)
{
if (y == 0) return 0;
x++;
return x / y;
}
int pembo(int x, int y)
{
if (y == 0) return 0;
else
{
x++;
return x / y;
}
}
int twiga(int x, int y, int z)
{
auto w = tembo(x, y);
return w * z;
}
int simba(int x, int y, int z)
{
auto w = pembo(x, y);
return w * z;
}
--

Compiling with `dmd -O -inline` and disassembling, I found that twiga still
contains a function call to tembo, whereas simba inlines pembo. Commenting out
the x++ from tembo and pembo causes successful inlining of both functions in
twiga and simba.  So it seems that the inliner is still unable to deal with the
case where the else block (with omitted `else`) contains anything more than
just a simple return statement.

--

[Issue 15852] ICE(cod1) 1669: DMD failed with SIMD code

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15852

Илья Ярошенко  changed:

   What|Removed |Added

   Keywords||ice, ice-on-valid-code

--

[Issue 15849] change in std.uni test leads to magic linking error for d_do_test

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15849

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx
Summary|change in std.ui test leads |change in std.uni test
   |to magic linking error for  |leads to magic linking
   |d_do_test   |error for d_do_test

--

[Issue 15852] New: ICE(cod1) 1669: DMD failed with SIMD code

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15852

  Issue ID: 15852
   Summary: ICE(cod1) 1669: DMD failed with SIMD code
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

import core.simd;

unittest
{
double2 a;
auto ds = foo([a]).array;
}

double2 foo(double2[] a)
{
auto f = a[0];
return f;
}


dmd -unittest -main sum.d
Internal error: backend/cod1.c 1669

--

[Issue 14804] Comparing two Nullables does not check if either is null

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14804

Luís Marques  changed:

   What|Removed |Added

 CC||l...@luismarques.eu

--- Comment #4 from Luís Marques  ---
I've also stumbled on this limitation, but the behavior I was looking forward
to was:

Nullable!int a;
Nullable!int b;
assert(a == b);

Nullable!int c;
Nullable!int d = 42;
assert(c != d);

Since I can see the benefit of using Nullable in these different ways, that
probably means this should be a template parameter.

--

[Issue 15850] Host gh-pages at official repo

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15850

--- Comment #2 from greenify  ---
Clarification: I am referring to
http://rainers.github.io/visuald/visuald/StartPage.html as documentation

--

[Issue 15847] It is not an error to call opAssign on an uninitialized object

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15847

monkeywork...@hotmail.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from monkeywork...@hotmail.com ---
"It simply isn't possible to detect that the variable is void-initialized in
the general case."

While it could be done reasonably well with flow control analysis, I agree that
it's a lot of work for a small return. Thus it makes more sense to disallow
void initialization for types with a custom opAssign.

"But note that void-initialization is already @system..."

Okay, I forgot this point, and it does mitigate my concerns. I will close this
bug.

--

[Issue 15851] New: Access violation when foreaching variadic template argument tuple

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15851

  Issue ID: 15851
   Summary: Access violation when foreaching variadic template
argument tuple
   Product: D
   Version: D2
  Hardware: x86_64
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: normal
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: sunsp...@gmail.com

The long description: Access violation when dereferencing a field in a foreach
of a variadic template argument tuple, when inside a switch case.

dmd is v2.070.2 from the official installer, and the machine is running Windows
8. ldc2 0.17.1 exhibits the same behaviour. Could not test gdc because of
difficulty of installation.


Reduced example (http://dpaste.dzfl.pl/ee9a4503f6f5):

---

import std.stdio;

version = broken;

struct Foo
{
string abc;
int def;
}

void walkArgumentTuple(T...)(ref T tup)
{
top:
final switch (0)
{
foreach (i, ref thing; tup)
{
// thing is invalid for some reason
// but the below doesn't fail
assert(thing is tup[i]);

case 0:
version(broken)
{ 
// object.Error@(0): Access Violation
writeln(thing);
}
else
{
// works
writeln(tup[i]);
}

break top;
}
}
}

void main()
{
Foo f;
walkArgumentTuple(f);
}

---

All tested compilers accept and compile this. It behaves differently depending
on the number (and maybe type) of members of the Foo struct. Likewise if
compiled with or without -m64, and whether parameters are marked as ref or not.
In many combinations it won't error out, but instead spam the screen with
garbage in hex. See the dpaste linked earlier, with version = dpastefreaksout
uncommented.

Foo(x"10 1C 00 00 00 00 00 00 7C FD 45 [... ad nauseam]

I have also had it spout out semi-intelligible things removing ref from
everything, but dpaste can't seem to reproduce that.

Foo("\x04\x10\0\0\0\0\0\0gc.config\0src\\gc\\config.d\0\0\0\0\0", 0)

--

[Issue 15837] [REG 2.071-b1] stdout.writeln not called anymore in static lib

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15837

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15836] [REG 2.071-b1] memory error when a class is not implicitly destructed and constructed with new

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15836

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15850] Host gh-pages at official repo

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15850

--- Comment #1 from greenify  ---
It would also be the nice if the domain then would become more offical, like

visual.dlang.org or visual.dlang.io

I already CNAME-mapped visual.dlang.io to d-programming-language.github.io, so
all you need to do would be to add a CNAME file in the root folder of the
gh-pages within the visuald folder of the d-programming-language account.

--

[Issue 15850] New: Host gh-pages at official repo

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15850

  Issue ID: 15850
   Summary: Host gh-pages at official repo
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: greeen...@gmail.com

Hey it would be nice if the documentation could be moved over to the official
repo. It gets an official touch and also can be modified be other people in
case needed.

--

[Issue 15847] It is not an error to call opAssign on an uninitialized object

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15847

--- Comment #4 from Marc Schütz  ---
It simply isn't possible to detect that the variable is void-initialized in the
general case. Other languages can do that by way of their design (e.g. Rust,
which does extensive data flow analysis, or languages that have a notion of
typestate), but D can't do that. At best, the compiler could try to detect
trivial cases like in your example. But note that void-initialization is
already @system (at least if references are involved), so as ag0aep6g says, the
user is responsible for using it correctly.

--

[Issue 15849] change in std.ui test leads to magic linking error for d_do_test

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15849

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--

[Issue 4142] Missing tags in compiler/druntime/phobos git repositories

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=4142

greenify  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||greeen...@gmail.com
 Resolution|--- |FIXED

--- Comment #5 from greenify  ---
AFAIK phobos and dmd now use git tags to annotate releases. closing.

--

[Issue 11274] Use a CDN for dlang.org

2016-03-30 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=11274

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
I can only recommend CloudFare and for such an high-traffic site like dlang.org
to use a CDN. I had good experiences with CloudFare in the past.

Bumping this as it can be done in ten minutes and adds a huge value to
visitors.

--