[Issue 8521] New: Internal error: e2ir.c 720 when a function uses a template which relies on that function and -release and -inline are used
http://d.puremagic.com/issues/show_bug.cgi?id=8521
Summary: Internal error: e2ir.c 720 when a function uses a
template which relies on that function and -release
and -inline are used
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-08-08 00:18:00
PDT ---
This is currently a blocker for phobos pull request# 743, which make stride,
strideBack, and decode work with arbitrary ranges of code units, which is
needed for the D lexer for Phobos that I'm working on.
This is the reduced code:
import std.traits;
void main()
{
auto tmp = hello;
size_t i = 0;
decode(tmp, i);
}
template isRange(R)
{
enum bool isRange = is(typeof(
{
R r = void;
auto w = r.front;
}));
}
@property dchar front(A)(A a)
{
size_t i = 0;
return decode(a, i);
}
dchar decode(S)(auto ref S str, ref size_t index)
{
return decodeImpl(str, index);
}
private dchar decodeImpl(S)(auto ref S str, ref size_t index)
{
enum canIndex = isRange!S;
assert(0);
}
It compiles just fine normally, but when you compile with -release and -inline
together, it fails to compile, giving this error:
decodeImpl(S)
Internal error: e2ir.c 720
I think that the problem stems from the fact that isRange depends on decode,
which in turn depends on isRange, and something about the inlining process
screws it up. Moving the line with isRange from decodeImpl into decode makes
the problem going away as does removing front from inside of isRange. And using
decode inside of isRange makes it go away as well. So, it seems that the number
of levels of indirection has to be at at least a certain level before the
failure occurs.
The code in pull request# 743 passes its unit tests just fine as long as you
don't compile with both -release and -inline, so clearly the code can work, but
something about -release and -inline screws it up.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1759] Closures and With Statements
http://d.puremagic.com/issues/show_bug.cgi?id=1759 timon.g...@gmx.ch changed: What|Removed |Added Status|RESOLVED|REOPENED CC||timon.g...@gmx.ch Resolution|INVALID | --- Comment #2 from timon.g...@gmx.ch 2012-08-08 02:05:30 PDT --- (In reply to comment #1) This is not a bug it's a feature, This can lead to memory corruption in @safe code, therefore it is a bug. there's solution: This is a workaround. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8520] Simple in-constrained opBinaryRight in interface doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=8520
--- Comment #2 from Alex R�nne Petersen a...@lycus.org 2012-08-08 12:15:19
CEST ---
(In reply to comment #1)
Your understanding is wrong - templates never go in the vtable.
The solution is to use NVI and forwarding:
interface I
{
int* opBinaryRight_in(int i);
int* opBinaryRight(string op : in)(int i)
{
return opBinaryRight_in(i);
}
}
class C : I
{
int* opBinaryRight_in(int i)
{
return null;
}
}
I could understand if the opBinaryRight template wasn't constrained to in,
but it is, so I see no reason why it cannot be in the vtable since it can only
ever have one instance in a class.
The NVI solution works, but it's very ugly.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8520] Simple in-constrained opBinaryRight in interface doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=8520 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Severity|major |enhancement --- Comment #3 from Alex R�nne Petersen a...@lycus.org 2012-08-08 12:15:50 CEST --- Changing to enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8522] New: Overloading template function with prefix const doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=8522
Summary: Overloading template function with prefix const
doesn't work
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-08-08 08:17:28 PDT ---
Postfix const works, but prefix version doesn't work
struct Tuple(Specs...)
{
Specs field;
bool opEquals(R)(R rhs) { return true; }
// bool opEquals(R)(R rhs) const { return true; } // OK
const bool opEquals(R)(R rhs) { return true; } // NG
}
void main()
{
Tuple!(size_t, size_t) t;
assert(t == t);// line 14
}
output:
test.d(14): Error: template test.Tuple!(uint,uint).Tuple.opEquals matches more
than one template declaration, test.d(5):opEquals(R) and test.d(8):opEquals(R)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8522] Overloading template function with prefix const doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=8522
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-08-08 08:51:16 PDT ---
More explainable test case.
struct Point
{
bool opEquals(R)(R rhs) { return true; }
bool opEquals(R)(R rhs) const { return true; }
}
void main()
{
Point mp;
const Point cp;
assert(mp == mp);
assert(mp == cp);
assert(cp == mp); // doesn't work
assert(cp == cp); // doesn't work
}
If the left hand side of '==' is const value, const opEquals never matches.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8522] Comparison operator overloading doesn't consider the qualifier of lhs
http://d.puremagic.com/issues/show_bug.cgi?id=8522 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Summary|Overloading template|Comparison operator |function with prefix const |overloading doesn't |doesn't work|consider the qualifier of ||lhs --- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-08-08 08:58:02 PDT --- https://github.com/D-Programming-Language/dmd/pull/1075 And changed the title. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8520] Simple in-constrained opBinaryRight in interface doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=8520
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
CC||jmdavisp...@gmx.com
--- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2012-08-08 10:11:34
PDT ---
I could understand if the opBinaryRight template wasn't constrained to in,
but it is, so I see no reason why it cannot be in the vtable since it can only
ever have one instance in a class.
Because templated functions _never_ end up in the vtable. Mixed in templates
may if they're fully instantiated when mixed in (I don't remember), but a
templated function written directly in the class is _never_ virtual.
That doesn't necessarily mean that there are no situations where the language
could be enhanced to make a templated function virtual if it's actually
restricted enough (and this may be such a case), but as it stands, being a
template is enough to make it non-virtual regardless of what it does or how
constrained it is or isn't. I don't believe that even
int func()() { return 2; }
would be virtual, and that's pretty much as constrained as it gets.
Of course, if such a function _did_ get changed to virtual, then it would
always defined, whereas right now it's only defined if used, which could be a
definite negative, depending on the programmer's intent. So, there's defintely
a tradeoff here even if it's possible to make some templated functions virtual.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8521] Internal error: e2ir.c 720 when a function uses a template which relies on that function and -release and -inline are used
http://d.puremagic.com/issues/show_bug.cgi?id=8521 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Severity|blocker |major --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-08-08 12:53:49 PDT --- Okay. I was finally able to find a workaround by moving the test inside of decodeImpl to outside of it, which is leaking its implementation details and forcing a bool with the result of the test to be passed to an overload of decodeImpl which doesn't need the test at all, but it does make it so that the code works, and it doesn't affect the public API at all. So, I'm changing this bug to major rather than blocker. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8523] New: compile time parsing of hex floats
http://d.puremagic.com/issues/show_bug.cgi?id=8523 Summary: compile time parsing of hex floats Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: ellery-newco...@utulsa.edu --- Comment #0 from Ellery Newcomer ellery-newco...@utulsa.edu 2012-08-08 12:55:19 PDT --- doesn't work, but should. enum string s = 0x9.D70A3D70A3D70A4p-3; enum d2 = to!real(s); pragma(msg, d2); gives me: /usr/include/dmd-d/std/conv.d(2305): Error: Cannot convert real to long* at compile time /usr/include/dmd-d/std/conv.d(1592):called from here: parse(value) /usr/include/dmd-d/std/conv.d(268):called from here: toImpl(_param_0) test.d(14):called from here: to(0x9.D70A3D70A3D70A4p-3) /usr/include/dmd-d/std/conv.d(2305): Error: Cannot convert real to long* at compile time /usr/include/dmd-d/std/conv.d(1592):called from here: parse(value) /usr/include/dmd-d/std/conv.d(268):called from here: toImpl(_param_0) test.d(15):called from here: to(0x9.D70A3D70A3D70A4p-3) to(0x9.D70A3D70A3D70A4p-3) however, double d = to!real(s); writeln(d); compiles and prints 1.23 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8524] New: Phobos cannot be compiled with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=8524 Summary: Phobos cannot be compiled with -inline Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-08-08 13:04:05 PDT --- If I change Phobos to be build with -O -release -inline for the release build, it fails to build with this error: std/file.d(2777): Error: function std.file.dirEntries compiler error, parameter 'pattern', bugzilla 2962? dmd: glue.c:758: virtual void FuncDeclaration::toObjFile(int): Assertion `0' failed. make[1]: *** [generated/linux/release/64/libphobos2.a] Aborted make: *** [unittest] Error 2 This may or may not be related to bug# 8250. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: OPTLINK : Error 118: Filename Expected
On 8/8/2012 4:11 PM, anon wrote: Yet another obscure error message that makes no sense. I suspect it's the ( ) you have in the file names.
[Issue 8525] New: optimizer loops infinitely
http://d.puremagic.com/issues/show_bug.cgi?id=8525
Summary: optimizer loops infinitely
Product: D
Version: D2
Platform: All
OS/Version: Other
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@dawgfoto.de
--- Comment #0 from d...@dawgfoto.de 2012-08-08 19:04:00 PDT ---
OpenBSD-only
cat bug.d CODE
class Foo
{
int[] elements;
final int bar()
{
return elements[0];
}
}
CODE
dmd -c -O bug.d
The bug is caused by infinitely performing two associative transformations.
- cgelem.c(): Replace (a op1 (b op2 c)) with ((a op2 b) op1 c)
- cgelem.c(4471): Replace ((a op c1) op c2) with (a op (c2 op c1))
It only happens on OpenBSD because folding 'c2 op c1' fails in evalu8 due to a
fenv.h workaround.
The proposed fix is to perform the first transformation only if 'b' is not a
constant.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8525] optimizer loops infinitely
http://d.puremagic.com/issues/show_bug.cgi?id=8525
--- Comment #1 from d...@dawgfoto.de 2012-08-08 20:19:56 PDT ---
There is another similar bug.
cat bug.d CODE
int get(int[] devt)
{
return devt[$ - 1];
}
CODE
dmd -c -O bug.d
This can be reproduced on non-OpenBSD platforms by deactivating evalu8,
i.e. defining 'elem * evalu8(elem *e) { return e; }'. This is effectively
what this functions does on OpenBSD.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8525] optimizer loops infinitely
http://d.puremagic.com/issues/show_bug.cgi?id=8525 --- Comment #2 from d...@dawgfoto.de 2012-08-08 20:30:50 PDT --- https://github.com/D-Programming-Language/dmd/pull/1076 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
