workaround in cl_nt_sqrtmodp.cc for gcc 3.5 branch?
Hi there, With a recent gcc HEAD CVS snapshot (which I came to try out because of gcc regression debug/16035 found during compilation of cln) linking against libcln.so fails with gcc-test/bin/g++ -g -O2 exam.o exam_I.o exam_RA.o exam_SF.o exam_FF.o exam_DF.o exam_LF.o exam_I_gcd.o exam_I_sqrtp.o -o .libs/exam ../src/.libs/libcln.so -lgmp -lm -Wl,--rpath -Wl,/usr/local/lib ../src/.libs/libcln.so: undefined reference to `cln::tonelli_shanks_sqrt(cln::cl_modint_ring const&, cln::cl_MI const&)::cl_sylow2gen_property::~cl_sylow2gen_property()' ../src/.libs/libcln.so: undefined reference to `cln::tonelli_shanks_sqrt(cln::cl_modint_ring const&, cln::cl_MI const&)::cl_sylow2gen_property::~cl_sylow2gen_property()' Reversing the logic of the two #if's in src/numtheory/cl_nt_sqrtmodp.cc, which seem to guard against a gcc-2 bug on s390, compilation succeeds and `make check' passes (no further tests done). This is on linux/x86 with no configuration options except setting CC and CXX. Now I'd like to know if this a sign of yet another gcc regression before reporting it? Regards, Ralf
Ralf Wildenhues wrote:
Reversing the logic of the two #if's in src/numtheory/cl_nt_sqrtmodp.cc, which seem to guard against a gcc-2 bug on s390, compilation succeeds and `make check' passes (no further tests done). This is on linux/x86 with no configuration options except setting CC and CXX.
Now I'd like to know if this a sign of yet another gcc regression before reporting it?
Yes. This code compiles fine with gcc-3.3 (well, "fine" means that it takes 700 MB RAM to compile it), so a bug report to the GCC people is in order. It will be most convincing to show them the preprocessed C++ code and the result of "nm" on the g++ generated object file. Bruno
* Bruno Haible wrote on Wed, Aug 25, 2004 at 12:44:31PM CEST:
Ralf Wildenhues wrote:
Now I'd like to know if this a sign of yet another gcc regression before reporting it?
Yes. This code compiles fine with gcc-3.3 (well, "fine" means that it takes 700 MB RAM to compile it), so a bug report to the GCC people is in order. It will be most convincing to show them the preprocessed C++ code and the result of "nm" on the g++ generated object file.
Done after cutting down to a small example: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17182 Regards, Ralf
On Wed, 25 Aug 2004, Ralf Wildenhues wrote:
* Bruno Haible wrote on Wed, Aug 25, 2004 at 12:44:31PM CEST:
Ralf Wildenhues wrote:
Now I'd like to know if this a sign of yet another gcc regression before reporting it?
Yes. This code compiles fine with gcc-3.3 (well, "fine" means that it takes 700 MB RAM to compile it), so a bug report to the GCC people is in order. It will be most convincing to show them the preprocessed C++ code and the result of "nm" on the g++ generated object file.
Done after cutting down to a small example: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17182
For the record: I just tried gcc-3.5-20040822 snapshot with Mark Mitchell's patch for PR c++/17155 applied (17182 and 17155 are duplicates of each other) and it fixes that problem. It also successfully compiled the entire library. The number of GCC bugs CLN keeps triggering is simply amazing. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (3)
-
Bruno Haible
-
Ralf Wildenhues
-
Richard B. Kreckel