[Issue 7442] ctRegex!`\p{Letter}` uses a lot memory in compilation

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7442



--- Comment #10 from Don clugd...@yahoo.com.au 2012-04-29 00:02:21 PDT ---
(In reply to comment #7)
 I investigated this further and conclude that there are 2 factors at work.
 
 I removed few thousands of codepoints from Letter, so it doesn't run out of 
 RAM
 outright.(see code below)
 Also separated parse from build steps.
 
 Here are collected stats on CTFE.
 
 parse only:
 
  CTFE Performance 
 max call depth = 20 max stack = 44
 array allocs = 2761 assignments = 430837
 
 build:
  CTFE Performance 
 max call depth = 20 max stack = 73
 array allocs = 8264 assignments = 1293421
 
 Parsing creates all the datastructures for unicode table machinery
 it takes slightly less then half of all allocs already.
 Another thing to notice is it fetures higher allocations per assigment.
 
 Then comes the codegen step and it's CTFE only and far more alloc happy. 
 Frankly I see no way to reduce all of this alloc fun because of COW
 that will ruin any attempt to preallocate buffer for generated code. 
 Am I right that arrays do dup on every write?

No, that was true a year or so ago, but not any more. One case which still
causing array dups is comparing slices of arrays (eg, if (x[0..5] == y). I've
put the machinery in place to get rid of that now (it's not gone yet, I need
another simple pull request for that). That _might_ help a little bit.

Slicing also causes array dups with ~, eg z = x[0..5] ~ y; creates a temporary
array with x[0..5]. But those are the only two that I know of.

Clearly in this case, it's slow because it does 1.3 million assignments. It's a
duplicate of bug 6498, unless you can find some way of drastically reducing the
work it has to do.

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


[Issue 7997] Optlink crash with static zero length array

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7997


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

   What|Removed |Added

 CC||clugd...@yahoo.com.au


--- Comment #1 from Don clugd...@yahoo.com.au 2012-04-29 00:07:44 PDT ---
Very similar to bug 5332, probably another symptom of the same bug.

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


[Issue 6983] Vararg corrupts string on 64bit

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6983


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

   What|Removed |Added

 CC||clugd...@yahoo.com.au


--- Comment #2 from Don clugd...@yahoo.com.au 2012-04-29 00:12:05 PDT ---
(In reply to comment #1)
 The 64 bit ABI won't allow using _argptr directly. Instead, use the functions
 in core.stdc.stdarg.

The real bug is bug 7893: the spec says you *can* use _argptr in this way.

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


[Issue 7442] ctRegex!`\p{Letter}` uses a lot memory in compilation

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7442



--- Comment #11 from Dmitry Olshansky dmitry.o...@gmail.com 2012-04-29 
05:53:34 PDT ---
 
 No, that was true a year or so ago, but not any more. One case which still
 causing array dups is comparing slices of arrays (eg, if (x[0..5] == y). I've
 put the machinery in place to get rid of that now (it's not gone yet, I need
 another simple pull request for that). That _might_ help a little bit.
 
 Slicing also causes array dups with ~, eg z = x[0..5] ~ y; creates a temporary
 array with x[0..5]. But those are the only two that I know of.
 

Ok does a ~= b; *always* reallocate a ? If not I'm fine.

 Clearly in this case, it's slow because it does 1.3 million assignments. It's 
 a
 duplicate of bug 6498, unless you can find some way of drastically reducing 
 the
 work it has to do.

Well take a look at benchmark for CTFE. It does a lot of bit-setting on array
of bytes. Posiibly a source of asigments since it does 1 bit-set per codepoint. 
That's unavoidable I'm afraid. 

I may special case things somewhat so that it checks if fullword write of zeros
or ones is possible.

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


[Issue 5650] A RedBlackTree performance problem

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5650


d...@dawgfoto.de changed:

   What|Removed |Added

 CC||d...@dawgfoto.de


--- Comment #15 from d...@dawgfoto.de 2012-04-29 07:04:14 PDT ---
Gr... I hate how dmd makes poor decisions about inlining and then won't let 
you force the issue...

This is an issue with how the exception handling alters the control
flow. Perhaps annotating the properties with nothrow would have a similar
effect.
Anyhow scope (success) means that you'll have to temporarily store the return
value, so a small penalty will remain in most cases.

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


[Issue 8001] New: Alias this takes ownership of explicit cast

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8001

   Summary: Alias this takes ownership of explicit cast
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jesse.k.phillip...@gmail.com


--- Comment #0 from Jesse Phillips jesse.k.phillip...@gmail.com 2012-04-29 
07:41:14 PDT ---
When attempting to downcast a class which uses alias this, the operation fails
because the cast is applied to the item aliased.

I think the semantics should be to attempt an implicit cast (alias this), then
a cast of the top class, afterwards the alias this item can be casted.

test.d(3): Error: e2ir: cannot cast a.val of type int to type test.B

void main () {
A a = new B();
B b = cast(B) a;
}

class A {
int val;
alias val this;
}
class B : A {}

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


[Issue 7243] Compiler should call separate function when allocating a struct on the heap

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7243



--- Comment #1 from Steven Schveighoffer schvei...@yahoo.com 2012-04-29 
11:29:39 PDT ---
Martin Nowak has found a very compelling case for this to be fixed, it is
affecting performance of RedBlackTree.

From bug 5650:

When in 64-bit mode, each pointer is 8 bytes.  RedBlackNodes have a left,
right, and parent pointer, consuming 24 bytes.  Then it contains the payload,
followed by a byte for the color (red or black).  The basic RedBlackTree!int
case has a payload of int, or 4 bytes.  With alignment padding, this brings the
size of the struct to 32 bytes.

Now, given that array appending needs the extra byte for 'used' length (also
serves as a sentinel to prevent accidentally accessing the subsequent block),
this will be with array padding, 33 bytes, pushing the block required to 64
bytes.

Not only that, but because the struct has pointers, it must zero out those 31
unused bytes.

With his measurements as quoted in bug 5650, fixing this problem resulted in
roughly a 40% runtime reduction.

Can we please get this fixed?  I'll be happy to implement the druntime function
if someone will take care of the compiler part.

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


[Issue 7243] Compiler should call separate function when allocating a struct on the heap

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7243



--- Comment #2 from github-bugzi...@puremagic.com 2012-04-29 14:04:13 PDT ---
Commit pushed to master at https://github.com/D-Programming-Language/druntime

https://github.com/D-Programming-Language/druntime/commit/c8897db61b76f4f2eac12581042adcfb35543bd4
fix Issue 7243 - Compiler should call separate function when allocating a
struct on the heap

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


[Issue 7243] Compiler should call separate function when allocating a struct on the heap

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7243


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

   What|Removed |Added

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


--- Comment #4 from Walter Bright bugzi...@digitalmars.com 2012-04-29 
14:06:50 PDT ---
Back to you, Steven!

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


[Issue 7243] Compiler should call separate function when allocating a struct on the heap

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7243



--- Comment #3 from github-bugzi...@puremagic.com 2012-04-29 14:05:47 PDT ---
Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/4004bb3b222676c74a41c0bb2507979963167457
fix Issue 7243 - Compiler should call separate function when allocating a
struct on the heap

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


[Issue 7243] Compiler should call separate function when allocating a struct on the heap

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7243



--- Comment #5 from github-bugzi...@puremagic.com 2012-04-29 14:07:27 PDT ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/a766e4a395e4fb86ff31c6161d343d85805d96b3
fix Issue 7243 - Compiler should call separate function when allocating a
struct on the heap

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


[Issue 8002] New: Excess initial errors when passing template args to non-templated struct

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8002

   Summary: Excess initial errors when passing template args to
non-templated struct
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Keywords: diagnostic
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: cbkbbej...@mailinator.com


--- Comment #0 from Nick Sabalausky cbkbbej...@mailinator.com 2012-04-29 
14:14:11 PDT ---
---
import std.stdio;

struct Foo
{
int a;
}

int bar()
{
writeln();
return 1;
}

void main()
{
Foo x = Foo!(bar());
}
---

A template argument is (accidentally) being passed to Foo. The compiler should,
and does, print a not a template declaration error. But before doing so, it
evaluates the completely erroneous template arg, resulting in a big pile of
totally non-applicable error text (cannot be interpreted at compile time)
which obscures the one real problem.

dmd test.d
C:\Documents and Settings\Nick Sabalausky\Application
Data\dvm\compilers\dmd-2.059\bin\..\src\phobos\std\stdio.d(1548): Error: fputc
cannot be interpreted at compile time, because it has no available source code
C:\Documents and Settings\Nick Sabalausky\Application
Data\dvm\compilers\dmd-2.059\bin\..\src\phobos\std\stdio.d(1548):called
from here: enforce(fputc(10,(*stdout.p).handle) == 10,delegate pure nothrow
@safe const(char)[]()
{
return null;
}
)
test.d(10):called from here: writeln()
test.d(16):called from here: bar()
test.d(16): Error: template instance Foo!(bar()) Foo is not a template
declaration, it is a struct

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


[Issue 8004] New: Direct call of function literal should consider default arguments

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8004

   Summary: Direct call of function literal should consider
default arguments
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Keywords: rejects-valid
  Severity: regression
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com


--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-04-29 18:15:35 PDT ---
This code doesn't compile in git head.

auto n = (int n = 10){ return n; }();

This regression is introduced by fixing bug 3866.
Calling function literal directly is never indirect call, so this is regression
IMO.

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


[Issue 8005] New: Lambda with parameter type inference should consider default args

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8005

   Summary: Lambda with parameter type inference should consider
default args
   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-04-29 18:17:27 PDT ---
This code should compile.

auto n = (a, int n = 10){ return n; }(10);

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


[Issue 8004] Direct call of function literal should consider default arguments

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8004


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

   What|Removed |Added

   Keywords||pull


--- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-04-29 20:26:11 PDT ---
https://github.com/D-Programming-Language/dmd/pull/913

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


[Issue 8005] Lambda with parameter type inference should consider default args

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8005


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

   What|Removed |Added

   Keywords||pull


--- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-04-29 20:33:36 PDT ---
https://github.com/D-Programming-Language/dmd/pull/914

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


[Issue 4744] std.conv: string-enum doesn't look for longer match

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4744


francois.chabot@gmail.com changed:

   What|Removed |Added

 CC||francois.chabot.dev@gmail.c
   ||om


--- Comment #2 from francois.chabot@gmail.com 2012-04-29 20:43:13 PDT ---
possible fix:

https://github.com/D-Programming-Language/phobos/pull/557

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


[Issue 6969] Forward reference on template class triangle

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6969



--- Comment #6 from Nick Sabalausky cbkbbej...@mailinator.com 2012-04-29 
21:23:36 PDT ---
This works:

class A
{
alias C C1;
}
class B
{
alias A A1;
}
class C : B
{
}

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


[Issue 8004] Direct call of function literal should consider default arguments

2012-04-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8004



--- Comment #2 from github-bugzi...@puremagic.com 2012-04-29 22:38:32 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/c62833f09f75091f9fd73edf051c720829513e4b
fix Issue 8004 - Direct call of function literal should consider default
arguments

https://github.com/D-Programming-Language/dmd/commit/aea217c612614d248c412d753ac135e86fad2931
Merge pull request #913 from 9rnsr/fix8004

Issue 8004 - Direct call of function literal should consider default arguments

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