<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/clang/test/OpenMP/parallel_master_taskloop_simd_firstprivate_codegen.cpp, branch main</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>[IRBuilder] Generate nuw GEPs for struct member accesses (#99538)</title>
<updated>2024-08-09T12:25:04+00:00</updated>
<author>
<name>Hari Limaye</name>
<email>hari.limaye@arm.com</email>
</author>
<published>2024-08-09T12:25:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=94473f4db6a6f5f12d7c4081455b5b596094eac5'/>
<id>94473f4db6a6f5f12d7c4081455b5b596094eac5</id>
<content type='text'>
Generate nuw GEPs for struct member accesses, as inbounds + non-negative
implies nuw.

Regression tests are updated using update scripts where possible, and by
find + replace where not.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Generate nuw GEPs for struct member accesses, as inbounds + non-negative
implies nuw.

Regression tests are updated using update scripts where possible, and by
find + replace where not.</pre>
</div>
</content>
</entry>
<entry>
<title>[CodeGen] Simplify codegen for array initialization (#93956)</title>
<updated>2024-06-10T07:19:55+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2024-06-10T07:19:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=12d24e0c56a154c88247e55c7c352030e4d9073d'/>
<id>12d24e0c56a154c88247e55c7c352030e4d9073d</id>
<content type='text'>
This makes codegen for array initialization simpler in two ways:
1. Drop the zero-index GEP at the start, which is no longer needed with
opaque pointers.
2. Emit GEPs directly to the correct element, instead of having a long
chain of +1 GEPs. This is more canonical, and also avoids regressions in
unoptimized builds from #93823.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This makes codegen for array initialization simpler in two ways:
1. Drop the zero-index GEP at the start, which is no longer needed with
opaque pointers.
2. Emit GEPs directly to the correct element, instead of having a long
chain of +1 GEPs. This is more canonical, and also avoids regressions in
unoptimized builds from #93823.</pre>
</div>
</content>
</entry>
<entry>
<title>[Clang] Regenerate test checks (NFC)</title>
<updated>2024-05-31T09:18:17+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2024-05-31T09:16:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=de32a3df354f1d01c0a5c81285ac786cea9d8bdf'/>
<id>de32a3df354f1d01c0a5c81285ac786cea9d8bdf</id>
<content type='text'>
To minimize diffs in an upcoming change.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To minimize diffs in an upcoming change.
</pre>
</div>
</content>
</entry>
<entry>
<title>Diagnose use of VLAs in C++ by default</title>
<updated>2023-10-20T17:10:03+00:00</updated>
<author>
<name>Aaron Ballman</name>
<email>aaron@aaronballman.com</email>
</author>
<published>2023-10-20T17:08:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=84a3aadf0f2483dde0acfc4e79f2a075a5f35bd1'/>
<id>84a3aadf0f2483dde0acfc4e79f2a075a5f35bd1</id>
<content type='text'>
Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "Diagnose use of VLAs in C++ by default"</title>
<updated>2023-10-20T14:00:18+00:00</updated>
<author>
<name>Aaron Ballman</name>
<email>aaron@aaronballman.com</email>
</author>
<published>2023-10-20T14:00:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f5043f46c089dfd2d397c745784fd4dd972618e2'/>
<id>f5043f46c089dfd2d397c745784fd4dd972618e2</id>
<content type='text'>
This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm.org/buildbot/#/builders/164/builds/45262
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm.org/buildbot/#/builders/164/builds/45262
</pre>
</div>
</content>
</entry>
<entry>
<title>Diagnose use of VLAs in C++ by default</title>
<updated>2023-10-20T13:50:21+00:00</updated>
<author>
<name>Aaron Ballman</name>
<email>aaron@aaronballman.com</email>
</author>
<published>2023-10-20T13:48:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7339c0f782d5c70e0928f8991b0c05338a90c84c'/>
<id>7339c0f782d5c70e0928f8991b0c05338a90c84c</id>
<content type='text'>
Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565
</pre>
</div>
</content>
</entry>
<entry>
<title>[OpenMP][NFC] Update clang OpenMP tests</title>
<updated>2023-08-23T17:40:31+00:00</updated>
<author>
<name>Johannes Doerfert</name>
<email>johannes@jdoerfert.de</email>
</author>
<published>2023-08-20T23:35:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5a64ae75b5a05bdfc7ccb12d0b0958478b5d865b'/>
<id>5a64ae75b5a05bdfc7ccb12d0b0958478b5d865b</id>
<content type='text'>
Just re-running the script to make future updates easier
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Just re-running the script to make future updates easier
</pre>
</div>
</content>
</entry>
<entry>
<title>clang: Regenerate OpenMP tests</title>
<updated>2023-07-11T22:28:10+00:00</updated>
<author>
<name>Matt Arsenault</name>
<email>Matthew.Arsenault@amd.com</email>
</author>
<published>2023-07-08T15:27:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a709c49d75c62ecce9e5598994692546dfd1e02b'/>
<id>a709c49d75c62ecce9e5598994692546dfd1e02b</id>
<content type='text'>
Avoid diffs from no longer hardcoding metadata checks
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Avoid diffs from no longer hardcoding metadata checks
</pre>
</div>
</content>
</entry>
<entry>
<title>[clang] Regenerate checks in OpenMP tests with opaque-pointers enabled</title>
<updated>2023-05-16T13:29:09+00:00</updated>
<author>
<name>Sergei Barannikov</name>
<email>barannikov88@gmail.com</email>
</author>
<published>2023-05-16T13:10:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=44e99c75b7a83a302767fcf55805e4ef82b9baed'/>
<id>44e99c75b7a83a302767fcf55805e4ef82b9baed</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[OpenMP] Prefix outlined and reduction func names with original func's name</title>
<updated>2023-04-19T20:00:26+00:00</updated>
<author>
<name>Itay Bookstein</name>
<email>itay.bookstein@nextsilicon.com</email>
</author>
<published>2022-12-23T09:35:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=782c59a4eef0bca8546b0cfbb1e48a9fcd044c93'/>
<id>782c59a4eef0bca8546b0cfbb1e48a9fcd044c93</id>
<content type='text'>
This patch prefixes omp outlined helpers and reduction funcs
with the original function's name.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D140722
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch prefixes omp outlined helpers and reduction funcs
with the original function's name.

Reviewed By: jdoerfert

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