<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/clang/test/OpenMP/single_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>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] Update the default version of OpenMP to 5.1</title>
<updated>2023-06-15T07:11:09+00:00</updated>
<author>
<name>Animesh Kumar</name>
<email>animesh.kumar@amd.com</email>
</author>
<published>2023-06-06T10:46:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0c6f2f629cc0017361310fa4c132090413a874db'/>
<id>0c6f2f629cc0017361310fa4c132090413a874db</id>
<content type='text'>
The default version of OpenMP is updated from 5.0 to 5.1 which means if -fopenmp is specified but -fopenmp-version is not specified with clang, the default version of OpenMP is taken to be 5.1.  After modifying the Frontend for that, various LIT tests were updated. This patch contains all such changes. At a high level, these are the patterns of changes observed in LIT tests -

  # RUN lines which mentioned `-fopenmp-version=50` need to kept only if the IR for version 5.0 and 5.1 are different. Otherwise only one RUN line with no version info(i.e. default version) needs to be there.

  # Test cases of this sort already had the RUN lines with respect to the older default version 5.0 and the version 5.1. Only swapping the version specification flag `-fopenmp-version` from newer version RUN line to older version RUN line is required.

  # Diagnostics: Remove the 5.0 version specific RUN lines if there was no difference in the Diagnostics messages with respect to the default 5.1.

  # Diagnostics: In case there was any difference in diagnostics messages between 5.0 and 5.1, mention version specific messages in tests.

  # If the test contained version specific ifdef's e.g. "#ifdef OMP5" but there were no RUN lines for any other version than 5.X, then bring the code guarded by ifdef's outside and remove the ifdef's.

  # Some tests had RUN lines for both 5.0 and 5.1 versions, but it is found that the IR for 5.0 is not different from the 5.1, therefore such RUN lines are redundant. So, such duplicated lines are removed.

  # To generate CHECK lines automatically, use the script llvm/utils/update_cc_test_checks.py

Reviewed By: saiislam, ABataev

Differential Revision: https://reviews.llvm.org/D129635

(cherry picked from commit 9dd2999907dc791136a75238a6000f69bf67cf4e)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The default version of OpenMP is updated from 5.0 to 5.1 which means if -fopenmp is specified but -fopenmp-version is not specified with clang, the default version of OpenMP is taken to be 5.1.  After modifying the Frontend for that, various LIT tests were updated. This patch contains all such changes. At a high level, these are the patterns of changes observed in LIT tests -

  # RUN lines which mentioned `-fopenmp-version=50` need to kept only if the IR for version 5.0 and 5.1 are different. Otherwise only one RUN line with no version info(i.e. default version) needs to be there.

  # Test cases of this sort already had the RUN lines with respect to the older default version 5.0 and the version 5.1. Only swapping the version specification flag `-fopenmp-version` from newer version RUN line to older version RUN line is required.

  # Diagnostics: Remove the 5.0 version specific RUN lines if there was no difference in the Diagnostics messages with respect to the default 5.1.

  # Diagnostics: In case there was any difference in diagnostics messages between 5.0 and 5.1, mention version specific messages in tests.

  # If the test contained version specific ifdef's e.g. "#ifdef OMP5" but there were no RUN lines for any other version than 5.X, then bring the code guarded by ifdef's outside and remove the ifdef's.

  # Some tests had RUN lines for both 5.0 and 5.1 versions, but it is found that the IR for 5.0 is not different from the 5.1, therefore such RUN lines are redundant. So, such duplicated lines are removed.

  # To generate CHECK lines automatically, use the script llvm/utils/update_cc_test_checks.py

Reviewed By: saiislam, ABataev

Differential Revision: https://reviews.llvm.org/D129635

(cherry picked from commit 9dd2999907dc791136a75238a6000f69bf67cf4e)
</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>
<entry>
<title>Revert "[OpenMP] Prefix outlined and reduction func names with original func's name"</title>
<updated>2023-04-19T16:08:49+00:00</updated>
<author>
<name>Itay Bookstein</name>
<email>itay.bookstein@nextsilicon.com</email>
</author>
<published>2023-04-19T16:08:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6fdd13e0ec61dfa5bd631ec44d2752d965c26436'/>
<id>6fdd13e0ec61dfa5bd631ec44d2752d965c26436</id>
<content type='text'>
This reverts commit 029bfc311d4d7d3cd90be81bb08c046848796d02.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 029bfc311d4d7d3cd90be81bb08c046848796d02.
</pre>
</div>
</content>
</entry>
<entry>
<title>[OpenMP] Prefix outlined and reduction func names with original func's name</title>
<updated>2023-04-19T16:05:21+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=029bfc311d4d7d3cd90be81bb08c046848796d02'/>
<id>029bfc311d4d7d3cd90be81bb08c046848796d02</id>
<content type='text'>
This patch attempts to prefix 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 attempts to prefix 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>
<entry>
<title>OpenMP: Use inbounds in EmitOMPAggregateAssign</title>
<updated>2023-01-13T00:03:10+00:00</updated>
<author>
<name>Matt Arsenault</name>
<email>Matthew.Arsenault@amd.com</email>
</author>
<published>2023-01-12T01:34:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=8efb8f776abf1cb66107c42b47e6a127828c4db0'/>
<id>8efb8f776abf1cb66107c42b47e6a127828c4db0</id>
<content type='text'>
This looked like a plausibly correct out of tree patch.
The changed testcases with the pragmas stripped out only use
inbounds GEPs so I assume this is correct.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This looked like a plausibly correct out of tree patch.
The changed testcases with the pragmas stripped out only use
inbounds GEPs so I assume this is correct.
</pre>
</div>
</content>
</entry>
<entry>
<title>[Clang] Use poison instead of undef where its used as placeholder [NFC]</title>
<updated>2022-12-11T16:18:06+00:00</updated>
<author>
<name>Manuel Brito</name>
<email>manuel.brito@tecnico.ulisboa.pt</email>
</author>
<published>2022-12-11T16:16:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2482dbff461e981203f9c691b24d6017de46a441'/>
<id>2482dbff461e981203f9c691b24d6017de46a441</id>
<content type='text'>
Differential Revision: https://reviews.llvm.org/D139745
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Differential Revision: https://reviews.llvm.org/D139745
</pre>
</div>
</content>
</entry>
</feed>
