@@ -1078,22 +1091,65 @@ void
ModuleSanitizerCoverage::InjectCoverageAtBlock(Function &F, BasicBlock &BB,
Store->setNoSanitizeMetadata();
}
if (Options.StackDepth && IsEntryBB && !IsLeafFunc) {
-// Check stack depth. If it's the deepest so far, record it.
Modu
@@ -158,6 +158,7 @@ struct SanitizerCoverageOptions {
bool PCTable = false;
bool NoPrune = false;
bool StackDepth = false;
+ int StackDepthCallbackMin = 0;
kees wrote:
Yeah, I wasn't sure if I should keep it with the other StackDepth var. I've
moved it
@@ -1078,22 +1091,61 @@ void
ModuleSanitizerCoverage::InjectCoverageAtBlock(Function &F, BasicBlock &BB,
Store->setNoSanitizeMetadata();
}
if (Options.StackDepth && IsEntryBB && !IsLeafFunc) {
-// Check stack depth. If it's the deepest so far, record it.
Modu
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/138323
>From 03e2eead7c4034c81c79619c1507dd27145aaa43 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Fri, 2 May 2025 10:51:02 -0700
Subject: [PATCH 1/2] [sancov] Introduce optional callback for stack-depth
tracking
Norma
@@ -1078,22 +1091,61 @@ void
ModuleSanitizerCoverage::InjectCoverageAtBlock(Function &F, BasicBlock &BB,
Store->setNoSanitizeMetadata();
}
if (Options.StackDepth && IsEntryBB && !IsLeafFunc) {
-// Check stack depth. If it's the deepest so far, record it.
Modu
kees wrote:
Okay, a couple small clean-ups, and I've also solved the lack of dynamic stack
size tracking.
https://github.com/llvm/llvm-project/pull/138323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
@@ -2361,6 +2361,13 @@ def fsanitize_coverage_ignorelist : Joined<["-"],
"fsanitize-coverage-ignorelist
HelpText<"Disable sanitizer coverage instrumentation for modules and
functions "
"that match the provided special case list, even the allowed
ones">,
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/138323
>From 549d71572f086a3ecab9d8cd4e546a55b078bf11 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Fri, 2 May 2025 10:51:02 -0700
Subject: [PATCH 1/3] [sancov] Introduce optional callback for stack-depth
tracking
Norma
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/138323
>From a481c0b96417c63786811e5bf118f3eb2e7dabb1 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Fri, 2 May 2025 10:51:02 -0700
Subject: [PATCH 1/2] [sancov] Introduce optional callback for stack-depth
tracking
Norma
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/138323
>From a481c0b96417c63786811e5bf118f3eb2e7dabb1 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Fri, 2 May 2025 10:51:02 -0700
Subject: [PATCH] [sancov] Introduce optional callback for stack-depth tracking
Normally -
https://github.com/kees closed https://github.com/llvm/llvm-project/pull/138385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2361,6 +2361,13 @@ def fsanitize_coverage_ignorelist : Joined<["-"],
"fsanitize-coverage-ignorelist
HelpText<"Disable sanitizer coverage instrumentation for modules and
functions "
"that match the provided special case list, even the allowed
ones">,
@@ -34,6 +34,7 @@ class SanitizerArgs {
std::vector CoverageIgnorelistFiles;
std::vector BinaryMetadataIgnorelistFiles;
int CoverageFeatures = 0;
+ int StackDepthCallbackMin = 0;
kees wrote:
Fixed.
https://github.com/llvm/llvm-project/pull/138323
_
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/138323
>From 027ff82e738f6bdf82f958a4774eb05d321b23ef Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Fri, 2 May 2025 10:51:02 -0700
Subject: [PATCH] [sancov] Introduce optional callback for stack-depth tracking
Normally -
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/138323
>From 729d249d3848c2e417174ed935bfefde5c048dc7 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Fri, 2 May 2025 10:51:02 -0700
Subject: [PATCH] [sancov] Introduce optional callback for stack-depth tracking
Normally -
kees wrote:
> This is also missing flag and IR tests.
Oh, yes, I will add those. Thanks!
https://github.com/llvm/llvm-project/pull/138323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
@@ -1078,22 +1092,44 @@ void
ModuleSanitizerCoverage::InjectCoverageAtBlock(Function &F, BasicBlock &BB,
Store->setNoSanitizeMetadata();
}
if (Options.StackDepth && IsEntryBB && !IsLeafFunc) {
-// Check stack depth. If it's the deepest so far, record it.
Modu
https://github.com/kees created https://github.com/llvm/llvm-project/pull/138385
Check for struct members that are structs filled only with function pointers by
recursively examining it. Since the lamba IsFunctionPointerOrForwardDecl cannot
call itself directly, move it into a helper function,
kees wrote:
> ⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️
>
> You can test this locally with the following command:
> View the diff from clang-format here.
Whoops, yes, I've fixed these now.
https://github.com/llvm/llvm-project/pull/138323
__
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/138323
>From 4c9e223b8f0457b3f3f66bbb3fa2688b49204cc9 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Fri, 2 May 2025 10:51:02 -0700
Subject: [PATCH] [sancov] Introduce optional callback for stack-depth tracking
Normally -
https://github.com/kees created https://github.com/llvm/llvm-project/pull/138323
Normally -fsanitize-coverage=stack-depth inserts inline arithmetic to update
thread_local __sancov_lowest_stack. To support stack depth tracking in the
Linux kernel, which does not implement traditional thread_loca
kees wrote:
This is looking good, but needs to support `void *` struct members (they are
treated as byte-sized for pointer arithmetic and `memcpy`). GCC has added
support for this. Otherwise, yes, this is building for Linux with some
(non-`void *`) annotations added and is operating correctly.
kees wrote:
Thanks for all the feedback! I'll continue working on this next week (I'm OoO
this week).
https://github.com/llvm/llvm-project/pull/132524
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
kees wrote:
> It looks like this is similar to `__builtin_constant_p` - what is the
> proposed behavior wrt. side effects in the evaluated expression? gcc and
> clang disagree about this a lot currently: https://godbolt.org/z/rbneznT9z
It is intended to have no side-effects. I followed the sam
https://github.com/kees created https://github.com/llvm/llvm-project/pull/132524
Provide a way to introspect expressions to see if they are assignable, which
becomes very useful in macros that want to perform additional work on arguments
that are lvalues. GCC is adding this builtin as well:
ht
@@ -8663,31 +8663,95 @@ static const RecordDecl
*GetEnclosingNamedOrTopAnonRecord(const FieldDecl *FD) {
return RD;
}
-static bool
-CheckCountExpr(Sema &S, FieldDecl *FD, Expr *E,
- llvm::SmallVectorImpl &Decls) {
+enum class CountedByInvalidPointeeTypeKind {
@@ -8663,31 +8663,95 @@ static const RecordDecl
*GetEnclosingNamedOrTopAnonRecord(const FieldDecl *FD) {
return RD;
}
-static bool
-CheckCountExpr(Sema &S, FieldDecl *FD, Expr *E,
- llvm::SmallVectorImpl &Decls) {
+enum class CountedByInvalidPointeeTypeKind {
kees wrote:
> Thankfully, this PR and my other PR (WIP) leave the door open. You can ignore
> all types and then mark a few as `no_wraps` or you can sanitize all types
> (the default) and mark a few as `wraps`.
Right, while I want to go full instrumentation, it's just not going to happen
in t
https://github.com/kees closed https://github.com/llvm/llvm-project/pull/110928
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
kees wrote:
> This is why I believe the gcc behavior is correct. When it knows the size
> given to `malloc` it uses that. When it doesn't know that it simply returns
> INT_MAX. When you ask gcc for the `__bdos` of the FAM it will use the `count`
> to calculate the size.
(nit: `SIZE_MAX`, not
kees wrote:
> > I’m a little concerned about not allowing the attribute in C++ - the
> > existence of other options in C++ does not mean they are an option (due to
> > various and sundry restrictions of C++ version upgrades different projects
> > have), but also you trivially end up in cases w
kees wrote:
> Can we split `-fsanitize=unsigned-integer-overflow` into
> `-fsanitize=unsigned-integer-overflow-patternA,unsigned-integer-overflow-patternB,unsigned-integer-overflow-patternC...`
> ?
>
> Then it's quite intuitive to disable them with `no-sanitize`.
Yikes, no way. The pattern ex
kees wrote:
> Before reland, please include me into review I'd like to understand why
> `-fsanitize-pattern-exclusion=all` is better than something like
> `-fno-sanitize=overflow-pattern-all`
The latter doesn't make sense to me. `no-sanitize` takes a list of sanitizers
to completely disable.
kees wrote:
> > I'd expect some kind of diagnostic when the specified field doesn't have a
> > corresponding counted_by field.
>
> So there's a complication with that. The use case for this builtin is to
> automatically set the `count` field during allocation in the Linux kernel.
> (It could
kees wrote:
> @rapidsna @hnrklssn @bwendling @kees Please let me know if you have any
> concerns about this refactor.
Yeah, FWIW, this is fine by me. I just want to make sure that we don't hide
stuff behind `-fbounds-safety` that doesn't need to be behind a flag (e.g.
`counted_by`, `sized_by`
https://github.com/kees approved this pull request.
Thanks for the updates! Let's get this in and continue with the rest of the
support. :)
https://github.com/llvm/llvm-project/pull/90786
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:/
@@ -0,0 +1,187 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+#define __counted_by(f) __attribute__((counted_by(f)))
+
+struct bar;
+
+struct not_found {
+ int count;
+ struct bar *fam[] __counted_by(bork); // expected-error {{use of undeclared
identifier 'bork'}}
+};
+
+s
kees wrote:
> Consider this example. It tries to illustrate why putting `__counted_by()` on
> a pointer to a structs containing flexible array members doesn't make sense.
>
> ```c
> struct HasFAM {
> int count;
> char buffer[] __counted_by(count); // This is OK
> };
>
> struct BufferOf
kees wrote:
> As @apple-fcloutier @rapidsna noted this is how `-fbounds-safety` is
> currently implemented (because its much simpler) but it is a restriction that
> could be lifted in future by only requiring `struct bar` to be defined at the
> point that `foo::bar` is used rather than when t
https://github.com/kees closed https://github.com/llvm/llvm-project/pull/89707
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
kees wrote:
My thinking about this attribute tends to follow from my desire not to change
the C type system, but rather to adjust the behavior of the sanitizers. This
means that it is possible to still build the Linux kernel without the
sanitizers (the build just ignores the attribute), or wit
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
kees wrote:
Ah-ha, thanks! Okay, I've updated the comments with just a minor
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/89707
>From c061c8f49f2b916bb5e60ec35d3e448ac13f2b72 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Mon, 22 Apr 2024 17:53:32 -0700
Subject: [PATCH 1/4] [CodeGen][i386] Move -mregparm storage earlier and fix
Runtime calls
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
kees wrote:
Comment added. Is this what you had in mind?
https://github.com
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/89707
>From c061c8f49f2b916bb5e60ec35d3e448ac13f2b72 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Mon, 22 Apr 2024 17:53:32 -0700
Subject: [PATCH 1/3] [CodeGen][i386] Move -mregparm storage earlier and fix
Runtime calls
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
kees wrote:
This seems like a large proposed change; is it worth it for this
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
kees wrote:
Oh, I think I see what you mean -- this is the common place wher
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
kees wrote:
I was trying to basically duplicate what was already done for th
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/89707
>From c061c8f49f2b916bb5e60ec35d3e448ac13f2b72 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Mon, 22 Apr 2024 17:53:32 -0700
Subject: [PATCH 1/2] [CodeGen][i386] Move -mregparm storage earlier and fix
Runtime calls
kees wrote:
This needs test cases, which I'll add tomorrow. I just wanted to get the core
logic up for review before I hit EOD...
https://github.com/llvm/llvm-project/pull/89707
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
https://github.com/kees created https://github.com/llvm/llvm-project/pull/89707
When building the Linux kernel for i386, the -mregparm=3 option is enabled.
Crashes were observed in the sanitizer handler functions, and the problem was
found to be mismatched calling convention.
As was fixed in c
kees wrote:
Does this still work for cases where there are multiple flexible arrays? e.g.
```
struct weird_protocol {
unsigned int cmd_type;
unsigned int data_len;
union {
struct cmd_one one[];
struct cmd_two two[];
struct cmd_three three[];
unsigned c
https://github.com/kees approved this pull request.
Tests and logic adjustment looks good to me.
https://github.com/llvm/llvm-project/pull/89126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe
kees wrote:
This now passes my behavioral testing suite for wrapping; yay! (The earlier
version didn't cover truncate, so this is very nice now.)
https://github.com/llvm/llvm-project/pull/86618
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
kees wrote:
I guess I don't have a strong opinion here, since these helpers are specific to
C++, and I've been generally trying to remove fixed-size 0-sized arrays in C
projects (i.e. the Linux kernel). I do care about C flexible arrays (and their
associated extensions), though. I suspect ther
https://github.com/kees commented:
I can't speak to the implementation details, but this passes my PoC tests that
examine subobjects.
https://github.com/llvm/llvm-project/pull/86858
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
kees wrote:
> My natural inclination is that it is array-like, but... that just makes me
> want `__is_array` to return `true` for it all the more.
Yes. An array is an array, regardless of its size. The size is just a storage
characteristic. It'd almost be like arguing that `NaN` isn't a float.
https://github.com/kees closed 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
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/84428
>From 59c81a85cd9652d02b15a79553259351a59e8534 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Thu, 7 Mar 2024 17:03:09 -0800
Subject: [PATCH] [Clang][Sema] Allow flexible arrays in unions and alone in
structs
GNU a
@@ -271,6 +271,9 @@ Improvements to Clang's diagnostics
- Clang now correctly diagnoses no arguments to a variadic macro parameter as
a C23/C++20 extension.
Fixes #GH84495.
+- ``-Wmicrosoft`` or ``-Wgnu`` is now required to diagnose C99 flexible
+ array members in a union
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/84428
>From eb5138b45fa450737600050ad8dabdcb27513d42 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Thu, 7 Mar 2024 17:03:09 -0800
Subject: [PATCH 1/8] [Clang][Sema]: Allow flexible arrays in unions and alone
in structs
@@ -21,10 +27,76 @@ struct __attribute((packed, aligned(4))) { char a; int x;
char z[]; } e = { 1, 2
struct { int x; char y[]; } f = { 1, { 13, 15 } };
// CHECK: @f ={{.*}} global <{ i32, [2 x i8] }> <{ i32 1, [2 x i8] c"\0D\0F" }>
-union {
- struct {
-int a;
-char b
https://github.com/kees 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
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/84428
>From eb5138b45fa450737600050ad8dabdcb27513d42 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Thu, 7 Mar 2024 17:03:09 -0800
Subject: [PATCH 1/7] [Clang][Sema]: Allow flexible arrays in unions and alone
in structs
https://github.com/kees 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
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/84428
>From eb5138b45fa450737600050ad8dabdcb27513d42 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Thu, 7 Mar 2024 17:03:09 -0800
Subject: [PATCH 1/7] [Clang][Sema]: Allow flexible arrays in unions and alone
in structs
kees wrote:
Ah, well, regardless, I think I found where the
`StructuredList->setInitializedFieldInUnion` was actually missing, and then I
could undo my zero-init-only and everything still appears fixed. Doing a full
debug build test run now...
https://github.com/llvm/llvm-project/pull/84428
_
kees wrote:
> > because we don't yet support non-zero initialization (as described in
> > commit
> > [5955a0f](https://github.com/llvm/llvm-project/commit/5955a0f9375a8c0b134eeb4a8de5155dcce7c94f))
>
> I'm confused. We support non-zero init, and there are tests for non-zero init
> in that com
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/84428
>From eb5138b45fa450737600050ad8dabdcb27513d42 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Thu, 7 Mar 2024 17:03:09 -0800
Subject: [PATCH 1/6] [Clang][Sema]: Allow flexible arrays in unions and alone
in structs
kees wrote:
> `InitListChecker::CheckStructUnionTypes` never calls
> `StructuredList->setInitializedFieldInUnion`
Ah-ha, thank you for the pointer. I think I've figured this out: initialization
was avoiding flexible arrays because we don't yet support non-zero
initialization (as described in
kees wrote:
> Is this an existing bug? i.e. it's the CodeGen test for `union { char x[]; }
> x = {0};` ... :P
Confirmed. Adding a CodeGen test for `union { char x[]; } x = {0};` without any
of the changes from this PR still hits the assert. I assume this was from
making flex array initializat
kees wrote:
Hmpf. Build failure encountered under an Assert:
```
# | Assertion failed: VarSize == CstSize && "Emitted constant has unexpected
size", file C:\ws\src\clang\lib\CodeGen\CodeGenModule.cpp, line 5294
# | PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/
and
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/84428
>From eb5138b45fa450737600050ad8dabdcb27513d42 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Thu, 7 Mar 2024 17:03:09 -0800
Subject: [PATCH 1/5] [Clang][Sema]: Allow flexible arrays in unions and alone
in structs
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/84428
>From eb5138b45fa450737600050ad8dabdcb27513d42 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Thu, 7 Mar 2024 17:03:09 -0800
Subject: [PATCH 1/3] [Clang][Sema]: Allow flexible arrays in unions and alone
in structs
https://github.com/kees 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
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,58 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only
// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compa
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/84428
>From eb5138b45fa450737600050ad8dabdcb27513d42 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Thu, 7 Mar 2024 17:03:09 -0800
Subject: [PATCH 1/2] [Clang][Sema]: Allow flexible arrays in unions and alone
in structs
@@ -1,13 +1,58 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only
// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compa
@@ -1,13 +1,58 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only
// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compa
kees wrote:
> That one ends up not being a problem, but presumably you are wanting to
> change that top-level 'struct' to be a 'union'?
No, I want to collapse the entire macro into just `TYPE NAME[]`. Right now the
Linux kernel uses the `DECLARE_FLEX_ARRAY` macro _in_ over 200 unions and
stru
kees wrote:
> There are currently over 200 separate unions using the work-around.
Specifically, this is what Linux uses for getting C99 flexible arrays in unions
and alone in structs:
```
#define DECLARE_FLEX_ARRAY(TYPE, NAME)\
struct { \
struct { } __empty_ ##
kees wrote:
> C99 added flexible array members, and the C99 rationale says the feature was
> added specifically as a replacement for the common idiom known as the "struct
> hack" for creating a structure containing a variable-size array.
This is my reasoning as well -- we (Linux dev hat on) ha
kees wrote:
> Left my comment on the main list, but I don't see this as a well motivated
> change, and even if GCC supported it, it would still be a very difficult to
> motivate extension without massive historical workloads already using it.
This is needed by the Linux kernel, and is in activ
kees wrote:
For historical reference, the first version of this PR is visible here now:
https://github.com/kees/llvm-project/commit/ce31f1d75f060b32e5dbc5756fe41cc8eaac83a6
https://github.com/llvm/llvm-project/pull/84428
___
cfe-commits mailing list
c
https://github.com/kees 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
https://github.com/kees updated https://github.com/llvm/llvm-project/pull/84428
>From eb5138b45fa450737600050ad8dabdcb27513d42 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Thu, 7 Mar 2024 17:03:09 -0800
Subject: [PATCH] [Clang][Sema]: Allow flexible arrays in unions and alone in
structs
GNU
kees wrote:
GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
Clang: https://github.com/llvm/llvm-project/issues/84565
https://github.com/llvm/llvm-project/pull/84428
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
kees 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 t
kees wrote:
> 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 (IIUC).
I didn't do this beca
@@ -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;
-
kees wrote:
With PR #82432 landed, this PR is redundant. Thanks for changing the option
name! Closing...
https://github.com/llvm/llvm-project/pull/80089
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
1 - 100 of 132 matches
Mail list logo
