[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison 3.0.3 (stable)
From: |
Akim Demaille |
Subject: |
Re: Bison 3.0.3 (stable) |
Date: |
Mon, 19 Jan 2015 11:44:20 +0100 |
> 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.
- Bison 3.0.3 (stable), Akim Demaille, 2015/01/15
- Message not available
- Re: Bison 3.0.3 (stable), Akim Demaille, 2015/01/18
- Re: Bison 3.0.3 (stable), Hans Aberg, 2015/01/18
- Re: Bison 3.0.3 (stable), Akim Demaille, 2015/01/18
- Re: Bison 3.0.3 (stable), Hans Aberg, 2015/01/18
- Re: Bison 3.0.3 (stable), John Horigan, 2015/01/18
- Re: Bison 3.0.3 (stable), Akim Demaille, 2015/01/19
Re: Bison 3.0.3 (stable), Thomas Jahns, 2015/01/19
- Message not available
- Re: Bison 3.0.3 (stable), Thomas Jahns, 2015/01/19
- Re: Bison 3.0.3 (stable),
Akim Demaille <=
- Re: Bison 3.0.3 (stable), Thomas Jahns, 2015/01/19
- Re: Bison 3.0.3 (stable), Akim Demaille, 2015/01/19
- Re: Bison 3.0.3 (stable), Thomas Jahns, 2015/01/20
- Re: Bison 3.0.3 (stable), Akim Demaille, 2015/01/20
- Re: Bison 3.0.3 (stable), Akim Demaille, 2015/01/20
Re: Bison 3.0.3 (stable), Akim Demaille, 2015/01/19
Re: Bison 3.0.3 (stable), Thomas Jahns, 2015/01/20
Re: Bison 3.0.3 (stable), Akim Demaille, 2015/01/20
Message not availableMessage not availableMessage not availableMessage not availableRe: Bison 3.0.3 (stable), Thomas Jahns, 2015/01/21
Re: Bison 3.0.3 (stable), Akim Demaille, 2015/01/21