jcranmer-intel wrote:
> Should this only apply in C23 mode? Standard behavior until C23 is that
> `_Float16` promotes to `double`. What about C++?
I can't find any reference in older versions of C or TS 18661-3 that suggests
that `_Float16` is promoted to `double`. The wording of 6.5.2.2 used
jcranmer-intel wrote:
> [N2844](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2844.pdf), as
> linked by OP, references the removed language that you are looking for.
Doing some more spelunking, no released version of the TS ever had default
argument promotion. The change to the TS was done
https://github.com/jcranmer-intel commented:
There's probably some useful discussion to be had about how aggressive
`-ffinite-math-only` at the clang level should be wrt lowering to `nnan`/`ninf`
in the IR.
It may be worth deferring the ReturnInst changes (but landing everything else)
until t
@@ -287,9 +288,47 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo &Op);
- QualType getPromotionType(QualType Ty) {
+ QualType GetHigherPrecisionFPType(QualType ElementType) {
+
@@ -287,9 +288,47 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo &Op);
- QualType getPromotionType(QualType Ty) {
+ QualType GetHigherPrecisionFPType(QualType ElementType) {
+
@@ -310,6 +310,13 @@ class ComplexExprEmitter
CGF.getContext().getFloatTypeSemantics(ElementType);
const llvm::fltSemantics &HigherElementTypeSemantics =
CGF.getContext().getFloatTypeSemantics(HigherElementType);
+// Check that LongDouble Size > Double S
@@ -310,6 +310,13 @@ class ComplexExprEmitter
CGF.getContext().getFloatTypeSemantics(ElementType);
const llvm::fltSemantics &HigherElementTypeSemantics =
CGF.getContext().getFloatTypeSemantics(HigherElementType);
+// Check that LongDouble Size > Double S
https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/81514
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jcranmer-intel wrote:
> I'd like to see this change land, but with the "-mdaz-ftz" option removed
> (because I don't think it's useful). That would fix the critical problem of
> fast-math infecting shared libraries with the ftz setting, and we could
> straighten out the other problems, which a
jcranmer-intel wrote:
> > > I'd like to see this change land, but with the "-mdaz-ftz" option removed
> > > (because I don't think it's useful). That would fix the critical problem
> > > of fast-math infecting shared libraries with the ftz setting, and we
> > > could straighten out the other p
https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/81108
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -982,13 +1024,18 @@ ComplexPairTy ComplexExprEmitter::EmitBinDiv(const
BinOpInfo &Op) {
llvm::Value *OrigLHSi = LHSi;
if (!LHSi)
LHSi = llvm::Constant::getNullValue(RHSi->getType());
-if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Fortran)
+Qua
@@ -283,9 +283,48 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo &Op);
- QualType getPromotionType(QualType Ty) {
+ QualType GetHigherPrecisionFPType(QualType ElementType) {
+
@@ -1847,19 +1847,50 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
+.. option:: -fcomplex-arithmetic=:
+
+ This option specifies the impl
jcranmer-intel wrote:
> It matters more for AMDGPU, where we need to care because some instructions
> just don't respect denormals. We legalize some operations differently
> depending on the mode
But the shared library stuff isn't an issue for AMDGPU, right?
https://github.com/llvm/llvm-proje
@@ -1847,19 +1847,50 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
+.. option:: -fcomplex-arithmetic=:
+
+ This option specifies the impl
@@ -283,9 +283,46 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo &Op);
- QualType getPromotionType(QualType Ty) {
+ QualType HigherPrecisionTypeForComplexArithmetic(QualType E
@@ -982,13 +1022,18 @@ ComplexPairTy ComplexExprEmitter::EmitBinDiv(const
BinOpInfo &Op) {
llvm::Value *OrigLHSi = LHSi;
if (!LHSi)
LHSi = llvm::Constant::getNullValue(RHSi->getType());
-if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Fortran)
+Qua
@@ -1847,19 +1847,33 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mat
@@ -1114,8 +1114,6 @@ static bool handleIntegerToComplexFloatConversion(Sema
&S, ExprResult &IntExpr,
if (IntTy->isIntegerType()) {
QualType fpTy = ComplexTy->castAs()->getElementType();
IntExpr = S.ImpCastExprToType(IntExpr.get(), fpTy, CK_IntegralToFloating);
-
@@ -0,0 +1,143 @@
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - |
FileCheck %s --check-prefix=X86
+
+// Check that for 'F _Complex + int' (F = real floating-point type), we emit an
+// implicit cast from 'int' to 'F', but NOT to 'F _Complex' (i.e. that
https://github.com/jcranmer-intel edited
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcranmer-intel commented:
I haven't attempted to make my way through the sema changes yet, but some
comments already:
https://github.com/llvm/llvm-project/pull/78503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://li
https://github.com/jcranmer-intel created
https://github.com/llvm/llvm-project/pull/80475
This fixes https://github.com/llvm/llvm-project/issues/57589, and aligns Clang
with the behavior of current versions of gcc. There is a new option, -mdaz-ftz,
to control the linking of the file that sets
jcranmer-intel wrote:
> I think there is a bit of a problematic interaction with
> getDenormalModeForType
> [here](https://github.com/llvm/llvm-project/blob/7a94acb2da5b20d12f13f3c5f4eb0f3f46e78e73/clang/lib/Driver/ToolChains/Linux.cpp#L838C8-L838C37).
> "-shared" is (should be) a flag used on
jcranmer-intel wrote:
> (Sidenote: "dynamic" isn't even
> [documented](https://clang.llvm.org/docs/UsersManual.html#cmdoption-fdenormal-fp-math)).
It's not a selectable enum of the Clang `-fdenormal-fp-math` flag, but it is
one for the LLVM function attribute `denormal-fp-math`.
https://githu
@@ -2807,6 +2807,9 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
bool StrictFPModel = false;
StringRef Float16ExcessPrecision = "";
StringRef BFloat16ExcessPrecision = "";
+ StringRef CxLimitedRange = "NoCxLimiteRange";
https://github.com/jcranmer-intel edited
https://github.com/llvm/llvm-project/pull/68820
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcranmer-intel commented:
I'm sure Aaron would appreciate me also saying that these changes would require
addition to the clang release notes. 😄
https://github.com/llvm/llvm-project/pull/68820
___
cfe-commits mailing list
cfe-commi
@@ -846,6 +859,31 @@ void Parser::HandlePragmaFEnvRound() {
Actions.ActOnPragmaFEnvRound(PragmaLoc, RM);
}
+void Parser::HandlePragmaCXLimitedRange() {
+ assert(Tok.is(tok::annot_pragma_cx_limited_range));
+ tok::OnOffSwitch OOS = static_cast(
+ reinterpret_cast(Tok.g
@@ -846,6 +865,105 @@ ComplexPairTy ComplexExprEmitter::EmitBinMul(const
BinOpInfo &Op) {
return ComplexPairTy(ResR, ResI);
}
+ComplexPairTy ComplexExprEmitter::EmitAlgebraicDiv(llvm::Value *LHSr,
+ llvm::Value *LHSi,
+
@@ -28,4 +28,6 @@ OPTION(FPEvalMethod, LangOptions::FPEvalMethodKind, 2,
AllowApproxFunc)
OPTION(Float16ExcessPrecision, LangOptions::ExcessPrecisionKind, 2,
FPEvalMethod)
OPTION(BFloat16ExcessPrecision, LangOptions::ExcessPrecisionKind, 2,
Float16ExcessPrecision)
OPTION(Mat
@@ -846,6 +865,105 @@ ComplexPairTy ComplexExprEmitter::EmitBinMul(const
BinOpInfo &Op) {
return ComplexPairTy(ResR, ResI);
}
+ComplexPairTy ComplexExprEmitter::EmitAlgebraicDiv(llvm::Value *LHSr,
+ llvm::Value *LHSi,
+
@@ -846,6 +865,105 @@ ComplexPairTy ComplexExprEmitter::EmitBinMul(const
BinOpInfo &Op) {
return ComplexPairTy(ResR, ResI);
}
+ComplexPairTy ComplexExprEmitter::EmitAlgebraicDiv(llvm::Value *LHSr,
+ llvm::Value *LHSi,
+
https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/66381
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Joshua Cranmer
Date: 2023-09-13T08:57:10-07:00
New Revision: bf492371033378cec4c0443a3f87db0f818bbade
URL:
https://github.com/llvm/llvm-project/commit/bf492371033378cec4c0443a3f87db0f818bbade
DIFF:
https://github.com/llvm/llvm-project/commit/bf492371033378cec4c0443a3f87db0f818bbade.diff
@@ -2313,14 +2313,20 @@ RValue CodeGenFunction::EmitBuiltinExpr(const
GlobalDecl GD, unsigned BuiltinID,
FD->hasAttr() ? 0 : BuiltinID;
bool ErrnoOverriden = false;
- // True if math-errno is overriden via the
+ bool ErrnoOverrideValue = false;
jcra
Author: Joshua Cranmer
Date: 2023-03-13T14:20:24-04:00
New Revision: bcad161db3e69e27736c975ef5eeac60c96dcc97
URL:
https://github.com/llvm/llvm-project/commit/bcad161db3e69e27736c975ef5eeac60c96dcc97
DIFF:
https://github.com/llvm/llvm-project/commit/bcad161db3e69e27736c975ef5eeac60c96dcc97.diff
https://github.com/jcranmer-intel updated
https://github.com/llvm/llvm-project/pull/80475
>From fc0507f013f556cc7c49a38f22d14578311f1f42 Mon Sep 17 00:00:00 2001
From: Joshua Cranmer
Date: Fri, 2 Feb 2024 10:35:29 -0800
Subject: [PATCH 1/3] Disable FTZ/DAZ when compiling shared libraries by
de
jcranmer-intel wrote:
I did a thorough investigation into how the
`denormal-fp-math=preserve-sign,preserve-sign` attribute affects the resulting
IR for all of the SPEC benchmarks (which actually do run into subnormals), and
the basic summary I found is that the only differences I found were th
@@ -1569,6 +1569,40 @@
// RUN:--gcc-toolchain="" \
// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NOCRTFASTMATH %s
+// Don't link crtfastmath.o with -shared
+// RUN: %clang --target=x86_64-unknown-linux -no-pie -###
@@ -816,6 +816,11 @@ class FPOptions {
setAllowFPReassociate(LO.AllowFPReassoc);
setNoHonorNaNs(LO.NoHonorNaNs);
setNoHonorInfs(LO.NoHonorInfs);
+// Ensure that if FiniteMathOnly is enabled, NoHonorNaNs and NoHonorInfs
are
+// also enabled. This is because
@@ -113,7 +113,11 @@ static T PickFP(const llvm::fltSemantics *Sem, T
IEEEHalfVal, T IEEESingleVal,
static void DefineFloatMacros(MacroBuilder &Builder, StringRef Prefix,
const llvm::fltSemantics *Sem, StringRef Ext) {
- const char *DenormMin, *
https://github.com/jcranmer-intel commented:
You're missing checks for type domain rules, so things like:
- converting between `float _Complex` and `double _Complex`
- common type of `float _Complex` and `double`
- result of `int` and `float _Complex`
- complex types not allowed in increment/dec
https://github.com/jcranmer-intel edited
https://github.com/llvm/llvm-project/pull/88161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,97 @@
+// RUN: %clang_cc1 -verify -std=c99 %s
+
+/* WG14 N620, N638, N657, N694, N809: Yes*
+ * Complex and imaginary support in
+ *
+ * NB: Clang supports _Complex but not _Imaginary. In C99, _Complex support is
+ * required outside of freestanding, but _Imaginary sup
@@ -0,0 +1,97 @@
+// RUN: %clang_cc1 -verify -std=c99 %s
+
+/* WG14 N620, N638, N657, N694, N809: Yes*
+ * Complex and imaginary support in
+ *
+ * NB: Clang supports _Complex but not _Imaginary. In C99, _Complex support is
+ * required outside of freestanding, but _Imaginary sup
@@ -373,6 +355,10 @@ C99 implementation status
Yes
+(2): Clang supports _Complex type specifiers
but
+does not support _Imaginary type specifiers. Support for
+_Imaginary is optional in C99 which is why Clang is fully
conforming.
jcranmer-intel wr
https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/88161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/90588
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -15883,6 +15883,95 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15868,6 +15868,51 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15883,6 +15883,95 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15868,6 +15868,51 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -15868,6 +15868,51 @@ The returned value is completely identical to the
input except for the sign bit;
in particular, if the input is a NaN, then the quiet/signaling bit and payload
are perfectly preserved.
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
@@ -1275,6 +1283,14 @@ let IntrProperties = [IntrInaccessibleMemOnly,
IntrWillReturn, IntrStrictFP] in
[ LLVMMatchType<0>,
LLVMMatchType<0>,
@@ -631,6 +631,46 @@ TEST(APFloatTest, Maximum) {
EXPECT_TRUE(std::isnan(maximum(nan, f1).convertToDouble()));
}
+TEST(APFloatTest, MinimumNumber) {
+ APFloat f1(1.0);
+ APFloat f2(2.0);
+ APFloat zp(0.0);
+ APFloat zn(-0.0);
+ APFloat nan = APFloat::getNaN(APFloat::IEE
@@ -9130,6 +9142,15 @@ void SelectionDAGBuilder::visitCall(const CallInst &I) {
if (visitBinaryFloatCall(I, ISD::FMAXNUM))
return;
break;
+ case LibFunc_fminimum_num:
+ case LibFunc_fminimum_numf:
+if (visitBinaryFloatCall(I, ISD::FMI
@@ -1723,6 +1723,18 @@ class MachineIRBuilder {
return buildInstr(TargetOpcode::G_FMAXNUM_IEEE, {Dst}, {Src0, Src1},
Flags);
}
+ MachineInstrBuilder
+ buildFMinimumNUM(const DstOp &Dst, const SrcOp &Src0, const SrcOp &Src1,
jcranmer-intel wrote:
How
@@ -3033,8 +3038,8 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
SignedZeros = true;
StringRef Val = A->getValue();
- if (OFastEnabled && Val != "fast") {
-// Only -ffp-model=fast is compatible with OFast, ignore.
+
@@ -1766,7 +1768,10 @@ for more details.
``STDC FENV_ACCESS``: by default ``FENV_ACCESS`` is disabled. This option
setting behaves as though ``#pragma STDC FENV_ACCESS ON`` appeared at the
top of the source file.
- * ``fast`` Behaves identically to specifying b
@@ -14674,6 +14676,31 @@ static bool TryEvaluateBuiltinNaN(const ASTContext
&Context,
return true;
}
+// Checks that the value x is in the range (-1;-0.5], [0.5; 1)
+static bool isInFrexpResultRange(const llvm::APFloat &x) {
+ llvm::APFloat minusOne(x.getSemantics(), "-1.
https://github.com/jcranmer-intel commented:
I don't think the test is testing conformance correctly, but I'm not entirely
sure how to test conformance correctly.
What the paper is saying is that, on a system like x87 where all evaluation
happens in `x86_fp80` instead of source types, you need
@@ -174,9 +174,10 @@ static void addVisualCDefines(const LangOptions &Opts,
MacroBuilder &Builder) {
// transformation unless the transformation is guaranteed to produce a
bitwise
// identical result."
const bool any_imprecise_flags =
- Opts.FastMath || Opts.Finite
@@ -2922,7 +2922,7 @@ static bool handleFloatFloatBinOp(EvalInfo &Info, const
BinaryOperator *E,
// If during the evaluation of an expression, the result is not
// mathematically defined [...], the behavior is undefined.
// FIXME: C++ rules require us to not conform
https://github.com/jcranmer-intel commented:
Other side notes:
fmin and frexp can signal exceptions if the input is an sNaN, which causes
[library.c]p3 to kick in. (That's the only time these operations can signal an
exception.)
https://github.com/llvm/llvm-project/pull/88978
https://github.com/jcranmer-intel updated
https://github.com/llvm/llvm-project/pull/80475
>From 971cc613e994a308f939f68247257b65e04c74fa Mon Sep 17 00:00:00 2001
From: Joshua Cranmer
Date: Fri, 2 Feb 2024 10:35:29 -0800
Subject: [PATCH 1/3] Disable FTZ/DAZ when compiling shared libraries by
de
jcranmer-intel wrote:
Ping for review
https://github.com/llvm/llvm-project/pull/80475
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jcranmer-intel wrote:
> I'm not sure what the correct behavior is across all platforms. My
> perspective on this is heavily X86-biased, so I'd really like some guidance
> from people who work on other targets about their expectations. I think I saw
> at least one target that sets denormal-fp-m
@@ -842,25 +842,6 @@ void Linux::addProfileRTLibs(const llvm::opt::ArgList
&Args,
ToolChain::addProfileRTLibs(Args, CmdArgs);
}
-llvm::DenormalMode
-Linux::getDefaultDenormalModeForType(const llvm::opt::ArgList &DriverArgs,
- const JobAct
https://github.com/jcranmer-intel edited
https://github.com/llvm/llvm-project/pull/80475
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcranmer-intel updated
https://github.com/llvm/llvm-project/pull/80475
>From 971cc613e994a308f939f68247257b65e04c74fa Mon Sep 17 00:00:00 2001
From: Joshua Cranmer
Date: Fri, 2 Feb 2024 10:35:29 -0800
Subject: [PATCH 1/4] Disable FTZ/DAZ when compiling shared libraries by
de
@@ -0,0 +1,160 @@
+// RUN: %clang_cc1 -S -triple x86_64-linux-gnu -emit-llvm %s -o - | \
+// RUN: FileCheck %s --implicit-check-not "call void @llvm.set.rounding"
--implicit-check-not "call i32 @llvm.get.rounding"
+
+float func_rz_ru(float w, float x, float y, float z) {
+ #pr
https://github.com/jcranmer-intel updated
https://github.com/llvm/llvm-project/pull/80475
>From 971cc613e994a308f939f68247257b65e04c74fa Mon Sep 17 00:00:00 2001
From: Joshua Cranmer
Date: Fri, 2 Feb 2024 10:35:29 -0800
Subject: [PATCH 1/5] Disable FTZ/DAZ when compiling shared libraries by
de
https://github.com/jcranmer-intel closed
https://github.com/llvm/llvm-project/pull/80475
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcranmer-intel commented:
This may need some release notes adjustments as well; I already have a todo to
revisit the release notes around release time to make sure we get the summary
of the denormal handling flag changes right.
https://github.com/llvm/llvm-project/pull/89477
jcranmer-intel wrote:
> The "etc." is eliding -fno-fast-math, -funsafe-math-optimizations, and
> -fno-unsafe-math-optimizations
Maybe "fast-math-ish flags" is a good summary of the lot?
https://github.com/llvm/llvm-project/pull/89477
___
cfe-commits
https://github.com/jcranmer-intel requested changes to this pull request.
I haven't fully tested the changes yet, so right now I'm looking at the test to
figure out how much is supported. Nevertheless, I can already tell that this is
not complete support.
7.6.2p4 does clearly state that floati
https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/89473
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jcranmer-intel wrote:
I've been doing some testing, and I do want to confirm my understanding of the
C standard here.
>From what I can tell, macro expansion (phase 4) happens before constants are
>parsed (phase 7). As a result, if you have code like this:
```c
#define CONSTANT 0.1f
```
the int
@@ -79,3 +79,16 @@ float V7 = []() -> float {
0x0.01p0F);
}();
// CHECK: @V7 = {{.*}} float 1.00e+00
+
+template struct L {
+ constexpr L() : value(V) {}
+ float value;
+};
+
+#pragma STDC FENV_ROUND FE_DOWNWARD
jcranmer-intel wrote:
The interactio
https://github.com/jcranmer-intel commented:
I'm generally happy with the testing and semantics at this point.
https://github.com/llvm/llvm-project/pull/90877
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
https://github.com/jcranmer-intel edited
https://github.com/llvm/llvm-project/pull/89617
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcranmer-intel commented:
Sorry for just thinking of this now, but we should also have tests for some of
the builtins like `__builtin_fma` or `__builtin_sqrt`.
https://github.com/llvm/llvm-project/pull/89617
___
cfe-commits mailing
@@ -1232,6 +1232,14 @@ class TargetInfo : public TransferrableTargetInfo,
return true;
}
+ /// Returns true, if an operations that depends on rounding mode can be
+ /// implemented without changing FP environment. In this case the rounding
+ /// mode is encoded in the
@@ -5980,6 +5987,64 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
return Ret;
}
+static bool endsWithRoundingModeSuffix(StringRef FuncName) {
+ size_t Underscore = FuncName.find_last_of("_");
+ if (Underscore == StringRef::npos || Underscore < 2)
+
@@ -5980,6 +5987,64 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
return Ret;
}
+static bool endsWithRoundingModeSuffix(StringRef FuncName) {
+ size_t Underscore = FuncName.find_last_of("_");
+ if (Underscore == StringRef::npos || Underscore < 2)
+
https://github.com/jcranmer-intel commented:
After banging my head on the desk trying to figure out why the tests were
giving such strange results, I realized the issue...
Could you please use `__builtin_complex` in the test to construct the complex
infinities instead of `__builtin_infinity()
jcranmer-intel wrote:
Overall, I'm not opposed to this patch.
This new macro should probably be mentioned somewhere in the clang user
documentation.
> The way this requirement is formulated indicates that it could be implemented
> using preprocessor facility. Such implementation would require
jcranmer-intel wrote:
I mentioned this offline, but worth repeating here: I feel *something* needs to
be marked as partial/no for the x87 case. Aaron suggested Annex F support be
that value rather than this paper, which I guess satisfies that.
https://github.com/llvm/llvm-project/pull/101214
_
https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/101214
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/104857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4387,12 +4387,12 @@ Simple Constants
zeros. So '``s0x0001``' of type '``i16``' will be -1, not 1.
**Floating-point constants**
Floating-point constants use standard decimal notation (e.g.
-123.421), exponential notation (e.g. 1.23421e+2), or a more precise
-
https://github.com/jcranmer-intel edited
https://github.com/llvm/llvm-project/pull/105693
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -216,35 +216,31 @@ C23 implementation status
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2341.pdf";>N2341
-Unknown
-
-
-https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2401.pdf";>N2401
-Unknown
+No
@@ -216,35 +216,31 @@ C23 implementation status
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2341.pdf";>N2341
-Unknown
-
-
-https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2401.pdf";>N2401
-Unknown
+No
https://github.com/jcranmer-intel commented:
It might be better to list most of these as "N/A" rather than "No", for the
simple reason that decimal floating point is an optional feature we do not
support. Or maybe just a footnote saying something to that effect?
https://github.com/llvm/llvm-pr
https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/105693
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jcranmer-intel wrote:
> I looked at my meeting notes for discussion of this paper and I think we do
> need to worry about what the C standard says. From my notes: `The big intent
> from this change seems to be about making INFINITY to be a feature test
> macro.`, so if users are going to porta
@@ -113,7 +113,11 @@ static T PickFP(const llvm::fltSemantics *Sem, T
IEEEHalfVal, T IEEESingleVal,
static void DefineFloatMacros(MacroBuilder &Builder, StringRef Prefix,
const llvm::fltSemantics *Sem, StringRef Ext) {
- const char *DenormMin, *
1 - 100 of 134 matches
Mail list logo
