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/>