[GiNaC-list] build problems with ver.1.3.3

[Richard B. Kreckel]

Joerg Arndt wrote:

>* Richard B. Kreckel <kreckel at 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/>