[Issue 2942] asm fadd; accepted, but generates code for faddp.
http://d.puremagic.com/issues/show_bug.cgi?id=2942 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #4 from Don 2009-10-01 00:27:56 PDT --- (In reply to comment #3) > These pseudo-ops *are* documented in older Intel manuals, like the 387 DX > User's Manual. I'm reluctant to change it. The last issue should be in a > separate report. Interesting. They aren't present in any manual which is still available. I found a website with material which was copied from the 386 manual (not 387), but it said that even in 1997, the manual was no longer officially available. I suspect that a lot of those pseudo-ops were bugs in DEBUG. (DEBUG also accepts fld addr, ST(6);). However, I just checked MSVC, and it _does_ accept fadd; (But it doesn't accept the legal faddp; !!) Pretty useless, and I think they should be abandoned, but no big deal if you want to keep them. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3354] New: asm fld x, ST(6); accepted.
http://d.puremagic.com/issues/show_bug.cgi?id=3354
Summary: asm fld x, ST(6); accepted.
Product: D
Version: 1.00
Platform: x86
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2009-10-01 00:29:53 PDT ---
This garbage compiles, but shouldn't.
void main() {
double x;
asm {
fld x, ST(6);
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3355] New: std.string.cmp works incorrectly for mixed-type and different-length strings
http://d.puremagic.com/issues/show_bug.cgi?id=3355
Summary: std.string.cmp works incorrectly for mixed-type and
different-length strings
Product: D
Version: 2.032
Platform: x86
OS/Version: Linux
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: acehr...@yahoo.com
--- Comment #0 from Ali Cehreli 2009-10-01 01:08:40 PDT ---
cmp fails unit tests when added this one
result = cmp("aa", "aaa"d);
assert(result < 0);
The patch is trivial:
109c109
< if (i1 == s1.length) return s2.length - i2;
---
> if (i1 == s1.length) return i2 - s2.length;
136a137,143
>
> result = cmp("aa", "aaa"d);
> assert(result < 0);
> result = cmp("aaa", "aa"d);
> assert(result > 0);
> result = cmp("aa", "aa"d);
> assert(result == 0);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3160] ICE(cgcod.c 1511-D1) or bad code-D2 returning string from void main
http://d.puremagic.com/issues/show_bug.cgi?id=3160 --- Comment #4 from Don 2009-10-01 05:47:20 PDT --- The patch for the related bug 3344 adds a check for side-effects. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3355] std.string.cmp works incorrectly for mixed-type and different-length strings
http://d.puremagic.com/issues/show_bug.cgi?id=3355 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3356] New: Make pure functions require immutable parameters
http://d.puremagic.com/issues/show_bug.cgi?id=3356
Summary: Make pure functions require immutable parameters
Product: D
Version: future
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dfj1es...@sneakemail.com
--- Comment #0 from Sobirari Muhomori 2009-10-01
07:39:29 PDT ---
Illustration:
---
int foo(const int[] bar) pure
{
return bar[1];
}
void goo()
{
int[2] a;
a[1]=1;
foo(a);
a[1]=2;
foo(a);
}
---
1. This doesn't affect functions with value type parameters.
2. When a function takes a reference type parameter, the chanses are slim, that
the return value doesn't depend on the referenced data. So the referenced data
must be immutable.
3. This doesn't require complex flow analysis, only a formal function signature
check.
4. (??) Replace immutability of explicit pointer type with constness, since
even if the referenced data is immutable, the code doesn't know, where the
immutable data ends and can access subsequent possibly mutating data. This will
instantly make any function, taking a pointer, impure. This should not apply to
objects and byref data.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3352] RangeError in std.conv
http://d.puremagic.com/issues/show_bug.cgi?id=3352 --- Comment #1 from Sobirari Muhomori 2009-10-01 07:43:35 PDT --- Also I think, it's an overkill to fine tune allocation as it's done in to!string(uint) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3356] Make pure functions require immutable parameters
http://d.puremagic.com/issues/show_bug.cgi?id=3356 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don 2009-10-01 08:09:24 PDT --- (In reply to comment #0) > 2. When a function takes a reference type parameter, the chanses are slim, > that > the return value doesn't depend on the referenced data. Yes. > So the referenced data must be immutable. That conclusion does not follow. I don't think you're seeing all of the benefits of 'pure'. Consider foo(a) + foo(a). This can be changed into 2*foo(a), even though a is not immutable. It is true that in the case where all parameters are immutable, additional optimisations (such as caching) can be performed. But there's more to pure than that. > 4. (??) Replace immutability of explicit pointer type with constness, since > even if the referenced data is immutable, the code doesn't know, where the > immutable data ends and can access subsequent possibly mutating data. This > will > instantly make any function, taking a pointer, impure. This should not apply > to > objects and byref data. That's a memory integrity issue, not a purity issue. That could only happen in an unsafe module. You are asking for a feature to be removed from the language, but I'm not really sure why. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3357] New: ICE with aa that use static char array as key
http://d.puremagic.com/issues/show_bug.cgi?id=3357
Summary: ICE with aa that use static char array as key
Product: D
Version: 1.047
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: fa...@gmx.ch
--- Comment #0 from Fawzi Mohamed 2009-10-01 08:05:44 PDT ---
I was trying to reduce an error, namely
Internal error: e2ir.c 4026
and I generated another one
{{{
struct Particle{
char[16] name;
}
class ReadSystem{
size_t[char[16]] pKindsIdx;
void t(Particle p){
auto idx=p.name in pKindsIdx; // fails (Internal error: ../ztc/cod1.c
2636)
}
}
void main(){
char[16] n;
size_t[char[16]] aa;
auto r=n in aa; // works
}
}}}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3357] ICE with aa that use static char array as key
http://d.puremagic.com/issues/show_bug.cgi?id=3357 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don 2009-10-01 08:11:41 PDT --- Is this the same as bug 1934? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1934] ICE(e2ir.c) using static array as AA key
http://d.puremagic.com/issues/show_bug.cgi?id=1934 Fawzi Mohamed changed: What|Removed |Added CC||fa...@gmx.ch --- Comment #4 from Fawzi Mohamed 2009-10-01 08:21:28 PDT --- *** Issue 3357 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3357] ICE with aa that use static char array as key
http://d.puremagic.com/issues/show_bug.cgi?id=3357 Fawzi Mohamed changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Fawzi Mohamed 2009-10-01 08:21:28 PDT --- Yes it looks like it, the line number changed (probably due to changes in the code) and I hadn't found it, but it really looks like the same issue. *** This issue has been marked as a duplicate of issue 1934 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3357] ICE with aa that use static char array as key
http://d.puremagic.com/issues/show_bug.cgi?id=3357 Don changed: What|Removed |Added Keywords||ice-on-valid-code Status|RESOLVED|REOPENED Platform|Other |All Resolution|DUPLICATE | OS/Version|Mac OS X|All --- Comment #3 from Don 2009-10-01 08:33:01 PDT --- This isn't the same as bug 1934, though it is clearly very closely related. My patch for 1934 doesn't fix this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3357] ICE with aa that use static char array as key
http://d.puremagic.com/issues/show_bug.cgi?id=3357 --- Comment #4 from Fawzi Mohamed 2009-10-01 08:35:40 PDT --- thanks for catching it... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2998] ICE(expression.c) with floating point enum
http://d.puremagic.com/issues/show_bug.cgi?id=2998 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright 2009-10-01 10:42:10 PDT --- The order in which those two functions are called shouldn't matter. The actual problem is the TypeEnum doesn't have proper overrides for isreal, isimaginary, etc. Will fix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3352] RangeError in std.conv
http://d.puremagic.com/issues/show_bug.cgi?id=3352 --- Comment #2 from Andrei Alexandrescu 2009-10-01 11:05:40 PDT --- (In reply to comment #1) > Also I think, it's an overkill to fine tune allocation as it's done in > to!string(uint) BTW I just improved optimization by adding preallocated strings for numbers between -1 and -9. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3358] Several typeof(Class.method).stringof incoherence
http://d.puremagic.com/issues/show_bug.cgi?id=3358 --- Comment #1 from Julien Leclercq 2009-10-01 15:27:56 PDT --- Created an attachment (id=467) Test case -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3358] New: Several typeof(Class.method).stringof incoherence
http://d.puremagic.com/issues/show_bug.cgi?id=3358 Summary: Several typeof(Class.method).stringof incoherence Product: D Version: 2.032 Platform: x86 OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: jul...@onandon.be --- Comment #0 from Julien Leclercq 2009-10-01 15:25:31 PDT --- Hello, the results of `typeof(&Class.method).stringof` for different methods sharing the same signature but different parameters name seems identical. Please view the attachment. Thank you, Julian. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
