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
|