<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/clang/test/CodeGen/flexible-array-init.c, branch users/nico/python-2</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>Reapply "[clang][CodeGen] Zero init unspecified fields in initializers in C" (#109898) (#110051)</title>
<updated>2024-10-14T23:32:24+00:00</updated>
<author>
<name>yabinc</name>
<email>yabinc@google.com</email>
</author>
<published>2024-10-14T23:32:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=627746581b8fde4143533937130f420bbbdf9ddf'/>
<id>627746581b8fde4143533937130f420bbbdf9ddf</id>
<content type='text'>
This reverts commit d50eaac12f0cdfe27e942290942b06889ab12a8c. Also fixes
a bug calculating offsets for bit fields in the original patch.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit d50eaac12f0cdfe27e942290942b06889ab12a8c. Also fixes
a bug calculating offsets for bit fields in the original patch.</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[clang][CodeGen] Zero init unspecified fields in initializers in C" (#109898)</title>
<updated>2024-09-25T03:31:54+00:00</updated>
<author>
<name>Eli Friedman</name>
<email>efriedma@quicinc.com</email>
</author>
<published>2024-09-25T03:31:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d50eaac12f0cdfe27e942290942b06889ab12a8c'/>
<id>d50eaac12f0cdfe27e942290942b06889ab12a8c</id>
<content type='text'>
Reverts llvm/llvm-project#97121

Causing failures on LNT bots; log shows a crash in
ConstStructBuilder::BuildStruct.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reverts llvm/llvm-project#97121

Causing failures on LNT bots; log shows a crash in
ConstStructBuilder::BuildStruct.</pre>
</div>
</content>
</entry>
<entry>
<title>[clang][CodeGen] Zero init unspecified fields in initializers in C (#97121)</title>
<updated>2024-09-25T02:06:20+00:00</updated>
<author>
<name>yabinc</name>
<email>yabinc@google.com</email>
</author>
<published>2024-09-25T02:06:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7a086e1b2dc05f54afae3591614feede727601fa'/>
<id>7a086e1b2dc05f54afae3591614feede727601fa</id>
<content type='text'>
When an initializer is provided to a variable, the Linux kernel relied
on the compiler to zero-initialize unspecified fields, as clarified in
https://www.spinics.net/lists/netdev/msg1007244.html.

But clang doesn't guarantee this:
1. For a union type, if an empty initializer is given, clang only
   initializes bytes for the first field, left bytes for other (larger)
   fields are marked as undef. Accessing those undef bytes can lead
   to undefined behaviors.
2. For a union type, if an initializer explicitly sets a field, left
   bytes for other (larger) fields are marked as undef.
3. When an initializer is given, clang doesn't zero initialize padding.

So this patch makes the following change:
1. In C, when an initializer is provided for a variable, zero-initialize
   undef and padding fields in the initializer.
2. Document the change in LanguageExtensions.rst.

As suggested in
https://github.com/llvm/llvm-project/issues/78034#issuecomment-2183437928,
the change isn't required by C23, but it's standards conforming to do
so.

Fixes: https://github.com/llvm/llvm-project/issues/97459</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When an initializer is provided to a variable, the Linux kernel relied
on the compiler to zero-initialize unspecified fields, as clarified in
https://www.spinics.net/lists/netdev/msg1007244.html.

But clang doesn't guarantee this:
1. For a union type, if an empty initializer is given, clang only
   initializes bytes for the first field, left bytes for other (larger)
   fields are marked as undef. Accessing those undef bytes can lead
   to undefined behaviors.
2. For a union type, if an initializer explicitly sets a field, left
   bytes for other (larger) fields are marked as undef.
3. When an initializer is given, clang doesn't zero initialize padding.

So this patch makes the following change:
1. In C, when an initializer is provided for a variable, zero-initialize
   undef and padding fields in the initializer.
2. Document the change in LanguageExtensions.rst.

As suggested in
https://github.com/llvm/llvm-project/issues/78034#issuecomment-2183437928,
the change isn't required by C23, but it's standards conforming to do
so.

Fixes: https://github.com/llvm/llvm-project/issues/97459</pre>
</div>
</content>
</entry>
<entry>
<title>[Clang][Sema] Allow flexible arrays in unions and alone in structs (#84428)</title>
<updated>2024-03-27T22:56:19+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2024-03-27T22:56:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=14ba782a87e16e9e15460a51f50e67e2744c26d9'/>
<id>14ba782a87e16e9e15460a51f50e67e2744c26d9</id>
<content type='text'>
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")
extension or when C99 flexible array members have been syntactically
obfuscated.

Clang needs to explicitly allow these extensions directly for C99
flexible arrays, since they are common code patterns in active use by
the
Linux kernel (and other projects). Such projects have been using either
0-sized arrays (which is considered deprecated in favor of C99 flexible
array members) or via obfuscated syntax, both of which complicate their
code bases.

For example, these do not error by default:
```
union one {
	int a;
	int b[0];
};

union two {
	int a;
	struct {
		struct { } __empty;
		int b[];
	};
};
```
But this does:
```
union three {
	int a;
	int b[];
};
```
Remove the default error diagnostics for this but continue to provide
warnings under Microsoft or GNU extensions checks. This will allow for
a seamless transition for code bases away from 0-sized arrays without
losing existing code patterns. Add explicit checking for the warnings
under various constructions.

Additionally fixes a CodeGen bug with flexible array members in unions
in C++, which was found when adding a testcase for:
```
union { char x[]; } z = {0};
```
which only had Sema tests originally.

Fixes #84565</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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")
extension or when C99 flexible array members have been syntactically
obfuscated.

Clang needs to explicitly allow these extensions directly for C99
flexible arrays, since they are common code patterns in active use by
the
Linux kernel (and other projects). Such projects have been using either
0-sized arrays (which is considered deprecated in favor of C99 flexible
array members) or via obfuscated syntax, both of which complicate their
code bases.

For example, these do not error by default:
```
union one {
	int a;
	int b[0];
};

union two {
	int a;
	struct {
		struct { } __empty;
		int b[];
	};
};
```
But this does:
```
union three {
	int a;
	int b[];
};
```
Remove the default error diagnostics for this but continue to provide
warnings under Microsoft or GNU extensions checks. This will allow for
a seamless transition for code bases away from 0-sized arrays without
losing existing code patterns. Add explicit checking for the warnings
under various constructions.

Additionally fixes a CodeGen bug with flexible array members in unions
in C++, which was found when adding a testcase for:
```
union { char x[]; } z = {0};
```
which only had Sema tests originally.

Fixes #84565</pre>
</div>
</content>
</entry>
<entry>
<title>[clang] Fix assertion failure when initializing union with FAM (#77298)</title>
<updated>2024-01-09T08:18:07+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2024-01-09T08:18:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c6bb89f308c6715edf3f35fb7c6257713ecfc614'/>
<id>c6bb89f308c6715edf3f35fb7c6257713ecfc614</id>
<content type='text'>
When initializing a union that constrain a struct with a flexible array
member, and the initializer list is empty, we currently trigger an
assertion failure. This happens because getFlexibleArrayInitChars()
assumes that the initializer list is non-empty.

Fixes https://github.com/llvm/llvm-project/issues/77085.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When initializing a union that constrain a struct with a flexible array
member, and the initializer list is empty, we currently trigger an
assertion failure. This happens because getFlexibleArrayInitChars()
assumes that the initializer list is non-empty.

Fixes https://github.com/llvm/llvm-project/issues/77085.</pre>
</div>
</content>
</entry>
<entry>
<title>Fix size of flexible array initializers, and re-enable assertions.</title>
<updated>2022-04-15T19:09:57+00:00</updated>
<author>
<name>Eli Friedman</name>
<email>efriedma@quicinc.com</email>
</author>
<published>2022-04-14T22:20:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4802edd1ac7a5aea8c8488b5baec221d722cbdde'/>
<id>4802edd1ac7a5aea8c8488b5baec221d722cbdde</id>
<content type='text'>
In D123649, I got the formula for getFlexibleArrayInitChars slightly
wrong: the flexible array elements can be contained in the tail padding
of the struct.  Fix the formula to account for that.

With the fixed formula, we run into another issue: in some cases, we
were emitting extra padding for flexible arrray initializers. Fix
CGExprConstant so it uses a packed struct when necessary, to avoid this
extra padding.

Differential Revision: https://reviews.llvm.org/D123826
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In D123649, I got the formula for getFlexibleArrayInitChars slightly
wrong: the flexible array elements can be contained in the tail padding
of the struct.  Fix the formula to account for that.

With the fixed formula, we run into another issue: in some cases, we
were emitting extra padding for flexible arrray initializers. Fix
CGExprConstant so it uses a packed struct when necessary, to avoid this
extra padding.

Differential Revision: https://reviews.llvm.org/D123826
</pre>
</div>
</content>
</entry>
<entry>
<title>Comment out assertions about initializer size added in D123649.</title>
<updated>2022-04-14T20:58:17+00:00</updated>
<author>
<name>Eli Friedman</name>
<email>efriedma@quicinc.com</email>
</author>
<published>2022-04-14T20:50:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6cf0b1b3da3e8662baf030a2d741e3becaaab2b0'/>
<id>6cf0b1b3da3e8662baf030a2d741e3becaaab2b0</id>
<content type='text'>
They're causing failures in LLVM test-suite.  Added some regression
tests that explain the issue.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
They're causing failures in LLVM test-suite.  Added some regression
tests that explain the issue.
</pre>
</div>
</content>
</entry>
<entry>
<title>[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences</title>
<updated>2020-12-31T08:27:11+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>i@maskray.me</email>
</author>
<published>2020-12-31T08:27:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=fd739804e0591468762eb87488a497a3f7d4afb0'/>
<id>fd739804e0591468762eb87488a497a3f7d4afb0</id>
<content type='text'>
For a default visibility external linkage definition, dso_local is set for ELF
-fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar
to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences.

To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition,
which sets dso_local for default visibility external linkage definitions.

To make this flip smooth and enable future (dso_local as definition default),
this patch replaces (function) `define ` with `define{{.*}} `,
(variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For a default visibility external linkage definition, dso_local is set for ELF
-fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar
to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences.

To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition,
which sets dso_local for default visibility external linkage definitions.

To make this flip smooth and enable future (dso_local as definition default),
this patch replaces (function) `define ` with `define{{.*}} `,
(variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition"</title>
<updated>2020-02-03T18:09:39+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>maskray@google.com</email>
</author>
<published>2020-02-03T18:09:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=dbc96b518b619d37aacf670e1a9d3b90b5614dd2'/>
<id>dbc96b518b619d37aacf670e1a9d3b90b5614dd2</id>
<content type='text'>
This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e.

Accidentally committed.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e.

Accidentally committed.
</pre>
</div>
</content>
</entry>
<entry>
<title>[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition</title>
<updated>2020-02-03T17:52:48+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>maskray@google.com</email>
</author>
<published>2020-02-02T20:23:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=789a46f2d742e11edaade28cb59a0f4d2a1d770e'/>
<id>789a46f2d742e11edaade28cb59a0f4d2a1d770e</id>
<content type='text'>
Summary:
Clang -fpic defaults to -fno-semantic-interposition (GCC -fpic defaults
to -fsemantic-interposition).
Users need to specify -fsemantic-interposition to get semantic
interposition behavior.

Semantic interposition is currently a best-effort feature. There may
still be some cases where it is not handled well.

Reviewers: peter.smith, rnk, serge-sans-paille, sfertile, jfb, jdoerfert

Subscribers: dschuff, jyknight, dylanmckay, nemanjai, jvesely, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, arphaman, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D73865
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
Clang -fpic defaults to -fno-semantic-interposition (GCC -fpic defaults
to -fsemantic-interposition).
Users need to specify -fsemantic-interposition to get semantic
interposition behavior.

Semantic interposition is currently a best-effort feature. There may
still be some cases where it is not handled well.

Reviewers: peter.smith, rnk, serge-sans-paille, sfertile, jfb, jdoerfert

Subscribers: dschuff, jyknight, dylanmckay, nemanjai, jvesely, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, arphaman, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D73865
</pre>
</div>
</content>
</entry>
</feed>
