[Issue 6019] Phobos imports in autogenerated .di header files break implicit linking with DLLs
http://d.puremagic.com/issues/show_bug.cgi?id=6019 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #5 from Rainer Schuetze 2011-05-17 23:53:29 PDT --- The import in the di file tells the compiler that there are dependencies to other modules that need to be respected during module initialization. That's why they are placed into the module info. I agree it is very annoying not to be able to use the generated di files (let alone the d files). Two possible solutions: - add a switch to the compiler to only put exported symbols into the di file and leave out imports. This might make it difficult to compile this file if there are still references to symbols defined by the imports. - add a modifier to the "import" declaration that avoids adding dependencies to the module info. (IIRC this has also been discussed to break cyclic module initialization.) If used in driver.d, it might even restrict imported symbols to the symbols marked "export" in the di file. If used for the imports of the generated di-file, it might break the correct init order when used for modules built to static libraries (as druntime). BTW: I checked the generated object files: the buggy version also adds symbols _D47TypeInfo_S3std6traits15__T8DemangleTkZ8Demangle6__initZ and _D3std6traits15__T8DemangleTkZ8Demangle6__initZ. I don't know why this happens, but as these are comdats, they problably won't break anything. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5845] Regression(2.041) [CTFE] "stack overflow" with recursive ref argument
http://d.puremagic.com/issues/show_bug.cgi?id=5845 --- Comment #2 from bearophile_h...@eml.cc 2011-05-17 16:03:23 PDT --- (In reply to comment #1) > This is not useful as a benchmark. Do you want to tell me why? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6019] Importing Phobos modules in a DLL breaks compilation
http://d.puremagic.com/issues/show_bug.cgi?id=6019 --- Comment #4 from Andrej Mitrovic 2011-05-17 15:49:02 PDT --- Freakin' hell. Ok so I've ran it down to blaming the header generation. Here's an example with a hand-generated .di header file versus automatically generated .di file. The hand-edited one is almost the same as the compiler generates it, except it has imports to Phobos *commented out*. http://dl.dropbox.com/u/9218759/DLL_bug_test_case.zip -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6019] Implicit linking with D DLLs using import switch doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=6019 --- Comment #3 from Andrej Mitrovic 2011-05-17 15:29:33 PDT --- Ok, I think I have found a very simple test case: http://dl.dropbox.com/u/9218759/dll_bugs.zip The only difference between the two projects is that the one which does an import to a Phobos function will not compile. So I'm changing the title of this bug report. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6026] New: DLL example needs update due to missing core.dll_helper
http://d.puremagic.com/issues/show_bug.cgi?id=6026 Summary: DLL example needs update due to missing core.dll_helper Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2011-05-17 14:33:36 PDT --- http://d-programming-language.org/dll.html#Cinterface core.dll_helper no longer exists in 2.053, replace the import with: import core.sys.windows.dll; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5258] [CTFE] Stack overflow with struct by ref
http://d.puremagic.com/issues/show_bug.cgi?id=5258 --- Comment #3 from Don 2011-05-17 14:22:02 PDT --- The bug reported in comment 1 is bug 5845, which is a different bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5845] Regression(2.041) [CTFE] "stack overflow" with recursive ref argument
http://d.puremagic.com/issues/show_bug.cgi?id=5845
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
Summary|[CTFE] "stack overflow" |Regression(2.041) [CTFE]
|with ref ulong argument + |"stack overflow" with
|CTFE benchmark |recursive ref argument
--- Comment #1 from Don 2011-05-17 14:04:11 PDT ---
This is not useful as a benchmark.
Reduced test case:
void test5845(ulong cols) {}
uint solve(bool niv, ref ulong cols) {
if (niv)
solve(false, cols);
else
test5845(cols);
return 65;
}
ulong nqueen(int n) {
ulong cols= 0;
return solve(true, cols);
}
static assert(nqueen(2) == 65);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6025] New: Fiber does not rethrow exceptions
http://d.puremagic.com/issues/show_bug.cgi?id=6025
Summary: Fiber does not rethrow exceptions
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: regression
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: psztur...@tlen.pl
--- Comment #0 from Piotr Szturmaj 2011-05-17 13:26:14 PDT
---
Documentation states that Fiber rethrows any exceptions thrown inside fiber
function, yet it do not happen.
Following program just terminates silently when ran in the console, and throws
Access violation when debugging inside VisualD. Tested under Windows XP.
-
module main;
import core.thread;
void fiberMain()
{
throw new Exception("test");
}
void main(string[] argv)
{
auto fiber = new Fiber(&fiberMain);
fiber.call();
}
-
Output from VisualD:
-
First-chance exception at 0x0042baca in DBugs3.exe: 0xC0FD: Stack overflow.
First-chance exception at 0x0042baca in DBugs3.exe: 0xC005: Access
violation reading location 0x00aafaa8.
Unhandled exception at 0x0042baca in DBugs3.exe: 0xC005: Access violation
reading location 0x00aafaa8.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6024] Windows 2000 SP4 is not supported any more? And what is still supported?
http://d.puremagic.com/issues/show_bug.cgi?id=6024 --- Comment #9 from Vladimir Panteleev 2011-05-17 13:18:21 PDT --- Jonathan, After quickly patching out RtlCaptureContext, I checked and std.datetime unittests start just fine on Windows 98. However, the unit tests fail. The first failure is a failed assert at line 30090 (call to SystemTimeToTzSpecificLocalTime fails). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6024] Windows 2000 SP4 is not supported any more? And what is still supported?
http://d.puremagic.com/issues/show_bug.cgi?id=6024 --- Comment #8 from Jonathan M Davis 2011-05-17 13:12:57 PDT --- Well, all I have to go on is the documentation, and it says Win2K pro. I have no idea if any of them work prior to that, and if they don't, then there's no way to get that code to work on a version of Windows that old. Still, I find it to be astonishing that we're at all concerned with anything prior to XP at this point. If there are developers who want to make it so that some code checks the version of Windows that it's on and adjusts what it's doing accordingly, then that's fine with me, but if it were my choice, I'd say that we should just say that we're not going to support anything older than XP (or _maybe_ Win2K) and be done with it. Heck, I'd _love_ to be able to require Vista or newer given some of the system calls that they added, but that would be totally unreasonable, since XP is still heavily used. But I wouldn't expect anything older than that to be much used at this point, and particularly for D2, which is a newer language and arguably not even production-ready yet, I think that it would be perfectly reasonable to say that it's not supported on OSes which are very much out-of-date. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6024] Windows 2000 SP4 is not supported any more? And what is still supported?
http://d.puremagic.com/issues/show_bug.cgi?id=6024 --- Comment #7 from Vladimir Panteleev 2011-05-17 13:02:52 PDT --- Jonathan, A while ago Microsoft updated the "minimum supported Windows version" fields in MSDN to only go back as far as Windows 2000. Thus, do not rely on that information being correct. For example, look at the documentation for GetMessage, the cornerstone function of Windows GUI applications - MSDN will also claim that the "Minimum supported client" is "Windows 2000 Professional". I believe the reason for that is simply that earlier Windows versions are completely unsupported by Microsoft. > and I suspect that the module won't compile on a Windows version older than > that. That's not how linking to libraries works on Windows. It doesn't matter which Windows version you compile on, since system DLLs are not accessed during compilation or linking - only the import libraries are. Attempting to run the executable for which the OS can't resolve all dependencies will result in an error message. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6024] Windows 2000 SP4 is not supported any more? And what is still supported?
http://d.puremagic.com/issues/show_bug.cgi?id=6024 --- Comment #6 from Jonathan M Davis 2011-05-17 12:55:58 PDT --- None of the Windows system function calls that std.datetime uses existed prior to Win2K Pro. So, if you use SysTime with either LocalTime (which is the default) or a WindowsTimeZone as its time zone, it won't work. Also, it uses Windows system functions to access the registry, and those didn't exist before Win2K Pro. To get those to work, it has the line pragma(lib, "advapi32.lib"); to link in the necessary library, and I don't know if that library even existed prior to Win2K pro. So, essentially, SysTime can't really be used on a version of Windows prior to Win2K pro, and I suspect that the module won't compile on a Windows version older than that. I'd have to dig through std.datetime to see what the exact list of the system functions is though. >From what I've see of the Windows system calls, a _lot_ of them were added with Win2K pro, and it would be very easy to create a program using much in the way of Windows system calls which wouldn't work prior to Win2K pro. I believe that Vista is the next version of Windows to really add much in the way of system calls (and it added some good ones), but I also don't think that it's at all reasonable to put anything into druntime or Phobos at this point which requires anything newer than XP. XP is still far too prevalent for that (and it would be nice to be able to use some of those calls added with Vista, since some of them are definite improvements over their predecessors). std.datetime simply cannot do what it does on a Windows system prior to Win2K. The functionality didn't exist as far as system calls go. And honestly, while I'm not opposed to us working to have druntime and Phobos work with versions of Windows prior to XP if we can reasonably do it, I think that it would very reasonable to simply say that we don't support versions of Windows older than XP. The user base for them is very small at this point, and frankly I'm surprised that we have anyone trying to use D on systems that old. Regardless, std.datetime cannot possibly work on a version of Windows older than Win2K pro. Depending on what you can get to compile, you should be able to use everything other than SysTime and its associated time zone stuff (since none of the rest needs Windows system calls), but they need it and won't work on anything prior to Win2K Pro. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6024] Windows 2000 SP4 is not supported any more? And what is still supported?
http://d.puremagic.com/issues/show_bug.cgi?id=6024 --- Comment #5 from Vladimir Panteleev 2011-05-17 12:21:10 PDT --- (In reply to comment #4) > (In reply to comment #2) > > It looks like the RtlCaptureContext call can be replaced with some simple > > assembler. All it needs is the contents of the EIP, EBP and ESP registers. > > Some > > compilers offer intrinsics for special CPU registers, although I don't think > > DMD does. > > DMD has inline assembler, so this should be straightforward. What exactly is > needed? The contents of the EIP, EBP and ESP registers. (I only mentioned intrinsics because they would be favorable to inline assembler.) StackWalk64 also accepts a CONTEXT structure, which, according to its documentation, is optional on x86, but may improve its behavior in certain situations. Thus, RtlCaptureContext should still be used when it is available. https://github.com/D-Programming-Language/druntime/blob/5098e60a74d5ff06aa808a5f02202f4762feac03/src/core/sys/windows/stacktrace.d#L288 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6024] Windows 2000 SP4 is not supported any more? And what is still supported?
http://d.puremagic.com/issues/show_bug.cgi?id=6024 --- Comment #4 from Walter Bright 2011-05-17 12:12:48 PDT --- (In reply to comment #2) > It looks like the RtlCaptureContext call can be replaced with some simple > assembler. All it needs is the contents of the EIP, EBP and ESP registers. > Some > compilers offer intrinsics for special CPU registers, although I don't think > DMD does. DMD has inline assembler, so this should be straightforward. What exactly is needed? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6024] Windows 2000 SP4 is not supported any more? And what is still supported?
http://d.puremagic.com/issues/show_bug.cgi?id=6024 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright 2011-05-17 12:11:54 PDT --- (In reply to comment #1) > std.datetime won't work with anything prior to Win2k pro because some of > the functions that it needs didn't exist before that. Which functions? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6018] Multiple includes of std.parallelism causes DMD to segfault.
http://d.puremagic.com/issues/show_bug.cgi?id=6018 --- Comment #2 from Jonathan Crapuchettes 2011-05-17 09:18:52 PDT --- Created an attachment (id=978) DMD2 -v output I just tried to create a simple test case, but couldn't get it to break. I am including the output from DMD with -v. As you can see all of the files were compiled together. I did notice, after commenting out one file, that DMD always died just after outputting "function this". This makes me wonder if it has some connection to auto varPool = taskPool.workerLocalStorage(new ThreadStore()); but that isn't based on actual evidence. I hope this helps a little. I would be happy to send you the files privately, but I can't post them as they belong to the company I work for. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6021] std.parallelism missing from dpl.org
http://d.puremagic.com/issues/show_bug.cgi?id=6021 David Simcha changed: What|Removed |Added CC||dsim...@yahoo.com --- Comment #1 from David Simcha 2011-05-17 05:36:47 PDT --- Same for std.net.isemail. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6000] Value range propagation does not work with modulus (%) with a constant
http://d.puremagic.com/issues/show_bug.cgi?id=6000
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc 2011-05-17 02:51:59 PDT ---
A similar case:
void main() {
long n = 10520;
ubyte b = n % 10;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6024] Windows 2000 SP4 is not supported any more? And what is still supported?
http://d.puremagic.com/issues/show_bug.cgi?id=6024 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev 2011-05-17 01:23:33 PDT --- It looks like the RtlCaptureContext call can be replaced with some simple assembler. All it needs is the contents of the EIP, EBP and ESP registers. Some compilers offer intrinsics for special CPU registers, although I don't think DMD does. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6024] Windows 2000 SP4 is not supported any more? And what is still supported?
http://d.puremagic.com/issues/show_bug.cgi?id=6024 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis 2011-05-17 00:56:09 PDT --- What is supported depends entirely on which feature or module you're talking about. std.datetime won't work with anything prior to Win2k pro because some of the functions that it needs didn't exist before that. std.file, on the other hand, manages to include compatability for Win98. It's not really possible at this point to say which versions of Windows are supported, because it depends entirely on which features you're talking about. I don't believe that anything in druntime or Phobos requires anything which was added after XP (and given how prevalent XP still is, it shouldn't), but anything older than XP is very much hit and miss. Personally, I think that it would be a great idea to just declare that anything older than XP is unsupported, but the general approach has been to support the oldest version of Windows that we reasonably can for any particular piece of functionality. I don't know what the situation is with the stacktraces and whether that can be dealt with in a way that allows druntime to function on OSes prior to XP. If anything, I'd say that the current state is that you should expect that the current dmd and libraries should fully work on XP but with anything before that, you risk it not working. Generally, however, bugs relating to pre-XP will be fixed if it can be reasonably done. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6024] New: Windows 2000 SP4 is not supported any more? And what is still supported?
http://d.puremagic.com/issues/show_bug.cgi?id=6024
Summary: Windows 2000 SP4 is not supported any more? And what
is still supported?
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: blocker
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis 2011-05-17 00:39:19 PDT
---
Since dmd v2.053 RtlCaptureContext function (minimum supported client Windows
XP) is in file
runtime\src\core\sys\windows\stacktrace.d
So on Windows 2000 you have "Entry point not found" error when any D2 program
starts (e.g "void main() { }" program).
I'll understand, if Windows 2000 is not supported any more. I think it can be
supported, but if community doesn't want, so be it. But this undefined
behaviour is very bad. Please write supported operating systems somewhere in
plain view (e.g. in Requirements and Downloads section of
http://www.digitalmars.com/d/2.0/dmd-windows.html). And in write in changelog
"... OS is not supported any more".
Since some previous version, you have no command line arguments on Windows 98,
but in std.file there are a lot of code aimed to support this OS. It's very
confusing. So, please, write what systems are supported. "operating system,
such as Windows XP" is sounds very obscure (and it is).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
