[Issue 7583] [CTFE] ICE with tuple and alias this

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7583



--- Comment #3 from github-bugzi...@puremagic.com 2012-02-29 23:58:47 PST ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/bcfd90aae05bd6259212ec870b2c037569029d77
Merge pull request #773 from 9rnsr/fix7583

fix Issue 7583 - [CTFE] ICE with tuple and alias this

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7617] New: Add support for 64bit and 256bit vectors

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7617

   Summary: Add support for 64bit and 256bit vectors
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: turkey...@gmail.com


--- Comment #0 from Manu turkey...@gmail.com 2012-03-01 00:51:26 PST ---
Many SSE opcodes interact with MMX regs, that is, 128bit vectors interacting
with 64bit vectors.
We currently have no expression of the MMX regs in the language.
Consider adding float2, short4, etc?

AVX is common now, has 256bit regs, I'd also like to start making use of this
architecture.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7251] GC not working

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7251


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||clugd...@yahoo.com.au
 Resolution||INVALID


--- Comment #3 from Don clugd...@yahoo.com.au 2012-03-01 01:22:39 PST ---
(In reply to comment #2)
 Just wondering, why was this marked as Resolved, Invalid with no comment?

Huh? Comment #1 was added when it was closed. Reclosing.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7251] GC not working

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7251


wfunct...@hotmail.com changed:

   What|Removed |Added

 Resolution|INVALID |REMIND


--- Comment #4 from wfunct...@hotmail.com 2012-03-01 02:01:33 PST ---
(In reply to comment #3)
 (In reply to comment #2)
  Just wondering, why was this marked as Resolved, Invalid with no comment?
 
 Huh? Comment #1 was added when it was closed. Reclosing.

Wait what?

This looks like false pointers [...] We really need precise heap scanning.

Doesn't that mean this needs to be fixed? Or is one of us misunderstanding the
meaning of the above?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7251] GC not working

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7251



--- Comment #5 from Don clugd...@yahoo.com.au 2012-03-01 03:39:55 PST ---
(In reply to comment #4)
 (In reply to comment #3)
  (In reply to comment #2)
   Just wondering, why was this marked as Resolved, Invalid with no 
   comment?
  
  Huh? Comment #1 was added when it was closed. Reclosing.
 
 Wait what?
 
 This looks like false pointers [...] We really need precise heap scanning.
 
 Doesn't that mean this needs to be fixed? Or is one of us misunderstanding the
 meaning of the above?

No, it's inevitable that a mark-and-sweep GC on a 32 bit system won't work if
large numbers of false pointers are present. And this code:

   foreach (i; 0 .. count)
a ~= i;

is flooding the system with false pointers.

You marked this as regression, is there any previous compiler where this
worked?
(reopen if it there is).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7618] New: delegate/function pointer call bypass parameter storage class

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7618

   Summary: delegate/function pointer call bypass parameter
storage class
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Keywords: accepts-invalid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com


--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-03-01 03:51:02 PST ---
Test case:

void foo(const int x)
{
int func(ref int) { return 1; }
func(x);
// Error: function test.foo.func (ref int x) is not callable
// using argument types (const(int))
/ -- OK

int delegate(ref int) dg = (ref int x) = 1;
dg(x);
// -- compiles without error, bad!

int function(ref int) fp = (ref int x) = 1;
fp(x);
// -- compiles without error, bad!
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7618] delegate/function pointer call bypass parameter storage class

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7618


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

   Keywords||pull


--- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-03-01 04:12:51 PST ---
https://github.com/D-Programming-Language/dmd/pull/776

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7610] DMD -H switch doesn't output interfaces to package hierarchy

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7610


Rene Zwanenburg renezwanenb...@gmail.com changed:

   What|Removed |Added

 AssignedTo|nob...@puremagic.com|renezwanenb...@gmail.com


--- Comment #2 from Rene Zwanenburg renezwanenb...@gmail.com 2012-03-01 
05:48:50 PST ---
Created an attachment (id=1079)
Improves documentation of -op switch in dcompiler.dd

Created patch for the compiler documentation in dcompiler.dd, the documentation
now states the -op switch also keeps file paths for interface and Ddoc files.
The -Dd, -Hd, and -od switches now mention the -op switch.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7619] New: Broken deprecated feature with template function

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7619

   Summary: Broken deprecated feature with template function
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com


--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-03-01 06:00:00 PST ---
I think following code should compile with and without -d switch.

test.d

void main(){}

void foo(T)(T t){}  // line 3

deprecated struct S{}

deprecated void test()
{
S s;
foo(s);   // line 10
// foo is instantiated with deprecated struct S.
}

command line

dmd -run test.d

output:

test.d(3): Error: struct test.S is deprecated
test.d(10): Error: template instance test.foo!(S) error instantiating

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6857] Precondition contract checks should be statically bound.

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6857


jens.k.muel...@gmx.de changed:

   What|Removed |Added

 CC||jens.k.muel...@gmx.de


--- Comment #1 from jens.k.muel...@gmx.de 2012-03-01 07:22:17 PST ---
Can you elaborate why the static type must be considered? What's the problem
with using the dynamic type?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6857] Precondition contract checks should be statically bound.

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6857


deadalnix deadal...@gmail.com changed:

   What|Removed |Added

 CC||deadal...@gmail.com


--- Comment #2 from deadalnix deadal...@gmail.com 2012-03-01 07:40:10 PST ---
(In reply to comment #1)
 Can you elaborate why the static type must be considered? What's the problem
 with using the dynamic type?

The problem is simple. Let's consider a class A and a subclass B.

Then a function as this :

void fun(A a) {
a.foo();
}

If passed an element of type B, fun will work, because B is a subclass of A. If
B.foo's contract is different than A.foo's, then B.foo's in contract is
executed.

It is a bug, because fun has no knowledge weither it manipulate an element of
type A or an element of type B. It means that fun must respect the in contract
provided by A.foo, because in other case, it may or may no work, depending on
how fun in called, which isn't a reliable behavior.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7619] Broken deprecated feature with template function

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7619


Stewart Gordon s...@iname.com changed:

   What|Removed |Added

 CC||s...@iname.com


--- Comment #1 from Stewart Gordon s...@iname.com 2012-03-01 09:10:41 PST ---
It seems to me the compiler generates

void fooS(S t) {}

but once the time's come to semantically analyse the instance, it has forgotten
what created it in the first place.

Perhaps what's needed is: If when semantically analysing a template instance a
deprecated symbol is hit, flag the template instance as deprecated.  Then only
if non-deprecated code references it will an error be generated.

The complication is that the error shown to the user should be about the
original deprecated symbol.  This can be achieved by accommodating in the
propagated deprecation flag a note of the original deprecation.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6892] Formatted write with specified length of enum member

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6892



--- Comment #3 from github-bugzi...@puremagic.com 2012-03-01 09:20:32 PST ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/b5256c57f64fa823ca8ba200d343674d6556c75c
Merge pull request #465 from 9rnsr/fix6892

Issue 6892 - Formatted write with specified length of enum member

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7620] New: format has different output compared to writef

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7620

   Summary: format has different output compared to writef
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com


--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-03-01 
09:58:29 PST ---
import std.string;
import std.stdio;

enum Foo { foo, bar }

void main()
{
Foo foo;
writefln(%s, foo);
writeln(format(%s, foo));
}

Prints:
foo
0

I really think these two should be in sync with each other. It's hard to switch
from writef debugging to log-based debugging when writef does one thing and
format() does another.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7620] format has different output compared to writef

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7620


bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc


--- Comment #1 from bearophile_h...@eml.cc 2012-03-01 10:09:16 PST ---
See also issue 7571

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7583] [CTFE] ICE with tuple and alias this

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7583


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7617] Add support for 64bit and 256bit vectors

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7617


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com


--- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-03-01 
11:52:59 PST ---
I don't see any need to support MMX. I think it is completely superceded by
XMM.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7617] Add support for 64bit and 256bit vectors

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7617


Sean Cavanaugh worksonmymach...@gmail.com changed:

   What|Removed |Added

 CC||worksonmymach...@gmail.com


--- Comment #2 from Sean Cavanaugh worksonmymach...@gmail.com 2012-03-01 
12:01:14 PST ---
FYI info:

MMX itself is a big pain in in x86 mode, as it shares registers with the FPU
stack and all MMX code needs to flush the register state before calling FPU
functions, and the compiler also needs to not interleave the generated code.

SSE2 supercedes MMX, it just expands everything from 64 to 128 bit, likewise
for x64 (as SSE2 is the absolute minspec for x64)

SSE2 is a good minspec cutoff for simd support on x86, since it includes the
integer ops and doubles.

At my job we have minspec'd SSE2 support for our games starting with Brothers
in Arms: Hell's Highway which was released in Oct 2008.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7617] Add support for 64bit and 256bit vectors

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7617



--- Comment #3 from Manu turkey...@gmail.com 2012-03-01 12:26:28 PST ---
I can buy possibly not supporting old MMX regs, but AVX is important.

That said, MMX is a physical feature in the x86 architecture, and it's also not
the only architecture with 64bit vectors, so I'd prefer to not see the type
definition ignored outright. Ie. GDC can't implement a type that the language
refuses to define.

Perhaps just define the types and leave them unsupported in DMD so Iain can
hook them up on GDC, since it already does support them all, or can he already
do that easily with the code how it is now? I thought I saw some hardcoded
widths in there...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7621] New: Immutable type equivalence problem

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7621

   Summary: Immutable type equivalence problem
   Product: D
   Version: D2
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2012-03-01 13:14:49 PST ---
I don't understand this bug. D2 code:


void main() {
enum uint N = 4u;
char[] A = hello.dup;
uint[immutable char[N]] dict;
dict[*cast(immutable char[4]*)(A[0 .. N].ptr)] = 0; // OK
dict[*cast(immutable char[N]*)(A[0 .. N].ptr)] = 0; // line 6, error
}


DMD 2.059head gives:

test.d(6): Error: cannot implicitly convert expression
(*cast(immutable(char[N]*))cast(char*)A[0u..4u]) of type immutable(char[N]) to
immutable(char[4u])

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7617] Add support for 64bit and 256bit vectors

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7617


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

   Severity|normal  |enhancement


--- Comment #4 from Walter Bright bugzi...@digitalmars.com 2012-03-01 
13:41:22 PST ---
Sure, I agree that AVX support is important.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7413] Vector literals don't work

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7413



--- Comment #2 from Manu turkey...@gmail.com 2012-03-01 13:53:30 PST ---
I'd like to see this promoted above the priority of other SIMD tasks.
This is holding me up. I can't write unit tests without literals.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7413] Vector literals don't work

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7413


Sean Cavanaugh worksonmymach...@gmail.com changed:

   What|Removed |Added

 CC||worksonmymach...@gmail.com


--- Comment #3 from Sean Cavanaugh worksonmymach...@gmail.com 2012-03-01 
14:16:27 PST ---
Hex float constants don't seem to be expressive enough to handle all 2^32 or
2^64 bit patterns for float or double (nan, exponent masks, mantissa only masks
etc).   

This is a problem for defining more exotic data while maintining the correct
'type' for the constant (float4 instead of an int4, double2 instead of long2
etc)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7622] New: Qualified imports inside functions don't work for real

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7622

   Summary: Qualified imports inside functions don't work for real
   Product: D
   Version: D2
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2012-03-01 14:19:31 PST ---
This is almost a regression, this used to work, for a short time.

In DMD 2.059head this compiles with no errors, so it looks like qualified
imports are allowed inside functions:


void main() {
import std.stdio: writeln;
}



But it seems you can't use them:

void main() {
import std.stdio: writeln;
writeln(hello);
}


test.d(3): Error: 'writeln' is not defined, perhaps you need to import
std.stdio; ?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7251] GC not working

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7251



--- Comment #6 from wfunct...@hotmail.com 2012-03-01 14:53:44 PST ---
(In reply to comment #5)
 No, it's inevitable that a mark-and-sweep GC on a 32 bit system won't work if
 large numbers of false pointers are present. And this code:
 
foreach (i; 0 .. count)
 a ~= i;
 
 is flooding the system with false pointers.

I think you might have misunderstood the problem, like I originally did.

I am **  NOT  *** filling the system with false pointers.
See David Simcha's comment in response to mine:
http://stackoverflow.com/a/8796226/541686

It's inherently defective -- I'm merely _allocating_ a lot of memory, that's
all. The rest is a problem with the GC's algorithm.
(Unless you expect that no one will allocate one 20-MB chunk of RAM?)

 
 You marked this as regression, is there any previous compiler where this
 worked?
 (reopen if it there is).

I marked it as remind, since I'm sorta reminding about this bug... if that's
not the implied meaning then my bad, but this still needs to be fixed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7624] New: std.typecons.Tuple slicing

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7624

   Summary: std.typecons.Tuple slicing
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2012-03-01 15:37:08 PST ---
std.typecons.Tuple supports both a slice method and normal array slicing
syntax:


import std.stdio, std.typecons;
void main() {
Tuple!(int,float,string,ubyte) t4;
t4[2] = XXX;
t4[3] = 99;
writeln(t4);
writeln(typeid(typeof(t4)), \n);

auto t2a = t4.slice!(1, 3);
writeln(t2a);
writeln(typeid(typeof(t2a)), \n);

auto t2b = t4[1 .. 3];
writeln(t2b);
writeln(typeid(typeof(t2b)), \n);
}


Outout with DMD 2.059head:

Tuple!(int,float,string,ubyte)(0, nan, XXX, 99)
std.typecons.Tuple!(int,float,string,ubyte).Tuple

Tuple!(float,string)(nan, XXX)
std.typecons.Tuple!(float,string).Tuple

nanXXX
(float,immutable(char)[])


But the natural syntax, using [1..3], returns a typetuple. Having two different
kinds of tuples in a language is confusing, but slicing a kind tuple and see as
a result the other kind of tuple is a bit too much confusing.

Is it possible to modify D/Phobos to make  t4[1..3]   return a
std.typecons.Tuple (and then deprecate the slice method)?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7625] New: inlining on works with explicit else branch

2012-03-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7625

   Summary: inlining on works with explicit else branch
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@dawgfoto.de


--- Comment #0 from d...@dawgfoto.de 2012-03-01 16:10:26 PST ---
int foo(int v)
{
return bar(2 * v);
}

int bar(int a)
{
if (a  0)
return 1;
// else
return baz(a);
}

int baz(int a)
{
if (a  0)
throw new Exception(a  0);
return a - 1;
}



bar is only inlined by foo when 'else' is present.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---