@@ -842,8 +842,8 @@ class LLVM_LIBRARY_VISIBILITY NaClTargetInfo : public
OSTargetInfo {
} else if (Triple.getArch() == llvm::Triple::mipsel) {
// Handled on mips' setDataLayout.
} else {
- assert(Triple.getArch() == llvm::Triple::le32);
-
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/97585
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3165,7 +3165,17 @@ bool Lexer::LexEndOfFile(Token , const char
*CurPtr) {
// C99 5.1.1.2p2: If the file is non-empty and didn't end in a newline, issue
// a pedwarn.
- if (CurPtr != BufferStart && (CurPtr[-1] != '\n' && CurPtr[-1] != '\r')) {
+ if (CurPtr !=
@@ -8955,6 +8960,36 @@ unsigned clang_Cursor_isExternalSymbol(CXCursor C,
CXString *language,
return 0;
}
+enum CX_BinaryOperatorKind clang_Cursor_getBinaryOpcode(CXCursor C) {
+ if (C.kind != CXCursor_BinaryOperator &&
+ C.kind != CXCursor_CompoundAssignOperator) {
@@ -8955,6 +8960,36 @@ unsigned clang_Cursor_isExternalSymbol(CXCursor C,
CXString *language,
return 0;
}
+enum CX_BinaryOperatorKind clang_Cursor_getBinaryOpcode(CXCursor C) {
+ if (C.kind != CXCursor_BinaryOperator &&
+ C.kind != CXCursor_CompoundAssignOperator) {
@@ -8955,6 +8960,36 @@ unsigned clang_Cursor_isExternalSymbol(CXCursor C,
CXString *language,
return 0;
}
+enum CX_BinaryOperatorKind clang_Cursor_getBinaryOpcode(CXCursor C) {
+ if (C.kind != CXCursor_BinaryOperator &&
+ C.kind != CXCursor_CompoundAssignOperator) {
@@ -2181,6 +2193,60 @@ def from_cursor_result(res, fn, args):
res._tu = args[0]._tu
return res
+class BinaryOperator(BaseEnumeration):
+"""
+Describes the BinaryOperator of a declaration
+"""
+
+# The unique kind objects, index by id.
+
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/98489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
Thank you for picking this back up! Hopefully @Endilll can comment on the
python bits, but the changes generally LGTM aside from some very minor nits.
One thing that should be added is a release note (in
`clang/docs/ReleaseNotes.rst` so users know
Martin =?utf-8?q?Storsj=C3=B6?=
Message-ID:
In-Reply-To:
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/98478
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -3165,7 +3165,17 @@ bool Lexer::LexEndOfFile(Token , const char
*CurPtr) {
// C99 5.1.1.2p2: If the file is non-empty and didn't end in a newline, issue
// a pedwarn.
- if (CurPtr != BufferStart && (CurPtr[-1] != '\n' && CurPtr[-1] != '\r')) {
+ if (CurPtr !=
https://github.com/AaronBallman commented:
The only other unreserved name I could find in the file is:
https://github.com/llvm/llvm-project/blob/d9c26b9d560f4362503b8f0ec97a52a0a36a57ce/clang/lib/Headers/avx512fp16intrin.h#L99
(uses `h`)
so we might as well fix this at the same time. We
@@ -203,6 +203,12 @@ def FmaF16F128 : Builtin, F16F128MathTemplate {
let Prototype = "T(T, T, T)";
}
+def Fmaf16 : Builtin, F16F128MathTemplate {
AaronBallman wrote:
Why is this needed when we have:
AaronBallman wrote:
> This is generally looking great, and I think it's ready to go as soon as you
> can finish the tests. (You said you weren't able to update all the tests —
> did you have questions about the remaining tests?)
>
> I did have a thought, though. Are we confident that the
AaronBallman wrote:
> Oh that makes sense so
>
> ```
> static void f();
> void *k = _Generic(, void (*)(void) : 0, default : f);
> ```
>
> should be ok since it is not in the result expression?
Correct, that's a good test case to add! Similarly, it would be good to add one
like:
```
void *k
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -pedantic-errors
AaronBallman wrote:
```suggestion
// RUN: %clang_cc1 -fsyntax-only -verify %s -Wno-pointer-arith -pedantic-errors
```
https://github.com/llvm/llvm-project/pull/98016
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c23 -pedantic-errors
+
+// expected-no-diagnostics
+
+static int f(void);
+
+int main(void)
+{
+typeof(f()) x;
AaronBallman wrote:
```suggestion
typeof() x;
```
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -pedantic-errors
+
+// expected-no-diagnostics
+
+static int f(void);
+
+int main(void)
+{
+int x = sizeof f();
AaronBallman wrote:
```suggestion
int x = sizeof(f);
```
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -pedantic-errors
AaronBallman wrote:
```suggestion
// RUN: %clang_cc1 -fsyntax-only -verify %s -Wno-pointer-arith -pedantic-errors
```
https://github.com/llvm/llvm-project/pull/98016
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -pedantic-errors
+
+static void *f(void); // expected-error {{function 'f' has internal linkage
but is not defined}}
+
+int main(void)
+{
+int j = _Generic(, void *(*)(void): 10, default: 20);
+//
@@ -554,6 +554,9 @@ Attribute Changes in Clang
Improvements to Clang's diagnostics
---
+- Clang now emits an error instead of a warning for `undefined_internal`
AaronBallman wrote:
```suggestion
- Clang now emits an error
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -pedantic-errors
AaronBallman wrote:
```suggestion
// RUN: %clang_cc1 -fsyntax-only -verify %s -Wno-unused -pedantic-errors
```
because the point of the test is the error about internal linkage, not
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/98016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
I think the test cases should all be combined into a single file -- we don't
stop issuing diagnostics after the first one, so it should be fine to put them
all together into one file.
https://github.com/llvm/llvm-project/pull/98016
AaronBallman wrote:
> For the other two I had something similar but that still misses this point:
> — part of the expression in a generic association that is not the result
> expression of its generic
> selection
> But that might also be because I don't understand this point well enough. I
>
AaronBallman wrote:
@budimirarandjelovicsyrmia -- do you need someone to land these changes on your
behalf?
https://github.com/llvm/llvm-project/pull/70307
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 %s -verify -fno-builtin -Werror=comment -Wno-error=abi
-Wfatal-errors=assume -Wno-fatal-errors=assume
+
+#define diagnose_if(...) __attribute__((diagnose_if(__VA_ARGS__)))
+
+template
+void diagnose_if_wcomma() diagnose_if(b, "oh no",
https://github.com/AaronBallman approved this pull request.
LGTM, thank you for the fix!
https://github.com/llvm/llvm-project/pull/98102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 %s -verify -fno-builtin -Werror=comment -Wno-error=abi
-Wfatal-errors=assume -Wno-fatal-errors=assume
+
+#define diagnose_if(...) __attribute__((diagnose_if(__VA_ARGS__)))
+
+template
+void diagnose_if_wcomma() diagnose_if(b, "oh no",
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 %s -verify -fno-builtin -Werror=comment -Wno-error=abi
-Wfatal-errors=assume -Wno-fatal-errors=assume
+
+#define diagnose_if(...) __attribute__((diagnose_if(__VA_ARGS__)))
+
+template
+void diagnose_if_wcomma() diagnose_if(b, "oh no",
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 %s -verify -fno-builtin -Werror=comment -Wno-error=abi
-Wfatal-errors=assume -Wno-fatal-errors=assume
+
+#define diagnose_if(...) __attribute__((diagnose_if(__VA_ARGS__)))
+
+template
+void diagnose_if_wcomma() diagnose_if(b, "oh no",
https://github.com/AaronBallman commented:
Sorry for the delay in review!
This seems like the right direction to go, in general. As @erichkeane, it's a
bit hard to review due to the whitespace-only changes and changes to
`__is_trivially_equality_comparable`, you should remove those changes or
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/70976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -686,6 +686,8 @@ Improvements to Clang's diagnostics
- Clang no longer emits a "no previous prototype" warning for Win32 entry
points under ``-Wmissing-prototypes``.
Fixes #GH94366.
+- Clang now diagnoses non-C++11 integer constant expressions. Fixes #GH59863
@@ -277,7 +277,9 @@ void dr258(void) {
void dr261(void) {
/* This is still an integer constant expression despite the overflow. */
AaronBallman wrote:
Probably good to update this comment to mention "extension".
https://github.com/AaronBallman approved this pull request.
LGTM aside from a few small things to correct. @tbaederr are you happy with the
state of things as well?
https://github.com/llvm/llvm-project/pull/70307
___
cfe-commits mailing list
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/70307
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,277 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wmissing-format-attribute %s
+
+typedef unsigned short char16_t;
+typedef unsigned int char32_t;
+typedef __WCHAR_TYPE__ wchar_t;
+typedef __SIZE_TYPE__ size_t;
+typedef __builtin_va_list va_list;
+
AaronBallman wrote:
Pre-commit CI seems to have found a valid failure:
```
_bk;t=1720616429374FAIL: Clang :: Sema/attr-format-missing.c (16228 of 20429)
_bk;t=1720616429374 TEST 'Clang ::
Sema/attr-format-missing.c' FAILED
_bk;t=1720616429374Exit
https://github.com/AaronBallman commented:
The changes seem reasonable to me, but I don't have a lot of expertise with
compiler-rt. Should the changes come with a release note though?
https://github.com/llvm/llvm-project/pull/96240
___
cfe-commits
@@ -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
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/96643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2068,7 +2068,8 @@ bool Lexer::LexNumericConstant(Token , const char
*CurPtr) {
}
// If we have a digit separator, continue.
- if (C == '\'' && (LangOpts.CPlusPlus14 || LangOpts.C23)) {
+ if (C == '\'' &&
+ (LangOpts.CPlusPlus14 || LangOpts.C23 ||
https://github.com/AaronBallman commented:
Thank you for working on this! I'll leave the codegen code review to John and
Eli, but I would appreciate explicit documentation in
`clang/docs/LanguageExtensions.rst` so that we explicitly document this
behavior and users (including the Linux
AaronBallman wrote:
> The pointer values in a specific `va_list` can and often do change when you
> call `va_arg`, but I am not aware of any targets where they do not always
> point to the same regions. In every ABI I've ever seen, `va_list` contains a
> pointer to the stack argument area,
@@ -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
https://github.com/AaronBallman approved this pull request.
Changes LGTM but this is complicated enough that it would be nice if
@hubert-reinterpretcast could also take a look, because @erichkeane isn't back
from leave yet.
https://github.com/llvm/llvm-project/pull/98160
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/98160
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -143,13 +157,125 @@ struct NormalizedConstraint {
return Constraint.get();
}
+ FoldExpandedConstraint *getFoldExpandedConstraint() const {
+assert(isFoldExpanded() &&
+ "getFoldExpandedConstraint called on non-fold-expanded
constraint.");
+return
@@ -5576,6 +5576,10 @@ static void TryOrBuildParenListInitialization(
ExprResult ER;
ER = IS.Perform(S, SubEntity, SubKind,
Arg ? MultiExprArg(Arg) : std::nullopt);
+
+ if (ER.isInvalid())
AaronBallman wrote:
Ah you are
https://github.com/AaronBallman commented:
The changes LGTM, but please add a release note to clang/docs/ReleaseNotes.rst
so users know about the fix.
https://github.com/llvm/llvm-project/pull/98102
___
cfe-commits mailing list
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/98102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
Thank you for working on this! C23 changed the normative wording here somewhat,
so I think we should add additional test coverage. Specifically:
Moreover, if an identifier declared with internal linkage is used in an
expression
there shall be exactly
@@ -113,7 +113,11 @@ static T PickFP(const llvm::fltSemantics *Sem, T
IEEEHalfVal, T IEEESingleVal,
static void DefineFloatMacros(MacroBuilder , StringRef Prefix,
const llvm::fltSemantics *Sem, StringRef Ext) {
- const char *DenormMin,
Author: Aaron Ballman
Date: 2024-07-09T16:31:02-04:00
New Revision: 0b53e7b1cb71e7a021d30efa1620c2e54383b64d
URL:
https://github.com/llvm/llvm-project/commit/0b53e7b1cb71e7a021d30efa1620c2e54383b64d
DIFF:
https://github.com/llvm/llvm-project/commit/0b53e7b1cb71e7a021d30efa1620c2e54383b64d.diff
AaronBallman wrote:
> I'd like to point out that most of the testcases I wrote for the GCC
> implementation still fail with the latest clang on godbolt.
Thank you for letting us know! The plan is to continue to polish this feature
through the Clang 19 release. The branch date for us is in two
AaronBallman wrote:
> > I'd like to point out that most of the testcases I wrote for the GCC
> > implementation still fail with the latest clang on godbolt.
>
> This patch should help with at least some of them.
It'd be good to verify that it does help with them or see if there are other
AaronBallman wrote:
> _Every_ `va_list` stores pointers; otherwise, it wouldn't be able to support
> an arbitrary number of arguments. Copying just copies the pointers, and
> that's fine because the memory they point to is immutable and always outlives
> the `va_list`. You can imagine a
https://github.com/AaronBallman approved this pull request.
LGTM, but please wait for @cor3ntin to give a final sign-off before landing.
https://github.com/llvm/llvm-project/pull/97208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
AaronBallman wrote:
> I can't imagine what optimizations that would enable.
It's more about correctness than optimization opportunities -- do we want to
promise users that the behavior will always work in all circumstances on a
bytewise copy? What about code like this:
```
va_list one, two;
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -verify=c23 -std=c23 %s
+// RUN: %clang_cc1 -verify=c17 -std=c17 %s
AaronBallman wrote:
I don't think we should remove the test for stdatomic,h, that's an important
property for us to test and may be papering over a bug
AaronBallman wrote:
> > > Discussion on the WG14 reflectors suggested that the qualifiers should
> > > still be stripped from the type of the controlling expression; the
> > > standard should be corrected to make this more clear.
> >
> >
> > Does WG14 think we're right to produce a qualified
@@ -143,13 +148,116 @@ struct NormalizedConstraint {
return Constraint.get();
}
+ FoldExpandedConstraint *getFoldExpandedConstraint() const {
+assert(isFoldExpanded() &&
+ "getFoldExpandedConstraint called on non-fold-expanded
constraint.");
+return
@@ -177,77 +178,180 @@ struct SatisfactionStackRAII {
};
} // namespace
-template
+template
static ExprResult
calculateConstraintSatisfaction(Sema , const Expr *ConstraintExpr,
ConstraintSatisfaction ,
-
@@ -1390,17 +1577,82 @@ NormalizedConstraint::fromConstraintExpr(Sema ,
NamedDecl *D, const Expr *E) {
return std::nullopt;
return New;
+ } else if (auto *FE = dyn_cast(E);
+ FE && S.getLangOpts().CPlusPlus26 &&
+ (FE->getOperator() ==
@@ -177,77 +178,180 @@ struct SatisfactionStackRAII {
};
} // namespace
-template
+template
static ExprResult
calculateConstraintSatisfaction(Sema , const Expr *ConstraintExpr,
ConstraintSatisfaction ,
-
@@ -143,13 +148,116 @@ struct NormalizedConstraint {
return Constraint.get();
}
+ FoldExpandedConstraint *getFoldExpandedConstraint() const {
+assert(isFoldExpanded() &&
+ "getFoldExpandedConstraint called on non-fold-expanded
constraint.");
+return
@@ -177,77 +178,180 @@ struct SatisfactionStackRAII {
};
} // namespace
-template
+template
static ExprResult
calculateConstraintSatisfaction(Sema , const Expr *ConstraintExpr,
ConstraintSatisfaction ,
-
@@ -177,77 +178,180 @@ struct SatisfactionStackRAII {
};
} // namespace
-template
+template
static ExprResult
calculateConstraintSatisfaction(Sema , const Expr *ConstraintExpr,
ConstraintSatisfaction ,
-
@@ -177,77 +178,180 @@ struct SatisfactionStackRAII {
};
} // namespace
-template
+template
static ExprResult
calculateConstraintSatisfaction(Sema , const Expr *ConstraintExpr,
ConstraintSatisfaction ,
-
@@ -143,13 +148,116 @@ struct NormalizedConstraint {
return Constraint.get();
}
+ FoldExpandedConstraint *getFoldExpandedConstraint() const {
+assert(isFoldExpanded() &&
+ "getFoldExpandedConstraint called on non-fold-expanded
constraint.");
+return
@@ -75,6 +75,17 @@ struct AtomicConstraint {
}
};
+struct FoldExpandedConstraint;
+
+using NormalFormConstraint =
+llvm::PointerUnion;
+struct NormalizedConstraint;
+using NormalForm =
+llvm::SmallVector, 4>;
+
+NormalForm makeCNF(const NormalizedConstraint );
@@ -143,13 +148,116 @@ struct NormalizedConstraint {
return Constraint.get();
}
+ FoldExpandedConstraint *getFoldExpandedConstraint() const {
+assert(isFoldExpanded() &&
+ "getFoldExpandedConstraint called on non-fold-expanded
constraint.");
+return
@@ -143,13 +148,116 @@ struct NormalizedConstraint {
return Constraint.get();
}
+ FoldExpandedConstraint *getFoldExpandedConstraint() const {
+assert(isFoldExpanded() &&
+ "getFoldExpandedConstraint called on non-fold-expanded
constraint.");
+return
https://github.com/AaronBallman commented:
Thank you!
You should also add test coverage (clang/test/SemaCXX) for the changes and a
release note (clang/docs/ReleaseNotes.rst).
https://github.com/llvm/llvm-project/pull/98102
___
cfe-commits mailing
@@ -5576,6 +5576,10 @@ static void TryOrBuildParenListInitialization(
ExprResult ER;
ER = IS.Perform(S, SubEntity, SubKind,
Arg ? MultiExprArg(Arg) : std::nullopt);
+
+ if (ER.isInvalid())
AaronBallman wrote:
Under what
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/98102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
The paper in question can be found here:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3262.pdf
https://github.com/llvm/llvm-project/pull/98146
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -113,7 +113,11 @@ static T PickFP(const llvm::fltSemantics *Sem, T
IEEEHalfVal, T IEEESingleVal,
static void DefineFloatMacros(MacroBuilder , StringRef Prefix,
const llvm::fltSemantics *Sem, StringRef Ext) {
- const char *DenormMin,
https://github.com/AaronBallman approved this pull request.
LGTM, thank you!
https://github.com/llvm/llvm-project/pull/98105
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/97436
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -249,13 +249,15 @@ class APValue {
struct NoLValuePath {};
struct UninitArray {};
struct UninitStruct {};
+ struct ConstexprUnknown {};
template friend class clang::serialization::BasicReaderBase;
friend class ASTImporter;
friend class ASTNodeImporter;
https://github.com/AaronBallman commented:
Generally seems like a reasonable direction, thank you!
https://github.com/llvm/llvm-project/pull/95474
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/95474
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/97846
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> > > > LGTM but please add a release note to clang/docs/ReleaseNotes.rst so
> > > > users know about the fix as well.
> > >
> > >
> > > Note that only clang 19 has `constexpr` support in C23.
> > > https://godbolt.org/z/4bThdsqK5 Release note saying that support has been
AaronBallman wrote:
> > LGTM but please add a release note to clang/docs/ReleaseNotes.rst so users
> > know about the fix as well.
>
> Note that only clang 19 has `constexpr` support in C23.
> https://godbolt.org/z/4bThdsqK5 Release note saying that support has been
> implemented is already
https://github.com/AaronBallman approved this pull request.
LGTM but please add a release note to clang/docs/ReleaseNotes.rst so users know
about the fix as well.
Once that's added, will you need someone to land the changes on your behalf?
https://github.com/llvm/llvm-project/pull/97846
AaronBallman wrote:
> No changelog?
I thought about adding a release note but because we never supported
`_Imaginary` to begin with, it didn't seem particularly useful. Want me to add
one anyway? "Clang continues to no longer support '_Imaginary', as always." ;-)
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/97581
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> > @AaronBallman
> > [N2848](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2848.pdf)
> > explicitly mentions that `NAN` and `INFINITY` macros should expand to a
> > constant expression of type `float` not `double` like was implemented in
> > this patch.
> >
AaronBallman wrote:
> Ping!
CC @rjmccall and @efriedma-quic -- we're still hoping to get this resolved for
Clang 19 and the branch date is Tue Jul 23, so it's coming up quickly.
https://github.com/llvm/llvm-project/pull/91364
___
cfe-commits mailing
Author: Aaron Ballman
Date: 2024-07-08T09:10:25-04:00
New Revision: 2f2b931e1296aebe6c03fd969363683b637973e5
URL:
https://github.com/llvm/llvm-project/commit/2f2b931e1296aebe6c03fd969363683b637973e5
DIFF:
https://github.com/llvm/llvm-project/commit/2f2b931e1296aebe6c03fd969363683b637973e5.diff
AaronBallman wrote:
> @AaronBallman
> [N2848](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2848.pdf)
> explicitly mentions that `NAN` and `INFINITY` macros should expand to a
> constant expression of type `float` not `double` like was implemented in this
> patch.
>
> `__builtin_nanf`
https://github.com/AaronBallman approved this pull request.
LGTM, thank you!
https://github.com/llvm/llvm-project/pull/94877
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> @AaronBallman please review
>
> I don't know how to go about measuring if there even is a performance
> regression. How would I do that?
I would put up a branch on http://llvm-compile-time-tracker.com (instructions
in the `About` page) and see how this impacts compile
@@ -2068,7 +2068,8 @@ bool Lexer::LexNumericConstant(Token , const char
*CurPtr) {
}
// If we have a digit separator, continue.
- if (C == '\'' && (LangOpts.CPlusPlus14 || LangOpts.C23)) {
+ if (C == '\'' &&
+ (LangOpts.CPlusPlus14 || LangOpts.C23 ||
AaronBallman wrote:
> > > You can certainly construct cases where the different lexing rules in
> > > different language modes allow you to detect which language you're in
> > > from within the preprocessor ([1](https://eel.is/c++draft/diff.cpp11.lex)
> > >
@@ -1165,6 +1165,8 @@ static void InitializePredefinedMacros(const TargetInfo
,
DefineType("__WCHAR_TYPE__", TI.getWCharType(), Builder);
DefineType("__WINT_TYPE__", TI.getWIntType(), Builder);
DefineTypeSizeAndWidth("__SIG_ATOMIC", TI.getSigAtomicType(), TI, Builder);
Author: Aaron Ballman
Date: 2024-07-03T10:36:12-04:00
New Revision: aa3c84c85c8c2ef5b8665932e7934458a44504ce
URL:
https://github.com/llvm/llvm-project/commit/aa3c84c85c8c2ef5b8665932e7934458a44504ce
DIFF:
https://github.com/llvm/llvm-project/commit/aa3c84c85c8c2ef5b8665932e7934458a44504ce.diff
201 - 300 of 5460 matches
Mail list logo
