patchThe FreeType Project - Patches: patch #9152, Compilation of FreeType 2.7.0 with...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #9152: Compilation of FreeType 2.7.0 with XLC compiler fails

Submitter:  Alexander <alex_sam_compart>
Submitted:  Wed 26 Oct 2016 02:32:35 PM UTC
   
 
Category:  None Priority:  5 - Normal
Status:  Invalid Privacy:  Public
Assigned to:  wl Open/Closed:  Closed

Wed 26 Oct 2016 03:04:47 PM UTC, comment #3: 

Oops, parallel editing of the patch report.  OK, closing, adding my comment to the bug report.

Werner LEMBERG <wl>
Group administrator
Wed 26 Oct 2016 03:00:54 PM UTC, comment #2: 

[Since you don't provide a real patch a better location for your report would have been FreeType's bug tracker.]

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>
Group administrator
Wed 26 Oct 2016 02:36:49 PM UTC, comment #1: 

Please, close this request, since it is a duplicate of: https://savannah.nongnu.org/bugs/?49448. The former one was created in a wrong PATCH section.

Alexander <alex_sam_compart>
Wed 26 Oct 2016 02:32:35 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.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by alex_sam_compart (Submitted the item)
  • -email is unavailable- added by alex_sam_compart (FreeType 2.7.0 XLC)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-08 wl Open/ClosedOpen Closed
    2016-10-26 wl StatusNeed Info Invalid
    2016-10-26 wl StatusNone Need Info
        Assigned toNone wl
    2016-10-26 alex_sam_compart Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code