bugThe FreeType Project - Bugs: bug #49448, Compilation of FreeType 2.7.0 with...

 
 

bug #49448: Compilation of FreeType 2.7.0 with XLC compiler fails

Submitted by:  Alexander <alex_sam_compart>
Submitted on:  Wed 26 Oct 2016 02:35:31 PM UTC  
 
Severity: 3 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: Werner LEMBERG <wl>Open/Closed: Closed
Planned Release: 2.7.1

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 06 Nov 2016 05:07:31 AM UTC, comment #3:

Fixed in git, thanks.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 28 Oct 2016 03:15:09 PM UTC, comment #2:

For the sake of other XLC users I ask you to report the problem ...
(CCing me)... - Done.

Alexander <alex_sam_compart>
Wed 26 Oct 2016 03:05:50 PM UTC, comment #1:

For the sake of other XLC users I ask you to report the problem to the gnulib bug mailing list

https://lists.gnu.org/mailman/listinfo/bug-gnulib

(CCing me), ideally by providing a small snippet that exhibits the compiler bug, or simply by pointing to this report.

I've taken the `TYPEOF' implementation from gnulib's `intprops.h' header file, and I'm quite sure that the maintainers can provide a much better, generic fix than I'm ever able to come up with, and which I can then add to FreeType.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Wed 26 Oct 2016 02:35:31 PM UTC, original submission:

Hello,

We support build of our product for AIX 5.2 with XLC (cc_r) compiler. Recently we migrated from FreeType 2.5.5 to 2.7.0 and got compilation errors:

"ftobjs.c", line 2692.52: 1506-045 (S) Undeclared identifier face.
"ftobjs.c", line 2692.68: 1506-045 (S) Undeclared identifier metrics.

"ttobjs.c", line 1229.34: 1506-045 (S) Undeclared identifier face.
"ttobjs.c", line 1229.55: 1506-045 (S) Undeclared identifier metrics.

For both source files the problem is the same and it is caused by call of FT_PIX_CEIL, FT_PIX_FLOOR, FT_PIX_ROUND with FT_MulFix inside.

After some investigation we found that the problem is that cc_r does not parse correctly the expression where the argument of typeof (that is called by FT_PIX_CEIL, FT_PIX_FLOOR, FT_PIX_ROUND) is a function (FT_MulFix in our case) with non-constant parameters.

We tried to solve it by explicit casting of variables to their own types, like:
metrics->ascender = FT_PIX_CEIL(FT_MulFix( FT_TYPEOF(face->ascender)face->ascender, FT_TYPEOF(metrics->y_scale)metrics->y_scale ));
But it worked on 32-bit compilation only. 64-bit compilation (-q64) failed due to another cc_r bug, since cc_r could not parse correctly such an expression thinking that it is a declaration:
"ftobjs.c", line 2696.41: 1506-343 (S) Redeclaration of FT_MulFix differs from previous declaration on line 231 of "ftcalc.c".

Finally we found a workaround which works for both 32- and 64-bit mode - to cast explicitly the result of FT_MulFix with variable arguments to a type of FT_MulFix with fixed arguments: FT_TYPEOF(FT_MulFix(0,0)). That works since compiler bug is not reproduced when typeof takes a function call with fixed arguments as an own argument.

So, the code fragment of ftobjs.c with a workaround looks like:

metrics->ascender = FT_PIX_CEIL( FT_TYPEOF(FT_MulFix(0,0))FT_MulFix( face->ascender, metrics->y_scale ) );

metrics->descender = FT_PIX_FLOOR( FT_TYPEOF(FT_MulFix(0,0))FT_MulFix( face->descender, metrics->y_scale ) );

metrics->height = FT_PIX_ROUND( FT_TYPEOF(FT_MulFix(0,0))FT_MulFix( face->height, metrics->y_scale ) );

metrics->max_advance = FT_PIX_ROUND( FT_TYPEOF(FT_MulFix(0,0))FT_MulFix( face->max_advance_width, metrics->x_scale ) );

And the same for ttobjs.c:
metrics->ascender =
FT_PIX_ROUND( FT_TYPEOF(FT_MulFix(0,0))FT_MulFix( face->root.ascender, metrics->y_scale ) );
metrics->descender =
FT_PIX_ROUND( FT_TYPEOF(FT_MulFix(0,0))FT_MulFix( face->root.descender, metrics->y_scale ) );
metrics->height =
FT_PIX_ROUND( FT_TYPEOF(FT_MulFix(0,0))FT_MulFix( face->root.height, metrics->y_scale ) );
metrics->max_advance =
FT_PIX_ROUND( FT_TYPEOF(FT_MulFix(0,0))FT_MulFix( face->root.max_advance_width, metrics->x_scale ) );

The issue was not reproduced in FreeType 2.5.5 because FT_TYPEOF macro was introduced later.

The workaround works fine, although we have a lot of warnings for 64-bit compilation about implicit casting between int <-> long that makes us think that runtime problems are also possible.

Could you please either provide a clear solution for the mentioned problem with cc_r compiler on AIX 5.2 for 32- and 64-bit or confirm that the proposed workaround is safe?

Thanks in advance!
--
Best Regards,
Alexander Samoilov,
Build & Integration Ingenieur,
Compart AG (Böblingen, Germany)

P.S.:
uname -a
AIX pavo 2 5 00C9E74E4C00

Alexander <alex_sam_compart>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by wl (Posted a comment)
  • -unavailable- added by alex_sam_compart (Submitted the item)
  • -unavailable- added by alex_sam_compart (Free)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 06 Nov 2016 05:07:31 AM UTCwlStatusNeed Info=>Fixed
      Open/ClosedOpen=>Closed
      Planned ReleaseNone=>2.7.1
    Wed 26 Oct 2016 03:05:50 PM UTCwlStatusNone=>Need Info
      Assigned toNone=>wl
    Wed 26 Oct 2016 02:35:31 PM UTCalex_sam_compartCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1