bug-bison
[Top][All Lists]
Advanced

[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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]