[GiNaC-list] Re: ginac parsing from string issue (hopefully nailed!)

[Jens Vollinga]

Hello,

Christian Bauer schrieb:
> On 7/12/2006, "Francesco Biscani" <bluescarni at gmail.com> wrote:
>> According to this, the optimization that causes the problem 
>> is "-fstrict-aliasing".
> 
> There may still be a problem with our (or bison's generated) code.
> Compiling with -fstrict-aliasing and -Wstrict-aliasing (or
> -Wstrict-aliasing=2) may give a hint.

this gives no information at all, neither when compiling GiNaC or bison 
itself.

On 7/12/2006, "Francesco Biscani" <bluescarni at gmail.com> wrote:
> I've followed the list's suggestion but unfortunately upgrading from bison-2.2 
> to bison-2.3 (and recompiling gcc+cln+ginac) did not solve the issue for me.

Maybe you didn't use new bison for the compilation. That depends on 
whether you used 'make clean' or removed the old compilation directory 
completely. The problem lies with 'make clean' (this is maybe not a 
feature but a bug?!?). 'make clean' doesn't remove the files "input_*" 
in the directory 'ginac'. Those are generated by bison and incorporate 
the bug in my opinion. Unless you delete these files by hand, they won't 
be re-generated by the newly installed bison.

What puzzles me is that you upgraded from 2.2 to 2.3. After some 
checking I found that the last working version of bison is 2.0a. 2.0 
fails. If you look at the release dates of 2.0 and 2.0a you will find 
that the gcc 4.0 release lies just in between ... Sadly, there are no 
explicit remarks about a related bug in the Changelog of bison (but 
maybe I've overseen it somehow), so I don't know about its nature and 
how it has been fixed.

Could I ask you recompile GiNaC again? Just delete the 'input_*' files 
in the ginac directory in advance. Compiling then should be fast. While 
I am convinced that the bug lies with bison I am maybe wrong.

Regards,
Jens