• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

1410 Excellent

About tanzanite7

  • Rank
  1. Followup:   Tried the old code with U3 - same behavior. Which at this point i am confident enough to call a bug (*) - no compiler should fail at this kind of basics. I have compared both compilations and they are nearly identical (even ends up using the exact same registers with same instructions throughout) - with the sole exception of minor difference at the function call site and the unnecessary spill (non-spilling code just uses R8 [free to trash] instead of RBX [requires spill]) and frame code.   Platform Toolset: Visual Studio 2015 (v140). Is this correct? How can i confirm the new compiler is in use (edit: i did notice that the compiler specifically told it had to recompile all functions instead of doing the usual incremental rebuild)?   Did i miss something?   *) Which it obviously technically is not - since the functional end result is exactly what it should be.
  2.   Still on Update1. New optimizer? Did not know that, thanks. Well, then i need to update - will do that.   However, before i revisited the forums today i noticed (since all that code was on slow path i did not care much what happened on that path before) that i can easily convince the compiler to tail-call optimize out the, somehow offending, function call:   ----------------- before:         auto res = man.get(at);         man.lock.put();         return res; ----------------- after:         return man.getAndUnlock(at);   ... and the compiler happily obliged - all of the spill nonsense is gone (ebx gone and all the frame junk also gone [since all the function calls got tail-call optimized causing the caller to be essentially leaf function enabling all relevant optimizations]).   So, unfortunately can not tell whether U3 would have made a difference (would be interesting to know, so might un-fix when i update).
  3. I am experiencing a perplexing registry spill in a function that uses ONLY (spill inclusive) the following registers: rax, rbx, rcx, rdx, rsp.   rsp: for spill (and one call - cannot remember whether it is required ... should be pointless in regards to unwind, dunno) rbx: for spill   Why would that happen? What could cause that? It does not even use all the volatile registers up ( https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx ) - at least R8 and R9 are free (i think R10 and R11 are also with standard Win x64 ABI).   Excluding code for rbx spill itself, rbx ends up used exactly 4 times:   Twice on fast path: movzx       ebx,byte ptr [rcx+rax] lea         rdx,[rax+rbx*4]   Twice on slow path, which i do not really care about: lock cmpxchg dword ptr [rbx],ecx lock cmpxchg dword ptr [rbx],ecx   None of them look suspicious (pretty sure LEA can take whatever as its index register). It is hard to believe VS2015 fails that badly with the basics ... umm ... ???   I guess the function responsible for the call (also on the slow path) is the cause - if i comment it out then rsp and rbx will be unused. If i allow inlining the function then the fast path will be filled with spill code (quadrupled). The function, from callers perspective, is a simple one - equivalent to "static int foo(int)". The slow path ends with another function call, but it is tail-call optimized ("jmp". so, does not care about caller stack frame at all - irrelevant to the issue).   Fun times.
  4. Using SetConsoleCtrlHandler i set a handler that gets called when needed (CTRL_C_EVENT, CTRL_BREAK_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, CTRL_SHUTDOWN_EVENT) [either the RTL or the OS or whatever spawns a high priority worker thread to run it].   The handler signals the apps worker thread to to finish what it is doing and exit. Then it will wait till the main thread signals back that it is safe to exit the handler (which will terminate the process in case of CTRL_CLOSE_EVENT).   All of this works perfectly.   However, there is a long ignored slight problem in the main threads termination code (before signalling the CtrlHandler) which i opted to try to amend today ... and ran into problems.   VS2015 just does not let me debug any of it.   All i can see is the state at breakpoint (which is of limited use) - F11 etc will just instantly terminate the process (debug build of course). At breakpoint i can see that the CtrlHandler thread is waiting in my custom infinite spin-lock as it should ... so, who is killing my process? Can i stop it from doing that (it is not logoff/shutdown, so, what the hell)?   Currently trying to debug by just putting the breakpoint in different places and trying to guess by the visible state what is going on - needless to say, it would help immensely if i could just step through that code.   Any ideas?
  5. VS2015 without internet explorer

    I have no need nor intention to "bite the bullet" or whatever. The original problem has been solved as noted in previous post: http://www.gamedev.net/topic/675576-vs2015-without-internet-explorer/?view=findpost&p=5276280   However, an update to the question i raised that was not answered:   Reinstalling IE nuked some of the settings needed for Classic Explorer to work (allow third party extensions got unchecked) - so, i needed to get access to the so called "internet" options again. Previously the only way i knew to do that was though IE and had to temporarily install IE just for that. This time i had a bit more luck with searching (by the virtue of Classic Shell having a sensible help around that does not wander through unrelated programs like IE) ... so, ...   ... that darn thing is accessible through Settings -> Control Panel -> Internet Options. (yep, sue me, but i did not think of looking around in control panel)   That and the settings mentioned in the linked post are all that is needed to make VS happy. No need to have IE around.
  6. VS2015 without internet explorer

    Reporting back.   Installed IE11 and: * cookies must be allowed. * whitelisting (trusted sites) did not work (live.com, visualstudio.com, microsoft etc/etc) somewhy. Only thing i found was that at least VS2013 had a bug where the sign in process actually mistakenly checked javascript access against the "internet zone" even though all the sites were in "trusted sites" zone - maybe it has not been fixed with VS2015? * setting internet zone to high security (basically disabling everything) and specifically allowing javascript (active scripting) Uninstalled IE (+restart even though it did not ask for it, just to be sure) and its security settings remained intact.   Had no problems registering / signing in after that. Yay!     The frontend does very little (UI platform etc?) ... AFAIK, anything related to rendering an actual webpage is not considered to be part of it (the whole renderer is a separate embeddable component that is made basically inseparable from rest of the OS).   Comments from more knowledgeable dudes'n'dudettes welcome.
  7. VS2015 without internet explorer

      It does require an occasional re-checkin, so you might have issues.     :/ ... that would be a nuisance (especially if it really is as often as mentioned [1-2 months]). So, register-time temporary fix is a no-go ... whatever i do, it will have to always work.   IE has been gradually built into the OS with only the front end being made uninstallable (to get around the lawsuit while still maximizing interdependency). The constant crap avalanche IE presence caused via updates was why i got rid of it way beck when - now only the OS internal parts get updates.   Checked with Wireshark and the "sign in" makes some https traffic with distinctly MS related payloads/destinations to fly around - so, it seems to be able to use the built in part of IE just fine, but just lacks the rights to run Javascript as the message indicated.   I wonder if installing IE to add some whitelists and then immediately uninstalling IE will perma-fix the situation :/ Can i do that without installing IE? How?   Will try it out when i get the time and say how it goes.
  8. Is it possible to use Visual Studio 2015 without having internet explorer (OS: Win7)?   It seems that registering needs "sign in" and that i suspect demands internet explorer - which i do not have. I can not find anything useful about this issue due to sheer amount of false positives for any search term i can come up with.   Error message for license / 'sing in':     My web browser is Firefox and has no Javascript blocking. I suspect that the error message is just a blatant lie in the usage of the term "web browser" as VS is just hardcoded to use some IE component directly. Either way - i can not find anything about it. Are there any workarounds?   Suppose i get to register it somehow - will it keep working without internet explorer?
  9. No shit sherlock *massive-facepalm*. Why did you even write that? Was it not crystal clear that discussions (at least without a lot more details) in that direction is undesired waste of everyone's time?   As i wrote: "[b]ATTEMPT[/b] surviving broken code /.../ [b]something that is normally undesirable[/b]".   PS. Since you like to ASS-U-ME stuff about what is or is not sensible for me to do in my specific case: the code runs in kernel land and some in user land via callbacks - there is no way for the OS to survive or cleanup anything when the program is broken (the process cannot even be terminated because it is in essence part of the kernel at that point - so, you get kernel panic ... BSOD). However i can send a message and initiate a proper teardown and hope the corruption has not already wrecked the OS (the [b]chances[/b] happen to be actually pretty good that the OS will remain unharmed [ie. all internal structures in valid state]). An approach that is highly desirable, in my case, while in development phase.   So, no, you could not be more wrong. Don't assume you know the necessary context and details of what i am doing to ignore my PS'note in OP. It is exceedingly unhelpful.
  10. Really, this is your misunderstanding. I was stating a fact (it has been this way at least a decade). C++ exceptions are implemented using SEH functionality in VC++.   Superficially true. To be specific: * SEH exception filter for catch(...) does not select only C++ exceptions anymore (which it normally would). * Optimizer can not rely on throws anymore and needs to emit all the unwind code it normally would omit.   That is messed up. SEH does not need to know anything about the unwind payload - C++ exceptions or otherwise.   This is completely backwards.   Incorrect.   Incorrect in principle. C++ exception catching is done via SEH exception records where C++ exceptions have the exception code 0xe06d7363. You are free to handle C++ exceptions in your __except - which, granted, is quite silly.   Incorrect. Compiler just can not do object unwinding in a function scope that also has __try ... which overloaded my sleepy brain - i just was not aware of that limitation (have Googled around since then and it is a well known limitation, but like i said - could not pinpoint any specific reason for it). PS. You are well advised to assume i am not totally talking out of my ass. Example code: struct Test { Test() { out << L"new Test"; } ~Test() { out << L"del Test"; } void panic() { throw 42; } }; void snafu() { out << L"shit's gonna hit the fan ..."; Test obj; obj.panic(); } int filter(LPEXCEPTION_POINTERS e) { out << L"exception code: " << std::hex << e->ExceptionRecord->ExceptionCode; // second parameter in c++ exceptions is a pointer to thrown object (plain int in this case) out << L"C++ exception payload object: " << std::dec << *(int*)e->ExceptionRecord->ExceptionInformation[1]; // yeah, we will take anything - including the C++ exception. return EXCEPTION_EXECUTE_HANDLER; } void test() { __try { snafu(); } __except(filter(GetExceptionInformation())) { out << L"panic averted"; } } Output (compiled with the default /EHsc option) as one would expect: shit's gonna hit the fan ... new Test exception code: e06d7363 C++ exception payload object: 42 del Test panic averted Cheers.
  11. Erm, you are confused or not expressing yourself clearly enough for me.   C++ exceptions are built on SEH. It will quite happily execute any C++ handlers along the way when unwinding. [b]So, of course all the destructors etc will be called[/b] - as long as compiler did add them to the unwind stack to begin with. VC++ compiler is free to optimize out adding thous when it sees that there can not be any exceptions (default compile options). To do that it only considers explicit exceptions (throw) by default. That is where "/EHa"  comes in - it disallows such optimizations and hence the entries will be there for even non-explicit exceptions (integer division by zero, access violation, etc).   My findings, based on and sanity-confirmed in practice: https://msdn.microsoft.com/en-us/library/swezty51.aspx https://msdn.microsoft.com/en-us/library/1deeycx5.aspx   My problem was caused by using "__try" in function scope that needs to unwind objects - which it cannot compile for some unknown reason i was not able to precisely pin down (might be some limitation of the function level handler that "__try" installs - ie. it can not add/remove unwind entries on the fly as functions with "try" can or more likely, the compiler is just not programmed to do so).   Which makes the solution obvious - move "__try" to a function scope that does not have objects to unwind. Unfortunately, in my case that would wreck readability - so, have to use "try catch(...)".   Examples for the benefit of passers by: struct Test() {     Test() { out << L"new Test"; }     ~Test() { out << L"del Test"; }     void crash() { out << *(int*)(0); } }   void func() {     Test foo; // Perfectly fine to unwind this object (Needs /EHa of couse as otherwise the code needed for unwind would be optimized out as "foo.crash" has no explicit "throw")     foo.crash(); }   void test() {     // Test notOkay; // Cannot compile this. Function uses __try and needs object unwinding.     __try {         func();     } __except(EXCEPTION_EXECUTE_HANDLER) {         out << L"crashed";     } }
  12. I do not get it, why does code that needs unwinding inside __try block give me errors/warnings: * warning C4509: nonstandard extension used: 'someFunctionScope' uses SEH and 'someVariable' has destructor * error C2712: Cannot use __try in functions that require object unwinding When /EHa (VC++ 2013) option is selected?   Isn't /EHa supposed to force the compiler to assume exceptions can occur anywhere (aka. asynchronous) and it hence must record all the destructors (ie. cannot optimize out the non-explicit ones like access violations etc).   What? I don't even ... what is my sleepy head missing? I could have sworn that i have done this before without problems.   PS. Since it is bound to come up: i really-really need to attempt (in my case, the chances are actually very good) surviving memory trashing / broken code (something that is normally undesirable), so SEH is a must as is unwinding.
  13. "defer": is this silly / broken?

    True that. Did not even think about that as exceptions are not relevant for me. Exceptions are usually disabled in my projects (well, depends) - currently writing a system driver for some personal stuff. Exceptions are completely and utterly useless there: * memory allocation cannot throw exceptions. * all inputs must be validated all error conditions must be checked etc. * there are no meaningful c++ exceptions. * ... leaving only inherently unrecoverable exceptions via SEH (just catch the exception via first chance handler and try to teardown the driver - is the only sane thing i can do). ... but the point is valid. Speaking of which: that would actually be what i am most interested in. I am wary of using questionable new stuff i have come up with ... debugging bluescreens is not fun (especially as i do not have kernel debugging capabilities right now - it is just not worth it).   Neither am i, to be honest - "There be dragons". "It suggests to me that the abstraction you are working with is poor; that the objects in question don't have properly written destructors or related cleanup semantics" If it would be correct/convenient to use destructors of related objects - i would do that. My interest for "defer" came from run-once initialization functions where there were no meaningful objects for encapsulation. Nor convenient or meaningful ways to compartmentalize in functions ... which reminding me Go for an alternative. PS. Do not confuse "interest" with "burning need" here - in case i am not being clear. The wast majority of time destructors/constructions/std-helpers are correct and/or convenient. "It implies you have to violate the general recommendation to declare variables as close to their first use as possible in C++, if you want those variables to subject to the cleanup code that the "defer" mechanism provides, making for potentially sloppier code." Sorry, could you rephrase that? I think i hit a language barrier (my English is actually fairly poor) - however many times i read it, i just can not follow. "I think it hurts readability to put code outside it's execution order like that" One of my golden rules: a system should try to prevent accidental mistakes and not intentional ones (without a bloody good and clear reason). One can easily write some unbelievably unreadable spaghetti using whatever language construct - or improve readability when using the same construct sensibly. So: yes and no. Blame the user and not the system. "and I certainly find the macro hackery to introduce a new "syntax element" offensive." Interesting. Is it because of macro usage in principle or because there is some legitimate problem with the macro (ie. opportunity for likely accidental mistakes)?   I agree. It is quite similar to try/finally, but not interchangeable from readability/use standpoint ("finally" block is not necessarily related to what is immediately before "try", whereas that is the only sane option for "defer" - ie. "defer" keeps the closely related code together).   You are being facetious. Or at least seem to. One once said that "Whiles, procedures and case structures are mental masturbation. They're all compiled to a bunch of goto's anyway." What i am talking about, as i said, is "defer" as in http://golangtutorials.blogspot.com/2011/06/control-structures-go-defer-statement.html in C++, wondering about its usefulness and most importantly - does it break somewhere? ie. Arbitrary finalization code without needing a special separately described object for the occasion and keeping the one-of closely related code together. C++ does not have any comparable language construct (closest match would be try/finally [non-standard] and, less so, RAII). My facsimile seems to fit the bill.
  14.   I nearly blew a fuse reading that. Please tell me that's a typo, and not how you think threading improves performance. "if being unrealistically ideal". His example was detailing the higher/upper bound and is correct as such. Reality of it is irrelevant in that context. edit: or did you get the impression he is not talking about hardware threads (cpu cores and HT if available ... typically 2-8)?
  15. The geek in me smiles, yet i can't get rid of the feeling that i am doing something eerily wonky. // clean is just a struct that plonks out all the unwanted default crap c++ attaches - not terribly important here. struct Defer : Clean { template<typename FN> struct Obj : Clean { Obj(FN fn) : fn(fn) {} ~Obj() { fn(); } private: FN fn; }; template<typename FN> Obj<FN> operator=(FN fn) { return Obj<FN>(fn); } }; #define defer auto JOIN(_defer, __COUNTER__) = Defer() = [&] Now i can use "defer" (iirc, Go language has it) in C++: __declspec(noinline) void test() { int i = 41; defer { // some code to defer msg(L"defer %d", i); // some typical logging function - note: "i" comes from outer scope. } // perhaps some other code (with multiple exit points etc) here msg(L"----- %d", i++); } VS2013 optimizes all of the overhead completely out: __declspec(noinline) void init() { 00FA1060 push ecx 00FA1061 push 29h 00FA1063 push 0FB1514h 00FA1068 mov dword ptr [esp+8],2Ah 00FA1070 call msg (0FA1000h) } 00FA1075 push dword ptr [esp+8] 00FA1079 push 0FB1524h 00FA107E call msg (0FA1000h) 00FA1083 add esp,14h 00FA1086 ret Giving the expected output: ----- 41 defer 42 What could go wrong? Am i nuts thinking this is occasionally useful? Why have i not seen it used anywhere, i wonder :/. Looks solid to me.
  • Advertisement