I don't believe you will be able to do that. The problem is that templates are actually converted into "regular source code" and then compiled. The only thing I can think of which might shed some light on things is running `objdump -C ' on the object code. Depending on your situation, that may, or may not be useful. Just a stab in the dark. Templates are "inlined" which is the correct terminology. The problem is that like preprocessor macros you can't really get to them per se. What I am trying to track down is that there are about 1000 instances of
The difference in behavior between the two compilers is probably a result of the "unspecified behavior" related to program termination. My guess is, the g++ generated version is trying to execute some cleanup code that is accessing an invalid memory address. Examine your destructors carfully. At the moment, I don't really care about the g++ segfault. We only built with g++ because we were having other problems with the Intel compiler (that was not a problem with the compiler, but with 3rd party libraries). The problem I'm focusing on is much earlier. What we are doing is a 64-bit proof of concept type of situation. In this case, the Intel compiler should generate code that runs about 40% faster
On Thursday 01 December 2005 2:44 pm, Steven T. Hatton wrote: this function, and I'm trying to find out why a number of them are not showing up in an array in the Intel compiler version, but do show up in the G++ version. (I also didn't mention that there are also a lot of dynamic shared libraries in the mix which makes it even more challenging). than the g++ code. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9