Re: Bison 3.0.3 (stable)

[Akim Demaille]

> Le 19 janv. 2015 à 11:31, Thomas Jahns <address@hidden> a écrit :
> 
> Is there some way to find what actually gets executed at
> 
> 
> $CXX $CXXFLAGS $CPPFLAGS -c -o cxx.o -c "address@hidden&*()-=_+{}[]|\\:;<>, 
> .'.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.