Re: Performance samples for LibreOffice ...

On Wed, Sep 10, 2014 at 01:20:28AM +0200, Jan Hubicka wrote:
> > On Fri, Aug 22, 2014 at 09:06:24PM +0200, Jan Hubicka wrote:
> >
> > > Another one I noticed :)
> > > /aux/hubicka/libreoffice/connectivity/source/inc/dbase/DIndex.hxx:41:15: warning: type 
> > > �struct ODbaseIndex� violates one definition rule [-Wodr]
> > >          class ODbaseIndex : public ODbaseIndex_BASE
> > >                ^
> > > /aux/hubicka/libreoffice/connectivity/source/inc/dbase/DIndex.hxx:41:15: note: a different 
> > > type is defined in another translation unit
> > >          class ODbaseIndex : public ODbaseIndex_BASE
> > >                ^
> > > /aux/hubicka/libreoffice/connectivity/source/inc/dbase/DIndex.hxx:74:29: note: the first 
> > > difference of corresponding definitions is field �m_aHeader�
> > >              NDXHeader       m_aHeader;
> > >                              ^
> > > /aux/hubicka/libreoffice/connectivity/source/inc/dbase/DIndex.hxx:74:29: note: a field of 
> > > same name but different type is defined in another translation unit
> > >              NDXHeader       m_aHeader;
> > >                              ^
> > > /aux/hubicka/libreoffice/connectivity/source/inc/dbase/DIndex.hxx:55:20: note: type �struct 
> > > NDXHeader� should match type �struct NDXHeader�
> > >              struct NDXHeader
> > >                     ^
> > > /aux/hubicka/libreoffice/connectivity/source/inc/dbase/DIndex.hxx:55:20: note: the 
> > > incompatible type is defined here
> > >              struct NDXHeader
> > >
> > > Thisone will be harder to track - I can get better diagnostic with ODR merging patch once I 
> > > get around updating it for mainline
> >
> > This looks like it is saying that there are two different
> > (incompatible) definitions of type
> > connectivity::dbase::ODbaseIndex::NDXHeader, but "git grep NDXHeader"
> > finds only one.
> >
> > Care to explain the problem? Thanks.
>
> The problem here will be most probably cause by difference in one of types NDXHeader is built 
> from.
> (or by #define somewhere earlier that makes it to diverge)

Here's the struct:

struct NDXHeader
{
    sal_uInt32  db_rootpage;                    /* Rootpage position                */
    sal_uInt32  db_pagecount;                   /* Page count                       */
    sal_uInt8   db_frei[4];                     /* Reserved                         */
    sal_uInt16  db_keylen;                      /* Key length                       */
    sal_uInt16  db_maxkeys;                     /* Maximum number of keys per page  */
    sal_uInt16  db_keytype;                     /* Type of key:
                                                   0 = Text
                                                   1 = Numerical                    */
    sal_uInt16  db_keyrec;                      /* Length of an index record
                                                   RecordNumber + keylen            */
    sal_uInt8   db_frei1[3];                    /* Reserved                         */
    sal_uInt8   db_unique;                      /* Unique                           */
    char        db_name[488];                   /* index_name (field name)          */
};

sal_uIntXX are LibreOffice internal #define for the unsigned integer
type of size XX bits. I find it rather unlikely they would differ
across the LibreOffice codebase; if they do, we have a "bigger"
problem.

What do you think about this conjecture: maybe gcc compiles the
structure with different alignment in different contexts? (Possibly
because the LibreOffice build system forces it to with compiler flags?)

> Currently GCC report just topelvel type difference, I have patch for
> the ODR merging that reports the inner type too. I will try to
> update it for mainline today or tomorrow and get back to you.

Great, thanks. I'm waiting for the result with great curiosity.

-- 
Lionel