Doris-Breakwater commented on issue #68722: URL: https://github.com/apache/doris/issues/68722#issuecomment-5978377479
Breakwater-GitHub-Analysis-Slot: slot_35f81dc4b4d8 **Triage:** This is a credible FE/BE correctness inconsistency for `DOUBLE` to `LARGEINT` constant folding in the reported 4.1.4 build. The issue is open and has no labels. The supplied SQL, version, and `EXPLAIN` observations are sufficient for a targeted regression case; no profile or additional logs are needed to identify this conversion mismatch. I reviewed the exact reported commit (`ad35a140c7f`) read-only, but did not run the SQL against a Doris cluster. **Verified in source:** Nereids' FE fold calls `checkedCastTo` for a literal cast ([fold visitor](https://github.com/apache/doris/blob/ad35a140c7f/fe/fe-core/src/main/java/org/apache/doris/nereids/rules/expression/rules/FoldConstantRuleOnFE.java#L499-L532)). For a `DoubleLiteral`, the integral cast path constructs `BigDecimal` from `value.toString()`, truncates it, and builds a `LargeIntLiteral` ([FE cast](https://github.com/apache/doris/blob/ad35a140c7f/fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/literal/FractionalLiteral.java#L47-L70)). `Double.toString(1e38)` is `1.0E38`, so this path yields `100000000000000000000000000000000000000`. The BE `DOUBLE` to integer path calls `CastToInt::from_float` ([dispatch](https://github.com/apache/doris/blob/ad35a140c7f/be/src/exprs/function/cast/cast_to_int.h#L73-L95)); that routine checks range, truncates the floating value, then casts the binary value to the destination integer ([conversion](https://github.com/apache /doris/blob/ad35a140c7f/be/src/exprs/function/cast/cast_to_basic_number_common.h#L182-L205)). The exact binary64 value of `1e38` is the reported `99999999999999997748809823456034029568`. A local Java numeric check produced both values from `new BigDecimal(Double.toString(d))` and `new BigDecimal(d)`, respectively. This accounts for the reported FE/BE difference; it does not establish whether any other cast types are affected. **Suggested next steps:** Add a paired constant-versus-column regression for this expression on the 4.1 branch, including `EXPLAIN`, plus negative values and values close to the `LARGEINT` bounds to check truncation and overflow behavior. Then align the FE fold with the BE conversion semantics while preserving strict/non-strict overflow behavior, and run the existing `DOUBLE` to `LARGEINT` cast suite. The existing suite covers column casts ([regression suite](https://github.com/apache/doris/blob/ad35a140c7f/regression-test/suites/function_p2/cast/to_int/from_float/test_cast_to_largeint_from_double.groovy)); this case needs an explicit fold-versus-execution assertion. For an immediate session-level mitigation, the reporter's `debug_skip_fold_constant = true` makes this expression execute on BE, but it disables constant folding more broadly and is best limited to affected queries pending a fix. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
