Re: Performance samples for LibreOffice ...

> 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?)

I have seen similar problem of warning in betwen units because one was compiled
with -fsigned-char and other with -funsigned-char (in Firefox). I think compiler is
valid to warn here about ODR violation since those flags are ABI breaking flags.

It is also possible it is compare bug in the new ODR checking code - but I do not
really see how it could get confused in such a rather simple structure.

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

Yep, I am curious too.  I just got my trees updated after vacation so hopefully
I will get there soon (for sure libreoffice will trigger few GCC bugs first)

Honza
> -- 
> Lionel