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
https://github.com/AaronBallman approved this pull request.
I think the changes LGTM, but I do think we've got some more work to do to make
this a first-class extension. For example, we lack constant expression support:
```
struct S { int y[]; };
constexpr struct S a1 = { 8, 12 };
```
gives:
```
AaronBallman wrote:
> LGTM
>
> The one thing I'm worried about here is the possibility that a future C
> standard version standardizes a similar extension, but with different
> semantics (since we're not using any reserved keywords here). Like I
> mentioned before, that's very unlikely to hap
@@ -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/efriedma-quic approved this pull request.
LGTM
The one thing I'm worried about here is the possibility that a future C
standard version standardizes a similar extension, but with different semantics
(since we're not using any reserved keywords here). Like I mentioned before
@@ -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/hvdijk approved this pull request.
Looks good to me, thanks, aside from one typo in the release notes. Let me
pre-emptively mark this as approved. Just to confirm, the warnings are also
enabled by `-pedantic`? Is that worth mentioning in the release notes too? I'm
fine if yo
github-actions[bot] wrote:
:white_check_mark: With the latest revision this PR passed the C/C++ code
formatter.
https://github.com/llvm/llvm-project/pull/84428
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
github-actions[bot] wrote:
:white_check_mark: With the latest revision this PR passed the Python code
formatter.
https://github.com/llvm/llvm-project/pull/84428
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
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
@@ -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
_
hvdijk wrote:
Flexible array initialization is, roughly, implemented as building a different
type in which the flexible array member is replaced by an array of the right
size, initializing that, and then pretending it was the original type. It does
not surprise me too much that this does not w
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
efriedma-quic 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 commit.
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
hvdijk wrote:
The problem with `union { char x[]; } x = {0};` is in
`ConstStructBuilder::Build` ( `clang/lib/CodeGen/CGExprConstant.cpp`). It does:
```diff
// If this is a union, skip all the fields that aren't being initialized.
if (RD->isUnion() &&
!declaresSameEntity(ILE->getI
efriedma-quic wrote:
The code in question is comparing what Sema thinks the size of a variable
should be, versus the size of the variable we're actually emitting into LLVM
IR. So try dumping the value of "Init". If it looks wrong, we need to fix
constant emission. If it's right, probably so
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
@@ -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,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
efriedma-quic wrote:
The primary problem with allowing flexible arrays alone in structs/unions is
that you end up with a zero-size type. This leads to weird semantic issues
because standard C/C++ doesn't have any provision for zero-size types: pointer
arithmetic, struct layout, and initializa
@@ -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
@@ -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
AaronBallman wrote:
Separating out some bits of discussion here.
Standardization of flexible arrays in unions
---
We can dispense with this topic quickly: the standard doesn't allow this, if
the standard should be relaxed then someone needs to write a pap
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
erichkeane 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 { \
>
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
erichkeane 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
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 {
AaronBallman 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_ "
>
erichkeane 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_ "
> (a
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
AaronBallman 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.
C23
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
erichkeane wrote:
> > Left my comment on the main list
>
> Sorry, I missed this. Where?
Bad phrasing: I jsut meant here:
https://github.com/llvm/llvm-project/pull/84428#issuecomment-1987017272
I commented on the 'overall' patch, but then to do the 'needs revision', I
needed to add a review m
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
erichkeane 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,
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
https://github.com/erichkeane requested changes to this pull request.
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.
erichkeane wrote:
I'm pretty unmotivated here, I don't think it is worth allowing this all the
time thanks to it not really being a conforming extension, and I don't think it
is sufficiently worth creating a dialect over with the flag.
>From what I can see, the GCC folks are equally as unmoti
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/
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
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
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
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;
-
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;
-
@@ -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
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/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
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: Kees Cook (kees)
Changes
GNU and MSVC have extensions where flexible array members (or their equivalent)
can be in unions or alone in structs. This is already fully supported in Clang
through the 0-sized array ("fake flexible array
https://github.com/kees created https://github.com/llvm/llvm-project/pull/84428
GNU and MSVC have extensions where flexible array members (or their equivalent)
can be in unions or alone in structs. This is already fully supported in Clang
through the 0-sized array ("fake flexible array") extens
86 matches
Mail list logo
