[12] RFR: 8214059: Undefined behaviour in ADLC

Aleksey Shipilev shade at redhat.com
Mon Nov 19 22:19:15 UTC 2018

On 11/19/18 10:06 PM, Simon Tooke wrote:
> Hello,
> I tried compiling with -fsanitize=undefined, and it found some issues in
> ADLC, relying on undefined behaviour.
> Issue: https://bugs.openjdk.java.net/browse/JDK-8214059
> Fix:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/stooke/JDK-8214059/01/webrev/
> There are two issues: an incorrect C-style downcast (fixed by casting to
> the correct class),

I wonder if this should instead be:

   while ((param = inst._parameters.iter()) != NULL) {
-    OperandForm* opForm = (OperandForm*) inst._localNames[param];
+    OpClassForm* opForm = inst._localNames[param]->is_opclass();
+    assert(opForm != NULL, "sanity");
     encoding->add_parameter(opForm->_ident, param);

> and a reliance on undefined integer overflow
> behaviour (proposed fix by using long long arithmetic and a compile-time
> guard to check correct sizeof())

So, wait. Why do we redefine STATIC_ASSERT? Should we instead make the globally available
STATIC_ASSERT right if it has problems?

I think the canonical way to perform overflow-sensitive addition involves checking against INT_MAX.
Or, in this case, Expr::Max. Instead of this "long long" and STATIC_ASSERT mess, we can say:

int Expr::compute_max(const Expr *c1, const Expr *c2) {
  int v1 = c1->_max_value;
  int v2 = c2->_max_value;

  // Check for overflow without producing UB. If v2 is positive
  // and not larger than Max, the subtraction cannot underflow.
  assert(0 <= v2 && v2 <= Expr::Max, "sanity");
  if (v1 > Expr::Max - v2) {
    return Expr::Max;

  return v1 + v2;


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20181119/fce2678c/signature.asc>

More information about the hotspot-compiler-dev mailing list