hubert.reinterpretcast added a comment. In D109751#3136543 <https://reviews.llvm.org/D109751#3136543>, @qiucf wrote:
> Because the piece of code will be expanded to: > > long double _Complex x; > > if ((__builtin_types_compatible_p(__typeof(creall(x)), _Float128) > ? __isinff128(creall(x)) > : __builtin_isinf_sign(creall(x))) || > (__builtin_types_compatible_p(__typeof(cimagl(x)), _Float128) > ? __isinff128(cimagl(x)) > : __builtin_isinf_sign(cimagl(x)))) > return inf; > > which requires 'long double' (the same semantics to `__ibm128` by default) > and '_Float128' are compatible. Noting that the way the types are implemented in Clang, the conversion isn't the first problem with the above code. The types with the same representation are not considered "compatible" by Clang: extern char x[__builtin_types_compatible_p(long double, __ibm128) ? 1 : -1]; // errors extern char x[__builtin_types_compatible_p(long double, __ieee128) ? 1 : -1]; // errors too Compiler Explorer link: https://godbolt.org/z/fP3MfdexM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109751/new/ https://reviews.llvm.org/D109751 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
