> Le 19 janv. 2015 à 11:31, Thomas Jahns <ja...@dkrz.de> a écrit : > > Is there some way to find what actually gets executed at > > > $CXX $CXXFLAGS $CPPFLAGS -c -o cxx.o -c "\`~!@#\$%^&*()-=_+{}[]|\\:;<>, .'.cc"
Indeed this is a problem. Try make check TESTSUITEFLAGS='-d -v -x 95' >> So it's on purpose that we have this 'break' there. However, it seems >> that your compiler's error recovery is not sufficient, hence (I guess) >> all the other messages. > > Yes, I never could understand why the consensus among compilers seems to be > to go on compiling when an error was encountered. To save the user time. I am _very_ happy that compiler offer error recovery, so that I can fix several issues at once, instead of having to wait for another compilation to fail. > Since the first error message still contains everything to make the grep > succeed, I stand by my initial assertion that compiler output simply needs to > be massaged appropriately. Yes, but that's the only test that fails this way, although there are other #line tests. > While the ISO standard C++ 98 is perhaps something to start from, most codes > seem to use one extension or another. In the context of Bison and its test suite, that would be a bug to report. >> For some reason, we have one more call to the destructor than expected. >> Which >> certainly means that one value was duplicated at some point, unexpectedly. >> Maybe your compiler does not perform some common optimizations, such as >> RVO and NRVO, possibly precisely because the destructor is nontrivial? > > I'm building without optimization. So that would be kind of the expected > behaviour then? Maybe you could try with optimizations enabled, to see if it makes any difference. >> Could you try to see where this destructor call is coming from? > > Is $PREPARSER anything I should be aware of? That's just whatever prefix command you want to prepend to commands running generated parsers, e.g., valgrind. > I've run the program named "list" in 426 from gdb with the attached script. > Please see the attached output for backtraces at (hopefully) the relevant > places. Please don't hesitate if something else from the debugger would be > useful. Thanks for the traces! I don't have time to try to understand them now, I'll try to address that in the near future. >> Also, running these test with valgrind, if applicable, might help us knowing >> whether this call to the destructor is ok or not (i.e., if there is indeed >> more copies than usual, or a double free somewhere). >> >> Try make maintainer-check-valgrind. > > Unfortunately, while valgrind had support for AIX 5.3, the necessary effort > hasn't been made for AIX 6.1 and I'm not well versed in using > libefence/dmalloc. Would it be sufficient to trace both constructor and > destructor calls and match the two? No, I doubt it: here we are most likely talking about a stack allocated symbol, not something malloc'ed.