leonardchan added inline comments.
================ Comment at: lib/AST/ExprConstant.cpp:9323 + if (Value.isSigned() && Value.isMinSignedValue() && E->canOverflow() && + !HandleOverflow(Info, E, -Value.extend(Value.getBitWidth() + 1), + E->getType())) ---------------- ebevhan wrote: > Is signed fixed-point overflow actually considered undefined behavior? I'm > not familiar with what Embedded-C says about this. > > Also, this routine will likely print the wrong number for fixed-point values. I believe clause 4.1.3 states that if `FX_FRACT_OVERFLOW` or `FX_ACCUM_OVERFLOW` are set to `SAT` then overflow behavior on the respective types is saturation. Otherwise, overflow has undefined behavior by default or if the pragma is set to `DEFAULT`. ================ Comment at: lib/Sema/SemaExpr.cpp:3407 + + if (Literal.fixedPointType == FPT_ACCUM) { + if (isSigned) { ---------------- ebevhan wrote: > It should be possible to do this in a much more concise manner. In our port > we do this with a table lookup indexed by the type selection bits. Replaced with getters for corresponding type followed by getters for information about the bits. ================ Comment at: lib/Sema/SemaExpr.cpp:3483 + assert( + (fbits + ibits + 1 <= bit_width) && + "The total fractional, integral, and sign bits exceed the bit width"); ---------------- ebevhan wrote: > It does not feel like verifying this is the responsibility of the literal > parser. Right, this is taken care of in the target creation. Repository: rC Clang https://reviews.llvm.org/D46915 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits