@@ -956,42 +956,70 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
&CGF,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
//===--
@@ -956,42 +956,70 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
&CGF,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
//===--
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 %s -fsyntax-only -Wextra -verify
nickdesaulniers wrote:
If this diagnostic is not already well tested, adding all of these additional
unit tests makes sense.
But it looks like there's quite a number of existing tests in othe
nickdesaulniers wrote:
Github trick not specific to llvm-project. If you put
```
Fixes: #76872
```
In the commit message, then merging this PR will automatically close
https://github.com/llvm/llvm-project/issues/76872.
https://github.com/llvm/llvm-project/pull/77178
__
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 %s -fsyntax-only -Wextra -verify
nickdesaulniers wrote:
I would just remove the newly created
clang/test/Sema/warn-extra-cast-function-type-strict.c. If you have cases that
expose bugs in the implementation, that is distinc
@@ -365,6 +365,10 @@ class DefaultFilterCCC final : public
CorrectionCandidateCallback {
template
class DeclFilterCCC final : public CorrectionCandidateCallback {
public:
+ explicit DeclFilterCCC(const IdentifierInfo *Typo = nullptr,
+ NestedNameSpeci
@@ -818,6 +819,189 @@ CodeGenFunction::evaluateOrEmitBuiltinObjectSize(const
Expr *E, unsigned Type,
return ConstantInt::get(ResType, ObjectSize, /*isSigned=*/true);
}
+const FieldDecl *CodeGenFunction::FindFlexibleArrayMemberField(
+ASTContext &Ctx, const RecordDecl *R
@@ -850,6 +1034,13 @@ CodeGenFunction::emitBuiltinObjectSize(const Expr *E,
unsigned Type,
}
}
+ if (IsDynamic) {
+// Emit special code for a flexible array member with the "counted_by"
+// attribute.
+if (Value *V = emitFlexibleArrayMemberSize(E, Type, Res
Author: Nick Desaulniers
Date: 2022-03-23T09:40:43-07:00
New Revision: 5a2e56b70e2fa7ad0d82e54bc4c741b16f05e475
URL:
https://github.com/llvm/llvm-project/commit/5a2e56b70e2fa7ad0d82e54bc4c741b16f05e475
DIFF:
https://github.com/llvm/llvm-project/commit/5a2e56b70e2fa7ad0d82e54bc4c741b16f05e475.di
Author: Nick Desaulniers
Date: 2022-07-12T09:17:54-07:00
New Revision: 2240d72f15f3b7b9d9fb65450f9bf635fd310f6f
URL:
https://github.com/llvm/llvm-project/commit/2240d72f15f3b7b9d9fb65450f9bf635fd310f6f
DIFF:
https://github.com/llvm/llvm-project/commit/2240d72f15f3b7b9d9fb65450f9bf635fd310f6f.di
Author: Nick Desaulniers
Date: 2022-07-14T09:49:11-07:00
New Revision: d2792e7d37c4b454a6b052cd569ff13ed7f22159
URL:
https://github.com/llvm/llvm-project/commit/d2792e7d37c4b454a6b052cd569ff13ed7f22159
DIFF:
https://github.com/llvm/llvm-project/commit/d2792e7d37c4b454a6b052cd569ff13ed7f22159.di
Author: Nick Desaulniers
Date: 2022-07-14T11:25:24-07:00
New Revision: 140bfdca60ae8b1b2ad115846379e3c9ca914bfb
URL:
https://github.com/llvm/llvm-project/commit/140bfdca60ae8b1b2ad115846379e3c9ca914bfb
DIFF:
https://github.com/llvm/llvm-project/commit/140bfdca60ae8b1b2ad115846379e3c9ca914bfb.di
Author: Ken Matsui
Date: 2022-05-16T15:46:59-07:00
New Revision: 45e01ce5fe6a5e4dc25ffdf626caa344fbcb93dd
URL:
https://github.com/llvm/llvm-project/commit/45e01ce5fe6a5e4dc25ffdf626caa344fbcb93dd
DIFF:
https://github.com/llvm/llvm-project/commit/45e01ce5fe6a5e4dc25ffdf626caa344fbcb93dd.diff
LO
nickdesaulniers wrote:
@efriedma-quic parting thoughts here?
https://github.com/llvm/llvm-project/pull/83431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nickdesaulniers wrote:
Right, I'm more interested in being able to use on aarch64 the `_Float128` type
as standardized by C23, than the clang specific `__float128` extension. Does
this PR help get us there?
https://github.com/llvm/llvm-project/pull/85070
__
nickdesaulniers wrote:
What's up with the commit message on this PR? Why is it so different from the
PR description?
https://github.com/llvm/llvm-project/pull/85501
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -std=c2x -verify %s
+
+/* WG14 N3006: Full
+ * Underspecified object declarations
+ */
+
+struct S1 { int x, y; };// expected-note {{previous definition is
here}}
+union U1 { int a; double b; }; // expected-note {{previous definition
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/82819
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nickdesaulniers commented:
This still has "foo"="true" style function attributes, which are problematic.
Is the plan to change that?
https://github.com/llvm/llvm-project/pull/82819
___
cfe-commits mailing list
cfe-commits@lists.llv
@@ -116,37 +116,22 @@ class AArch64TargetCodeGenInfo : public TargetCodeGenInfo
{
if (!FD)
return;
-const auto *TA = FD->getAttr();
-if (TA == nullptr)
- return;
-
-ParsedTargetAttr Attr =
-CGM.getTarget().parseTargetAttr(TA->getFeaturesStr(
@@ -43,4 +49,4 @@
// BTE-NOT: !"sign-return-address-with-bkey"
// B-KEY: !{i32 8, !"sign-return-address-with-bkey", i32 1}
-void foo() {}
+void foo() {}
nickdesaulniers wrote:
retain newline at EOF
https://github.com/llvm/llvm-project/pull/82819
__
@@ -1398,6 +1400,42 @@ class TargetInfo : public TransferrableTargetInfo,
}
llvm_unreachable("Unexpected SignReturnAddressKeyKind");
}
+
+ public:
+BranchProtectionInfo() = default;
nickdesaulniers wrote:
Do we still need the default const
nickdesaulniers wrote:
@overmighty do you need one of us to commit this for you? Thanks for working on
it!
https://github.com/llvm/llvm-project/pull/83431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
https://github.com/nickdesaulniers closed
https://github.com/llvm/llvm-project/pull/83431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -660,15 +660,23 @@ def Clz : Builtin, BitShort_Int_Long_LongLongTemplate {
let Prototype = "int(unsigned T)";
}
-// FIXME: Add int clzimax(uintmax_t)
+def Clzg : Builtin {
+ let Spellings = ["__builtin_clzg"];
+ let Attributes = [NoThrow, Const, CustomTypeChecking];
---
@@ -660,15 +660,23 @@ def Clz : Builtin, BitShort_Int_Long_LongLongTemplate {
let Prototype = "int(unsigned T)";
}
-// FIXME: Add int clzimax(uintmax_t)
+def Clzg : Builtin {
+ let Spellings = ["__builtin_clzg"];
+ let Attributes = [NoThrow, Const, CustomTypeChecking];
---
https://github.com/nickdesaulniers commented:
thanks for the patch!
https://github.com/llvm/llvm-project/pull/86577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -12367,8 +12368,17 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
BuiltinOp != Builtin::BI__lzcnt &&
BuiltinOp != Builtin::BI__lzcnt64;
-if (ZeroIsUndefined && !Val)
- return Error(E);
+i
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/86577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -12354,6 +12354,7 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
case Builtin::BI__builtin_clzl:
case Builtin::BI__builtin_clzll:
case Builtin::BI__builtin_clzs:
+ case Builtin::BI__builtin_clzg:
nickdesaulniers wrote:
ctzg too?
@@ -12410,12 +12420,22 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
case Builtin::BI__builtin_ctz:
case Builtin::BI__builtin_ctzl:
case Builtin::BI__builtin_ctzll:
- case Builtin::BI__builtin_ctzs: {
+ case Builtin::BI__builtin_ctzs:
+ case Builti
@@ -12354,6 +12354,7 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
case Builtin::BI__builtin_clzl:
case Builtin::BI__builtin_clzll:
case Builtin::BI__builtin_clzs:
+ case Builtin::BI__builtin_clzg:
nickdesaulniers wrote:
d'oh!
http
@@ -12367,8 +12368,17 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
BuiltinOp != Builtin::BI__lzcnt &&
BuiltinOp != Builtin::BI__lzcnt64;
-if (ZeroIsUndefined && !Val)
- return Error(E);
+i
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/86577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/86577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -12367,8 +12368,17 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
BuiltinOp != Builtin::BI__lzcnt &&
BuiltinOp != Builtin::BI__lzcnt64;
-if (ZeroIsUndefined && !Val)
- return Error(E);
+i
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/86577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/86577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -12367,8 +12368,17 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
BuiltinOp != Builtin::BI__lzcnt &&
BuiltinOp != Builtin::BI__lzcnt64;
-if (ZeroIsUndefined && !Val)
- return Error(E);
+i
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/86577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -12367,8 +12368,17 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
BuiltinOp != Builtin::BI__lzcnt &&
BuiltinOp != Builtin::BI__lzcnt64;
-if (ZeroIsUndefined && !Val)
- return Error(E);
+i
@@ -12367,8 +12368,17 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
BuiltinOp != Builtin::BI__lzcnt &&
BuiltinOp != Builtin::BI__lzcnt64;
-if (ZeroIsUndefined && !Val)
- return Error(E);
+i
@@ -12367,8 +12368,17 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
BuiltinOp != Builtin::BI__lzcnt &&
BuiltinOp != Builtin::BI__lzcnt64;
-if (ZeroIsUndefined && !Val)
- return Error(E);
+i
@@ -12410,12 +12420,22 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
case Builtin::BI__builtin_ctz:
case Builtin::BI__builtin_ctzl:
case Builtin::BI__builtin_ctzll:
- case Builtin::BI__builtin_ctzs: {
+ case Builtin::BI__builtin_ctzs:
+ case Builti
@@ -12367,8 +12368,17 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
BuiltinOp != Builtin::BI__lzcnt &&
BuiltinOp != Builtin::BI__lzcnt64;
-if (ZeroIsUndefined && !Val)
- return Error(E);
+i
https://github.com/nickdesaulniers approved this pull request.
thanks! are you able to merge or do you need me to?
https://github.com/llvm/llvm-project/pull/86577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
https://github.com/nickdesaulniers closed
https://github.com/llvm/llvm-project/pull/86577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,39 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+constexpr int increment(int& x) {
+ x++;
+ return x;
+}
+
+constexpr int test_clzg_0() {
+ int x = 0;
+ [[maybe_unused]] int unused = __builtin_clzg(0U, increment(x));
+ return x;
+}
@@ -0,0 +1,39 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+constexpr int increment(int& x) {
+ x++;
+ return x;
+}
+
+constexpr int test_clzg_0() {
+ int x = 0;
+ [[maybe_unused]] int unused = __builtin_clzg(0U, increment(x));
+ return x;
+}
nickdesaulniers wrote:
> I think I am generally deeply confused about what should be provided by the
> compiler and what should be provided by the C Standard Library on any given
> platform.
+1
> Doing otherwise and trying to be "helpful" in Clang only creates confusion
> and forces C librar
https://github.com/nickdesaulniers approved this pull request.
https://github.com/llvm/llvm-project/pull/86742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1980,6 +1981,23 @@ static void handleWeakRefAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
D->addAttr(::new (S.Context) WeakRefAttr(S.Context, AL));
}
+// Mark alias/ifunc target as used. For C++, we look up the demangled name
+// ignoring parameters. This should handle
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/87130
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1980,6 +1981,23 @@ static void handleWeakRefAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
D->addAttr(::new (S.Context) WeakRefAttr(S.Context, AL));
}
+// Mark alias/ifunc target as used. For C++, we look up the demangled name
+// ignoring parameters. This should handle
https://github.com/nickdesaulniers commented:
As the author of https://reviews.llvm.org/D54188 and the TODO added from there,
this patch is the right thing to do. I fixed a false positive diagnostic for C
and knew that the fix was insufficient for C++.
I do appreciate the abundance of caution
@@ -1,7 +1,35 @@
-// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunneeded-internal-declaration -x
c -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunused -x c -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunused -x c++ -verify %s
+
+#ifdef __cplusplus
+exter
@@ -1,7 +1,35 @@
-// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunneeded-internal-declaration -x
c -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunused -x c -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunused -x c++ -verify %s
+
+#ifdef __cplusplus
+exter
@@ -1,7 +1,35 @@
-// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunneeded-internal-declaration -x
c -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunused -x c -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunused -x c++ -verify %s
+
+#ifdef __cplusplus
+exter
@@ -1980,6 +1981,23 @@ static void handleWeakRefAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
D->addAttr(::new (S.Context) WeakRefAttr(S.Context, AL));
}
+// Mark alias/ifunc target as used. For C++, we look up the demangled name
+// ignoring parameters. This should handle
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/87130
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1980,6 +1981,23 @@ static void handleWeakRefAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
D->addAttr(::new (S.Context) WeakRefAttr(S.Context, AL));
}
+// Mark alias/ifunc target as used. For C++, we look up the demangled name
+// ignoring parameters. This should handle
@@ -1,7 +1,35 @@
-// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunneeded-internal-declaration -x
c -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunused -x c -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunused -x c++ -verify %s
+
+#ifdef __cplusplus
+exter
@@ -1,7 +1,35 @@
-// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunneeded-internal-declaration -x
c -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunused -x c -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -Wunused -x c++ -verify %s
+
+#ifdef __cplusplus
+exter
@@ -1980,6 +1981,23 @@ static void handleWeakRefAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
D->addAttr(::new (S.Context) WeakRefAttr(S.Context, AL));
}
+// Mark alias/ifunc target as used. For C++, we look up the demangled name
+// ignoring parameters. This should handle
@@ -5167,6 +5199,41 @@ void llvm::UpgradeFunctionAttributes(Function &F) {
F.removeRetAttrs(AttributeFuncs::typeIncompatible(F.getReturnType()));
for (auto &Arg : F.args())
Arg.removeAttrs(AttributeFuncs::typeIncompatible(Arg.getType()));
+
+ if (!ModuleMetadataIsMater
@@ -0,0 +1,126 @@
+; Check the inliner doesn't inline a function with different sign return
address schemes.
+; RUN: opt < %s -passes=inline -S | FileCheck %s
+
+declare void @init(ptr)
+
+define internal i32 @foo_all() #0 {
+ ret i32 43
+}
+
+define internal i32 @foo_nonleaf()
@@ -0,0 +1,126 @@
+; Check the inliner doesn't inline a function with different sign return
address schemes.
+; RUN: opt < %s -passes=inline -S | FileCheck %s
+
+declare void @init(ptr)
+
+define internal i32 @foo_all() #0 {
+ ret i32 43
+}
+
+define internal i32 @foo_nonleaf()
@@ -1606,6 +1606,10 @@ Error IRLinker::run() {
// Loop over all of the linked values to compute type mappings.
computeTypeMapping();
+ // Update function attributes before copy them to destation module.
nickdesaulniers wrote:
s/copy/copying/
https://git
@@ -5155,7 +5155,39 @@ struct StrictFPUpgradeVisitor : public
InstVisitor {
};
} // namespace
-void llvm::UpgradeFunctionAttributes(Function &F) {
+static void
+CopyModuleAttributeToFunction(Function &F, StringRef FnAttrName,
+ StringRef ModAttrNa
@@ -2110,6 +2110,21 @@ llvm::InlineResult llvm::InlineFunction(CallBase &CB,
InlineFunctionInfo &IFI,
return InlineResult::failure("incompatible strictfp attributes");
}
+ // Do not inline function with a different signing scheme.
+ if (CalledFunc->getFnAttribute("sig
@@ -5155,7 +5155,39 @@ struct StrictFPUpgradeVisitor : public
InstVisitor {
};
} // namespace
-void llvm::UpgradeFunctionAttributes(Function &F) {
+static void
+CopyModuleAttributeToFunction(Function &F, StringRef FnAttrName,
+ StringRef ModAttrNa
@@ -5155,7 +5155,39 @@ struct StrictFPUpgradeVisitor : public
InstVisitor {
};
} // namespace
-void llvm::UpgradeFunctionAttributes(Function &F) {
+static void
+CopyModuleAttributeToFunction(Function &F, StringRef FnAttrName,
+ StringRef ModAttrNa
@@ -0,0 +1,43 @@
+; Testcase to check that module with different branch-target-enforcement can
+; be mixed.
+;
+; RUN: llvm-as %s -o %t1.bc
+; RUN: llvm-as %p/Inputs/foo.ll -o %t2.bc
+; RUN: llvm-lto -exported-symbol main \
+; RUN: -exported-symbol foo \
+; RUN:
nickdesaulniers wrote:
thanks for the patch!
https://github.com/llvm/llvm-project/pull/80642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nickdesaulniers wrote:
Also, consider submitting your 3 commits as 3 distinct PRs. The first is ready
to land. I think the auto upgrade could be detached from the inlining
decisions.
Also, I'm kind of surprised you didn't have to change anything in clang codegen
of LLVM IR. Shouldn't clang
@@ -5155,7 +5155,39 @@ struct StrictFPUpgradeVisitor : public
InstVisitor {
};
} // namespace
-void llvm::UpgradeFunctionAttributes(Function &F) {
+static void
+CopyModuleAttributeToFunction(Function &F, StringRef FnAttrName,
+ StringRef ModAttrNa
@@ -0,0 +1,77 @@
+// Check that -fsanitize=signed-integer-wrap instruments with -fwrapv
+// RUN: %clang_cc1 -fwrapv -triple x86_64-apple-darwin -emit-llvm -o - %s
-fsanitize=signed-integer-wrap | FileCheck %s --check-prefix=CHECKSIW
+
+// Check that -fsanitize=signed-integer-over
@@ -3554,12 +3572,20 @@ Value
*ScalarExprEmitter::EmitOverflowCheckedBinOp(const BinOpInfo &Ops) {
const std::string *handlerName =
&CGF.getLangOpts().OverflowHandler;
if (handlerName->empty()) {
-// If the signed-integer-overflow sanitizer is enabled, emit a call
https://github.com/nickdesaulniers commented:
PATCH mostly LGTM
UBSan is documented clang/docs/UndefinedBehaviorSanitizer.rst
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
Please make sure to update the list [of available
checks](https://clang.llvm.org/docs/UndefinedBehaviorSani
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/80089
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,77 @@
+// Check that -fsanitize=signed-integer-wrap instruments with -fwrapv
nickdesaulniers wrote:
> I must be doing something wrong because it suggests I remove all my Check:
> ...'s and replace them with Check: {{.*}}
Huh, indeed. I can repro. Not
https://github.com/nickdesaulniers commented:
Rather than have a `-f` flag to opt into this extension, I think instead you
should just make it always available, then have tests that it can be used, but
will trigger diagnostics under `-Wpedantic` since it's technically a language
extension (IIU
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/84428
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 %s -verify=c -fsyntax-only -fflex-array-extensions
+
+// The test checks that flexible array members do not emit warnings when
+// -fflex-array-extensions when used in a union or alone in a structure.
+
+struct already_hidden {
+ int a;
-
@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 %s -verify=c -fsyntax-only -fflex-array-extensions
+
+// The test checks that flexible array members do not emit warnings when
+// -fflex-array-extensions when used in a union or alone in a structure.
+
+struct already_hidden {
+ int a;
-
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/84428
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nickdesaulniers wrote:
> I didn't do this because it seemed like this would change a lot of existing
> test cases
Can you give some examples of tests that would fail? If we have tests checking
that these fail, then perhaps those tests should add `-Werror=pedantic` so that
they can continue to
nickdesaulniers wrote:
> Should I update this PR or create a new one?
Consider updating this one. Worst case, if my fellow reviewers disagree with
my suggestion, there's always `git reflog` for getting back to the initial
version.
> GCC does not support this in either!
Do you have a bug on
nickdesaulniers wrote:
> Left my comment on the main list
Sorry, I missed this. Where?
https://github.com/llvm/llvm-project/pull/84428
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nickdesaulniers wrote:
> [Since the C standard requires the test case to be
> diagnosed](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548#c3)
I wonder what part of the spec discusses this? Perhaps it's worth having the
citation, just in case it helps revise the spec here one day.
https://g
nickdesaulniers wrote:
> C23 6.7.3.2p20: "As a special case, the last member of a structure with more
> than one named member may have an incomplete array type; this is called a
> flexible array member. ..."
Thanks! Yeah, I wonder if that could have been "of a structure _or union_ " (as
in wa
nickdesaulniers wrote:
But then we (and GCC and MSVC) support the `[0]` extension syntax. So it's not
like codegen is impossible.
https://godbolt.org/z/PGa9KWGxq
```c
union foo {
int a;
int b[]; // error: flexible array member 'b' in a union is not allowed
};
union bar {
nickdesaulniers wrote:
Looks like the linter is upset with pre-existing changes. ok2land. Are you
able to merge this @overmighty or do you need us to?
https://github.com/llvm/llvm-project/pull/82359
___
cfe-commits mailing list
cfe-commits@lists.llvm
https://github.com/nickdesaulniers closed
https://github.com/llvm/llvm-project/pull/82359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,11 @@
+/// This is the regression test for
https://github.com/llvm/llvm-project/issues/83050.
+/// This just needs to compile.
+// RUN: %clang_cc1 -x c++ -ffixed-point -S %s -o /dev/null
-triple=x86_64-linux -ffixed-point
nickdesaulniers wrote:
Consi
@@ -0,0 +1,11 @@
+/// This is the regression test for
https://github.com/llvm/llvm-project/issues/83050.
+/// This just needs to compile.
+// RUN: %clang_cc1 -x c++ -ffixed-point -S %s -o /dev/null
-triple=x86_64-linux -ffixed-point
+static constexpr unsigned short _Fract SQRT_F
nickdesaulniers wrote:
> @nickdesaulniers I am interested in implementing more builtins like this one.
> :)
Cool, I've filed:
1. https://github.com/llvm/llvm-project/issues/83075
2. https://github.com/llvm/llvm-project/issues/83076
Those would be helpful to have next, and I suspect as straigh
nickdesaulniers wrote:
For the commit message and PR description, please consider:
1. using a subject that describes more of what the patch does, such as "[clang]
fixes inf loop parsing fixed point literal"
2. put "Fixes #83050" in the commit body; when merged, github will auto close
the corres
@@ -0,0 +1,11 @@
+/// This is the regression test for
https://github.com/llvm/llvm-project/issues/83050.
+/// This just needs to compile.
+// RUN: %clang_cc1 -x c++ -ffixed-point -S %s -o /dev/null
-triple=x86_64-linux -ffixed-point
+static constexpr unsigned short _Fract SQRT_F
https://github.com/nickdesaulniers approved this pull request.
https://github.com/llvm/llvm-project/pull/83071
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
101 - 200 of 446 matches
Mail list logo
