Strict-aliasing problem in Streamer() for class using enum

When trying to compile simple class with Streamer() generated by rootcint:

rootcint -f -c A.h ALinkDef.h 
g++ -c -o A_dict.lo -Wall -I/cern/root_v5.20.00-1/include -O2

I obtain such warning: In member function ‘virtual void A::Streamer(TBuffer&)’: warning: dereferencing type-punned pointer will break strict-aliasing rules

compiler -02 options includes -fstrict-aliasing so the definition of streamer:

void A::Streamer(TBuffer &R__b)
   // Stream an object of class A.

   UInt_t R__s, R__c;
   if (R__b.IsReading()) {
      Version_t R__v = R__b.ReadVersion(&R__s, &R__c); if (R__v) { }
      R__b >> (Int_t&)typ;
      R__b.CheckByteCount(R__s, R__c, A::IsA());
   } else {
      R__c = R__b.WriteVersion(A::IsA(), kTRUE);
      R__b << (Int_t)typ;
      R__b.SetByteCount(R__c, kTRUE);

produces this warning because of this line:

R__b >> (Int_t&)typ;

How should I generate _dict file with LinkDef pragma’s to have it properly done ?
I am not interested in solution with -fno-strict-aliasing option given to compiler.

My root version is 5.20.

Thans in advance!
ALinkDef.h (197 Bytes)
A.h (132 Bytes)


The Streamer function, as you have it, is obsolete; instead you should request the new style of streamer function by using in your LinkDef.h:#pragma link C++ class A+;


That old Streamer works in my software when new one generates Segmentation Fault … So I must check it again why is that.

I found another problem with strict-aliasing when dealing with stl’s map and pair.

There is typedef in class C:

class C : public TNamed  {
  C() : TNamed() {}
  typedef std::map<int, B*> t_m;

which is a source of strict-aliasing warnings:

rootcint -f -c C.h CLinkDef.h 
g++ -c -o C_dict.lo -Wall -I/cern/root_v5.20.00-1/include -I ./ -O2 In function ‘int G__C_dict_345_0_2(G__value*, const char*, G__param*, int)’: warning: dereferencing type-punned pointer will break strict-aliasing rules warning: dereferencing type-punned pointer will break strict-aliasing rules

I found that when I overwrite pair’s copy constructor:

namespace std {
  template <> class pair<int, B*> {
    pair(const pair &) {};

warnings are not present anymore. I guess that is not easy to correct that problem with pragmas’ in LinkDef file. What should I do ?


CLinkDef.h (282 Bytes)
C.h (335 Bytes)


My apologies for the late answer.

I am unable to reproduce your last problem. Which platform are you running on? Do you still see the problem with a newer version of ROOT (v5.25/04)?


The dictionary file ( created by rootcint within both root versions 5.20 and 5.24 has the same part of code:

     p = new pair<int,B*>(*(int*) G__Intref(&libp->para[0]), libp->para[1].ref ? *(B**) libp->para[1].ref : *(B**) (&G__Mlong(libp->para[1])));
   } else {
     p = new((void*) gvp) pair<int,B*>(*(int*) G__Intref(&libp->para[0]), libp->para[1].ref ? *(B**) libp->para[1].ref : *(B**) (&G__Mlong(libp->para[1])));

I do not know what G__Mlong is but dereferencing it breaks strict-aliasing rules… but life is not so simply and that warning is visible with gcc 4.1.2 (debian 3.4.6-5). I tested compilation of the same with 3.4.6. & 4.3.2 and did not see any warning.

So maybe first check dictionary file created with the newest rootcint and decide if it is real warning or fake for one compilator version.


Warning is also visible with gcc 4.2.2

I cannot reproduce your problem with any ROOT version or compiler version. May be you have some pathological include in your local directory.
Could you replace:



I guess it is not a problem of includes. Tried your modification but without positive result.

In generated with rootcint I have 2 places in which dereferencing of G__Mlong is applied : (&G__Mlong(libp->para[1]))). In dictionary file included to this post you can try to find them and check if in dictionary files generated by your rootcint they still exist or not.

Please submit your dictionary file created for class C.

Marcin (6.9 KB)

My file is identical to your file and I do not see any warning/error generated by the compiler (I tried with gcc4.3 and 4.4)


Since the newest version of gcc 4.3.2 (and 4.4) does not show any problem, I am assuming that this was a ‘deficiency’ in gcc.