[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison 3.0.3 (stable)
From: |
Thomas Jahns |
Subject: |
Re: Bison 3.0.3 (stable) |
Date: |
Mon, 19 Jan 2015 16:10:20 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 |
Hello Akim,
On 01/19/15 11:44, Akim Demaille wrote:
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'
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 "address@hidden&*()-=_+{}[]|\\:;<>, .'.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 <address@hidden>
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
- 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, 2015/01/19
- Re: Bison 3.0.3 (stable),
Thomas Jahns <=
- 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
Re: Bison 3.0.3 (stable), Thomas Jahns, 2015/01/22