Hello, Christian Bauer schrieb:
On 7/12/2006, "Francesco Biscani" <bluescarni@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@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