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

 
 

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

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

Submitter:  Alexander <alex_sam_compart>
Submitted:  Wed 26 Oct 2016 02:35:31 PM UTC
   
 
Severity:  3 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.7.1

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

Fixed in git, thanks.

Werner LEMBERG <wl>
Group administrator
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>
Group administrator
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.)

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 (Free)
  •  

    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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-06 wl StatusNeed Info Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.7.1
    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-caa5.
    Corresponding source code