Hello Akim, On 01/19/15 11:44, Akim Demaille wrote:
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'
That does unfortunately only give stdout:/sw/src/bison/bison-3.0.3/tests/output.at:264: $CC $CFLAGS $CPPFLAGS -c -o glr.o -c "\`~!@#\$%^&*()-=_+{}[]|\\:;<>, .'.c"
Not enabling shell tracing (command contains a `...` command substitution) :-(
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.
If the number of further errors + warnings was limited to perhaps 2 or 3 that makes sense, but in my experience, more often than not, I get dozens of followup errors that simply make me scroll up to get at the initial problem.
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.
Ok, that's interesting.
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.
I tried another build with -qlanglvl=strict98 but that didn't make a difference.
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.
Unfortunately switching to -O2 at least didn't make a difference either.
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.
So should I trace the constructors too?
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.
Okay, that would indeed limit the usefulness of efence/dmalloc. Regards, Thomas -- Thomas Jahns HD(CP)^2 Abteilung Anwendungssoftware Deutsches Klimarechenzentrum GmbH Bundesstraße 45a • D-20146 Hamburg • Germany Phone: +49 40 460094-151 Fax: +49 40 460094-270 Email: Thomas Jahns <ja...@dkrz.de> URL: www.dkrz.de Geschäftsführer: Prof. Dr. Thomas Ludwig Sitz der Gesellschaft: Hamburg Amtsgericht Hamburg HRB 39784
smime.p7s
Description: S/MIME Cryptographic Signature
