[Issue 2551] std.format on invariant values : error and segmentation fault
http://d.puremagic.com/issues/show_bug.cgi?id=2551 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #3 from Don clugd...@yahoo.com.au 2009-10-19 01:19:49 PDT --- This was fixed between 2.026 and 2.030. I believe the segfault was fixed in 2.027. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3409] stdio.File.seek() doesn't work for files 2GB
http://d.puremagic.com/issues/show_bug.cgi?id=3409 --- Comment #5 from Sobirari Muhomori dfj1es...@sneakemail.com 2009-10-19 02:08:08 PDT --- I don't know why under Windows c_long is actually 32 bit. because msvc compiler is LLP64. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3409] stdio.File.seek() doesn't work for files 2GB
http://d.puremagic.com/issues/show_bug.cgi?id=3409 --- Comment #6 from Sobirari Muhomori dfj1es...@sneakemail.com 2009-10-19 02:13:29 PDT --- (In reply to comment #4) Could be wrong, but I think the way druntime defines these functions is because that's the way they're defined in the C std lib API. Yes, but that's *C* API, so the type should be c_long. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2364] ftell return type is long in C, that is 64-bit on x86-64
http://d.puremagic.com/issues/show_bug.cgi?id=2364 Sobirari Muhomori dfj1es...@sneakemail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3409] stdio.File.seek() doesn't work for files 2GB
http://d.puremagic.com/issues/show_bug.cgi?id=3409 Sobirari Muhomori dfj1es...@sneakemail.com changed: What|Removed |Added Severity|major |regression --- Comment #7 from Sobirari Muhomori dfj1es...@sneakemail.com 2009-10-19 02:20:19 PDT --- Strange, in 2.020 it was intfseek(FILE* stream, c_long offset, int whence); so this is regression. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3282] The overload and override issue of const/immutable member functions
http://d.puremagic.com/issues/show_bug.cgi?id=3282 --- Comment #1 from Haruki Shigemori rayerd@gmail.com 2009-10-19 03:22:09 PDT --- This problem occurs when const is shared. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2364] ftell return type is long in C, that is 64-bit on x86-64
http://d.puremagic.com/issues/show_bug.cgi?id=2364 Tomas Lindquist Olsen to...@famolsen.dk changed: What|Removed |Added CC||to...@famolsen.dk --- Comment #5 from Tomas Lindquist Olsen to...@famolsen.dk 2009-10-19 03:20:56 PDT --- Even with the misunderstanding of C long being 32 or 64 bit, translating a C long to a D int is still wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3416] Non-compilable template instantiation in is(typeof()) fails compilation
http://d.puremagic.com/issues/show_bug.cgi?id=3416 --- Comment #6 from Max Samukha samu...@voliacable.com 2009-10-19 06:24:50 PDT --- Ok, but there is no other way to determine if some syntactically correct code is also correct semantically. And without that, D's metaprogramming system is of little use. Anyway, I'm not sure whether semantically incorrect code should produce a valid type, which void is. Should it? And the current compiler seems to treat __traits(compiles, X) and is(typeof(X)) identically... I think this bug should remain open until is(typeof(X)) is fixed or a different/better mechanism is introduced. And it is definitely a blocker. Thanks -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3420] New: Impossible to specify -J path for subdirectories
http://d.puremagic.com/issues/show_bug.cgi?id=3420 Summary: Impossible to specify -J path for subdirectories Product: D Version: 1.042 Platform: All OS/Version: Windows Status: NEW Severity: regression Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: thecybersha...@gmail.com --- Comment #0 from Vladimir thecybersha...@gmail.com 2009-10-19 07:55:10 PDT --- const data = import(dir/data.txt); Specifying -J. for DMD 1.041 is sufficient to allow this to compile. I couldn't find an option for DMD 1.042 and newer which would allow this to compile. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3421] New: Inline assembler problems accessing static variables
http://d.puremagic.com/issues/show_bug.cgi?id=3421
Summary: Inline assembler problems accessing static variables
Product: D
Version: 2.035
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: grahamc00...@yahoo.co.uk
--- Comment #0 from Graham grahamc00...@yahoo.co.uk 2009-10-19 08:03:19 PDT
---
This code works in DMD v1.047 and fails in DMD v2.035
import std.stdio;
static int value1;
void main() {
value1 = 2;
asm {
movEAX,1;
mov[value1],EAX;
}
writefln(value1 %d, value1);
}
The code generated in each case is:
Compiled under DMD v 1.047:
u __Dmain l39
TEST03!__Dmain+0x0:
0x00402010 55 push ebp
0x00402011 8bec mov ebp,esp
0x00402013 c705801445000200
mov dword ptr [_D6test036value1i
(00451480)],0002
0x0040201d b80100 mov eax,0001
0x00402022 a380144500 mov dword ptr [_D6test036value1i
(00451480)],eax
0x00402027 ff3580144500 push dword ptr [_D6test036value1i
(00451480)]
0x0040202d ff3594b04400 push dword ptr [_TMP0+0004 (0044b094)]
0x00402033 ff3590b04400 push dword ptr [_TMP0 (0044b090)]
0x00402039 b8f0b04400 mov eax,0044b0f0
0x0040203e 50 push eax
0x0040203f e83017 call _D3std5stdio8writeflnFYv (00403774)
0x00402044 83c410 add esp,10
0x00402047 5d pop ebp
0x00402048 c3 retn
Compiled under DMD v 2.0035:
u __Dmain l43
TEST03!__Dmain+0x0:
0x00402010 55 push ebp
0x00402011 8bec mov ebp,esp
0x00402013 53 push ebx
0x00402014 64a12c00 mov eax,dword ptr fs:[002c]
0x0040201a 8b08 mov ecx,dword ptr [eax]
0x0040201c c78104000200
mov dword ptr [ecx+0004],0002
0x00402026 b80100 mov eax,0001
0x0040202b a30400 mov dword ptr [0004],eax
0x00402030 ff3594904200 push dword ptr [_TMP0+0004 (00429094)]
0x00402036 ff3590904200 push dword ptr [_TMP0 (00429090)]
0x0040203c 648b152c00 mov edx,dword ptr fs:[002c]
0x00402043 8b1a mov ebx,dword ptr [edx]
0x00402045 8b830400 mov eax,dword ptr [ebx+0004]
0x0040204b e80400 call
_D3std5stdio19__T8writeflnTAyaTiZ8writeflnFAyaiZv (00402054)
0x00402050 5b pop ebx
0x00402051 5d pop ebp
0x00402052 c3 retn
The D code accesses 'value1' as dword ptr [ecx+0004] and the inline
assember as dword ptr [0004]
Is this a change in the language runtime specification for how module static
variables are accessed or it this a bug ?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3421] Inline assembler problems accessing static variables
http://d.puremagic.com/issues/show_bug.cgi?id=3421 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2009-10-19 08:37:32 PDT --- It's a change. statics are now thread-local by default. You need to mark as __gshared if you want the D1 behaviour. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2364] ftell return type is long in C, that is 64-bit on x86-64
http://d.puremagic.com/issues/show_bug.cgi?id=2364 Brad Roberts bra...@puremagic.com changed: What|Removed |Added CC||bra...@puremagic.com Resolution|INVALID |FIXED --- Comment #6 from Brad Roberts bra...@puremagic.com 2009-10-19 09:20:26 PDT --- Changing to resolved-fixed. In druntime, where this stuff lives now, it's defined as a c_long: c_long ftell(FILE* stream); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3381] [tdpl] Incorrect assessment of overriding in triangular-shaped hierarchy
http://d.puremagic.com/issues/show_bug.cgi?id=3381 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added CC||llu...@gmail.com --- Comment #4 from Leandro Lucarella llu...@gmail.com 2009-10-19 12:46:00 PDT --- I wonder you (Andrei) don't search for existing bugs instead of blindly creating new ones =( If you want to mark all TDPL bugs by prefixing [tldp] to the subject, you can edit the old bug's title. I'm saying this because I saw several bugs which were duplicates of old ones. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3381] [tdpl] Incorrect assessment of overriding in triangular-shaped hierarchy
http://d.puremagic.com/issues/show_bug.cgi?id=3381 --- Comment #5 from Andrei Alexandrescu and...@metalanguage.com 2009-10-19 12:55:57 PDT --- (In reply to comment #4) I wonder you (Andrei) don't search for existing bugs instead of blindly creating new ones =( If you want to mark all TDPL bugs by prefixing [tldp] to the subject, you can edit the old bug's title. I'm saying this because I saw several bugs which were duplicates of old ones. I'll try to look harder. My problem is that I never know what keywords to look for. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3387] gdb: symbols in the backtrace are not demangled
http://d.puremagic.com/issues/show_bug.cgi?id=3387 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added Version|1.047 |1.051 Severity|regression |normal --- Comment #2 from Leandro Lucarella llu...@gmail.com 2009-10-19 19:07:58 PDT --- It doesn't look like a regression after all, it seems to depend on whatever -g or -gc is used. With -g I get the properly demangled names, but with -gc I don't. The problem is, -g is broken with GDB, so I can't use -g. It would be a problem to have -gc producing the necessary debug info to get properly demangled names? Sorry for the noise. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
