Re: Bison 3.0.3 (stable)

[Thomas Jahns]

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