build problems with ver.1.3.3
attached is the log of a failed build of ginac 1.3.3 gcc used is: gcc-4.1.0_20051123-3 gcc-c++-4.1.0_20051123-3 The log is virtually identical for i386, ia64, ppc, ppc64, s390, s390x, x86_64. As the problems look rather generic I'd recommend these errors and warnings be fixed in the original package (instead of producing another SuSE patch). [resent because uncompressed log is >40KB and rejected] attached is the bzip2 compressed log -- p=2^q-1 prime <== q>2, cosh(2^(q-2)*log(2+sqrt(3)))%p=0 Life is hard and then you die.
Replying to myself :) On Thu, Nov 24, 2005 at 05:42:06PM +0300, Sheplyakov Alexei wrote:
Hello,
On Thu, Nov 24, 2005 at 12:59:00PM +0100, Joerg Arndt wrote:
attached is the log of a failed build of ginac 1.3.3 gcc used is: gcc-4.1.0_20051123-3 gcc-c++-4.1.0_20051123-3
Does attached patch fix that?
It does, but `make check' still fails with the following error: if g++-4.1 -DHAVE_CONFIG_H -I. -I. -I../config -I./../ginac -I../ginac -O2 -g -finline-limit=1000 -pipe -MT exam_structure.o -MD -MP -MF ".deps/exam_structure.Tpo" -c -o exam_structure.o exam_structure.cpp; \ then mv -f ".deps/exam_structure.Tpo" ".deps/exam_structure.Po"; else rm -f ".deps/exam_structure.Tpo"; exit 1; fi exam_structure.cpp:50: error: specialization of ‘void GiNaC::structure<T, ComparisonPolicy>::print(const GiNaC::print_context&, unsigned int) const [with T = sprod_s, ComparisonPolicy = GiNaC::compare_std_less]’ in different namespace exam_structure.cpp:50: error: from definition of ‘void GiNaC::structure<T, ComparisonPolicy>::print(const GiNaC::print_context&, unsigned int) const [with T = sprod_s, ComparisonPolicy = GiNaC::compare_std_less]’ exam_structure.cpp:56: error: specialization of ‘GiNaC::ex GiNaC::structure<T, ComparisonPolicy>::eval(int) const [with T = sprod_s, ComparisonPolicy = GiNaC::compare_std_less]’ in different namespace exam_structure.cpp:56: error: from definition of ‘GiNaC::ex GiNaC::structure<T, ComparisonPolicy>::eval(int) const [with T = sprod_s, ComparisonPolicy = GiNaC::compare_std_less]’ Quick and dirty fix is attached. -- All science is either physics or stamp collecting.
Hi! Sheplyakov Alexei wrote:
if g++-4.1 -DHAVE_CONFIG_H -I. -I. -I../config -I./../ginac -I../ginac -O2 -g -finline-limit=1000 -pipe -MT exam_structure.o -MD -MP -MF ".deps/exam_structure.Tpo" -c -o exam_structure.o exam_structure.cpp; \ then mv -f ".deps/exam_structure.Tpo" ".deps/exam_structure.Po"; else rm -f ".deps/exam_structure.Tpo"; exit 1; fi exam_structure.cpp:50: error: specialization of ‘void GiNaC::structure<T, ComparisonPolicy>::print(const GiNaC::print_context&, unsigned int) const [with T = sprod_s, ComparisonPolicy = GiNaC::compare_std_less]’ in different namespace exam_structure.cpp:50: error: from definition of ‘void GiNaC::structure<T, ComparisonPolicy>::print(const GiNaC::print_context&, unsigned int) const [with T = sprod_s, ComparisonPolicy = GiNaC::compare_std_less]’ exam_structure.cpp:56: error: specialization of ‘GiNaC::ex GiNaC::structure<T, ComparisonPolicy>::eval(int) const [with T = sprod_s, ComparisonPolicy = GiNaC::compare_std_less]’ in different namespace exam_structure.cpp:56: error: from definition of ‘GiNaC::ex GiNaC::structure<T, ComparisonPolicy>::eval(int) const [with T = sprod_s, ComparisonPolicy = GiNaC::compare_std_less]’
Are you sure this is not the latest GCC whim which will disappear again? (We've seen quite a few of these, lately.) If yes, the specialization of bar::f() below must really be wrapped in namespace A? namespace A { template<class T> class foo { public: void f(); }; } // namespace A namespace B { typedef A::foo<int> bar; template<> void bar::f(); } // namespace B Oouw, sucks... -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hello! On Sat, Nov 26, 2005 at 10:02:27PM +0100, Richard B. Kreckel wrote:
Sheplyakov Alexei wrote:
if g++-4.1 -DHAVE_CONFIG_H -I. -I. -I../config -I./../ginac -I../ginac -O2 -g -finline-limit=1000 -pipe -MT exam_structure.o -MD -MP -MF ".deps/exam_structure.Tpo" -c -o exam_structure.o exam_structure.cpp; \ then mv -f ".deps/exam_structure.Tpo" ".deps/exam_structure.Po"; else rm -f ".deps/exam_structure.Tpo"; exit 1; fi exam_structure.cpp:50: error: specialization of ‘void GiNaC::structure<T, ComparisonPolicy>::print(const GiNaC::print_context&, unsigned int) const [with T = sprod_s, ComparisonPolicy = GiNaC::compare_std_less]’ in different namespace exam_structure.cpp:50: error: from definition of ‘void GiNaC::structure<T, ComparisonPolicy>::print(const GiNaC::print_context&, unsigned int) const [with T = sprod_s, ComparisonPolicy = GiNaC::compare_std_less]’ exam_structure.cpp:56: error: specialization of ‘GiNaC::ex GiNaC::structure<T, ComparisonPolicy>::eval(int) const [with T = sprod_s, ComparisonPolicy = GiNaC::compare_std_less]’ in different namespace exam_structure.cpp:56: error: from definition of ‘GiNaC::ex GiNaC::structure<T, ComparisonPolicy>::eval(int) const [with T = sprod_s, ComparisonPolicy = GiNaC::compare_std_less]’
Are you sure this is not the latest GCC whim which will disappear again?
See ISO C++ standard, 14.7.3, paragraph 2.
If yes, the specialization of bar::f() below must really be wrapped in namespace A?
namespace A { template<class T> class foo { public: void f(); }; } // namespace A namespace B { typedef A::foo<int> bar; template<> void bar::f(); } // namespace B
Yes.
Oouw, sucks...
I agree with you completely. Best regards, Alexei -- All science is either physics or stamp collecting.
Sheplyakov Alexei wrote:
Hello,
On Thu, Nov 24, 2005 at 12:59:00PM +0100, Joerg Arndt wrote:
attached is the log of a failed build of ginac 1.3.3 gcc used is: gcc-4.1.0_20051123-3 gcc-c++-4.1.0_20051123-3
Does attached patch fix that?
A Friend declaration is not a declaration, all right. But: is it really the intent to have that signature of simplify_indexed hidden? Or should the definition rather go into the header file indexed.h? Just asking -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hello, On Thu, Nov 24, 2005 at 09:17:38PM +0100, Richard B. Kreckel wrote:
A Friend declaration is not a declaration, all right. But: is it really the intent to have that signature of simplify_indexed hidden?
Yes. simplify_indexed, simplify_indexed_product, reposition_dummy_indices are helper functions used only by the `indexed' class...
Or should the definition rather go into the header file indexed.h?
... so I don't think they should be visible elsewhere. -- All science is either physics or stamp collecting.
Sheplyakov Alexei wrote:
Yes. simplify_indexed, simplify_indexed_product, reposition_dummy_indices are helper functions used only by the `indexed' class...
Committed. Thanks. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
* Sheplyakov Alexei <varg@theor.jinr.ru> [Nov 24. 2005 15:42]:
Hello,
On Thu, Nov 24, 2005 at 12:59:00PM +0100, Joerg Arndt wrote:
attached is the log of a failed build of ginac 1.3.3 gcc used is: gcc-4.1.0_20051123-3 gcc-c++-4.1.0_20051123-3
Does attached patch fix that?
Yes. Of course the "virtual" warnings remain. make check fails on all platforms we (SuSE) have so I had to disable it. Thanks for the quick fix & sorry for the delayed answer!
[...]
-- p=2^q-1 prime <== q>2, cosh(2^(q-2)*log(2+sqrt(3)))%p=0 Life is hard and then you die.
Joerg Arndt wrote:
* Sheplyakov Alexei <varg@theor.jinr.ru> [Nov 24. 2005 15:42]:
Does attached patch fix that?
Yes. Of course the "virtual" warnings remain.
The "virtual" warnings will go away with GiNaC-1.4. Till then, feel free to ignore them...
make check fails on all platforms we (SuSE) have so
?!? I've tried with a GCC-4.1 snapshot and it worked like a charm. Do the CLN tests pass? Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
* Richard B. Kreckel <kreckel@ginac.de> [Dec 02. 2005 20:36]:
Joerg Arndt wrote: [...] ?!? I've tried with a GCC-4.1 snapshot and it worked like a charm. Do the CLN tests pass?
This may be the reason(?): ------------------------------- [...] Wrote: /usr/src/packages/SRPMS/cln-1.1.11-2.src.rpm Wrote: /usr/src/packages/RPMS/i586/cln-1.1.11-2.i586.rpm ... checking for files with abuild user/group ... installing all built rpms Preparing packages for installation... cln-1.1.11-2 ... testing for empty debuginfo packages [OK up to here] ... testing for serious compiler warnings Program is likely to break with new gcc. Add -fno-strict-aliasing or fix. Problematic file(s) and their linenumbers: ./real/ring/cl_R_ring.cc: 133 ./vector/cl_GV_I.cc: 384, 399 ./integer/ring/cl_I_ring.cc: 129 ./rational/ring/cl_RA_ring.cc: 129 ./complex/ring/cl_C_ring.cc: 132 ------------------------------- The package does not build b/c our buildsystem refuses to accept strict-aliasing warnings. So I may be building ginac against the older CLN... E.g., ./real/ring/cl_R_ring.cc: 133 is class cl_heap_real_ring : public cl_heap_number_ring { SUBCLASS_cl_heap_ring() public: // Constructor. cl_heap_real_ring () : cl_heap_number_ring (&R_setops,&R_addops,&R_mulops, /* HERE: */ (cl_number_ring_ops<cl_number>*) &R_ops) { type = &cl_class_real_ring; } // Destructor. ~cl_heap_real_ring () {} }; Can one expect problems here? Or should I just add -fno-strict-aliasing? -- p=2^q-1 prime <== q>2, cosh(2^(q-2)*log(2+sqrt(3)))%p=0 Life is hard and then you die.
Joerg Arndt wrote:
* Richard B. Kreckel <kreckel@ginac.de> [Dec 02. 2005 20:36]:
Joerg Arndt wrote: [...] ?!? I've tried with a GCC-4.1 snapshot and it worked like a charm. Do the CLN tests pass?
This may be the reason(?):
JJ, what are you trying to accomplish? Find the culprit for your crashes? Can't you instead send us a backtrace? And: What about the CLN tests (make check)? Do they pass?
------------------------------- [...] Wrote: /usr/src/packages/SRPMS/cln-1.1.11-2.src.rpm Wrote: /usr/src/packages/RPMS/i586/cln-1.1.11-2.i586.rpm ... checking for files with abuild user/group ... installing all built rpms Preparing packages for installation... cln-1.1.11-2 ... testing for empty debuginfo packages [OK up to here] ... testing for serious compiler warnings Program is likely to break with new gcc. Add -fno-strict-aliasing or fix. Problematic file(s) and their linenumbers: ./real/ring/cl_R_ring.cc: 133 ./vector/cl_GV_I.cc: 384, 399 ./integer/ring/cl_I_ring.cc: 129 ./rational/ring/cl_RA_ring.cc: 129 ./complex/ring/cl_C_ring.cc: 132 ------------------------------- The package does not build b/c our buildsystem refuses to accept strict-aliasing warnings. So I may be building ginac against the older CLN...
E.g., ./real/ring/cl_R_ring.cc: 133 is
class cl_heap_real_ring : public cl_heap_number_ring { SUBCLASS_cl_heap_ring() public: // Constructor. cl_heap_real_ring () : cl_heap_number_ring (&R_setops,&R_addops,&R_mulops, /* HERE: */ (cl_number_ring_ops<cl_number>*) &R_ops) { type = &cl_class_real_ring; } // Destructor. ~cl_heap_real_ring () {} };
Can one expect problems here? Or should I just add -fno-strict-aliasing?
I don't know. Can you try, please? Anyway, the code marked "HERE:" above tries to store the address of a static cl_number_ring_ops<cl_R> in the ops member variable of type cl_number_ring_ops<cl_number>* inside cl_heap_number_ring. What's wrong with that and what's it got to do with aliasing? Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
* Richard B. Kreckel <kreckel@ginac.de> [Dec 04. 2005 11:05]:
Joerg Arndt wrote:
* Richard B. Kreckel <kreckel@ginac.de> [Dec 02. 2005 20:36]:
Joerg Arndt wrote: [...] ?!? I've tried with a GCC-4.1 snapshot and it worked like a charm. Do the CLN tests pass?
This may be the reason(?):
JJ, what are you trying to accomplish? Find the culprit for your crashes? Can't you instead send us a backtrace? And: What about the CLN tests (make check)? Do they pass?
I'll debug (& hopefully fix) mid next week, busy ATM. -- p=2^q-1 prime <== q>2, cosh(2^(q-2)*log(2+sqrt(3)))%p=0 Life is hard and then you die.
participants (3)
-
Joerg Arndt
-
Richard B. Kreckel
-
varg＠theor.jinr.ru