[Issue 2617] incorrect code generation for asm{ inc eax }
http://d.puremagic.com/issues/show_bug.cgi?id=2617
--- Comment #1 from 2kor...@gmail.com 2009-01-26 00:25 ---
(In reply to comment #0)
> The following code fails to assert.
>
> import tango.core.Atomic;
> void main(){
> int j;
> foreach (i; 1..500_000){
> atomicIncrement!(msync.raw, int)(j);
> assert(j == (i%256));
> }
> }
>
Shouldn't that be:
assert(j == i); // ?
I have noted that Tango atomicIncrement increments least significant byte only,
too, and was wondering whether it is intended...
--
[Issue 2448] template return by reference causes seg fault
http://d.puremagic.com/issues/show_bug.cgi?id=2448
and...@metalanguage.com changed:
What|Removed |Added
Severity|normal |major
--- Comment #1 from and...@metalanguage.com 2009-01-25 23:32 ---
Adding another example and bumping this to major because it stops std.algorithm
development dead in its tracks.
template ElementType(R)
{
alias typeof({ R r; return r[0]; }()) ElementType;
}
bool empty(T)(in T[] a) { return !a.length; }
void next(T)(ref T[] a) { assert(a.length); a = a[1 .. $]; }
void retreat(T)(ref T[] a) { assert(a.length); a = a[0 .. $ - 1]; }
T head(T)(T[] a) { assert(a.length); return a[0]; }
ref T toe(T)(T[] a) { assert(a.length); return a[a.length - 1]; }
struct Retro(R)
{
private:
R _input;
public:
bool empty()
{
return _input.empty;
}
void next()
{
_input.retreat;
}
ElementType!(R) head()
{
return _input.toe;
}
}
void main()
{
void test(int[] input)
{
foreach (e; Retro!(int[])(input))
{
}
}
test([ 1 ]);
}
--
[Issue 2328] setTypeInfo in gc.d backwards.
http://d.puremagic.com/issues/show_bug.cgi?id=2328 dsim...@yahoo.com changed: What|Removed |Added Severity|major |critical Version|2.018 |1.039 --- Comment #1 from dsim...@yahoo.com 2009-01-25 22:15 --- No longer relevant to D2, but should still be fixed in D1. --
[Issue 2268] Hijacking of non-templated functions by templated functions should not be allowed.
http://d.puremagic.com/issues/show_bug.cgi?id=2268
dsim...@yahoo.com changed:
What|Removed |Added
Severity|major |critical
Keywords||diagnostic
Version|2.017 |2.023
--- Comment #2 from dsim...@yahoo.com 2009-01-25 22:11 ---
Upgrading to critical and incrementing version because this bug still exists,
I've been bitten by this several times now, and each time it's quite confusing.
Also, the following example actually does give a proper error message, because
instantiation of std.algorithm.find succeeds, and then DMD realizes that it
conflicts with std.string.find:
import std.algorithm, std.string;
void main() {
auto i = find("foobar", 'f');
}
The root of the problem, then, is that DMD tries to instantiate any template
functions that match the name of the function being called before outputting a
name conflict error message. If the instantiation of these templates fails,
then DMD fails with error messages related to its attempt at instantiating the
template, rather than either silently using the non-template function (probably
a bad idea) or failing with a name conflict error message (the right thing).
Instead, DMD should fail *before* trying to instantiate the template function
whose name conflicts with the non-template function, if they are not in the
same overload set.
--
[Issue 2618] New: Assert errors should be unrecoverable.
http://d.puremagic.com/issues/show_bug.cgi?id=2618
Summary: Assert errors should be unrecoverable.
Product: D
Version: 2.023
Platform: PC
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: dsim...@yahoo.com
void main() {
foo(1);
}
void foo(int i) nothrow {
assert(i < 0);
return i;
}
Compiles in release mode because asserts are disabled. When asserts are
enabled, compilation fails w/ the following error msg:
test.d|5|function test.foo 'foo' is nothrow yet may throw
Fixing this is necessary to allow some code that doesn't throw any "real"
exceptions, but uses asserts for internal consistency checks, to compile in
debug mode. Also, if asserts are used in the precondition block instead of in
the body, then the code compiles:
void foo(int i) nothrow
in {
assert(i < 0);
} body {
return i;
}
--
[Issue 2600] Nonuniform treatment of built-in types and user-defined types in value syntax
http://d.puremagic.com/issues/show_bug.cgi?id=2600 --- Comment #1 from wbax...@gmail.com 2009-01-25 18:35 --- This has my vote. --
[Issue 2614] auto + templated structs = unhelpful error messages
http://d.puremagic.com/issues/show_bug.cgi?id=2614 --- Comment #2 from wbax...@gmail.com 2009-01-25 18:19 --- (In reply to comment #1) > See also #2510 > Feh, I always forget what magic invocation creates a hyperlink so here's a regular url: http://d.puremagic.com/issues/show_bug.cgi?id=2510 And some more attempts issue 2510 number 2510 bug 2510 --
[Issue 2614] auto + templated structs = unhelpful error messages
http://d.puremagic.com/issues/show_bug.cgi?id=2614 --- Comment #1 from wbax...@gmail.com 2009-01-25 18:16 --- See also #2510 --
[Issue 2616] Undocumented behaviour: part-explicit, part-implicit instantiations of function templates are accepted
http://d.puremagic.com/issues/show_bug.cgi?id=2616 --- Comment #1 from wbax...@gmail.com 2009-01-25 18:12 --- See this bug: http://d.puremagic.com/issues/show_bug.cgi?id=493 It was mentioned in the changelog of 1.038. It could certainly be documented better. --
[Issue 2617] New: incorrect code generation for asm{ inc eax }
http://d.puremagic.com/issues/show_bug.cgi?id=2617
Summary: incorrect code generation for asm{ inc eax }
Product: D
Version: 2.022
Platform: PC
OS/Version: Linux
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: jason.james.ho...@gmail.com
The following code fails to assert.
import tango.core.Atomic;
void main(){
int j;
foreach (i; 1..500_000){
atomicIncrement!(msync.raw, int)(j);
assert(j == (i%256));
}
}
Digging deeper, this is a problem because the atomicIncrement is translated to
the following assembly. Note the critical line of "lock incb" which should be
"lock inc"
80496b4: 55 push %ebp
80496b5: 8b ec mov%esp,%ebp
80496b7: 50 push %eax
80496b8: 8b 45 fcmov-0x4(%ebp),%eax
80496bb: f0 fe 00lock incb (%eax)
80496be: 8b 00 mov(%eax),%eax
80496c0: 8b e5 mov%ebp,%esp
80496c2: 5d pop%ebp
80496c3: c3 ret
Here's the original assembly in the Tango module:
asm
{
mov EAX, val;
lock; // lock always needed to make this op atomic
inc [EAX];
mov EAX, [EAX];
}
This problem appears in both D1 and D2 and prevents lockless algorithms.
--
[Issue 2613] The trivial hello.d sample program fails at execution
http://d.puremagic.com/issues/show_bug.cgi?id=2613 --- Comment #2 from bra...@puremagic.com 2009-01-25 16:58 --- Walter, these sources don't seem to be part of either the phobos or druntime projects, so they must live along side the compiler itself. Over half of them use printf, and I'll bet that most could stand to be updated in one way or another. This applies to both 1.x and 2.x as well. --
[Issue 2613] The trivial hello.d sample program fails at execution
http://d.puremagic.com/issues/show_bug.cgi?id=2613
s...@iname.com changed:
What|Removed |Added
CC||s...@iname.com
--- Comment #1 from s...@iname.com 2009-01-25 16:25 ---
Wrong again. It should be fixed to use writefln, in both the D1 and D2
packages. And probably have args declared as string[] rather than char[][].
--
import std.stdio;
int main(string[] args)
{
writefln("hello world");
writefln("args.length = %d", args.length);
for (int i = 0; i < args.length; i++)
writefln("args[%d] = '%s'", i, args[i]);
return 0;
}
--
--
[Issue 2616] New: Undocumented behaviour: part-explicit, part-implicit instantiations of function templates are accepted
http://d.puremagic.com/issues/show_bug.cgi?id=2616
Summary: Undocumented behaviour: part-explicit, part-implicit
instantiations of function templates are accepted
Product: D
Version: 1.039
Platform: PC
URL: http://www.digitalmars.com/d/1.0/template.html
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid, spec
Severity: normal
Priority: P2
Component: www.digitalmars.com
AssignedTo: bugzi...@digitalmars.com
ReportedBy: s...@iname.com
OtherBugsDependingO 2599
nThis:
`Function templates can be explicitly instantiated with a
!(TemplateArgumentList):
writefln("The square of %s is %s", 3, Square!(int)(3));
or implicitly, where the TemplateArgumentList is deduced from the types of the
function arguments:
writefln("The square of %s is %s", 3, Square(3)); // T is deduced to be int`
It's just come to my attention that the compiler allows an in-between case that
isn't covered by the current documentation, either for D1 or for D2.
--
import std.stdio;
void fun(T1, T2)(T2 x) {
pragma(msg, T1.stringof);
writefln(x);
}
void main() {
fun!(int)("hello!");
}
--
C:\Users\Stewart\Documents\Programming\D\Tests>dmd template_partial.d
int
C:\Users\Stewart\Documents\Programming\D\Tests>template_partial
hello!
--
What is T2? The template instantiation is explicit in form, but doesn't match
the parameter list with which the template is declared. Neither is T2 deduced
from the given template arguments. Neither is it IFTI as currently documented,
since a template parameter list has been given. Rather, the template
instantiation is of an undocumented mix of the two styles.
Issue 2599 comment 6 implies that this feature is intended, but you forgot to
document it.
--
[Issue 2599] Two variadic parameters should be accepted
http://d.puremagic.com/issues/show_bug.cgi?id=2599
--- Comment #6 from and...@metalanguage.com 2009-01-25 09:46 ---
(In reply to comment #5)
> (In reply to comment #4)
> > Try this at home:
> >
> > void fun(T1, T2)(T2 x)
> > {
> > }
> >
> > void main()
> > {
> > fun!(int)("a");
> > }
>
> But where's it documented? Are you sure it isn't a bug that DMD accepts it?
Not sure if Walter documented it. But I'm sure it's deliberately in there
because I asked for the feature and Walter took the time to implement it. As
far as I remember the feature was introduced in 2.015.
--
[Issue 2599] Two variadic parameters should be accepted
http://d.puremagic.com/issues/show_bug.cgi?id=2599
--- Comment #5 from s...@iname.com 2009-01-25 09:37 ---
(In reply to comment #4)
> Try this at home:
>
> void fun(T1, T2)(T2 x)
> {
> }
>
> void main()
> {
> fun!(int)("a");
> }
But where's it documented? Are you sure it isn't a bug that DMD accepts it?
--
[Issue 2599] Two variadic parameters should be accepted
http://d.puremagic.com/issues/show_bug.cgi?id=2599
--- Comment #4 from and...@metalanguage.com 2009-01-25 09:09 ---
(In reply to comment #3)
> > When instantiated explicitly, all explicit arguments are eaten by
> > T1. This is the purpose of the pattern: pass some explicit
> > arguments, then deduce some more implicitly.
>
> In the current template system, a template is instantiated either implicitly
> or
> explicitly - no in-between.
Try this at home:
void fun(T1, T2)(T2 x)
{
}
void main()
{
fun!(int)("a");
}
> To allow part-explicit, part-implicit template instantiations like you're
> asking for would be in itself a change in the language that must come first.
Already has (incidentally at my request.) It's used in much of std.algorithm.
> > Currently this is possible, but only with one ellipsis.
>
> I'm not sure what you mean by this
This works:
void fun(T1, T2, T3...)(T2 x, T3 xs)
{
}
void main()
{
fun!(int)("a");
}
This doesn't, which is another bug:
void fun(T1, T2...)(T2 xs)
{
}
void main()
{
fun!(int)("a");
}
> BTW your workaround can be written more simply:
>
> template f(T1...) {
> void f(T2...)(T2 args) { ... }
> }
Thanks!
--
[Issue 2599] Two variadic parameters should be accepted
http://d.puremagic.com/issues/show_bug.cgi?id=2599
--- Comment #3 from s...@iname.com 2009-01-25 08:54 ---
> When instantiated explicitly, all explicit arguments are eaten by
> T1. This is the purpose of the pattern: pass some explicit
> arguments, then deduce some more implicitly.
In the current template system, a template is instantiated either implicitly or
explicitly - no in-between. At least, AIUI, the only exception is when one
template argument is deduced from another, as in
template temp(T : U[], U) {
const string temp = "array of " ~ U.stringof;
}
pragma(msg, temp!(int[]));
To allow part-explicit, part-implicit template instantiations like you're
asking for would be in itself a change in the language that must come first.
> Currently this is possible, but only with one ellipsis.
I'm not sure what you mean by this
BTW your workaround can be written more simply:
template f(T1...) {
void f(T2...)(T2 args) { ... }
}
--
