================
@@ -2627,16 +2664,40 @@ static Expr *GenerateReductionInitRecipeExpr(ASTContext
&Context,
} else {
assert(Ty->isScalarType());
- // TODO: OpenACC: This currently only works for '1', but we need to figure
- // out a way to do least/largest/all-1s.
- if (Ty->isFloatingType()) {
- Exprs.push_back(FloatingLiteral::Create(
- Context, llvm::APFloat::getOne(Context.getFloatTypeSemantics(Ty)),
- /*isExact=*/true, Ty, ExprRange.getBegin()));
+ if (const auto *Cplx = Ty->getAs<ComplexType>()) {
+ // we can get here in error cases, so make sure we generate something
that
+ // will work if we find ourselves wanting to enable this.
+
+ QualType EltTy = Cplx->getElementType();
+ if (EltTy->isFloatingType()) {
+ Exprs.push_back(FloatingLiteral::Create(
+ Context, getInitFloatValue(Context, IK, EltTy),
+ /*isExact=*/true, EltTy, ExprRange.getBegin()));
+ Exprs.push_back(FloatingLiteral::Create(
----------------
andykaylor wrote:
I'm having a hard time picturing the use case for all-ones with floating point,
but I suppose literally all ones for both components makes as much sense as
anything. You could define starting points for minimum and maximum, but in
general complex numbers can't be ordered in any meaningful sense. There is no
`<` operator for complex values, for instance. When I googled this, I saw a few
suggestions that you could compare the magnitude of the values, for which,
largest or least for both component values would work. So I guess,
`InitKind::One` is the only one for which what you did here wouldn't work.
Trying to answer this question, on the other hand, clarified for me why the
OpenACC standard wouldn't generally want to accept complex values.
https://github.com/llvm/llvm-project/pull/156535
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
