Pull in r354937 from upstream clang trunk (by Jörg Sonnenberger):

Pull in r354937 from upstream clang trunk (by Jörg Sonnenberger):

  Fix inline assembler constraint validation

  The current constraint logic is both too lax and too strict. It fails
  for input outside the [INT_MIN..INT_MAX] range, but it also
  implicitly accepts 0 as value when it should not. Adjust logic to
  handle both correctly.

  Differential Revision: https://reviews.llvm.org/D58649

Pull in r355491 from upstream clang trunk (by Hans Wennborg):

  Inline asm constraints: allow ICE-like pointers for the "n"
  constraint (PR40890)

  Apparently GCC allows this, and there's code relying on it (see bug).

  The idea is to allow expression that would have been allowed if they
  were cast to int. So I based the code on how such a cast would be
  done (the CK_PointerToIntegral case in
  IntExprEvaluator::VisitCastExpr()).

  Differential Revision: https://reviews.llvm.org/D58821

These should fix assertions and errors when using the inline assembly
"n" constraint in certain ways.

In case of devel/valgrind, a pointer was used as the input for the
constraint, which lead to "Assertion failed: (isInt() && "Invalid
accessor"), function getInt".

In case of math/secp256k1, a very large integer value was used as input
for the constraint, which lead to "error: value '4624529908474429119'
out of range for constraint 'n'".

PR:             236216, 236194
MFC after:      1 month
X-MFC-With:     r344779