Performance samples for LibreOffice ...
Lionel Elie Mamane
lionel at mamane.lu
Tue Sep 9 22:29:02 PDT 2014
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
More information about the LibreOffice
mailing list