Author: Chuanqi Xu
Date: 2024-03-13T13:57:52+08:00
New Revision: 4d62929852849f768d7397f634cfdebc85de96a4
URL:
https://github.com/llvm/llvm-project/commit/4d62929852849f768d7397f634cfdebc85de96a4
DIFF:
https://github.com/llvm/llvm-project/commit/4d62929852849f768d7397f634cfdebc85de96a4.diff
https://github.com/yamt updated https://github.com/llvm/llvm-project/pull/84137
>From 6c1bfa0aa292d81102a9aeb86ca4264516beb634 Mon Sep 17 00:00:00 2001
From: YAMAMOTO Takashi
Date: Fri, 9 Feb 2024 15:49:55 +0900
Subject: [PATCH 01/13] [WebAssembly] Implement an alternative translation for
quic-garvgupt wrote:
Thanks for the prompt reply and latest patchset.
1. Do we need to add documentation in RISCVUsage.rst file for xsfcease?
2. Also, as we are adding cease instruction in this PR, can we rename the PR to
include the cease instruction as well?
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Zepp (ZeppLu)
Changes
The documentation has already been there in `AttrDocs.td`, just lacks proper
reference
---
Full diff: https://github.com/llvm/llvm-project/pull/85022.diff
1 Files Affected:
- (modified)
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be
notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you,
https://github.com/ZeppLu created
https://github.com/llvm/llvm-project/pull/85022
The documentation has already been there in `AttrDocs.td`, just lacks proper
reference
>From 814db124d1f9bba3fe5878b93bc4cad520160005 Mon Sep 17 00:00:00 2001
From: Zepp
Date: Wed, 13 Mar 2024 13:25:43 +0800
https://github.com/topperc updated
https://github.com/llvm/llvm-project/pull/83896
>From f22a5cd30f77b2043f9c1f7f4482fad87fb79250 Mon Sep 17 00:00:00 2001
From: Craig Topper
Date: Mon, 4 Mar 2024 11:24:34 -0800
Subject: [PATCH 1/8] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1
topperc wrote:
> Thanks for clearing the confusion around whether rs1 would be optional or
> not. Can we also add lit tests for the aliases?
I already addded tests
https://github.com/llvm/llvm-project/pull/83896/commits/f6f43e9f8ffa8b58d63178d28c826d0009de2f3b
quic-garvgupt wrote:
Thanks for clearing the confusion around whether rs1 would be optional or not.
Can we also add lit tests for the aliases?
https://github.com/llvm/llvm-project/pull/83896
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/inclyc approved this pull request.
https://github.com/llvm/llvm-project/pull/84874
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zyn0217 wrote:
> I think some `static_assert` statements are required to demonstrate it does
> deduce the type of template parameters correctly.
Added. Although the patch doesn't touch that type deduction part and thus they
are theoretically not affected.
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/82310
>From 25f493da55e5cd7d46dda6fca6062aa56b6a3fd0 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Tue, 20 Feb 2024 14:54:14 +0800
Subject: [PATCH 1/7] The lambda call inside of a type alias
---
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/82310
>From 25f493da55e5cd7d46dda6fca6062aa56b6a3fd0 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Tue, 20 Feb 2024 14:54:14 +0800
Subject: [PATCH 1/7] The lambda call inside of a type alias
---
jcsxky wrote:
Probably I haven't understand these code deeply and I have some confusions on
this patch. I wonder has this patch solved essential issue, or it just fixed
the crash. I think some `static_assert` statements are required to demonstrate
it does deduce the type of template
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?=
Message-ID:
In-Reply-To:
@@ -1130,8 +1130,96 @@ struct BitTest {
static BitTest decodeBitTestBuiltin(unsigned BuiltinID);
};
+
+// Returns the first convergence
Author: Chuanqi Xu
Date: 2024-03-13T11:22:32+08:00
New Revision: 5d7796e674224be54c48a8db981f4134845bcc7c
URL:
https://github.com/llvm/llvm-project/commit/5d7796e674224be54c48a8db981f4134845bcc7c
DIFF:
https://github.com/llvm/llvm-project/commit/5d7796e674224be54c48a8db981f4134845bcc7c.diff
ian-twilightcoder wrote:
> I'm not excited by the complexity we are moving toward with the builtin
> headers. But I don't have any alternatives.
>
> Given the situation we are in, I think the change is ok. But I'd like someone
> else to look at it as it is tricky to reason about it. No
https://github.com/hdoc updated https://github.com/llvm/llvm-project/pull/84726
>From ec3f444913d9162de4494cdb09b336b1b00380fa Mon Sep 17 00:00:00 2001
From: hdoc
Date: Mon, 11 Mar 2024 01:13:25 -0700
Subject: [PATCH 1/3] Comment parsing: add argument parsing for @throw @throws
@exception
zyn0217 wrote:
@cor3ntin WDYT?
https://github.com/llvm/llvm-project/pull/83420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vsapsai wrote:
I'm not excited by the complexity we are moving toward with the builtin
headers. But I don't have any alternatives.
Given the situation we are in, I think the change is ok. But I'd like someone
else to look at it as it is tricky to reason about it. No blockers from me but
want
https://github.com/dougsonos edited
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -10778,6 +10778,101 @@ def warn_imp_cast_drops_unaligned : Warning<
"implicit cast from type %0 to type %1 drops __unaligned qualifier">,
InGroup>;
+def warn_func_effect_allocates : Warning<
+ "'%0' function '%1' must not allocate or deallocate memory">,
+ InGroup;
+
rjmccall wrote:
> @rjmccall Re asking GCC developers about gcc_struct on non-x86:
> https://gcc.gnu.org/pipermail/gcc/2024-January/243154.html. Either GCC devs
> aren't really worried about this or I can't properly write emails (what's
> totally possible).
Alright, well, we tried. I think
DanShaders wrote:
@rjmccall Re asking GCC developers about gcc_struct on non-x86:
https://gcc.gnu.org/pipermail/gcc/2024-January/243154.html. Either GCC devs
aren't really worried about this or I can't properly write emails (what's
totally possible).
@MaskRay Any chance you can look at this
shafik wrote:
It looks like it passed on your last commit but you have a conflict now which
you need to resolve.
Can you merge or do you need help with that?
https://github.com/llvm/llvm-project/pull/80040
___
cfe-commits mailing list
https://github.com/DanShaders updated
https://github.com/llvm/llvm-project/pull/71148
>From d0484b032b13109a226c088f18cf0ccd6026bceb Mon Sep 17 00:00:00 2001
From: Dan Klishch
Date: Fri, 3 Nov 2023 21:18:06 -0400
Subject: [PATCH] [clang] Stub out gcc_struct attribute
This commit implements
@@ -10778,6 +10778,101 @@ def warn_imp_cast_drops_unaligned : Warning<
"implicit cast from type %0 to type %1 drops __unaligned qualifier">,
InGroup>;
+def warn_func_effect_allocates : Warning<
+ "'%0' function '%1' must not allocate or deallocate memory">,
+ InGroup;
+
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+// RUN: %clang_cc1 -std=c++23 -verify %s
+// expected-no-diagnostics
+
+template concept IsOk = requires() { typename T::Float; };
+
+template struct Thing;
+
+template struct Foobar {
jcsxky wrote:
zyn0217 wrote:
> I'm reducing the test case. In the meantime, should this be reverted?
I think this depends on the case. Note the issues addressed by this patch may
not only cause some crashes in debug build, but probably lead to incorrect
constraint evaluation in release build, which means
@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID ,
const ASTContext ) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::~FunctionEffect() =
https://github.com/jcsxky updated
https://github.com/llvm/llvm-project/pull/84671
>From fd1711b61478866ca1cd890a3dcfe3d1a8e1c211 Mon Sep 17 00:00:00 2001
From: huqizhi
Date: Sun, 10 Mar 2024 16:11:18 +0800
Subject: [PATCH] [Clang][Sema] Fix a bug on type constraint checking
---
https://github.com/yinying-lisa-li updated
https://github.com/llvm/llvm-project/pull/78000
>From 3d2716ad6088f600c14d6ff724aa90453130a1f7 Mon Sep 17 00:00:00 2001
From: Yeoul Na
Date: Mon, 18 Dec 2023 10:58:16 +0900
Subject: [PATCH 01/13] [BoundsSafety] Introduce CountAttributedType
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/84285
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Chuanqi Xu
Date: 2024-03-13T09:26:53+08:00
New Revision: 9d6c43b4aed117f53167e72749b31a943941345d
URL:
https://github.com/llvm/llvm-project/commit/9d6c43b4aed117f53167e72749b31a943941345d
DIFF:
https://github.com/llvm/llvm-project/commit/9d6c43b4aed117f53167e72749b31a943941345d.diff
https://github.com/petrhosek updated
https://github.com/llvm/llvm-project/pull/84671
>From 1b71ce0ece77060591edaf69794e184d58ad9b15 Mon Sep 17 00:00:00 2001
From: huqizhi
Date: Sun, 10 Mar 2024 16:11:18 +0800
Subject: [PATCH] [Clang][Sema] Fix a bug on type constraint checking
---
https://github.com/bob80905 updated
https://github.com/llvm/llvm-project/pull/83938
>From 7453ffdea39c624221c9696394bbd47be7eec662 Mon Sep 17 00:00:00 2001
From: Joshua Batista
Date: Mon, 4 Mar 2024 13:42:02 -0800
Subject: [PATCH 1/7] first try
---
clang/include/clang/Driver/Options.td | 4
https://github.com/DataCorrupted updated
https://github.com/llvm/llvm-project/pull/83896
>From f22a5cd30f77b2043f9c1f7f4482fad87fb79250 Mon Sep 17 00:00:00 2001
From: Craig Topper
Date: Mon, 4 Mar 2024 11:24:34 -0800
Subject: [PATCH 1/7] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -fsyntax-only -fblocks -verify %s
+// R UN: %clang_cc1 -fsyntax-only -fblocks -verify -x c -std=c23 %s
+
+#if !__has_attribute(clang_nolock)
+#error "the 'nolock' attribute is not available"
+#endif
+
+void unannotated(void);
+void
https://github.com/Sirraide updated
https://github.com/llvm/llvm-project/pull/84981
>From b60ff0c29f367306beb5ea0965dfaf5b7f361654 Mon Sep 17 00:00:00 2001
From: Sirraide
Date: Tue, 12 Mar 2024 13:53:34 +0100
Subject: [PATCH 1/4] [Clang] [CodeGen] Fix codegen bug in constant
initialisation in
@@ -0,0 +1,84 @@
+// RUN: %clang_cc1 -fsyntax-only -fblocks -verify %s
dougsonos wrote:
Thanks, yes, I will merge them (other than the one that is checking the AST
dump).
https://github.com/llvm/llvm-project/pull/84983
@@ -259,6 +259,10 @@ Bug Fixes in This Version
operator.
Fixes (#GH83267).
+- Clang no longer fails to codegen static ``const`` variables whose
initialiser performs
+ a floating-point division by 0 in C23.
+ Fixes (#GH84784).
Sirraide wrote:
Oh, I
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -fsyntax-only -fblocks -verify %s
+// R UN: %clang_cc1 -fsyntax-only -fblocks -verify -x c -std=c23 %s
+
+#if !__has_attribute(clang_nolock)
+#error "the 'nolock' attribute is not available"
+#endif
+
+void unannotated(void);
+void
https://github.com/Sirraide edited
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -395,6 +395,33 @@ bool Sema::checkStringLiteralArgumentAttr(const ParsedAttr
, unsigned ArgNum,
return checkStringLiteralArgumentAttr(AL, ArgExpr, Str, ArgLocation);
}
+/// Check if the argument \p ArgNum of \p Attr is a compile-time constant
+/// integer (boolean)
alexfh wrote:
I'm reducing the test case. In the meantime, should this be reverted?
https://github.com/llvm/llvm-project/pull/83997
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -259,6 +259,10 @@ Bug Fixes in This Version
operator.
Fixes (#GH83267).
+- Clang no longer fails to codegen static ``const`` variables whose
initialiser performs
+ a floating-point division by 0 in C23.
+ Fixes (#GH84784).
efriedma-quic wrote:
We
jinge90 wrote:
Using general option to pass device specific flags to device compilation should
be better approach, so this pr is not needed any more, thanks very much!
https://github.com/llvm/llvm-project/pull/76127
___
cfe-commits mailing list
@@ -339,6 +349,11 @@ namespace {
bool didParseNoDeref() const { return parsedNoDeref; }
+void setParsedNolock(unsigned char v) { parsedNolock = v; }
+unsigned char getParsedNolock() const { return parsedNolock; }
+void setParsedNoalloc(unsigned char v) {
yonghong-song wrote:
For this one:
> A kernel function will expect the uint to be sign-extended, not zero-extended.
I suspect riscv bpf jit will do sign-extension. @pulehui can confirm.
https://github.com/llvm/llvm-project/pull/84874
___
cfe-commits
https://github.com/jinge90 closed
https://github.com/llvm/llvm-project/pull/76127
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -395,6 +395,33 @@ bool Sema::checkStringLiteralArgumentAttr(const ParsedAttr
, unsigned ArgNum,
return checkStringLiteralArgumentAttr(AL, ArgExpr, Str, ArgLocation);
}
+/// Check if the argument \p ArgNum of \p Attr is a compile-time constant
+/// integer (boolean)
Author: Qizhi Hu
Date: 2024-03-13T08:42:22+08:00
New Revision: 8bda5657332c7a94900d3eb2891d2b86e60b0e68
URL:
https://github.com/llvm/llvm-project/commit/8bda5657332c7a94900d3eb2891d2b86e60b0e68
DIFF:
https://github.com/llvm/llvm-project/commit/8bda5657332c7a94900d3eb2891d2b86e60b0e68.diff
Author: Qizhi Hu
Date: 2024-03-13T08:42:22+08:00
New Revision: 8bda5657332c7a94900d3eb2891d2b86e60b0e68
URL:
https://github.com/llvm/llvm-project/commit/8bda5657332c7a94900d3eb2891d2b86e60b0e68
DIFF:
https://github.com/llvm/llvm-project/commit/8bda5657332c7a94900d3eb2891d2b86e60b0e68.diff
@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID ,
const ASTContext ) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::~FunctionEffect() =
@@ -2380,6 +2382,1239 @@ class UnsafeBufferUsageReporter : public
UnsafeBufferUsageHandler {
};
} // namespace
+//
=
+
+// Temporary debugging option
+#define FX_ANALYZER_VERIFY_DECL_LIST 1
+
craigflores wrote:
Test from "craig.flo...@sony.com".
https://github.com/llvm/llvm-project/pull/83447
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> My understanding is that you refer to the following part of the
> [specification](https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf):
Yes. For example, on RISC-V, the function `long f(unsigned g) { return (int)g;
}` compiles to just a "ret".
> clang would
https://github.com/jcsxky closed https://github.com/llvm/llvm-project/pull/83847
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vitalybuka approved this pull request.
https://github.com/llvm/llvm-project/pull/75481
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
yonghong-song wrote:
@pulehui Could you check whether with -mcpu=v2 (no-alu32 mode) we have
'unsigned int' related issue or not? Specifically, given a 'unsigned int' does
riscv use subregister to access 32-bit value, or use 64-bit register to access
the value without zero-extension of 32-bit
zyn0217 wrote:
> Was this sort of a behavior change expected?
I don't think so; a reproducer would be really appreciated.
https://github.com/llvm/llvm-project/pull/83997
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID ,
const ASTContext ) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::~FunctionEffect() =
yonghong-song wrote:
The following is an example to show 'unsigned int' case. The current behavior
(i.e., without this patch):
```
$ cat u.c
void foo(unsigned);
void bar(unsigned a, unsigned b) {
foo(a + b);
}
$ clang --target=bpf -O2 -c u.c && llvm-objdump -d u.o
u.o:file format
@@ -1094,6 +1114,27 @@ void ScalarExprEmitter::EmitIntegerTruncationCheck(Value
*Src, QualType SrcType,
{Src, Dst});
}
+static llvm::Value *EmitIsNegativeTestHelper(Value *V, QualType VType,
vitalybuka wrote:
I still see it here, does it
@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID ,
const ASTContext ) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::~FunctionEffect() =
alexfh wrote:
Hi folks, we've started seeing "implicit instantiation of undefined template"
compilation errors after this commit. In all cases code used to compile fine
before this commit. I haven't spotted any particular issues in the code (though
the examples are looked at are rather
@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID ,
const ASTContext ) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::~FunctionEffect() =
@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID ,
const ASTContext ) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::~FunctionEffect() =
@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID ,
const ASTContext ) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::~FunctionEffect() =
@@ -3666,11 +3673,14 @@ void FunctionProtoType::Profile(llvm::FoldingSetNodeID
, QualType Result,
// Finally we have a trailing return type flag (bool)
// combined with AArch64 SME Attributes, to save space:
// int
+ // Then add the FunctionEffects
//
//
https://github.com/vitalybuka requested changes to this pull request.
Removing from my pending reviews
https://github.com/llvm/llvm-project/pull/76127
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/eddyz87 closed
https://github.com/llvm/llvm-project/pull/84410
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: 4ast
Date: 2024-03-13T02:27:25+02:00
New Revision: 2aacb56e8361213c1bd69c2ceafdea3aa0ca9125
URL:
https://github.com/llvm/llvm-project/commit/2aacb56e8361213c1bd69c2ceafdea3aa0ca9125
DIFF:
https://github.com/llvm/llvm-project/commit/2aacb56e8361213c1bd69c2ceafdea3aa0ca9125.diff
LOG:
@@ -10778,6 +10778,101 @@ def warn_imp_cast_drops_unaligned : Warning<
"implicit cast from type %0 to type %1 drops __unaligned qualifier">,
InGroup>;
+def warn_func_effect_allocates : Warning<
+ "'%0' function '%1' must not allocate or deallocate memory">,
+ InGroup;
+
https://github.com/dougsonos edited
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dougsonos edited
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -10778,6 +10778,101 @@ def warn_imp_cast_drops_unaligned : Warning<
"implicit cast from type %0 to type %1 drops __unaligned qualifier">,
InGroup>;
+def warn_func_effect_allocates : Warning<
+ "'%0' function '%1' must not allocate or deallocate memory">,
+ InGroup;
+
@@ -3666,11 +3673,14 @@ void FunctionProtoType::Profile(llvm::FoldingSetNodeID
, QualType Result,
// Finally we have a trailing return type flag (bool)
// combined with AArch64 SME Attributes, to save space:
// int
+ // Then add the FunctionEffects
//
//
@@ -10778,6 +10778,101 @@ def warn_imp_cast_drops_unaligned : Warning<
"implicit cast from type %0 to type %1 drops __unaligned qualifier">,
InGroup>;
+def warn_func_effect_allocates : Warning<
+ "'%0' function '%1' must not allocate or deallocate memory">,
+ InGroup;
+
@@ -1402,6 +1402,29 @@ def CXX11NoReturn : InheritableAttr {
let Documentation = [CXX11NoReturnDocs];
}
+def NoLock : DeclOrTypeAttr {
+ let Spellings = [CXX11<"clang", "nolock">,
+ C23<"clang", "nolock">,
+ GNU<"clang_nolock">];
+
+ //
@@ -10778,6 +10778,101 @@ def warn_imp_cast_drops_unaligned : Warning<
"implicit cast from type %0 to type %1 drops __unaligned qualifier">,
InGroup>;
+def warn_func_effect_allocates : Warning<
+ "'%0' function '%1' must not allocate or deallocate memory">,
+ InGroup;
+
ian-twilightcoder wrote:
> > Sometimes it does confuse clang, at least I saw problems with a `typedef
> > enum` when I made an include-once header `textual`.
>
> Ok, I see. I would just consider it a bug, not a design decision.
>
> > That's correct. `#import` is an external source - often it
eddyz87 wrote:
Hi @efriedma-quic,
> That said, this isn't handling "unsigned int" correctly. "unsigned int" is
> supposed to be sign-extended on RISC-V targets. (How you resolve the conflict
> with PowerPC, where "unsigned int" is supposed to be zero-extended, I'm not
> sure.)
Could you
https://github.com/dougsonos edited
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1402,6 +1402,29 @@ def CXX11NoReturn : InheritableAttr {
let Documentation = [CXX11NoReturnDocs];
}
+def NoLock : DeclOrTypeAttr {
+ let Spellings = [CXX11<"clang", "nolock">,
+ C23<"clang", "nolock">,
+ GNU<"clang_nolock">];
+
+ //
https://github.com/eddyz87 approved this pull request.
https://github.com/llvm/llvm-project/pull/84874
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dougsonos reopened
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dougsonos wrote:
> > * Does the FunctionEffect / FunctionEffectSet abstraction make sense
> > (Type.h)? The idea is that an abstract effect system for functions could
> > easily support things like "TCB with types" or adding "nowait" to the
> > "nolock/noalloc" group of effects.
>
> Hmm,
https://github.com/dougsonos closed
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/PeimingLiu updated
https://github.com/llvm/llvm-project/pull/79230
>From 678cd8ea37f1d02c70fd09b7107542c8301c3bd2 Mon Sep 17 00:00:00 2001
From: Akira Hatanaka
Date: Tue, 16 Jan 2024 13:18:09 -0800
Subject: [PATCH 01/10] Add support for builtin_verbose_trap
The builtin
Sirraide wrote:
> * Conversions between functions / function pointers with and without the
> attribute work in C++ but not in C and I'm a bit lost (there's a bunch of
> debug logging around this e.g. Sema::IsFunctionConversion and
> Sema::ImpCastExprToType)
Er, I’ll see if I can find some
https://github.com/topperc edited
https://github.com/llvm/llvm-project/pull/83674
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/topperc edited
https://github.com/llvm/llvm-project/pull/83674
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -8927,8 +8927,13 @@ void Sema::CheckVariableDeclarationType(VarDecl *NewVD) {
}
}
- if (T->isRVVSizelessBuiltinType())
-checkRVVTypeSupport(T, NewVD->getLocation(), cast(CurContext));
+ if (T->isRVVSizelessBuiltinType() && isa(CurContext)) {
+const
Sirraide wrote:
> - Does the FunctionEffect / FunctionEffectSet abstraction make sense
> (Type.h)? The idea is that an abstract effect system for functions could
> easily support things like "TCB with types" or adding "nowait" to the
> "nolock/noalloc" group of effects.
Hmm, this is a
asl wrote:
> Maybe `emitRawPointerFromAddress` is better. I see a lot of functions
> starting with `emit` in CodeGen.
Works for me!
https://github.com/llvm/llvm-project/pull/67454
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
Sirraide wrote:
> * FunctionEffect/FunctionEffectSet need to be serialized as part of
> FunctionProtoType
That’s in `TypeProperties.td` from what I recall. You might be able to pack
this into an integer or something similar perhaps.
https://github.com/llvm/llvm-project/pull/84983
@@ -3173,41 +3174,46 @@ class ArrayType : public Type, public
llvm::FoldingSetNode {
return T->getTypeClass() == ConstantArray ||
T->getTypeClass() == VariableArray ||
T->getTypeClass() == IncompleteArray ||
- T->getTypeClass() ==
pinskia wrote:
Does it make sense to have some C testcases too? Likewise some testcases
testing the __attribute__ style attribute?
I would say more testcases the better really.
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/84874
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 477 matches
Mail list logo
