[Issue 859] float vector codegen after inlining very different from manual inlined code

2010-07-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=859



--- Comment #8 from Brad Roberts bra...@puremagic.com 2010-07-11 09:05:03 PDT 
---
This was fixed by the changes that fixed bug 2008.  This report passes static
arrays as a parameter which was one of the things that caused the inliner to
reject a function.

I'm going to close this bug.

I've opened bug 4447 to track a remaining issue regarding oddities involving
the first function taking significantly longer to execute, regardless of which
it is.

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


[Issue 859] float vector codegen after inlining very different from manual inlined code

2010-07-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=859


Brad Roberts bra...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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


[Issue 4440] inlined delegates produces different asm than straight lined code

2010-07-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4440


Brad Roberts bra...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|nob...@puremagic.com|bra...@puremagic.com


--- Comment #2 from Brad Roberts bra...@puremagic.com 2010-07-11 10:13:14 PDT 
---
Reducing the test case further:
extern(C) int printf(const char*, ...);

bool if_delegate(int i, bool delegate(ref int) predicate)
{
return predicate(i);
}

bool if_nodelegate(int i)
{
return i == 99;
}

void main()
{
foreach(i; 1 .. 100)
if (if_delegate(i, (ref int j) { return j == 99; }))
printf(i = %d\n, i);

foreach(i; 1 .. 100)
if (if_nodelegate(i))
printf(i = %d\n, i);
}

In the previous version of the code, the use of the for loops makes the cost of
the functions too high for the inliner to bother inlining find_if into main. 
Also,in the non-inlined version of the function, there's no way for it to
inline the delegate since it's a variable, not a constant thing.

This changed version reduces the problem to: will it inline the delegate?  The
answer is still no, but allows that specific problem to be explored.

Leandro, does this stray too far away from the underlying code that led you to
file this bug?

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


[Issue 4440] inlined delegates produces different asm than straight lined code

2010-07-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4440



--- Comment #5 from Brad Roberts bra...@puremagic.com 2010-07-11 11:31:38 PDT 
---
Ok.  I'll keep that in mind.  One step at a time for now though; need to get
_any_ delegate inlining to happen before worrying about popping up the layers
up to an opApply function.

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


[Issue 4440] inlined delegates produces different asm than straight lined code

2010-07-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4440



--- Comment #6 from Leandro Lucarella llu...@gmail.com 2010-07-11 13:22:56 
PDT ---
(In reply to comment #5)
 Ok.  I'll keep that in mind.  One step at a time for now though; need to get
 _any_ delegate inlining to happen before worrying about popping up the layers
 up to an opApply function.

Agreed, thanks for giving it some time to this :)

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


[Issue 4440] inlined delegates produces different asm than straight lined code

2010-07-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4440



--- Comment #7 from Brad Roberts bra...@puremagic.com 2010-07-11 14:39:39 PDT 
---
Created an attachment (id=690)
add support for inlining function literals

This patch adds support for inlining function literals.  This won't cover many
cases as most hide behind a variable, but it's a building block in the right
direction:

The test case for this patch.. very contrived:

extern(C) int printf(const char*, ...);

void main()
{
int i = 99;
if ((delegate(ref int j) { return j == 99; })(i))
printf(i = %d\n, i);
}

same result if the keyword 'delegate' is omitted.

It passes an abbreviated (only used ARGS=-O -inline -release) run of the test
suite.

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


[Issue 4448] New: labeled break doesn't work in CTFE

2010-07-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4448

   Summary: labeled break doesn't work in CTFE
   Product: D
   Version: D2
  Platform: Other
OS/Version: Windows
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: shro8...@vandals.uidaho.edu


--- Comment #0 from BCS shro8...@vandals.uidaho.edu 2010-07-11 15:12:45 PDT 
---
string CTFE(string s) {
  int i, j;
  L1: for(i = 0; i  s.length; i++)
switch(s[i]) {
  case ' ', '\n', '\r', '\t':
continue;
  default: break L1;
}
  L2: for(j = s.length; j  i; j--)
switch(s[j-1]) {
  case ' ', '\n', '\r', '\t':
continue;
  default: break L2;
}
  return s[i..j];
}

import std.stdio;
pragma(msg, CTFE( hello world!\n));
void main(){ writef('%s'\n, CTFE( hello world!\n)); }

the function works at runtime but fails under CTFE. There may be a few cases
where labeled break may be hard to deal with but this one shouldn't cause
problems.

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


[Issue 2834] Struct Destructors are not called by the GC, but called on explicit delete.

2010-07-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2834


bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc


--- Comment #6 from bearophile_h...@eml.cc 2010-07-11 15:16:07 PDT ---
For the moment the compiler can show a warning when the code allocates on the
heap a struct that has a destructor.

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


[Issue 2834] Struct Destructors are not called by the GC, but called on explicit delete.

2010-07-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2834



--- Comment #7 from bearophile_h...@eml.cc 2010-07-11 17:24:58 PDT ---
One case where struct destructors are not called, in this situation it seems
simpler for the GC to know what destructors to call:


import core.memory: GC;
import core.stdc.stdio: printf;
struct Foo {
int x;
this(int xx) { this.x = xx; }
~this() { printf(Foo dtor x: %d\n, x); }
}
void main() {
Foo[] a;
a.length = 2;
a[0].x = 1;
a[1].x = 2;
// delete a;
}


(I am not sure, but a type information can be useful in arrays, maybe to fix
bug 2095 too.)

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


[Issue 2971] map no longer works with to

2010-07-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2971


Andrei Alexandrescu and...@metalanguage.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


--- Comment #2 from Andrei Alexandrescu and...@metalanguage.com 2010-07-11 
18:29:07 PDT ---
Changeset 1747.

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


[Issue 4397] const/CTFE does not work

2010-07-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4397


nfx...@gmail.com changed:

   What|Removed |Added

Summary|D1 const/CTFE does not work |const/CTFE does not work


--- Comment #2 from nfx...@gmail.com 2010-07-11 22:04:16 PDT ---
(Wrong code on v2.046 too, when switching const with enum.)

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