[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 11:31:13 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 |
On 01/19/15 10:23, Akim Demaille wrote:
[internal compiler error for 95]
That's weird. I have no idea what we might be doing here
that troubles it.
Is there some way to find what actually gets executed at
$CXX $CXXFLAGS $CPPFLAGS -c -o cxx.o -c "address@hidden&*()-=_+{}[]|\\:;<>,
.'.cc"
?
189: the error output from xlC should probably be normalized in
AT_SYNCLINES_COMPILE
[error message output doesn't match gcc]
The point of this test is to check that the location of an
invalid identifier is properly reported. The input file is:
[..]
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.
I'll try to find a means to avoid that.
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.
241, 440-443, 463, 464 these can possibly be cured by choosing another language
level with compiler option -qlanglvl=, but there's so many to choose from. Is
the version of C++ bison would like documented somewhere?
I don't know :) There weren't that many C++s before. It aims at C++98/C++03.
While the ISO standard C++ 98 is perhaps something to start from, most codes
seem to use one extension or another.
426 427 428 429 430 431 432: looks like repetitions of basically the same
bug.
Well, this is surprising:
426. c++.at:371: testing Variants lalr1.cc ...
/sw/src/bison/bison-3.0.3/tests/c++.at:371: bison -fno-caret -o list.cc list.y
/sw/src/bison/bison-3.0.3/tests/c++.at:371: $BISON_CXX_WORKS
stderr:
stdout:
/sw/src/bison/bison-3.0.3/tests/c++.at:371: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS
-o list list.cc $LIBS
stderr:
stdout:
/sw/src/bison/bison-3.0.3/tests/c++.at:371: $PREPARSER ./list
stderr:
Destroy: ""
Destroy: "0"
Destroy: (0)
Destroy: (0)
Destroy: 1
Destroy: "1"
Destroy: ()
Destroy: ""
Destroy: "2"
Destroy: ()
Destroy: ""
Destroy: 3
Destroy: ()
Destroy: ""
Destroy: "4"
Destroy: ()
Destroy: ()
Destroy: 5
Destroy: ()
Destroy: ""
Destroy: "6"
Destroy: ()
Destroy: (0, 1, 2, 4, 6)
/sw/src/bison/bison-3.0.3/tests/c++.at:371: sed >&2 -e '/^profiling:.*:Merge
mismatch for summaries/d' stderr
--- - 2015-01-15 12:17:22.000000000 +0100
+++
/sw/src/bison/bison-3.0.3-build-64bit/tests/testsuite.dir/at-groups/426/stderr
2015-01-15 12:17:22.000000000 +0100
@@ -1,6 +1,7 @@
Destroy: ""
Destroy: "0"
Destroy: (0)
+Destroy: (0)
Destroy: 1
Destroy: "1"
Destroy: ()
426. c++.at:371: 426. Variants lalr1.cc (c++.at:371): FAILED (c++.at:371)
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?
Could you try to see where this destructor call is coming from?
Is $PREPARSER anything I should be aware of? When I run the program as ./list, I
get the following output:
Destroy: ""
Destroy: "0"
Destroy: (0)
Destroy: (0)
Destroy: 1
Destroy: "1"
Destroy: ()
Destroy: ""
Destroy: "2"
Destroy: ()
Destroy: ""
Destroy: 3
Destroy: ()
Destroy: ""
Destroy: "4"
Destroy: ()
Destroy: ()
Destroy: 5
Destroy: ()
Destroy: ""
Destroy: "6"
Destroy: ()
(0, 1, 2, 4, 6)
Destroy: (0, 1, 2, 4, 6)
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.
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?
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
CMDFILE
Description: Text document
list.debug.out
Description: Text document
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 <=
- Re: Bison 3.0.3 (stable), Akim Demaille, 2015/01/19
- 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