[clang] Fix complex long double division with -mno-x87. (PR #133152)

@@ -0,0 +1,49 @@ +// RUN %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown \ +// RUN -verify -complex-range=promoted -o - | FileCheck %s + +// RUN %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown \ +// RUN -verify=nopromotion -complex-range=promoted -target-fe

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

@@ -11226,12 +11232,14 @@ void Sema::CheckImplicitConversion(Expr *E, QualType T, SourceLocation CC, DiagnoseImpCast(*this, E, T, CC, diag::warn_impcast_float_precision); } // ... or possibly if we're increasing rank, too - else if (Order < 0) { +

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

@@ -132,6 +133,70 @@ template <> struct llvm::DenseMapInfo { return LHS == RHS; } }; +constexpr unsigned CXX23FloatRankToIndex(clang::BuiltinType::Kind Kind) { jcranmer-intel wrote: This function appears to be unused now. https://github.com/llvm/llvm-p

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

@@ -0,0 +1,505 @@ +// RUN: %clang_cc1 -fsyntax-only -std=c++23 -triple x86_64-unknown-unknown -target-feature +fullbf16 -verify -ast-dump %s | FileCheck %s +#include +_Float16 f16_val_1 = 1.0bf16; // expected-error {{cannot initialize a variable of type '_Float16' with an rvalu

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

@@ -4446,6 +4455,73 @@ CompareStandardConversionSequences(Sema &S, SourceLocation Loc, ? ImplicitConversionSequence::Better : ImplicitConversionSequence::Worse; + // C++23 [over.ics.rank]p4b3: + // A conversion in either direction between float

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

https://github.com/jcranmer-intel commented: I think this concludes my full look at this PR. I don't fully have a grasp on the mechanisms of C++ overload to comment on key parts of this patch. This also doesn't implement enough of the hard cases of P1467R9 (namely _Float32/_Float64) for me to

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

@@ -7444,9 +7444,12 @@ isArithmeticArgumentPromotion(Sema &S, const ImplicitCastExpr *ICE) { From = VecTy->getElementType(); if (const auto *VecTy = To->getAs()) To = VecTy->getElementType(); - // It's a floating promotion if the source type is a lower rank. - retu

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

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

[clang] [llvm] [IR][AsmParser] Revamp how floating-point literals in LLVM IR. (PR #121838)

jcranmer-intel wrote: > As you still support the legacy format, could you please restrict this PR to > only the parser changes, and leave the printer changes (and the mass test > update they require) to a followup? Sure, I can do it. I made them two separate in the commits partly for that rea

[clang] [llvm] [IR][AsmParser] Revamp how floating-point literals in LLVM IR. (PR #121838)

https://github.com/jcranmer-intel edited https://github.com/llvm/llvm-project/pull/121838 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

@@ -132,6 +133,70 @@ template <> struct llvm::DenseMapInfo { return LHS == RHS; } }; +constexpr unsigned CXX23FloatRankToIndex(clang::BuiltinType::Kind Kind) { + switch (Kind) { + case clang::BuiltinType::Float16: +return 0; + case clang::BuiltinType::BFloat16: +

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

@@ -132,6 +133,70 @@ template <> struct llvm::DenseMapInfo { return LHS == RHS; } }; +constexpr unsigned CXX23FloatRankToIndex(clang::BuiltinType::Kind Kind) { + switch (Kind) { + case clang::BuiltinType::Float16: +return 0; + case clang::BuiltinType::BFloat16: +

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

@@ -470,8 +470,16 @@ static void InitializeStandardPredefinedMacros(const TargetInfo &TI, if (LangOpts.CPlusPlus26) // FIXME: Use correct value for C++26. Builder.defineMacro("__cplusplus", "202400L"); -else if (LangOpts.CPlusPlus23) +else if (LangOpts.

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

@@ -7670,27 +7739,68 @@ static FloatingRank getFloatingRank(QualType T) { } } +/// C++23 6.8.5 [conv.rank] /// getFloatingTypeOrder - Compare the rank of the two specified floating /// point types, ignoring the domain of the type (i.e. 'double' == -/// '_Complex double').

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

@@ -0,0 +1,563 @@ +// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --function-signature +// RUN: %clang_cc1 -std=c++23 -triple x86_64-unknown-unknown -target-feature +fullbf16 -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK ---

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

https://github.com/jcranmer-intel commented: I haven't fully reviewed this, but here's some comments to start with: https://github.com/llvm/llvm-project/pull/78503 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/m

[clang] [llvm] [Clang][C++23] Core language changes from P1467R9 extended floating-point types and standard names. (PR #78503)

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

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

@@ -357,6 +357,9 @@ class IRBuilderBase { void setConstrainedFPCallAttr(CallBase *I) { I->addFnAttr(Attribute::StrictFP); +MemoryEffects ME = MemoryEffects::inaccessibleMemOnly(); jcranmer-intel wrote: It should be possible to make `CallBase::getMem

[clang] [llvm] [IR] Allow fast math flags on fptrunc and fpext (PR #115894)

https://github.com/jcranmer-intel approved this pull request. I think there's some followup work needed to get this working in SelectionDAG as well, but that can live in a separate patch (especially as we need to do a followup pass in DAGCombine to check for flags on the fpext/fptrunc nodes).

[clang] [llvm] Clang: emit llvm.minnum and llvm.maxnum with nsz always (PR #113133)

https://github.com/jcranmer-intel commented: You'll want to merge the fast-math flags, so that compiling with -ffinite-math-only gets you nnan ninf nsz on the maxnum/minnum, rather than just nsz. https://github.com/llvm/llvm-project/pull/113133 ___ c

[clang] [Clang] Enable -fpointer-tbaa by default. (PR #117244)

jcranmer-intel wrote: > do other tools like UBSan (etc) help users to find and fix the issues? We don't yet have a reliable tool for sanitizing TBAA failures. There is a project to do that (the TypeSanitizer, see https://discourse.llvm.org/t/reviving-typesanitizer-a-sanitizer-to-catch-type-bas

[clang] [llvm] [IR] Allow fast math flags on fptrunc and fpext (PR #115894)

@@ -3730,10 +3730,10 @@ Fast-Math Flags LLVM IR floating-point operations (:ref:`fneg `, :ref:`fadd `, :ref:`fsub `, :ref:`fmul `, :ref:`fdiv `, -:ref:`frem `, :ref:`fcmp `), and :ref:`phi `, -:ref:`select `, or :ref:`call ` instructions that return -floating-point types may u

[clang] [C2y] Add conformance test for WG14 N3364 (PR #115332)

https://github.com/jcranmer-intel approved this pull request. https://github.com/llvm/llvm-project/pull/115332 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C2y] Add conformance test for WG14 N3364 (PR #115332)

@@ -0,0 +1,35 @@ +// RUN: %clang_cc1 -verify -std=c2y -Wall -pedantic -emit-llvm -o - %s +// RUN: %clang_cc1 -verify -Wall -pedantic -emit-llvm -o - %s +// expected-no-diagnostics + +/* WG14 N3364: Yes + * Give consistent wording for SNAN initialization v3 + * + * Ensure that init

[clang] [llvm] [Transforms][Utils][PromoteMem2Reg] Propagate nnan flag on par with the nsz flag (PR #114271)

jcranmer-intel wrote: arsenm sums it up quite well, I think. Personally, I dislike the FMF being on select/phi only somewhat less than I dislike the function-level attributes, and I'd rather avoid needing to use them if there's a better way forward. Because nnan/ninf induce poison, you can get

[clang] [libunwind] [llvm] Replace documentation mentions of IRC with Discord (PR #114276)

https://github.com/jcranmer-intel edited https://github.com/llvm/llvm-project/pull/114276 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libunwind] [llvm] Replace documentation mentions of IRC with Discord (PR #114276)

https://github.com/jcranmer-intel commented: One thing I have noticed is that this does seem to more or less by accident remove the IRC channel from the list of communication channels to which the code of conduct and other policies applied. I am on board with generally replacing use of IRC wit

[clang] [libunwind] [llvm] Replace documentation mentions of IRC with Discord (PR #114276)

@@ -388,27 +384,18 @@ Guidance for office hours hosts from the list above. -.. _IRC: - -IRC +Discord jcranmer-intel wrote: You've removed the thing that lets you link to this section, if I'm recalling my RST correctly. https://github.com/llvm/llvm-p

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

jcranmer-intel wrote: > We will need someone to go through and audit the libm-style intrinsics and > make sure all optimizations of them are safe before we can switch over. Those > are "unsafe by default" since the optimizers know about them already. I've already been looking at all of the opt

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

@@ -2994,6 +2994,29 @@ A "convergencectrl" operand bundle is only valid on a ``convergent`` operation. When present, the operand bundle must contain exactly one value of token type. See the :doc:`ConvergentOperations` document for details. +.. _ob_fpe: + +Floating-point Envir

[clang] [NFC] Move warning from CodeGen to Sema. (PR #107397)

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

[clang] [NFC] Move warning from CodeGen to Sema. (PR #107397)

@@ -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

[clang] [NFC] Move warning from CodeGen to Sema. (PR #107397)

@@ -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

[clang] [C23] Update status page for TS 18661 integration (PR #105693)

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

[clang] [C23] Update status page for TS 18661 integration (PR #105693)

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

[clang] [C23] Update status page for TS 18661 integration (PR #105693)

@@ -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

[clang] [C23] Update status page for TS 18661 integration (PR #105693)

@@ -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

[clang] [C23] Update status page for TS 18661 integration (PR #105693)

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

[clang] [llvm] [AsmWriter] Print `nan`, `pinf`, and `ninf` when applicable (PR #105618)

@@ -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 -

[clang] Fix bug with -ffp-contract=fast-honor-pragmas (PR #104857)

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

[clang] [C11] Claim conformance to WG14 N1396 (PR #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

[clang] [C11] Claim conformance to WG14 N1396 (PR #101214)

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 _

[clang] [C11] Claim conformance to WG14 N1396 (PR #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

[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)

@@ -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.

[clang] [Driver] Introduce ffp-model=aggressive (PR #100453)

@@ -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

[clang] [Driver] Introduce ffp-model=aggressive (PR #100453)

@@ -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. +

[clang] Remove FiniteMathOnly and use only NoHonorINFs and NoHonorNANs. (PR #97342)

@@ -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

[clang] [C23] Add *_NORM_MAX macros to (PR #96643)

@@ -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, *

[clang] [NFC] Add assertion to ensure FiniteMathOnly is in sync with HonorINFs and HonorNANs. (PR #97342)

@@ -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

[clang] [C23] Add INFINITY and NAN macros to (PR #96659)

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

[clang] [C23] Add *_NORM_MAX macros to (PR #96643)

@@ -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, *

[clang] [C23] Add INFINITY and NAN macros to (PR #96659)

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

[clang] [llvm] Intrinsic: introduce minimumnum and maximumnum (PR #93841)

@@ -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

[clang] [llvm] Intrinsic: introduce minimumnum and maximumnum (PR #93841)

@@ -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

[clang] [llvm] Intrinsic: introduce minimumnum and maximumnum (PR #93841)

@@ -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

[clang] [clang] Report erroneous floating point results in _Complex math (PR #90588)

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

[clang] [llvm] Intrinsic: introduce minimumnum and maximumnum (PR #93841)

@@ -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

[clang] [llvm] Intrinsic: introduce minimumnum and maximumnum (PR #93841)

@@ -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

[clang] [llvm] Intrinsic: introduce minimumnum and maximumnum (PR #93841)

@@ -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

[clang] [llvm] Intrinsic: introduce minimumnum and maximumnum (PR #93841)

@@ -1275,6 +1283,14 @@ let IntrProperties = [IntrInaccessibleMemOnly, IntrWillReturn, IntrStrictFP] in [ LLVMMatchType<0>, LLVMMatchType<0>,

[clang] [llvm] Intrinsic: introduce minimumnum and maximumnum (PR #93841)

@@ -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

[clang] [llvm] Intrinsic: introduce minimumnum and maximumnum (PR #93841)

@@ -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

[clang] [clang] Macro for constant rounding mode (PR #92699)

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

[clang] [clang] Report erroneous floating point results in _Complex math (PR #90588)

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()

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

@@ -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) +

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

@@ -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) +

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

@@ -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

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

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

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

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

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

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

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

@@ -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

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

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

[clang] Fix -fno-unsafe-math-optimizations behavior (PR #89473)

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

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

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

[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #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

[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)

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

[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)

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

[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)

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

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

@@ -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

[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)

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

[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)

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

[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)

@@ -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

[clang] Align -ffp-model=fast denormal handling with -ffast-math (PR #89477)

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

[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)

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

[clang] Disable FTZ/DAZ when compiling shared libraries by default. (PR #80475)

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

[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)

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

[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #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

[clang] [C99] Claim conformance for _Complex support (PR #88161)

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

[clang] [C99] Claim conformance for _Complex support (PR #88161)

@@ -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

[clang] [C99] Claim conformance for _Complex support (PR #88161)

@@ -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

[clang] [C99] Claim conformance for _Complex support (PR #88161)

@@ -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

[clang] [C99] Claim conformance for _Complex support (PR #88161)

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

[clang] [C99] Claim conformance for _Complex support (PR #88161)

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

[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)

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

[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)

@@ -310,6 +310,13 @@ class ComplexExprEmitter CGF.getContext().getFloatTypeSemantics(ElementType); const llvm::fltSemantics &HigherElementTypeSemantics = CGF.getContext().getFloatTypeSemantics(HigherElementType); +// Check that LongDouble Size > Double S

[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)

@@ -310,6 +310,13 @@ class ComplexExprEmitter CGF.getContext().getFloatTypeSemantics(ElementType); const llvm::fltSemantics &HigherElementTypeSemantics = CGF.getContext().getFloatTypeSemantics(HigherElementType); +// Check that LongDouble Size > Double S

[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)

@@ -287,9 +288,47 @@ class ComplexExprEmitter ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName, const BinOpInfo &Op); - QualType getPromotionType(QualType Ty) { + QualType GetHigherPrecisionFPType(QualType ElementType) { +

[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)

@@ -287,9 +288,47 @@ class ComplexExprEmitter ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName, const BinOpInfo &Op); - QualType getPromotionType(QualType Ty) { + QualType GetHigherPrecisionFPType(QualType ElementType) { +

[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)

@@ -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

[clang] [CLANG] Full support of complex multiplication and division. (PR #81514)

@@ -283,9 +283,48 @@ class ComplexExprEmitter ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName, const BinOpInfo &Op); - QualType getPromotionType(QualType Ty) { + QualType GetHigherPrecisionFPType(QualType ElementType) { +

  1   2   >