lgtm.
On 26 October 2012 11:26, Ulrich Weigand <[email protected]> wrote: > > Hello, > > system header files on PowerPC Linux contain the following macro: > > /* The weird 'i#*X' constraints on the following suppress a gcc > warning when __excepts is not a constant. Otherwise, they mean the > same as just plain 'i'. */ > > /* Inline definition for feraiseexcept. */ > # define feraiseexcept(__excepts) \ > ((__builtin_constant_p (__excepts) > \ > && ((__excepts) & ((__excepts)-1)) == 0 > \ > && (__excepts) != FE_INVALID) > \ > ? ((__excepts) != 0 > \ > ? (__extension__ ({ __asm__ __volatile__ > \ > ("mtfsb1 %s0" > \ > : : "i#*X"(__builtin_ffs (__excepts))); > \ > 0; })) > \ > : 0) > \ > : (feraiseexcept) (__excepts)) > > [ The GCC warning refers to a problem in certain older GCC version, where > you'd get a warning when using an "i" inline assembler constraint with a > non-constant operand -- even if the code could never be executed because it > was guarded by a __builtin_constant_p check. ] > > This code fails to compile with clang, since it doesn't understand the '*' > and '#' constraint modifiers. '*' means to ignore the rest of the > constraint alternative for purposes of computing register preferences, and > '#' means to ignore the rest of the constraint alternative as actual > constraint, and *only* consider it for computing register preferences. A > combination of both thus means ignoring the rest of the constraint > alternative completely for code generation (but apparently not necessarily > for purposes of semantical checks in the front end). > > The attached patch makes this code compile by just skipping '*' and '#' > when checking constraint validity in TargetInfo::validateInputConstraint > and TargetInfo::validateOutputConstraint, and ignoring the rest of the > alternative after '#' in SimplifyConstraint for code generation -- since > LLVM doesn't seem to use constraints for "register preferences" like GCC > does. (The latter routine already ignores '*' but keeps using the rest of > the alternative; this seems correct since those are still valid as > constraints.) > > Is this OK to commit? > > Thanks, > Ulrich > > (See attached file: diff-clang-asmconstraint) > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
