Re: ginac parsing from string issue (hopefully nailed!)
On Tuesday 11 July 2006 20:36, you wrote:
Please have a look at the ginac-list mailing list archives: The problem has been traced to be in an interaction with the bison-generated file with gcc 4.1.x.
Hi Richy, 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. However, one post in the list mentioned that turning off optimizations made the issue disappear. So I made a bisect search for the faulty gcc optimization starting from -O1 (where the problem was not present) to -O2, recompiling ginac each time. According to this, the optimization that causes the problem is "-fstrict-aliasing". Then I recompiled ginac with -O1 plus all the additional optimizations of -O2 (according to gcc man page) _excluding_ "-fstrict-aliasing". Now the test program runs properly :) I hope this can somehow be useful. I don't think I should open a bug against gcc, since apparently in gcc-4.1.2pre the problem seems to be solved. Suggestions are welcome... Thanks for all the help guys, now I can go back to coding :) Regards, Francesco -- Dr. Francesco Biscani Dipartimento di Astronomia Università di Padova biscani@pd.astro.it
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. Bye, Christian
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
Hello, On Wednesday 12 July 2006 18:38, Jens Vollinga wrote:
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.
I don't think that this is the case. I compiled ginac using the gentoo "portage" package manager, which erases the source directory every time it has finished compiling something. There is no garbage left from previous compilations. I also checked that the bison version is really 2.3, and that there are no old binaries lying around.
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.
I'm not familiar with the intricacies of bison and friends, so I don't quite understand how it relates to the compiler and ginac. But please tell me if I can do more tests, I'll be an happy guinea pig :) Thanks, Francesco
On Wed, Jul 12, 2006 at 06:57:53PM +0200, Francesco Biscani wrote:
On Wednesday 12 July 2006 18:38, Jens Vollinga wrote:
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.
I don't think that this is the case. I compiled ginac using the gentoo "portage" package manager, which erases the source directory every time it has finished compiling something. There is no garbage left from previous compilations.
There is a copy of input_parser.{cc,h} in the GiNaC tarball. These files have been generated with bison version 1.875d (as the very first line indicates). However, from the make's point of view they are up-to-date (since make only looks at the timestamps and have no idea that code depends on version of bison).
I also checked that the bison version is really 2.3, and that there are no old binaries lying around.
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.
Since make does not even try to rebuild files, the actual version of bison on *user's machine* does not really matter.
I'm not familiar with the intricacies of bison and friends, so I don't quite understand how it relates to the compiler and ginac. But please tell me if I can do more tests, I'll be an happy guinea pig :)
Could you please 1. unpack GiNaC tarball, 2. remove ginac/input_parser.{cc,h} 3. run ./configure --disable-static CXXFLAGS="-O2 -g" && make && make check Best regards, Alexei. -- All science is either physics or stamp collecting.
Hello, On Wednesday 12 July 2006 20:19, Sheplyakov Alexei wrote:
There is a copy of input_parser.{cc,h} in the GiNaC tarball. These files have been generated with bison version 1.875d (as the very first line indicates). However, from the make's point of view they are up-to-date (since make only looks at the timestamps and have no idea that code depends on version of bison).
*me slaps my forehead*
Could you please 1. unpack GiNaC tarball, 2. remove ginac/input_parser.{cc,h} 3. run ./configure --disable-static CXXFLAGS="-O2 -g" && make && make check
Yes it works :) make check passed successfully. I had not correctly understood the problem at first... I apologize for the noise on the list. Thanks all for your help, Francesco -- Dr. Francesco Biscani Dipartimento di Astronomia Università di Padova biscani@pd.astro.it
Hello, On Wed, Jul 12, 2006 at 02:51:29PM +0200, Francesco Biscani 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.
However, one post in the list mentioned that turning off optimizations made the issue disappear. So I made a bisect search for the faulty gcc optimization starting from -O1 (where the problem was not present) to -O2, recompiling ginac each time.
According to this, the optimization that causes the problem is "-fstrict-aliasing". Then I recompiled ginac with -O1 plus all the additional optimizations of -O2 (according to gcc man page) _excluding_ "-fstrict-aliasing". Now the test program runs properly :)
I've tried building *old* bison generated code with '-O2 -g -fno-strict-aliasing': make CXXFLAGS="-O2 -g -Wall" && rm -f ginac/.libs/input_parser.o && \ rm -f ginac/input_parser.lo && \ make CXXFLAGS="-O2 -g -Wall -fno-strict-aliasing" && \ make check CXXFLAGS="-O2 -g -Wall" No test failed. So I suspect that code in question (files ginac/input_parser.cc ginac/input_parser.h) have not been re-generated (since make does not know that code depends on version of bison). Could you please check if this is the case? Try to remove these files (source and header), and rebuild GiNaC with CXXFLAGS="-O2". Best regards, Alexei. -- All science is either physics or stamp collecting.
participants (4)
-
Christian Bauer
-
Francesco Biscani
-
Jens Vollinga
-
varg＠theor.jinr.ru