* Including <iostream> affects whether or not program freezes? @ 2008-07-09 3:26 James Gregory 2008-07-09 12:03 ` Lionel B ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: James Gregory @ 2008-07-09 3:26 UTC (permalink / raw) To: gcc-help 1. Compile with MSVC 7.1, no optimization: my program doesn't freeze 2. Compile with MSVC 7.1, with optimization: my program doesn't freeze 3. Compile with gcc 4.2.3 (Ubuntu 64 bit), no optimization: my program doesn't freeze 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my program freezes in a particular function 5. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization, and include <iostream> at the top of the file where the function which freezes is defined: my program doesn't freeze Debugging this is difficult. James ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Including <iostream> affects whether or not program freezes? 2008-07-09 3:26 Including <iostream> affects whether or not program freezes? James Gregory @ 2008-07-09 12:03 ` Lionel B 2008-07-09 16:49 ` James Gregory 2008-07-09 13:43 ` Andrew Bell 2008-07-09 17:02 ` Chris Jefferson 2 siblings, 1 reply; 13+ messages in thread From: Lionel B @ 2008-07-09 12:03 UTC (permalink / raw) To: gcc-help On Wed, 09 Jul 2008 03:31:35 +0100, James Gregory wrote: > 1. Compile with MSVC 7.1, no optimization: my program doesn't freeze 2. > Compile with MSVC 7.1, with optimization: my program doesn't freeze 3. > Compile with gcc 4.2.3 (Ubuntu 64 bit), no optimization: my program > doesn't freeze > 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my program > freezes in a particular function 5. Compile with gcc 4.2.3 (Ubuntu 64 > bit), with optimization, and include <iostream> at the top of the file > where the function which freezes is defined: my program doesn't freeze You give *way* too little information to even begin to guess what the problem might be... but this smells like a classic case of Undefined Behaviour - sometimes it appears to work, sometimes it doesn't. I.e. you have a bug in your program. > Debugging this is difficult. It frequently is ;-) but what other choice do you have? There are tools to help (debuggers such as gdb, memory leak checkers such as valgrind, ...) First I would try stripping your program down to a minimal core that exhibits the buggy behaviour. Often in doing so you will isolate and identify the bug. If not seek help here or in a C (or C++, you don't say which language your program is in) forum. You can post minimal code demonstrating the problem. -- Lionel B ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Including <iostream> affects whether or not program freezes? 2008-07-09 12:03 ` Lionel B @ 2008-07-09 16:49 ` James Gregory 2008-07-09 18:08 ` Burlen Loring 0 siblings, 1 reply; 13+ messages in thread From: James Gregory @ 2008-07-09 16:49 UTC (permalink / raw) To: Lionel B; +Cc: gcc-help On Wed, Jul 9, 2008 at 12:28 PM, Lionel B <lionelb.nospam@gmail.com> wrote: > On Wed, 09 Jul 2008 03:31:35 +0100, James Gregory wrote: > >> 1. Compile with MSVC 7.1, no optimization: my program doesn't freeze 2. >> Compile with MSVC 7.1, with optimization: my program doesn't freeze 3. >> Compile with gcc 4.2.3 (Ubuntu 64 bit), no optimization: my program >> doesn't freeze >> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my program >> freezes in a particular function 5. Compile with gcc 4.2.3 (Ubuntu 64 >> bit), with optimization, and include <iostream> at the top of the file >> where the function which freezes is defined: my program doesn't freeze > > You give *way* too little information to even begin to guess what the > problem might be... but this smells like a classic case of Undefined > Behaviour - sometimes it appears to work, sometimes it doesn't. I.e. you > have a bug in your program. Sure, I agree it is 99.999999% certain I am doing something wrong hence the undefined behaviour. But doesn't it seem somewhat out of the ordinary that the behaviour can be affected by which standard library header files I include? How can this make a difference to the code that gcc produces? It seems unlikely that it's a total coincidence that whenever I run the version with iostream included it doesn't freeze and whenever I run the version without it does (I just tried recompiling the two versions again and the pattern holds). > >> Debugging this is difficult. > > It frequently is ;-) but what other choice do you have? There are tools > to help (debuggers such as gdb, memory leak checkers such as > valgrind, ...) I have used gdb to see which function it freezes in, but as noted I cannot compile with full debugging symbols and watch variables/step through the code as this removes the bug. valgrind doesn't report any problems at all (except a few warnings about functions called in external libraries at start up). The reason I originally wanted to include iostream was an effort to output the value of variables at various points in the function which freezes, but as noted this also removes the bug. > > First I would try stripping your program down to a minimal core that > exhibits the buggy behaviour. Often in doing so you will isolate and > identify the bug. If not seek help here or in a C (or C++, you don't say > which language your program is in) forum. You can post minimal code > demonstrating the problem. But if even including a certain header file can affect the behaviour, how can I strip down the program except through random trial and error? I guess what I'm trying to say is not "What is wrong with my program?", when clearly I haven't given enough information for anyone to help, but rather "Does anyone know what sort of thing might be affected in the code gcc produces if I include iostream is included?". (And it is C++ not C, hence <iostream>) James ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Including <iostream> affects whether or not program freezes? 2008-07-09 16:49 ` James Gregory @ 2008-07-09 18:08 ` Burlen Loring 0 siblings, 0 replies; 13+ messages in thread From: Burlen Loring @ 2008-07-09 18:08 UTC (permalink / raw) To: James Gregory; +Cc: Lionel B, gcc-help Hi James, Including a header can affect the program somewhat.variables for instance might be placed in a different physical location due to slightly different executable size or optimization packing/aligning. This is the type of thing that you can see with using uninitialized variables. Also if you are running off the end of an array that was allocated on the stack(valgrind doesn't catch this as far as I know), you can see changes in behavior that come about with variations in the compile, because optimization sometimes packs and aligns data so that it ends up in a different spot relative to unoptimized build. With different memory used different bytes get trashed and hence the run time variability. Its often repeatable due to the fact that once the program runs it's likely to get loaded into the same physical memory each time it runs. Burlen James Gregory wrote: > On Wed, Jul 9, 2008 at 12:28 PM, Lionel B <lionelb.nospam@gmail.com> wrote: > >> On Wed, 09 Jul 2008 03:31:35 +0100, James Gregory wrote: >> >> >>> 1. Compile with MSVC 7.1, no optimization: my program doesn't freeze 2. >>> Compile with MSVC 7.1, with optimization: my program doesn't freeze 3. >>> Compile with gcc 4.2.3 (Ubuntu 64 bit), no optimization: my program >>> doesn't freeze >>> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my program >>> freezes in a particular function 5. Compile with gcc 4.2.3 (Ubuntu 64 >>> bit), with optimization, and include <iostream> at the top of the file >>> where the function which freezes is defined: my program doesn't freeze >>> >> You give *way* too little information to even begin to guess what the >> problem might be... but this smells like a classic case of Undefined >> Behaviour - sometimes it appears to work, sometimes it doesn't. I.e. you >> have a bug in your program. >> > > Sure, I agree it is 99.999999% certain I am doing something wrong > hence the undefined behaviour. But doesn't it seem somewhat out of the > ordinary that the behaviour can be affected by which standard library > header files I include? How can this make a difference to the code > that gcc produces? It seems unlikely that it's a total coincidence > that whenever I run the version with iostream included it doesn't > freeze and whenever I run the version without it does (I just tried > recompiling the two versions again and the pattern holds). > > >>> Debugging this is difficult. >>> >> It frequently is ;-) but what other choice do you have? There are tools >> to help (debuggers such as gdb, memory leak checkers such as >> valgrind, ...) >> > > I have used gdb to see which function it freezes in, but as noted I > cannot compile with full debugging symbols and watch variables/step > through the code as this removes the bug. valgrind doesn't report any > problems at all (except a few warnings about functions called in > external libraries at start up). The reason I originally wanted to > include iostream was an effort to output the value of variables at > various points in the function which freezes, but as noted this also > removes the bug. > > >> First I would try stripping your program down to a minimal core that >> exhibits the buggy behaviour. Often in doing so you will isolate and >> identify the bug. If not seek help here or in a C (or C++, you don't say >> which language your program is in) forum. You can post minimal code >> demonstrating the problem. >> > > But if even including a certain header file can affect the behaviour, > how can I strip down the program except through random trial and > error? I guess what I'm trying to say is not "What is wrong with my > program?", when clearly I haven't given enough information for anyone > to help, but rather "Does anyone know what sort of thing might be > affected in the code gcc produces if I include iostream is included?". > > (And it is C++ not C, hence <iostream>) > > James > -- Burlen Loring Kitware, Inc. R&D Engineer 28 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-371-3971 x137 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Including <iostream> affects whether or not program freezes? 2008-07-09 3:26 Including <iostream> affects whether or not program freezes? James Gregory 2008-07-09 12:03 ` Lionel B @ 2008-07-09 13:43 ` Andrew Bell 2008-07-09 14:35 ` Andrew Haley 2008-07-09 17:02 ` Chris Jefferson 2 siblings, 1 reply; 13+ messages in thread From: Andrew Bell @ 2008-07-09 13:43 UTC (permalink / raw) To: James Gregory; +Cc: gcc-help On Tue, Jul 8, 2008 at 9:31 PM, James Gregory <james.jrg@gmail.com> wrote: > > 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my > program freezes in a particular function Kill the process with some signal that will generate a core. This at least gives you a exact location of the hang, if you don't already know it. -- Andrew Bell andrew.bell.ia@gmail.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Including <iostream> affects whether or not program freezes? 2008-07-09 13:43 ` Andrew Bell @ 2008-07-09 14:35 ` Andrew Haley 0 siblings, 0 replies; 13+ messages in thread From: Andrew Haley @ 2008-07-09 14:35 UTC (permalink / raw) To: Andrew Bell; +Cc: James Gregory, gcc-help Andrew Bell wrote: > On Tue, Jul 8, 2008 at 9:31 PM, James Gregory <james.jrg@gmail.com> wrote: >> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my >> program freezes in a particular function > > Kill the process with some signal that will generate a core. This at > least gives you a exact location of the hang, if you don't already > know it. I'll use this opportunity to mention Valgrind's memory checker. Andrew. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Including <iostream> affects whether or not program freezes? 2008-07-09 3:26 Including <iostream> affects whether or not program freezes? James Gregory 2008-07-09 12:03 ` Lionel B 2008-07-09 13:43 ` Andrew Bell @ 2008-07-09 17:02 ` Chris Jefferson 2008-07-10 10:58 ` James Gregory 2008-07-12 21:16 ` James Gregory 2 siblings, 2 replies; 13+ messages in thread From: Chris Jefferson @ 2008-07-09 17:02 UTC (permalink / raw) To: James Gregory; +Cc: gcc-help 2008/7/9 James Gregory <james.jrg@gmail.com>: > 1. Compile with MSVC 7.1, no optimization: my program doesn't freeze > 2. Compile with MSVC 7.1, with optimization: my program doesn't freeze > 3. Compile with gcc 4.2.3 (Ubuntu 64 bit), no optimization: my program > doesn't freeze > 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my > program freezes in a particular function > 5. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization, and > include <iostream> at the top of the file where the function which > freezes is defined: my program doesn't freeze > > Debugging this is difficult. While I could well be repeating what others say, my usual tools for situations like this, which (touch wood) tend to get me out of it: A) Turn on all warnings, and read what they say. I've found this kind of thing can be caused by a missing return statement. B) Turn on the debugging standard library, if you are using any of the STL in your code. C) Find the minimial set of optimisation flags you need to trigger your problem (in particular if you can turn off inlining it will make things easier). This makes the next stage easier. D) Use valgrind and see what it comes up with. The <iostream> problem sounds to me like your problem could well be triggered by inlining, which is often very sensitive (at least in g++) and can change from headers being included on occasion. > > James > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Including <iostream> affects whether or not program freezes? 2008-07-09 17:02 ` Chris Jefferson @ 2008-07-10 10:58 ` James Gregory 2008-08-05 6:45 ` Christoph Bartoschek 2008-07-12 21:16 ` James Gregory 1 sibling, 1 reply; 13+ messages in thread From: James Gregory @ 2008-07-10 10:58 UTC (permalink / raw) To: Chris Jefferson; +Cc: gcc-help On Wed, Jul 9, 2008 at 5:49 PM, Chris Jefferson <chris@bubblescope.net> wrote: >> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my >> program freezes in a particular function >> >> Debugging this is difficult. > > While I could well be repeating what others say, my usual tools for > situations like this, which (touch wood) tend to get me out of it: > > A) Turn on all warnings, and read what they say. I've found this kind > of thing can be caused by a missing return statement. No warnings... > B) Turn on the debugging standard library, if you are using any of the > STL in your code. OK this reported a problem somewhere else, but fixing it didn't make any difference to the freezing problem. > C) Find the minimial set of optimisation flags you need to trigger > your problem (in particular if you can turn off inlining it will make > things easier). This makes the next stage easier. At first it required -finline-functions, but then I manually inlined an a function called in the part which freezes and now the minimum set of flags that triggers the problem is: -O1 -fstrict-aliasing > D) Use valgrind and see what it comes up with. Nothing at all. A minimal version of the function which freezes is something like: bool AIInterpreter::is_group_like_this(int n_side, int n_group) { //it is the second condition (scanned_groups) which triggers this code branch, but deleting anything at all here removes the bug if ((!sides[n_side].groups[n_group].get_alive()) || !sides[my_side].scanned_groups[n_side][n_group] || sides[n_side].groups[n_group].get_in_hangar()) { while (l_iter != l_end) ++l_iter; return false; } write_log(L"it never gets this far"); <the function continues but though deleting it removes the bug, the fact the above log never gets written means it is probably irrelevant> } So I guess "while (l_iter != l_end)" is becoming an infinite loop, but if I log the value of &(*l_iter) and &(*l_end) on each loop then a) it removes the bug and b) there is nothing obviously wrong. Anything else I can do? James ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Including <iostream> affects whether or not program freezes? 2008-07-10 10:58 ` James Gregory @ 2008-08-05 6:45 ` Christoph Bartoschek 2008-08-05 9:31 ` James Gregory 0 siblings, 1 reply; 13+ messages in thread From: Christoph Bartoschek @ 2008-08-05 6:45 UTC (permalink / raw) To: gcc-help; +Cc: James Gregory Am Donnerstag 10 Juli 2008 schrieb James Gregory: > A minimal version of the function which freezes is something like: > > bool AIInterpreter::is_group_like_this(int n_side, int n_group) { > //it is the second condition (scanned_groups) which triggers this > code branch, but deleting anything at all here removes the bug > if ((!sides[n_side].groups[n_group].get_alive()) > > || !sides[my_side].scanned_groups[n_side][n_group] > || sides[n_side].groups[n_group].get_in_hangar()) { > > while (l_iter != l_end) > ++l_iter; > return false; > } > write_log(L"it never gets this far"); > > <the function continues but though deleting it removes the bug, the > fact the above log never gets written means it is probably irrelevant> > } > > So I guess "while (l_iter != l_end)" is becoming an infinite loop, but > if I log the value of &(*l_iter) and &(*l_end) on each loop then a) it > removes the bug and b) there is nothing obviously wrong. Anything else > I can do? Did you find the bug? What was the problem? If you did not find it yet: 1. Check with a debugger that the while loop is indeed an endless loop. 2. You did not show what containers l_iter and l_end come from and what happens with the containers in this function. Christoph ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Including <iostream> affects whether or not program freezes? 2008-08-05 6:45 ` Christoph Bartoschek @ 2008-08-05 9:31 ` James Gregory 0 siblings, 0 replies; 13+ messages in thread From: James Gregory @ 2008-08-05 9:31 UTC (permalink / raw) To: Christoph Bartoschek; +Cc: gcc-help On Tue, Aug 5, 2008 at 7:45 AM, Christoph Bartoschek <bartoschek@gmx.de> wrote: >> So I guess "while (l_iter != l_end)" is becoming an infinite loop, but >> if I log the value of &(*l_iter) and &(*l_end) on each loop then a) it >> removes the bug and b) there is nothing obviously wrong. Anything else >> I can do? > > Did you find the bug? What was the problem? > > If you did not find it yet: > > 1. Check with a debugger that the while loop is indeed an endless loop. > 2. You did not show what containers l_iter and l_end come from and what > happens with the containers in this function. > > Christoph > I never did find the bug, no. 1. I thought gdb couldn't give accurate line numbers for optimized code? In this slightly modified version of my code (I was attempting to cut down the code as much as possible): bool get_true() { return true; } bool AIInterpreter::is_group_like_this(int n_side, int n_group) { if ((!get_true()) || !sides[my_side].scanned_groups[n_side][n_group] || !get_true()) { while (l_iter != l_end) ++l_iter; return false; } write_log(L"it never gets this far"); gdb says: Program received signal SIGINT, Interrupt. 0x0000000000404356 in AIInterpreter::is_group_like_this (this=0x659338, n_side=1, n_group=0) at src/AIInterpreter.cpp:388 388 if ((!get_true()) (gdb) bt #0 0x0000000000404356 in AIInterpreter::is_group_like_this (this=0x659338, n_side=1, n_group=0) at src/AIInterpreter.cpp:388 I can't see how it could freeze on that line? 2. l_iter and l_end are of type std::basic_string<unsigned char>::const_iterator As for what happens to the container, the full source code for the cut-down version of the file is here: http://rrgbis.svn.sourceforge.net/viewvc/rrgbis/rrgbis-bug/src/AIInterpreter.cpp?view=markup And yes the code is a bit of a mess but hey I wrote that file years ago. The "rrgbis-bug" directory is/was my attempt to find the minimal amount of code required to make it freeze, though it's still almost 7000 lines of code in total, so I didn't really succeed. I am no longer subscribed to gcc-help, so if anyone wants me to see a reply please include me in the cc list. Thanks, James ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Including <iostream> affects whether or not program freezes? 2008-07-09 17:02 ` Chris Jefferson 2008-07-10 10:58 ` James Gregory @ 2008-07-12 21:16 ` James Gregory 2008-07-12 21:05 ` James Gregory 2008-07-12 22:11 ` James Gregory 1 sibling, 2 replies; 13+ messages in thread From: James Gregory @ 2008-07-12 21:16 UTC (permalink / raw) To: Chris Jefferson; +Cc: gcc-help On Wed, Jul 9, 2008 at 5:49 PM, Chris Jefferson <chris@bubblescope.net> wrote: > 2008/7/9 James Gregory <james.jrg@gmail.com>: >> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my >> program freezes in a particular function >> 5. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization, and >> include <iostream> at the top of the file where the function which >> freezes is defined: my program doesn't freeze Chris Jefferson suggested I add the compiler flag "-fdump-tree-all". I did this for the build which included iostream and the one which didn't, produced a diff of the final code produced for the problematic source file between each version, cropped it a bit, and came up with the following. I don't understand assembler, but the header file inclusion has clearly changed the code gcc produces. The obvious differences are: 1. The existence of the line "-Invalid sum of incoming frequencies 873, should be 0" in the freezing version 2. The replacement of this in the version which freezes: - const unsigned char * this___l_iterthis__I___M_currentthis____.4618; - const unsigned char * this___l_iterthis__I___M_currentthis____.4617; - const unsigned char * this___l_iterthis__I___M_currentthis____.4616; to this in the version which doesn't: + unsigned char temp.4650; + unsigned char temp.4649; + unsigned char temp.4648; Can anyone tell me what is going on here? --- AIInterpreter.cpp.102t.final_cleanup 2008-07-12 21:21:37.000000000 +0100 +++ ../nofreeze/AIInterpreter.cpp.102t.final_cleanup 2008-07-12 21:23:33.000000000 +0100 <snip> bool AIInterpreter::is_group_like_this(int, int, bool, bool) (this, n_side, n_group, discount_dead, discount_our) { - int stat_value.4637; - const unsigned char * this___l_iterthis__I___M_currentthis____.4618; - const unsigned char * this___l_iterthis__I___M_currentthis____.4617; - const unsigned char * this___l_iterthis__I___M_currentthis____.4616; + int stat_value.4653; + unsigned char temp.4650; + unsigned char temp.4649; + unsigned char temp.4648; int give_group; int give_side; - struct Group_Base * D.100623; - bool D.100627; + struct Group_Base * D.100677; + bool D.100681; size_t __n; - struct Group_Base * D.100588; - const unsigned char * D.86283; - const unsigned char & D.86265; - unsigned char D.86266; - const unsigned char & D.86197; - unsigned char D.86198; - const unsigned char & D.86143; - unsigned char D.86144; + struct Group_Base * D.100642; + const unsigned char * D.86304; + const unsigned char & D.86286; + unsigned char D.86287; + const unsigned char * D.86270; + const unsigned char & D.86218; + unsigned char D.86219; + const unsigned char * D.86202; + const unsigned char & D.86164; + unsigned char D.86165; + const unsigned char * D.86148; size_t __n; - struct Side * D.86086; + struct Side * D.86107; int second_value; const unsigned char operator_type; int stat_value; - const unsigned char & D.68774; - unsigned char D.68755; - int D.68741; + const unsigned char & D.68792; + unsigned char D.68773; + int D.68759; <bb 2>: - D.100588 = operator-> (&((sides.D.66353._M_impl._M_start + (struct Side *) ((long unsigned int) n_side * 256))->groups.D.33422._M_impl._M_start + (struct Group *) ((long unsigned int) n_group * 16))->h_group); - if (D.100588->alive) goto <L1>; else goto <L0>; + D.100642 = operator-> (&((sides.D.66353._M_impl._M_start + (struct Side *) ((long unsigned int) n_side * 256))->groups.D.33422._M_impl._M_start + (struct Group *) ((long unsigned int) n_group * 16))->h_group); + if (D.100642->alive) goto <L1>; else goto <L0>; <L0>:; if (discount_dead) goto <L8>; else goto <L1>; @@ -6385,72 +6402,70 @@ <L1>:; __n = (long unsigned int) n_group; __n = (long unsigned int) n_side; - D.86086 = sides.D.66353._M_impl._M_start; - if ((*(((D.86086 + (struct Side *) ((long unsigned int) this->my_side * 256))->scanned_groups.D.34444._M_impl._M_start + (struct vector<bool,std::allocator<bool> > *) (__n * 40))->D.67000._M_impl._M_start.D.26400._M_p + (_Bit_type *) ((__n >> 6) * 8)) & 1 << (int) ((unsigned int) __n & 63)) == 0) goto <L8>; else goto <L2>; + D.86107 = sides.D.66353._M_impl._M_start; + if ((*(((D.86107 + (struct Side *) ((long unsigned int) this->my_side * 256))->scanned_groups.D.34444._M_impl._M_start + (struct vector<bool,std::allocator<bool> > *) (__n * 40))->D.67000._M_impl._M_start.D.26400._M_p + (_Bit_type *) ((__n >> 6) * 8)) & 1 << (int) ((unsigned int) __n & 63)) == 0) goto <L8>; else goto <L2>; <L2>:; - D.100623 = operator-> (&((D.86086 + (struct Side *) (__n * 256))->groups.D.33422._M_impl._M_start + (struct Group *) (__n * 16))->h_group); - D.100627 = OBJ_TYPE_REF(*(D.100623->_vptr.Group_Base + 152B);D.100623->19) (D.100623); - if (D.100627 != 0) goto <L8>; else goto <L3>; + D.100677 = operator-> (&((D.86107 + (struct Side *) (__n * 256))->groups.D.33422._M_impl._M_start + (struct Group *) (__n * 16))->h_group); + D.100681 = OBJ_TYPE_REF(*(D.100677->_vptr.Group_Base + 152B);D.100677->19) (D.100677); + if (D.100681 != 0) goto <L8>; else goto <L3>; <L3>:; - if (this->my_side != n_side) goto <L160>; else goto <L4>; + if (this->my_side != n_side) goto <L163>; else goto <L4>; <L4>:; - if (this->my_group != n_group) goto <L160>; else goto <L5>; + if (this->my_group != n_group) goto <L163>; else goto <L5>; <L5>:; - if (discount_our) goto <L8>; else goto <L160>; + if (discount_our) goto <L8>; else goto <L163>; <L8>:; - D.86143 = this->l_iter._M_current; - if (D.86143 == this->l_end._M_current) goto <L36>; else goto <L103>; + D.86164 = this->l_iter._M_current; + if (D.86164 == this->l_end._M_current) goto <L36>; else goto <L103>; <L103>:; - D.86144 = *D.86143; - if (D.86144 == 157) goto <L36>; else goto <L104>; + temp.4648 = *D.86164; + if (temp.4648 == 157) goto <L36>; else goto <L104>; <L104>:; - if (D.86144 == 158) goto <L36>; else goto <L120>; + if (temp.4648 == 158) goto <L36>; else goto <L166>; -<L120>:; - this___l_iterthis__I___M_currentthis____.4616 = (const unsigned char *) ((long unsigned int) D.86143 + 1); +<L39>:; + D.86165 = *D.86148; + if (D.86165 == 157) goto <L36>; else goto <L40>; -Invalid sum of incoming frequencies 873, should be 0 <L40>:; - this___l_iterthis__I___M_currentthis____.4616 = (const unsigned char *) ((long unsigned int) this___l_iterthis__I___M_currentthis____.4616 + 1); - if (D.86144 == 157) goto <L162>; else goto <L40>; + if (D.86165 == 158) goto <L36>; else goto <L166>; -Invalid sum of incoming frequencies 0, should be 301 -<L162>:; - this->l_iter._M_current = this___l_iterthis__I___M_currentthis____.4616; - D.68741 = 0; - goto <bb 42> (<L174>); +<L166>:; + D.86148 = this->l_iter._M_current + 1B; + this->l_iter._M_current = D.86148; + if (this->l_end._M_current == D.86148) goto <L36>; else goto <L39>; <snip> James ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Including <iostream> affects whether or not program freezes? 2008-07-12 21:16 ` James Gregory @ 2008-07-12 21:05 ` James Gregory 2008-07-12 22:11 ` James Gregory 1 sibling, 0 replies; 13+ messages in thread From: James Gregory @ 2008-07-12 21:05 UTC (permalink / raw) To: gcc-help On Sat, Jul 12, 2008 at 9:38 PM, James Gregory <james.jrg@gmail.com> wrote: > I don't understand assembler, but Actually it is clearly still C++ not assembler, I meant "I don't understand the resulting lower level code". James ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Including <iostream> affects whether or not program freezes? 2008-07-12 21:16 ` James Gregory 2008-07-12 21:05 ` James Gregory @ 2008-07-12 22:11 ` James Gregory 1 sibling, 0 replies; 13+ messages in thread From: James Gregory @ 2008-07-12 22:11 UTC (permalink / raw) To: Chris Jefferson; +Cc: gcc-help On Sat, Jul 12, 2008 at 9:38 PM, James Gregory <james.jrg@gmail.com> wrote: In a more readable fashion, the difference between the two versions is: /////////////// Include <iostream>, no freeze: /////////////// ;; Function bool AIInterpreter::is_group_like_this(int, int, bool, bool) (_ZN13AIInterpreter18is_group_like_thisEiibb) Removing basic block 39 bool AIInterpreter::is_group_like_this(int, int, bool, bool) (this, n_side, n_group, discount_dead, discount_our) { unsigned char temp.4650; unsigned char temp.4649; unsigned char temp.4648; const unsigned char * D.86270; unsigned char D.86219; const unsigned char * D.86202; unsigned char D.86165; const unsigned char * D.86148; <L39>:; D.86165 = *D.86148; if (D.86165 == 157) goto <L36>; else goto <L40>; <L40>:; if (D.86165 == 158) goto <L36>; else goto <L166>; <L166>:; D.86148 = this->l_iter._M_current + 1B; this->l_iter._M_current = D.86148; if (this->l_end._M_current == D.86148) goto <L36>; else goto <L39>; /////////////// Don't include <iostream>, freeze: /////////////// ;; Function bool AIInterpreter::is_group_like_this(int, int, bool, bool) (_ZN13AIInterpreter18is_group_like_thisEiibb) Removing basic block 39 bool AIInterpreter::is_group_like_this(int, int, bool, bool) (this, n_side, n_group, discount_dead, discount_our) { const unsigned char * this___l_iterthis__I___M_currentthis____.4618; const unsigned char * this___l_iterthis__I___M_currentthis____.4617; const unsigned char * this___l_iterthis__I___M_currentthis____.4616; unsigned char D.86198; unsigned char D.86144; <L120>:; this___l_iterthis__I___M_currentthis____.4616 = (const unsigned char *) ((long unsigned int) D.86143 + 1); Invalid sum of incoming frequencies 873, should be 0 <L40>:; this___l_iterthis__I___M_currentthis____.4616 = (const unsigned char *) ((long unsigned int) this___l_iterthis__I___M_currentthis____.4616 + 1); if (D.86144 == 157) goto <L162>; else goto <L40>; Invalid sum of incoming frequencies 0, should be 301 <L162>:; this->l_iter._M_current = this___l_iterthis__I___M_currentthis____.4616; D.68741 = 0; goto <bb 42> (<L174>); ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-08-05 9:31 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-07-09 3:26 Including <iostream> affects whether or not program freezes? James Gregory 2008-07-09 12:03 ` Lionel B 2008-07-09 16:49 ` James Gregory 2008-07-09 18:08 ` Burlen Loring 2008-07-09 13:43 ` Andrew Bell 2008-07-09 14:35 ` Andrew Haley 2008-07-09 17:02 ` Chris Jefferson 2008-07-10 10:58 ` James Gregory 2008-08-05 6:45 ` Christoph Bartoschek 2008-08-05 9:31 ` James Gregory 2008-07-12 21:16 ` James Gregory 2008-07-12 21:05 ` James Gregory 2008-07-12 22:11 ` James Gregory
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).