https://github.com/jcranmer-intel approved this pull request.
https://github.com/llvm/llvm-project/pull/107397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -780,6 +780,25 @@ class ASTContext : public RefCountedBase {
const TargetInfo &getTargetInfo() const { return *Target; }
const TargetInfo *getAuxTargetInfo() const { return AuxTarget; }
+ const QualType GetHigherPrecisionFPType(QualType ElementType) const {
+const
@@ -6784,6 +6784,12 @@ def warn_arc_lifetime_result_type : Warning<
"ARC %select{unused|__unsafe_unretained|__strong|__weak|__autoreleasing}0 "
"lifetime qualifier on return type is ignored">,
InGroup;
+def warn_excess_precision_not_supported : Warning<
+ "excess precisi
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
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
@@ -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 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
@@ -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 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
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
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 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
@@ -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.
@@ -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
@@ -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.
+
@@ -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
@@ -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, *
@@ -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
jcranmer-intel wrote:
Some thoughts of my own:
The decision being discussed here has two main repercussions:
* An attempt to use `INFINITY` gets a symbol-not-found error message, or it
gets whatever warning/error message we attach to `__builtin_inf()` in
`-ffinite-math-only` mode.
* Code that
@@ -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, *
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
@@ -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
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
@@ -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
@@ -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
@@ -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
@@ -1275,6 +1283,14 @@ let IntrProperties = [IntrInaccessibleMemOnly,
IntrWillReturn, IntrStrictFP] in
[ LLVMMatchType<0>,
LLVMMatchType<0>,
@@ -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
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
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()
@@ -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)
+
@@ -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
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
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:
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
@@ -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
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
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
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
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 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
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 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
@@ -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/4] Disable FTZ/DAZ when compiling shared libraries by
de
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
@@ -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
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
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
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
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
@@ -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 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
@@ -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
@@ -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
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
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 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
@@ -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
@@ -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) {
+
@@ -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,48 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo &Op);
- QualType getPromotionType(QualType Ty) {
+ QualType GetHigherPrecisionFPType(QualType ElementType) {
+
@@ -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
@@ -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
@@ -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);
-
@@ -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
@@ -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
@@ -283,9 +283,46 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo &Op);
- QualType getPromotionType(QualType Ty) {
+ QualType HigherPrecisionTypeForComplexArithmetic(QualType E
@@ -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
@@ -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 -###
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
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
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
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
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:
> (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
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
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
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 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:
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
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
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
@@ -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,
+
@@ -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 +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
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
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
@@ -2807,6 +2807,9 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
bool StrictFPModel = false;
StringRef Float16ExcessPrecision = "";
StringRef BFloat16ExcessPrecision = "";
+ StringRef CxLimitedRange = "NoCxLimiteRange";
1 - 100 of 104 matches
Mail list logo
