[clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

[mibintc]

Summary

This patch adds a new clang builtin, __arithmetic_fence. The purpose of the builtin is to provide the user fine control, at the expression level, over floating point optimization when -ffast-math (-ffp-model=fast) is enabled. We are also proposing a new clang builtin that provides access to this intrinsic, as well as a new clang command line option -fprotect-parens that will be implemented using this intrinsic.

This is the clang patch corresponding to https://reviews.llvm.org/D99675 which proposes a new llvm intrinsic llvm.arith.fence

Rationale

Some expression transformations that are mathematically correct, such as reassociation and distribution, may be incorrect when dealing with finite precision floating point. For example, these two expressions,

(a + b) + c
a + (b + c)

are equivalent mathematically in integer arithmetic, but not in floating point. In some floating point (FP) models, the compiler is allowed to make these value-unsafe transformations for performance reasons, even when the programmer uses parentheses explicitly. But the compiler must always honor the parentheses implied by __arithmetic_fence, regardless of the FP model settings.

Under –ffp-model=fast, __arithmetic_fence provides a way to partially enforce ordering in an FP expression.

Original expression	Transformed expression	Permitted?
(a + b) + c	a + (b + c)	Yes!
__arithmetic_fence(a + b) + c	a + (b + c)	No!

NOTE: The __arithmetic_fence serves no purpose in value-safe FP modes like –ffp-model=precise: FP expressions are already strictly ordered.

Motivation:

• The new clang builtin provides clang compatibility with the Intel C++ compiler builtin __fence which has similar semantics, and likewise enables implementation of the option -fprotect-parens.
• The new builtin provides the clang programmer control over floating point optimizations at the expression level.
• The gnu fortran compiler, gfortran, likewise supports -fprotect-parens

Requirements for __arithmetic_fence:

• There is one operand. The operand type must be scalar floating point, complex floating point or vector thereof.
• The return type is the same as the operand type.
• The return value is equivalent to the operand.
• The invocation of __arithmetic_fence is not a C/C++ constant expression, even if the operands are constant.

New option -fprotect-parens

• Determines whether the optimizer honors parentheses when floating-point expressions are evaluated
• Option defaults to fno-protect-parens

[mibintc]

This is a minor change with only formatting changes, this patch is not yet ready for review, only discussion.
Together with the llvm parent patch, this simple program can now run end-to-end

clang -c -ffast-math test.c

float addF(float x, float y) {
  return __arithmetic_fence(x + y);
}

[kpn]

I thought that adding a new fence required changing every optimization pass in LLVM. That's why the constrained intrinsics were implemented they way they are where no fence is needed.

Aren't you going to have miscompiles using this new fence until all that optimization work is done? Or am I wrong? @andrew.w.kaylor?

[kpn]

In D100118#2695365, @kpn wrote:

I thought that adding a new fence required changing every optimization pass in LLVM. That's why the constrained intrinsics were implemented they way they are where no fence is needed.

Aren't you going to have miscompiles using this new fence until all that optimization work is done? Or am I wrong? @andrew.w.kaylor?

Perhaps there is no problem. I'm looking at D99675 now.

[kpn]

clang/lib/CodeGen/CGBuiltin.cpp

2844

Does this say that the fence will be silently dropped if any of the fast math flags are disabled? Silently dropping something used for correctness makes me nervous. Is there a case where all of these flags are required for correct behavior of the fence?

[mibintc]

clang/lib/CodeGen/CGBuiltin.cpp

2844

Yes that is the idea, the clang builtin is only meaningful for float operations when -ffast-math is enabled. If fast math isn't enabled then the operations should already be performed strictly. I didn't have "isFast", should rewrite with isFast to make it easier to understand

[mibintc]

clang/lib/CodeGen/CGBuiltin.cpp

2844

Oops I'm wrong. @kbsmith1 tells me only the reassoc bit is interesting. i'll need to fix this in the documentation etc. Thanks for your careful reading.

[mibintc]

clang/lib/CodeGen/CGBuiltin.cpp

2844

BTW in the options parsing, any of the unsafe fp math options freciprocal-math, fsigned-zeros and fapprox-func have the effect of enabing LangOptions.AllowFPReassoc. This is in the file Options.td

[mibintc]

I think this patch is complete except it needs to wait until the parent patch is finished. Also some re-factoring may be desireable, I'll add some inline comments about that.

[mibintc]

some inline comments for reviewers

clang/include/clang/Basic/TargetInfo.h

1162 ↗

(On Diff #340598)

There's no good place to diagnose when LangOptions and TargetOptions conflict, I see "conflict" diagnostics being emitted in clang/CodeGen when creating the func or module, which seems wrong to me. On the other hand, the "adjust" function makes a good place to do the reconciliation I think. This is the change that could be pulled out in a refactoring and committed prior to this patch. What do you think?

clang/include/clang/Driver/Options.td

4300 ↗

(On Diff #340598)

@jansvoboda11 This is a gfortran option, but I don't think there's a way to allow the same option spelling for gfortran and clang. Other clang options, like -short-enum, also have been pulled out of gfortran group, and the gfortran option test is an expected-fail test.

[mibintc]

Rebased the patch. The parent patch is updated and corrected as well, and tests can run end-to-end.

Ready for your code review, thanks!

[mibintc]

I made a change to ActOnParenExpr to check that the parenthesized expression is not an lvalue before inserting the call to builtin __arithmetic_fence

[aaron.ballman]

clang/docs/UsersManual.rst

1484 ↗

(On Diff #349644)

We may need to expound on what "honor parentheses" means. The summary for the patch mentions (a + b) + c, but does this also mean (x + y) * z could be interpreted as x + (y * z)? What about for non-arithmetic expressions involving parentheses, like (float1 == float2 && float1 == float3) || blah()?

clang/include/clang/Basic/DiagnosticSemaKinds.td

8412–8413

clang/include/clang/Basic/TargetInfo.h

1162 ↗

(On Diff #340598)

I think this makes sense, but should be done as a separate patch.

1427 ↗

(On Diff #349644)

clang/include/clang/Driver/Options.td

1757 ↗

(On Diff #349644)

Should this option also be exposed to clang-cl (should it be a CoreOption)?

clang/lib/CodeGen/CGBuiltin.cpp

2839

Please spell out the type here.

clang/lib/Driver/ToolChains/Clang.cpp

2712–2714 ↗

(On Diff #349644)

Is this code needed for some reason?

clang/lib/Sema/SemaChecking.cpp

6391

What if there is no argument given?

6394

6396–6399

6405–6406

This looks like it should move up a bit.

clang/lib/Sema/SemaCoroutine.cpp

387 ↗

(On Diff #349644)

I am fine ignoring this clang-format issue; I think your formatting is far more readable.

clang/lib/Sema/SemaExpr.cpp

4026 ↗

(On Diff #349644)

Do you have to worry about vector types here as well?

4027 ↗

(On Diff #349644)

One worry I have about this is that the AST will be a bit mysterious for people writing AST matchers. The source code will have parens in it, but the AST will have a ParenExpr node or not only depending on the language options. This may also cause problems for other parts of the code that are checking for properly-parenthesized expressions (like && and || within the same expression), so we should probably have a test case like:

bool func(float f1, float f2, float f3) {
  return (f1 == f2 && f1 == f3) || f2 == f3; // Should not warn here
}

6535 ↗

(On Diff #349644)

Because this cannot fail, is there a benefit to returning an ExprResult rather than an Expr * as before? Then you can remove a bunch of get() calls elsewhere that look suspicious because they're not checking for a failure.

clang/test/Sema/arithmetic-fence-builtin.c

46

You should add a test that we diagnose things like:

__arithmetic_fence();
__arithmetic_fence(1, 2);

I think it would also be useful to add an AST test (to clang\test\AST) that shows the call expression AST nodes being inserted for paren expressions.

[mibintc]

question for @aaron.ballman

clang/docs/UsersManual.rst

1484 ↗

(On Diff #349644)

Thanks for your review. Just a quick first response, What do you mean "(x + y) * z could be reinterpreted as x + (y * z)" -- not following you here?

[aaron.ballman]

clang/docs/UsersManual.rst

1484 ↗

(On Diff #349644)

"whether the optimizer honors the parentheses" reads to me like (x + y) * z could either honor or not honor the parentheses, so that could either evaluate as (x + y) * z or x + (y * z) depending on whether the parens are honored or not.

[joerg]

clang/docs/UsersManual.rst

1484 ↗

(On Diff #349644)

I would prefer to start with a description of the intended behavior from first principles. The logic here should not be tied to fast-mode as it also overlaps a lot with the formulation of fused multiply-add expressions and certainly should have specified behavior on the interaction. I'm also not sure about what you mean with value-safe FP modes, IIRC the C/C++ standard explicitly leave it open in which order floating point expressions of the same operand priority are evaluated.

I'm also a bit puzzled why __arithmethic_fence should not be considered a constant expression?

[mibintc]

Reply to @joerg proposing new wording for the option description

clang/docs/UsersManual.rst

1484 ↗

(On Diff #349644)

I would prefer to start with a description of the intended behavior from first principles. The logic here should not be tied to fast-mode as it also overlaps a lot with the formulation of fused multiply-add expressions and certainly should have specified behavior on the interaction. I'm also not sure about what you mean with value-safe FP modes, IIRC the C/C++ standard explicitly leave it open in which order floating point expressions of the same operand priority are evaluated.

@joerg Thank you. What do you think about this modified description of the option:
option:: -f[no-]protect-parens:

This option pertains to floating-point types, complex types with floating-point components, and vectors of these types. Some arithmetic expression transformations that are mathematically correct and permissible according to the C and C++ language standards may be incorrect when dealing with floating-point types, such as reassociation and distribution. Further, the optimizer may ignore parentheses when computing arithmetic expressions in circumstances where the parenthesized and unparenthesized expression express the same mathematical value. For example (a+b)+c is the same mathematical value as a+(b+c), but the optimizer is free to evaluate the additions in any order regardless of the parentheses. When enabled, this option forces the optimizer to honor the order of operations with respect to parentheses in all circumstances.

Note that floating-point contraction (option -ffp-contract=) is disabled when -fprotect-parens is enabled. Also note that in safe floating-point modes, such as -ffp-model=precise or -ffp-model=strict, this option has no effect because the optimizer is prohibited from making unsafe transformations.

I'm also a bit puzzled why __arithmethic_fence should not be considered a constant expression?

I can see your point about that. I was leery of steering into constant folding waters but I will make that change.

[joerg]

Thanks, that's better. The clang front-end option is not directly relevant for the semantic of the intrinsic, so it would be better to explicitly specify it was not being fuseable unless the operand degenerates into a single operand. Otherwise the specification sounds reasonable.

[mibintc]

This patch addresses almost all the review comments, not yet sure about @aaron.ballman 's question about CoreOptions

[aaron.ballman]

In D100118#2833864, @mibintc wrote:

This patch addresses almost all the review comments, not yet sure about @aaron.ballman 's question about CoreOptions

FWIW, I'm fine addressing that comment in a follow-up. Also, it looks like the Clang changes didn't make it into the latest updated patch.

[mibintc]

The patch I uploaded for review yesterday wasn't correct, not sure what happened. This one looks better.

[mibintc]

A couple inline replies to go along with the updated patch

clang/include/clang/Driver/Options.td

1757 ↗

(On Diff #349644)

I don't know the answer to this, do you have a recommendation?

clang/lib/Sema/SemaChecking.cpp

6396–6399

I found there was a boolean function, so i got rid of the lambda.

clang/lib/Sema/SemaCoroutine.cpp

294 ↗

(On Diff #354009)

I moved this function to public because another file is also using the same logic

clang/lib/Sema/SemaExpr.cpp

4026 ↗

(On Diff #349644)

Oh yes, i didn't get this one.

4027 ↗

(On Diff #349644)

I added an AST test case

[aaron.ballman]

clang/include/clang/Driver/Options.td

1757 ↗

(On Diff #349644)

I think this would be useful for clang-cl users, so I'd recommend adding it to CoreOption unless there's a reason not to.

clang/lib/AST/ExprConstant.cpp

9309–9311

Under what circumstances could we get here? (Given that this is within PointerExprEvaluator, I would have assumed this would be unreachable code.)

clang/lib/CodeGen/CGBuiltin.cpp

2841

May as well fix this clang-format issue.

clang/lib/Sema/SemaExpr.cpp

6568 ↗

(On Diff #354009)

Might as well hit this clang-format warning too.

clang/test/AST/arithmetic-fence-builtin.c

34 ↗

(On Diff #354009)

Does the (a + b) still have an AST node for the ParenExpr?

[aaron.ballman]

clang/test/AST/arithmetic-fence-builtin.c

34 ↗

(On Diff #354009)

Nevermind, it won't, it'll have the CallExpr node.

I think this may be somewhat surprising to folks who use AST matchers or -ast-print, but I'm not certain that there's a better way to implement this that would keep the ParenExpr in the AST for full source fidelity, so I think this is reasonable enough.

[mibintc]

Respond to @aaron.ballman 's review

[mibintc]

some inline replies. I think this is all set now.

clang/lib/Sema/SemaExpr.cpp

4026 ↗

(On Diff #349644)

Yes thanks, i also added a little test case for this

[mibintc]

Rebase

[aaron.ballman]

In general, I think this looks good (I did find one minor nit that removes an include, but that can be fixed as you land). There's an open question for @jansvoboda11 and it'd be nice to hear if @joerg agrees their concerns are fully addressed, so please wait a bit before landing to give them time to respond with any concerns or feedback.

clang/include/clang/Driver/Options.td

4300 ↗

(On Diff #340598)

@jansvoboda11 -- do you have any ideas here? Or is the current approach fine (and we can remove this commented-out line)?

clang/include/clang/Sema/Sema.h

5375

I think it might make sense to pass in an unsigned rather than a Builtin::ID so that we can avoid including Builtins.h (we do this sort of dance to avoid including headers elsewhere as well). WDYT?

[mibintc]

buildbot fails on lldb need to update this patch

clang/include/clang/Basic/Builtins.def

 BUILTIN(__xray_customevent, "vcC*z", "")
 BUILTIN(__xray_typedevent, "vzcC*z", "")
 
 // Win64-compatible va_list functions
 BUILTIN(__builtin_ms_va_start, "vc*&.", "nt")
 BUILTIN(__builtin_ms_va_end, "vc*&", "n")
 BUILTIN(__builtin_ms_va_copy, "vc*&c*&", "n")
 
+// Arithmetic Fence: to prevent FP reordering and reassociation optimizations
+LANGBUILTIN(__arithmetic_fence, "v.", "t", ALL_LANGUAGES)
+
 #undef BUILTIN
 #undef LIBBUILTIN
 #undef LANGBUILTIN

clang/include/clang/Basic/DiagnosticSemaKinds.td

 def err_cast_pointer_to_non_pointer_int : Error<
   "pointer cannot be cast to type %0">;
 def err_cast_to_bfloat16 : Error<"cannot type-cast to __bf16">;
 def err_cast_from_bfloat16 : Error<"cannot type-cast from __bf16">;
 def err_typecheck_expect_scalar_operand : Error<
   "operand of type %0 where arithmetic or pointer type is required">;
 def err_typecheck_cond_incompatible_operands : Error<
   "incompatible operand types%diff{ ($ and $)|}0,1">;
+def err_typecheck_expect_flt_or_vector : Error<
+  "operand of type %0 where floating, complex or "
+  "a vector of such types is required (%0 invalid)">;
 def err_cast_selector_expr : Error<
   "cannot type cast @selector expression">;
 def ext_typecheck_cond_incompatible_pointers : ExtWarn<
   "pointer type mismatch%diff{ ($ and $)|}0,1">,
   InGroup<DiagGroup<"pointer-type-mismatch">>;
 def ext_typecheck_cond_pointer_integer_mismatch : ExtWarn<
   "pointer/integer type mismatch in conditional expression"
   "%diff{ ($ and $)|}0,1">,

clang/include/clang/Sema/Sema.h

public:
   ExprResult ActOnCallExpr(Scope *S, Expr *Fn, SourceLocation LParenLoc,
                            MultiExprArg ArgExprs, SourceLocation RParenLoc,
                            Expr *ExecConfig = nullptr);
   ExprResult BuildCallExpr(Scope *S, Expr *Fn, SourceLocation LParenLoc,
                            MultiExprArg ArgExprs, SourceLocation RParenLoc,
                            Expr *ExecConfig = nullptr,
                            bool IsExecConfig = false,
                            bool AllowRecovery = false);
   enum class AtomicArgumentOrder { API, AST };
   ExprResult
   BuildAtomicExpr(SourceRange CallRange, SourceRange ExprRange,
                   SourceLocation RParenLoc, MultiExprArg Args,
                   AtomicExpr::AtomicOp Op,
                   AtomicArgumentOrder ArgOrder = AtomicArgumentOrder::API);
   ExprResult
   BuildResolvedCallExpr(Expr *Fn, NamedDecl *NDecl, SourceLocation LParenLoc,
                         ArrayRef<Expr *> Arg, SourceLocation RParenLoc,
public:
   ExprResult SemaBuiltinShuffleVector(CallExpr *TheCall);
   ExprResult SemaConvertVectorExpr(Expr *E, TypeSourceInfo *TInfo,
                                    SourceLocation BuiltinLoc,
                                    SourceLocation RParenLoc);
 
 private:
   bool SemaBuiltinPrefetch(CallExpr *TheCall);
   bool SemaBuiltinAllocaWithAlign(CallExpr *TheCall);
+  bool SemaBuiltinArithmeticFence(CallExpr *TheCall);
   bool SemaBuiltinAssume(CallExpr *TheCall);
   bool SemaBuiltinAssumeAligned(CallExpr *TheCall);
   bool SemaBuiltinLongjmp(CallExpr *TheCall);
   bool SemaBuiltinSetjmp(CallExpr *TheCall);
   ExprResult SemaBuiltinAtomicOverloaded(ExprResult TheCallResult);
   ExprResult SemaBuiltinNontemporalOverloaded(ExprResult TheCallResult);
   ExprResult SemaAtomicOpsOverloaded(ExprResult TheCallResult,
                                      AtomicExpr::AtomicOp Op);

clang/lib/AST/ExprConstant.cpp

while (true) {
       if (--NElems == 0)
         return true;
       if (!HandleLValueArrayAdjustment(Info, E, Src, T, Direction) ||
           !HandleLValueArrayAdjustment(Info, E, Dest, T, Direction))
         return false;
     }
   }
 
+  case Builtin::BI__arithmetic_fence:
+    return false;
+
   default:
     break;
   }
 
   return visitNonBuiltinCallExpr(E);
 }
 
 static bool EvaluateArrayNewInitList(EvalInfo &Info, LValue &This,

clang/lib/CodeGen/CGBuiltin.cpp

RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl GD, unsigned BuiltinID,
   case Builtin::BI__builtin_assume: {
     if (E->getArg(0)->HasSideEffects(getContext()))
       return RValue::get(nullptr);
 
     Value *ArgValue = EmitScalarExpr(E->getArg(0));
     Function *FnAssume = CGM.getIntrinsic(Intrinsic::assume);
     return RValue::get(Builder.CreateCall(FnAssume, ArgValue));
   }
+  case Builtin::BI__arithmetic_fence: {
+    Value *ArgValue = EmitScalarExpr(E->getArg(0));
+    QualType ArgType = E->getArg(0)->getType();
+    auto FMF = Builder.getFastMathFlags();
+    if (FMF.allowReassoc() && FMF.noNaNs() && FMF.noInfs() &&
+        FMF.noSignedZeros() && FMF.allowReciprocal() && FMF.allowContract() &&
+        FMF.approxFunc())
+      return RValue::get(
+          Builder.CreateArithmeticFence(ArgValue, ConvertType(ArgType)));
+    return RValue::get(ArgValue);
+  }
   case Builtin::BI__builtin_bswap16:
   case Builtin::BI__builtin_bswap32:
   case Builtin::BI__builtin_bswap64: {
     return RValue::get(emitUnaryBuiltin(*this, E, Intrinsic::bswap));
   }
   case Builtin::BI__builtin_bitreverse8:
   case Builtin::BI__builtin_bitreverse16:
   case Builtin::BI__builtin_bitreverse32:

clang/lib/Sema/SemaChecking.cpp

Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl, unsigned BuiltinID,
   case Builtin::BI__builtin_alloca_with_align:
     if (SemaBuiltinAllocaWithAlign(TheCall))
       return ExprError();
     LLVM_FALLTHROUGH;
   case Builtin::BI__builtin_alloca:
     Diag(TheCall->getBeginLoc(), diag::warn_alloca)
         << TheCall->getDirectCallee();
     break;
+  case Builtin::BI__arithmetic_fence:
+    if (SemaBuiltinArithmeticFence(TheCall))
+      return ExprError();
+    break;
   case Builtin::BI__assume:
   case Builtin::BI__builtin_assume:
     if (SemaBuiltinAssume(TheCall))
       return ExprError();
     break;
   case Builtin::BI__builtin_assume_aligned:
     if (SemaBuiltinAssumeAligned(TheCall))
       return ExprError();
bool Sema::SemaBuiltinPrefetch(CallExpr *TheCall) {
   // constant integers.
   for (unsigned i = 1; i != NumArgs; ++i)
     if (SemaBuiltinConstantArgRange(TheCall, i, 0, i == 1 ? 1 : 3))
       return true;
 
   return false;
 }
 
+/// SemaBuiltinArithmeticFence - Handle __arithmetic_fence.
+bool Sema::SemaBuiltinArithmeticFence(CallExpr *TheCall) {
+  Expr *Arg = TheCall->getArg(0);
+  if (Arg->isInstantiationDependent())
+    return false;
+
+  const QualType ArgTy = TheCall->getArg(0)->getType();
+  bool IsFloating = [&]() {
+    if (const VectorType *VT = dyn_cast<VectorType>(ArgTy.getCanonicalType()))
+      return VT->getElementType().getTypePtr()->isFloatingType();
+    if (const ComplexType *CT = dyn_cast<ComplexType>(ArgTy.getCanonicalType()))
+      return CT->getElementType().getTypePtr()->isFloatingType();
+    return ArgTy->isFloatingType();
+  }();
+  if (!IsFloating)
+    return Diag(TheCall->getEndLoc(), diag::err_typecheck_expect_flt_or_vector)
+           << ArgTy;
+  if (checkArgCount(*this, TheCall, 1))
+    return true;
+  TheCall->setType(ArgTy);
+  return false;
+}
+
 /// SemaBuiltinAssume - Handle __assume (MS Extension).
 // __assume does not evaluate its arguments, and should warn if its argument
 // has side effects.
 bool Sema::SemaBuiltinAssume(CallExpr *TheCall) {
   Expr *Arg = TheCall->getArg(0);
   if (Arg->isInstantiationDependent()) return false;
 
   if (Arg->HasSideEffects(Context))

clang/test/CodeGen/arithmetic-fence-builtin.c

+// Test with fast math
+// RUN: %clang_cc1 -triple i386-pc-linux-gnu -emit-llvm \
+// RUN: -menable-no-infs -menable-no-nans -menable-unsafe-fp-math \
+// RUN: -fno-signed-zeros -mreassociate -freciprocal-math \
+// RUN: -ffp-contract=fast -fno-rounding-math -ffast-math -ffinite-math-only \
+// RUN: -o - %s | FileCheck %s
+//
+// Test with fast math, showing incomplete implementaton for Complex
+// this test fails.
+// RUN: %clang_cc1 -triple i386-pc-linux-gnu -emit-llvm \
+// RUN: -menable-no-infs -menable-no-nans -menable-unsafe-fp-math \
+// RUN: -fno-signed-zeros -mreassociate -freciprocal-math \
+// RUN: -ffp-contract=fast -fno-rounding-math -ffast-math -ffinite-math-only \
+// RUN: -o - -DSHOWBUG %s | FileCheck %s
+//
+// TBD: Add test without fast flags showing llvm intrinsic not created
+int v;
+int addit(float a, float b) {
+//CHECK: define {{.*}} @addit(float %a, float %b) #0 {
+#ifdef SHOWBUG
+  // Assertion fail in clang when try to Emit complex expression
+  // Complex should be supported.
+  _Complex double cd, cd1;
+  cd = __arithmetic_fence(cd1);
+#endif
+  // Vector should be supported.
+  typedef float __v2f32 __attribute__((__vector_size__(8)));
+  __v2f32 vec1, vec2;
+  vec1 = __arithmetic_fence(vec2);
+  // CHECK: call fast <2 x float> @llvm.arithmetic.fence.v2f32
+
+  v = __arithmetic_fence(a + b);
+  // CHECK: call fast float @llvm.arithmetic.fence.f32(float %add)
+  return 0;
+}

clang/test/Sema/arithmetic-fence-builtin.c

+// RUN: %clang_cc1 -triple i386-pc-linux-gnu -emit-llvm -o - -verify -x c++ %s
+int v;
+template <typename T> T addT(T a, T b) {
+  T *q = __arithmetic_fence(&a);
+  // expected-error@-1 {{operand of type 'float *' where floating, complex or a vector of such types is required ('float *' invalid)}}
+  // expected-error@-2 {{operand of type 'int *' where floating, complex or a vector of such types is required ('int *' invalid)}}
+  return __arithmetic_fence(a + b);
+  // expected-error@-1 {{operand of type 'int' where floating, complex or a vector of such types is required ('int' invalid)}}
+}
+int addit(int a, int b) {
+  float x, y;
+  typedef struct {
+    int a, b;
+  } stype;
+  stype s;
+  s = __arithmetic_fence(s);    // expected-error {{operand of type 'stype' where floating, complex or a vector of such types is required ('stype' invalid)}}
+  x = __arithmetic_fence(x, y); // expected-error {{too many arguments to function call, expected 1, have 2}}
+  // Complex is supported.
+  _Complex double cd, cd1;
+  cd = __arithmetic_fence(cd1);
+  // Vector is supported.
+  typedef float __v4hi __attribute__((__vector_size__(8)));
+  __v4hi vec1, vec2;
+  vec1 = __arithmetic_fence(vec2);
+
+  v = __arithmetic_fence(a + b); // expected-error {{operand of type 'int' where floating, complex or a vector of such types is required ('int' invalid)}}
+  float f = addT<float>(a, b);   // expected-note {{in instantiation of function template specialization 'addT<float>' requested here}}
+  int i = addT<int>(1, 2);       // expected-note {{in instantiation of function template specialization 'addT<int>' requested here}}
+  constexpr float d = 1.0 + 2.0;
+  constexpr float c = __arithmetic_fence(1.0 + 2.0);
+  // expected-error@-1 {{constexpr variable 'c' must be initialized by a constant expression}}
+  return 0;
+}