Re: Enumerate CTFE bug...
On Monday, 21 November 2016 at 13:22:57 UTC, Paolo Invernizzi
wrote:
I'm not sure if it's the same as #15064 bug:
import std.array, std.range, std.algorithm;
immutable static foo = ["a", "b", "c"];
auto bar(R)(R r)
{
string s = r[1];
return s;
}
immutable static res = foo.enumerate.map!bar().array;
std/typecons.d(526): Error: reinterpreting cast from
inout(ulong)* to inout(Tuple!(ulong, immutable(string)))* is
not supported in CTFE
bug.d(9):called from here: r._Tuple_super()
std/algorithm/iteration.d(593):called from here:
bar(this._input.front())
std/array.d(105):called from here: __r2091.front()
bug.d(15):called from here: array(map(enumerate(foo,
0LU)))
---
Paolo
Yes looks like it.
Adding a special case in phobos should solve the problem.
Enumerate CTFE bug...
I'm not sure if it's the same as #15064 bug:
import std.array, std.range, std.algorithm;
immutable static foo = ["a", "b", "c"];
auto bar(R)(R r)
{
string s = r[1];
return s;
}
immutable static res = foo.enumerate.map!bar().array;
std/typecons.d(526): Error: reinterpreting cast from
inout(ulong)* to inout(Tuple!(ulong, immutable(string)))* is not
supported in CTFE
bug.d(9):called from here: r._Tuple_super()
std/algorithm/iteration.d(593):called from here:
bar(this._input.front())
std/array.d(105):called from here: __r2091.front()
bug.d(15):called from here: array(map(enumerate(foo,
0LU)))
---
Paolo
Re: CTFE bug or enhancement?
On Thu, Jul 03, 2014 at 02:09:09AM +, safety0ff via Digitalmars-d-learn wrote: On Thursday, 3 July 2014 at 02:02:19 UTC, safety0ff wrote: On Thursday, 3 July 2014 at 01:55:14 UTC, safety0ff wrote: Actually, this is an enhancement because adding: enum b = blah Makes them fail. :( The question is now: how can the delegate be evaluated for the return value but not for the enum? Looks like an ICE: https://github.com/D-Programming-Language/dmd/blob/master/src/interpret.c#L5169 All ICE's are bugs and should be reported as such. T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
CTFE bug or enhancement?
Everything compiles fine except for function qux2: http://dpaste.dzfl.pl/9d9187e0b450 Is this a bug or an enhancement for CTFE? It would be really nice to have this feature because core.simd has functions such as: void16 __simd(XMM opcode, void16 op1, void16 op2, ubyte imm8); Where all the arguments must be compile time constants. It would be nice to be able to push some parameters out from the type list and into the argument list in user code too.
Re: CTFE bug or enhancement?
Actually, this is an enhancement because adding: enum b = blah Makes them fail. :(
Re: CTFE bug or enhancement?
On Thursday, 3 July 2014 at 01:55:14 UTC, safety0ff wrote: Actually, this is an enhancement because adding: enum b = blah Makes them fail. :( The question is now: how can the delegate be evaluated for the return value but not for the enum?
Re: CTFE bug or enhancement?
On Thursday, 3 July 2014 at 02:02:19 UTC, safety0ff wrote: On Thursday, 3 July 2014 at 01:55:14 UTC, safety0ff wrote: Actually, this is an enhancement because adding: enum b = blah Makes them fail. :( The question is now: how can the delegate be evaluated for the return value but not for the enum? Looks like an ICE: https://github.com/D-Programming-Language/dmd/blob/master/src/interpret.c#L5169
DMD CTFE Bug?
I have this code: http://dpaste.dzfl.pl/dbe2a07f It works perfectly fine, except for `t!(2, 10)` and `t!(1, 10)`: // Expected: [Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5, 0.5, 0, 1, 0, 3, 10, 3, 10, 0, 0), Vertex(0.5, 0.5, -0.5, 0, 1, 0, 3, 9, 3, 9, 0, 0), Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5, -0.5, 0, 1, 0, 3, 9, 3, 9, 0, 0), Vertex(-0.5, 0.5, -0.5, 0, 1, 0, 2, 9, 2, 9, 0, 0)] // Actual result: [Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5, 0.5, 0, 1, 0, 3, 10, 3, 10, 0, 0), Vertex(0.5, -0.5, 0.5, 0, -1, 0, 6, 3, 6, 3, 0, 0), Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5, -0.5, 0, 1, 0, 3, 9, 3, 9, 0, 0), Vertex(-0.5, 0.5, -0.5, 0, 1, 0, 2, 9, 2, 9, 0, 0)] If I change `enum` in line 117 to `auto` it produces the expected result. Any ideas why this happens? (Btw. I wasn't able produce a smaller testcase)
Re: DMD CTFE Bug?
On 17-Aug-12 20:27, David wrote: I have this code: http://dpaste.dzfl.pl/dbe2a07f It works perfectly fine, except for `t!(2, 10)` and `t!(1, 10)`: // Expected: [Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5, 0.5, 0, 1, 0, 3, 10, 3, 10, 0, 0), Vertex(0.5, 0.5, -0.5, 0, 1, 0, 3, 9, 3, 9, 0, 0), Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5, -0.5, 0, 1, 0, 3, 9, 3, 9, 0, 0), Vertex(-0.5, 0.5, -0.5, 0, 1, 0, 2, 9, 2, 9, 0, 0)] // Actual result: [Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5, 0.5, 0, 1, 0, 3, 10, 3, 10, 0, 0), Vertex(0.5, -0.5, 0.5, 0, -1, 0, 6, 3, 6, 3, 0, 0), Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5, -0.5, 0, 1, 0, 3, 9, 3, 9, 0, 0), Vertex(-0.5, 0.5, -0.5, 0, 1, 0, 2, 9, 2, 9, 0, 0)] If I change `enum` in line 117 to `auto` it produces the expected result. Any ideas why this happens? Bug. There is no excuse for compiler to get different result during CTFE. (Btw. I wasn't able produce a smaller testcase) It's not thousands of lines either. But where does Vertex type comes from? -- Olshansky Dmitry
Re: DMD CTFE Bug?
Am 17.08.2012 18:36, schrieb Dmitry Olshansky:
On 17-Aug-12 20:27, David wrote:
I have this code: http://dpaste.dzfl.pl/dbe2a07f
It works perfectly fine, except for `t!(2, 10)` and `t!(1, 10)`:
// Expected:
[Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5,
0.5, 0, 1, 0, 3, 10, 3, 10, 0, 0), Vertex(0.5, 0.5, -0.5, 0, 1, 0, 3,
9, 3, 9, 0, 0),
Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5,
-0.5, 0, 1, 0, 3, 9, 3, 9, 0, 0), Vertex(-0.5, 0.5, -0.5, 0, 1, 0, 2, 9,
2, 9, 0, 0)]
// Actual result:
[Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5,
0.5, 0, 1, 0, 3, 10, 3, 10, 0, 0), Vertex(0.5, -0.5, 0.5, 0, -1, 0, 6,
3, 6, 3, 0, 0),
Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5,
-0.5, 0, 1, 0, 3, 9, 3, 9, 0, 0), Vertex(-0.5, 0.5, -0.5, 0, 1, 0, 2, 9,
2, 9, 0, 0)]
If I change `enum` in line 117 to `auto` it produces the expected result.
Any ideas why this happens?
Bug. There is no excuse for compiler to get different result during CTFE.
Great ...
(Btw. I wasn't able produce a smaller testcase)
It's not thousands of lines either. But where does Vertex type comes from?
struct Vertex {
float x;
float y;
float z;
float nx;
float ny;
float nz;
byte u_terrain;
byte v_terrain;
byte u_mask;
byte v_mask;
float u_biome;
float v_biome;
}
Re: DMD CTFE Bug?
On 17-Aug-12 20:40, David wrote:
Am 17.08.2012 18:36, schrieb Dmitry Olshansky:
On 17-Aug-12 20:27, David wrote:
I have this code: http://dpaste.dzfl.pl/dbe2a07f
It works perfectly fine, except for `t!(2, 10)` and `t!(1, 10)`:
// Expected:
[Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5,
0.5, 0, 1, 0, 3, 10, 3, 10, 0, 0), Vertex(0.5, 0.5, -0.5, 0, 1, 0, 3,
9, 3, 9, 0, 0),
Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5,
-0.5, 0, 1, 0, 3, 9, 3, 9, 0, 0), Vertex(-0.5, 0.5, -0.5, 0, 1, 0, 2, 9,
2, 9, 0, 0)]
// Actual result:
[Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5,
0.5, 0, 1, 0, 3, 10, 3, 10, 0, 0), Vertex(0.5, -0.5, 0.5, 0, -1, 0, 6,
3, 6, 3, 0, 0),
Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5,
-0.5, 0, 1, 0, 3, 9, 3, 9, 0, 0), Vertex(-0.5, 0.5, -0.5, 0, 1, 0, 2, 9,
2, 9, 0, 0)]
If I change `enum` in line 117 to `auto` it produces the expected
result.
Any ideas why this happens?
Bug. There is no excuse for compiler to get different result during CTFE.
Great ...
(Btw. I wasn't able produce a smaller testcase)
It's not thousands of lines either. But where does Vertex type comes
from?
struct Vertex {
float x;
float y;
float z;
float nx;
float ny;
float nz;
byte u_terrain;
byte v_terrain;
byte u_mask;
byte v_mask;
float u_biome;
float v_biome;
}
Well then I think all you have to do is to put together the complete
sample and file it as CTFE bug here:
http://d.puremagic.com/issues/
--
Olshansky Dmitry
Re: ctfe bug?
Johannes Pfau wrote: Has this bug already been filed? I could possibly circumvent it by making ragel use array indexing instead of pointers, but that'd be a performance issue for runtime code as well. OK, I found a workaround: If I use data[x] = parse!ubyte(input[p-input.ptr-2 .. p-input.ptr], 16); instead, it works. So the issue is related to pointer slicing in ctfe.
Re: ctfe bug?
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any out-of-bound reads.
AFAIK pointers are supported in CTFE now as long as they're pointing to an
array and there are no out-of-bounds reads. Still, the following code fails:
ubyte[4] testCTFE()
{
ubyte[4] data;
string input = 8ab3060e2cba4f23b74cb52db3bdfb46;
auto p = input.ptr;
p++; p++;
data[0] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[1] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[2] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[3] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
return data;
}
enum ctfe = testCTFE();
void main()
{
import std.stdio;
writeln(testCTFE()); //[138, 179, 6, 14]
writeln(ctfe); //[138, 138, 138, 138]
}
Has this bug already been filed? I could possibly circumvent it by making
ragel use array indexing instead of pointers, but that'd be a performance
issue for runtime code as well.
Why would arrays be slower than pointers? You do know that you can turn
off array bounds checking?
--
/Jacob Carlborg
Re: ctfe bug?
Jacob Carlborg wrote:
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any out-of-bound reads.
AFAIK pointers are supported in CTFE now as long as they're pointing to
an array and there are no out-of-bounds reads. Still, the following code
fails:
ubyte[4] testCTFE()
{
ubyte[4] data;
string input = 8ab3060e2cba4f23b74cb52db3bdfb46;
auto p = input.ptr;
p++; p++;
data[0] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[1] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[2] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[3] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
return data;
}
enum ctfe = testCTFE();
void main()
{
import std.stdio;
writeln(testCTFE()); //[138, 179, 6, 14]
writeln(ctfe); //[138, 138, 138, 138]
}
Has this bug already been filed? I could possibly circumvent it by making
ragel use array indexing instead of pointers, but that'd be a performance
issue for runtime code as well.
Why would arrays be slower than pointers? You do know that you can turn
off array bounds checking?
Don't know, but I remember some benchmarks showed that arrays were slower,
even with bounds-checking off. (I think that was brought up in some
discussion about the tango xml parser).
Also the default for ragel is to use pointers, so I'd like to use that.
Making it use arrays means extra work ;-)
And turning off bounds-checking is not a perfect solution, as it applies to
the complete module. As I said, ragel makes sure that the pointer access is
safe, so there's really no issue in using pointers.
Re: ctfe bug?
On 12/22/2011 10:28 AM, Jacob Carlborg wrote:
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any out-of-bound reads.
AFAIK pointers are supported in CTFE now as long as they're pointing
to an
array and there are no out-of-bounds reads. Still, the following code
fails:
ubyte[4] testCTFE()
{
ubyte[4] data;
string input = 8ab3060e2cba4f23b74cb52db3bdfb46;
auto p = input.ptr;
p++; p++;
data[0] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[1] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[2] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[3] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
return data;
}
enum ctfe = testCTFE();
void main()
{
import std.stdio;
writeln(testCTFE()); //[138, 179, 6, 14]
writeln(ctfe); //[138, 138, 138, 138]
}
Has this bug already been filed? I could possibly circumvent it by making
ragel use array indexing instead of pointers, but that'd be a performance
issue for runtime code as well.
Why would arrays be slower than pointers? You do know that you can turn
off array bounds checking?
Yes but the length has to be stored and updated, therefore for example
p++ is less machine instructions/memory accesses/register pressure than
arr = arr[1..$].
Re: ctfe bug?
On 2011-12-22 14:39, Timon Gehr wrote:
On 12/22/2011 10:28 AM, Jacob Carlborg wrote:
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any out-of-bound reads.
AFAIK pointers are supported in CTFE now as long as they're pointing
to an
array and there are no out-of-bounds reads. Still, the following code
fails:
ubyte[4] testCTFE()
{
ubyte[4] data;
string input = 8ab3060e2cba4f23b74cb52db3bdfb46;
auto p = input.ptr;
p++; p++;
data[0] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[1] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[2] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[3] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
return data;
}
enum ctfe = testCTFE();
void main()
{
import std.stdio;
writeln(testCTFE()); //[138, 179, 6, 14]
writeln(ctfe); //[138, 138, 138, 138]
}
Has this bug already been filed? I could possibly circumvent it by
making
ragel use array indexing instead of pointers, but that'd be a
performance
issue for runtime code as well.
Why would arrays be slower than pointers? You do know that you can turn
off array bounds checking?
Yes but the length has to be stored and updated, therefore for example
p++ is less machine instructions/memory accesses/register pressure than
arr = arr[1..$].
Ok, I see. Then this seems to be a very performance critical piece of code.
--
/Jacob Carlborg
Re: ctfe bug?
Jacob Carlborg wrote:
On 2011-12-22 14:39, Timon Gehr wrote:
On 12/22/2011 10:28 AM, Jacob Carlborg wrote:
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any out-of-bound reads.
AFAIK pointers are supported in CTFE now as long as they're pointing
to an
array and there are no out-of-bounds reads. Still, the following code
fails:
ubyte[4] testCTFE()
{
ubyte[4] data;
string input = 8ab3060e2cba4f23b74cb52db3bdfb46;
auto p = input.ptr;
p++; p++;
data[0] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[1] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[2] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[3] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
return data;
}
enum ctfe = testCTFE();
void main()
{
import std.stdio;
writeln(testCTFE()); //[138, 179, 6, 14]
writeln(ctfe); //[138, 138, 138, 138]
}
Has this bug already been filed? I could possibly circumvent it by
making
ragel use array indexing instead of pointers, but that'd be a
performance
issue for runtime code as well.
Why would arrays be slower than pointers? You do know that you can turn
off array bounds checking?
Yes but the length has to be stored and updated, therefore for example
p++ is less machine instructions/memory accesses/register pressure than
arr = arr[1..$].
Ok, I see. Then this seems to be a very performance critical piece of
code.
In this special case it's not that important (simple UUID parser), but ragel
is also used for HTTP parsers in webservers (lighttpd2), json parsers, etc
and it's main advantage is speed.
ctfe bug?
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any out-of-bound reads.
AFAIK pointers are supported in CTFE now as long as they're pointing to an
array and there are no out-of-bounds reads. Still, the following code fails:
ubyte[4] testCTFE()
{
ubyte[4] data;
string input = 8ab3060e2cba4f23b74cb52db3bdfb46;
auto p = input.ptr;
p++; p++;
data[0] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[1] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[2] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[3] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
return data;
}
enum ctfe = testCTFE();
void main()
{
import std.stdio;
writeln(testCTFE()); //[138, 179, 6, 14]
writeln(ctfe); //[138, 138, 138, 138]
}
Has this bug already been filed? I could possibly circumvent it by making
ragel use array indexing instead of pointers, but that'd be a performance
issue for runtime code as well.
