[Issue 6489] Should be able to copy double[] to float[]
http://d.puremagic.com/issues/show_bug.cgi?id=6489
--- Comment #5 from bearophile_h...@eml.cc 2011-08-27 16:18:55 PDT ---
Please show one or more use case.
Do you want it to be like a reinterpret cast? Currently this works:
void main() {
ushort[4] a = [1, 2, 3, 4];
uint[2] b = cast(uint[2])a;
assert(b == [131073, 262147]);
}
Mixing reinterpret cast with conversion casts is a bad design.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2941] Wrong code for inline asm because CPU type is set too late
http://d.puremagic.com/issues/show_bug.cgi?id=2941 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 2011-08-27 15:07:18 PDT --- https://github.com/D-Programming-Language/dmd/commit/ad979f369e0c3d0d8fdb1fd3aa2d3a5805204b1b https://github.com/D-Programming-Language/dmd/commit/c9938a9d88574be2b74eedb964f15633f9847d2b -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6548] [e2ir.c] Problem with ^^ vector op
http://d.puremagic.com/issues/show_bug.cgi?id=6548 --- Comment #2 from Iain Buclaw 2011-08-27 13:02:04 PDT --- Can you see if you can break things in any way after this commit? https://github.com/D-Programming-Language/dmd/pull/344 Regards Iain -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6563] wrong code when using at least 8 XMM regs
http://d.puremagic.com/issues/show_bug.cgi?id=6563 --- Comment #1 from d...@dawgfoto.de 2011-08-27 12:46:10 PDT --- https://github.com/D-Programming-Language/dmd/pull/343 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6452] RDMD shouldn't put the compiler in the rsp file
http://d.puremagic.com/issues/show_bug.cgi?id=6452 GreatEmerald changed: What|Removed |Added CC||past...@gmail.com --- Comment #2 from GreatEmerald 2011-08-27 12:21:25 PDT --- *** Issue 6543 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 6543] RDMD -I character limitation
http://d.puremagic.com/issues/show_bug.cgi?id=6543 GreatEmerald changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from GreatEmerald 2011-08-27 12:21:24 PDT --- Yeap, I believe so, the output reads: dmd -I../../../../Documents/D/LuaD -Isrc -L-llua -v -o- 'clarcomage.d' -I'.' >clarcomage.d.deps dmd '@/tmp/.rdmd/rdmd.BCB020D4C2774917E15EAB178F8B5D3C.rsp' Error: cannot read file dmd.d So I guess it's resolved duplicate, then. *** This issue has been marked as a duplicate of issue 6452 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6563] New: wrong code when using at least 8 XMM regs
http://d.puremagic.com/issues/show_bug.cgi?id=6563
Summary: wrong code when using at least 8 XMM regs
Product: D
Version: D2
Platform: Other
OS/Version: FreeBSD
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@dawgfoto.de
--- Comment #0 from d...@dawgfoto.de 2011-08-27 11:52:50 PDT ---
alias float T;
T val = 1;
int plot(T a, T b, T c, T d, T e, T f, T g, T h) {
assert(a == val);
return 0;
}
int main() {
return plot(
val,
val,
val,
val,
val,
val,
val,
val,
);
}
--
The values h-b are correctly loaded from XMM0-XMM6.
The calling function put a correctly into XMM7 but the plot
function loads it from the calling stack (misinterpreted as push parameter).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3009] format.d(2072) uses deprecated function
http://d.puremagic.com/issues/show_bug.cgi?id=3009 yebblies changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||yebbl...@gmail.com Resolution||WORKSFORME --- Comment #3 from yebblies 2011-08-28 04:03:28 EST --- The first test case now compiles without error, and the second does too (once an import to std.array is added). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5432] Allow variable declaration inside while condition
http://d.puremagic.com/issues/show_bug.cgi?id=5432 yebblies changed: What|Removed |Added Keywords||patch --- Comment #2 from yebblies 2011-08-28 03:56:34 EST --- https://github.com/D-Programming-Language/dmd/pull/342 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5432] Allow variable declaration inside while condition
http://d.puremagic.com/issues/show_bug.cgi?id=5432 yebblies changed: What|Removed |Added CC||yebbl...@gmail.com Component|websites|DMD Summary|if/for/while inconsistency: |Allow variable declaration |while( auto a = ... ) does |inside while condition |not compile | Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5432] if/for/while inconsistency: while( auto a = ... ) does not compile
http://d.puremagic.com/issues/show_bug.cgi?id=5432 yebblies changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from yebblies 2011-08-28 02:17:45 EST --- *** Issue 6550 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 6550] Allow (auto var = expression) in while() loops
http://d.puremagic.com/issues/show_bug.cgi?id=6550 yebblies changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #2 from yebblies 2011-08-28 02:17:45 EST --- *** This issue has been marked as a duplicate of issue 5432 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4782] core.atomic.atomicLoad broken for floating point
http://d.puremagic.com/issues/show_bug.cgi?id=4782 --- Comment #2 from David Simcha 2011-08-27 08:47:59 PDT --- https://github.com/D-Programming-Language/druntime/pull/61 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2818] Pointer parameters in core.memory should be const(void)*.
http://d.puremagic.com/issues/show_bug.cgi?id=2818 David Simcha changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from David Simcha 2011-08-27 07:43:55 PDT --- This was fixed a long time ago. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2327] opDot() should work as expected with operator overloading.
http://d.puremagic.com/issues/show_bug.cgi?id=2327 David Simcha changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from David Simcha 2011-08-27 07:37:14 PDT --- I'm resolving this as WONTFIX because opDot has been superseded by alias this and is no longer documented and scheduled for deprecation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2105] Manual Memory Management for Associative Arrays
http://d.puremagic.com/issues/show_bug.cgi?id=2105 David Simcha changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #14 from David Simcha 2011-08-27 07:35:35 PDT --- I'm resolving this one as fixed because the NO_INTERIOR patch accomplishes the same thing, though in a different way. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6489] Should be able to copy double[] to float[]
http://d.puremagic.com/issues/show_bug.cgi?id=6489 --- Comment #4 from David Simcha 2011-08-27 07:34:39 PDT --- The compelling rationale is consistency. I can assign the elements of a float[] to a double[] one-by-one, so why not with array-wise operations? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6560] Exponentiation operator ^^ doesn't work for complex numbers
http://d.puremagic.com/issues/show_bug.cgi?id=6560 --- Comment #7 from bearophile_h...@eml.cc 2011-08-27 07:29:09 PDT --- (In reply to comment #6) > I couldn't test the above because sqrt( ) and log( ) are not implemented for > complex numbers in 2.051. I do not know the situation in 2.055head. Could you > please verify this, if possible ? Added two days ago: https://github.com/D-Programming-Language/phobos/commit/cc2d7c9703c5b264f9e6aebeec314917b7805bec I suggest you do dowload the latest std.complex: https://raw.github.com/D-Programming-Language/phobos/master/std/complex.d Probably it works with DMD 2.054 compiler too (or it works with tiny changes). > The expected answer is (+inf, 1.0f) but the above prints "inf-nani". > > I do not know how it was in D1, but in D2 the above produces mathematically > incorrect result. Again, I'm unaware how it is in C99/C++, etc. or is it > always > like this. I presume that Don or Walter will take a look at this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5623] Slow GC with large heaps
http://d.puremagic.com/issues/show_bug.cgi?id=5623 David Simcha changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #17 from David Simcha 2011-08-27 07:29:44 PDT --- I'm marking this as resolved. My pull request was merged a long time ago and Steve's issue is probably related to false pointers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2927] Ignore Interior GC attribute
http://d.puremagic.com/issues/show_bug.cgi?id=2927 David Simcha changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from David Simcha 2011-08-27 07:25:57 PDT --- https://github.com/D-Programming-Language/druntime/commit/41e84c021f56171cf2993bc479c6498686cc2d2a -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6557] Inplace enum literals
http://d.puremagic.com/issues/show_bug.cgi?id=6557
--- Comment #4 from Kenji Hara 2011-08-27 07:15:29 PDT ---
My thought case is following code.
void foo()(int n){} // 1
void foo()(enum {a, b} arg) {} // 2
void main() {
int a;
foo(a); // 1 or 2 ?
}
To determine the signature of foo, 'a' is judged as integer typed variable, and
1st foo overload is selected. 2nd version of foo is never selected.
And this is natural behavior guided from the current specification.
But this enhancement is require to determine foo's signature *before* argument
types. This is a serious conflict.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6560] Exponentiation operator ^^ doesn't work for complex numbers
http://d.puremagic.com/issues/show_bug.cgi?id=6560
--- Comment #6 from bdsat...@gmail.com 2011-08-27 07:14:06 PDT ---
(In reply to comment #5)
I found a workaround for ^^, looks like this works:
import std.stdio;
import std.complex;
void main() {
auto x = Complex!real(1,2);
auto y = Complex!real(3,4);
writeln(x^^y);
}
> Please, show examples of the real problems, so Andrei & Walter will judge the
> situation.
Let's consider the same cases as mentioned in the "Semantics" section of:
http://www.digitalmars.com/d/2.0/cppcomplex.html
Well, unfortunately std.complex; in v2.051 is not up-to-date. I wanted to
verify whether the following identities hold:
* sqrt(conj(z)) == conj(sqrt(z)) whenever z takes on negative real values
* conj(log(z)) == log(conj(z)) whenever z takes on negative real values
I couldn't test the above because sqrt( ) and log( ) are not implemented for
complex numbers in 2.051. I do not know the situation in 2.055head. Could you
please verify this, if possible ?
However, I do have a testcase for this one:
* (1 - infinity*i)*i == (infinity + i) but not (infinity + NaN*i)
where i = sqrt(-1), the imaginary constant. The following demonstrates how a
"spurious NaN" is generated, as mentioned in the above link.
import std.stdio;
import std.complex;
union INFINITY {
float inf;
uint num;
};
union NOT_A_NUMBER {
float nan;
uint num;
};
void main() {
INFINITY posinf, neginf;
NOT_A_NUMBER nan;
posinf.num = 0x7F80; // positive infinity
neginf.num = 0xFF80; // negative infinity
nan.num = 0x7FC0;// Not a Number
writefln("Positive infinity = %f", posinf.inf);
writefln("Negative infinity = %f", neginf.inf);
writefln("Not a number = %f", nan.nan);
Complex!float i = Complex!float(0.0f, 1.0f);// i
Complex!float p = Complex!float(1.0f, neginf.inf); // 1-inf*i
writefln("%f",p*i); // Must be (1-inf*i)*i = inf + 1i
}
The expected answer is (+inf, 1.0f) but the above prints "inf-nani".
I do not know how it was in D1, but in D2 the above produces mathematically
incorrect result. Again, I'm unaware how it is in C99/C++, etc. or is it always
like this.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6414] Possible problem with pure and const attribute
http://d.puremagic.com/issues/show_bug.cgi?id=6414 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from bearophile_h...@eml.cc 2011-08-27 05:14:41 PDT --- The latest versions of 2.055 give no errors, so I close this bug report. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6557] Inplace enum literals
http://d.puremagic.com/issues/show_bug.cgi?id=6557
--- Comment #3 from bearophile_h...@eml.cc 2011-08-27 05:06:36 PDT ---
(In reply to comment #1)
> I think the enum scope inference from their member name is nearly impossible,
> because D has template function.
> The feature requires a function signature to determine the argument types, but
> template function call requires argument types to determine the function
> signature!
Do you mean this problem?
void foo(T)(T x, enum : T { A, B }) {}
void main() {
typeof(foo.A) a = foo.B;
foo(a);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6385] isInputRange!(ubyte[2u]) is a failure when used in global scope
http://d.puremagic.com/issues/show_bug.cgi?id=6385
yebblies changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #3 from yebblies 2011-08-27 21:06:24 EST ---
(In reply to comment #2)
> The test case was accidentally fixed by commit:
> https://github.com/D-Programming-Language/dmd/commit/dc83c
> but I don't really understand why. It seems to be just luck.
dc83c prevents dmd from re-evaluating the template constraint when the args
match an instance that already exists. Previously the constraint would be run
unless all template args had a spec. You can see this by changing 'void
bug6385(A)(A a) if (template6385!A)' to 'void bug6385(A : ubyte[2])(A a) if
(template6385!A)'.
Slightly smaller test case:
void templ6385(A)(A a) if ( { return false; }() )
{
this_is_an_error();
}
const bool bool6385 =
is(typeof(
{
this_is_another_error();
templ6385(1);
}()
));
void main() {}
Using an older commit, it seems that the cause is re-running semantic on
templ6385, as it's been added to the list of module members. This seems to be
similar to issue 4302 (caused by the fix to bug 4042) but missed by the patch
in 4302.
Changing
- if (!(sc->flags & SCOPEstaticif))
+ if (!(sc->flags & SCOPEstaticif) && !sc->intypeof)
from that patch seems to fix it, but I have no idea if there are any other
missing cases.
My guess at a correct solution is that
http://www.dsource.org/projects/dmd/changeset/477 is incorrect, and should
instead remove the TemplateInstance from the module's list of members.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6560] Exponentiation operator ^^ doesn't work for complex numbers
http://d.puremagic.com/issues/show_bug.cgi?id=6560 --- Comment #5 from bearophile_h...@eml.cc 2011-08-27 04:03:38 PDT --- (In reply to comment #4) > D1 agrees with Prof. Kahan but D2 diverges so that it > can introduce inadvertent errors > (http://www.digitalmars.com/d/2.0/cppcomplex.html). Please, show examples of the real problems, so Andrei & Walter will judge the situation. > The above program gives an error: > > complexes.d(6): Error: undefined identifier complex, did you mean struct > Complex(T) if (isFloatingPoint!(T))? > complexes.d(6): Error: undefined identifier complex, did you mean struct > Complex(T) if (isFloatingPoint!(T))? > > I thought 1,3, etc. are integers, may be, so changing 1 -> 1.0, 3 -> 3.0 etc. > it still gives same error. Recently they have improved the std.complex module. I am using a very recent version of DMD (2.055head) so maybe you have to wait for the release of 2.055 to see the correct code, or you have to download and compile the bleeding edge compiler + Phobos. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6560] Exponentiation operator ^^ doesn't work for complex numbers
http://d.puremagic.com/issues/show_bug.cgi?id=6560
--- Comment #4 from bdsat...@gmail.com 2011-08-27 03:00:15 PDT ---
(In reply to comment #3)
> The deprecation of the built-in complex numbers will cause the deprecation of
> their nice literals too. This means in your program you are not really using
> the std.complex module.
Looks like D is going in the wrong direction. IIUC, there is no longer a
builtin imaginary type. D1 agrees with Prof. Kahan but D2 diverges so that it
can introduce inadvertent errors
(http://www.digitalmars.com/d/2.0/cppcomplex.html).
> You have to write it this way:
>
> import std.stdio, std.complex;
>
> void main() {
> writeln(complex(1, 3) ^^ complex(4, 6));
> }
The above program gives an error:
complexes.d(6): Error: undefined identifier complex, did you mean struct
Complex(T) if (isFloatingPoint!(T))?
complexes.d(6): Error: undefined identifier complex, did you mean struct
Complex(T) if (isFloatingPoint!(T))?
I thought 1,3, etc. are integers, may be, so changing 1 -> 1.0, 3 -> 3.0 etc.
it still gives same error.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 Kenji Hara changed: What|Removed |Added Keywords||patch --- Comment #33 from Kenji Hara 2011-08-27 02:51:00 PDT --- Posted pull request. https://github.com/D-Programming-Language/dmd/pull/341 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
