<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in generated-funcs.c.generated.expected</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>b16a3b4f - [Clang] Add -no-opaque-pointers to more tests (NFC)</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected#b16a3b4f</link>
        <description>[Clang] Add -no-opaque-pointers to more tests (NFC)This adds the flag to more tests that were not caught by themass-migration in 532dc62b907554b3f07f17205674aa71e76fc863.

            List of files:
            /llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected</description>
        <pubDate>Thu, 07 Apr 2022 10:15:37 +0000</pubDate>
        <dc:creator>Nikita Popov &lt;npopov@redhat.com&gt;</dc:creator>
    </item>
<item>
        <title>0dd49a56 - Use functions with prototypes when appropriate; NFC</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected#0dd49a56</link>
        <description>Use functions with prototypes when appropriate; NFCA significant number of our tests in C accidentally use functionswithout prototypes. This patch converts the function signatures to havea prototype for the situations where the test is not specific to K&amp;R Cdeclarations. e.g.,  void func();becomes  void func(void);This is the eighth batch of tests being updated (there are asignificant number of other tests left to be updated).

            List of files:
            /llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected</description>
        <pubDate>Sat, 12 Feb 2022 12:23:43 +0000</pubDate>
        <dc:creator>Aaron Ballman &lt;aaron@aaronballman.com&gt;</dc:creator>
    </item>
<item>
        <title>ac90dfc4 - Revert &quot;[OpenMP] Codegen aggregate for outlined function captures&quot;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected#ac90dfc4</link>
        <description>Revert &quot;[OpenMP] Codegen aggregate for outlined function captures&quot;This reverts commit 1d66649adf28d48ae1731516d87fb899426e3349.Revert to fix AMG GPU issue.

            List of files:
            /llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected</description>
        <pubDate>Tue, 21 Sep 2021 20:20:39 +0000</pubDate>
        <dc:creator>Giorgis Georgakoudis &lt;georgakoudis1@llnl.gov&gt;</dc:creator>
    </item>
<item>
        <title>1d66649a - [OpenMP] Codegen aggregate for outlined function captures</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected#1d66649a</link>
        <description>[OpenMP] Codegen aggregate for outlined function capturesParallel regions are outlined as functions with capture variables explicitly generated as distinct parameters in the function&apos;s argument list. That complicates the fork_call interface in the OpenMP runtime: (1) the fork_call is variadic since there is a variable number of arguments to forward to the outlined function, (2) wrapping/unwrapping arguments happens in the OpenMP runtime, which is sub-optimal, has been a source of ABI bugs, and has a hardcoded limit (16) in the number of arguments, (3)  forwarded arguments must cast to pointer types, which complicates debugging. This patch avoids those issues by aggregating captured arguments in a struct to pass to the fork_call.Reviewed By: jdoerfert, jhuber6Differential Revision: https://reviews.llvm.org/D102107

            List of files:
            /llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected</description>
        <pubDate>Tue, 21 Sep 2021 00:12:14 +0000</pubDate>
        <dc:creator>Giorgis Georgakoudis &lt;georgakoudis1@llnl.gov&gt;</dc:creator>
    </item>
<item>
        <title>fb0cf017 - Revert &quot;[OpenMP] Codegen aggregate for outlined function captures&quot;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected#fb0cf017</link>
        <description>Revert &quot;[OpenMP] Codegen aggregate for outlined function captures&quot;This reverts commit e9c7291cb25f071f1a1dfa4049ed9f5a8a217b3e.Fix failing tests

            List of files:
            /llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected</description>
        <pubDate>Mon, 19 Jul 2021 14:54:26 +0000</pubDate>
        <dc:creator>Giorgis Georgakoudis &lt;georgakoudis1@llnl.gov&gt;</dc:creator>
    </item>
<item>
        <title>e9c7291c - [OpenMP] Codegen aggregate for outlined function captures</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected#e9c7291c</link>
        <description>[OpenMP] Codegen aggregate for outlined function capturesParallel regions are outlined as functions with capture variables explicitly generated as distinct parameters in the function&apos;s argument list. That complicates the fork_call interface in the OpenMP runtime: (1) the fork_call is variadic since there is a variable number of arguments to forward to the outlined function, (2) wrapping/unwrapping arguments happens in the OpenMP runtime, which is sub-optimal, has been a source of ABI bugs, and has a hardcoded limit (16) in the number of arguments, (3)  forwarded arguments must cast to pointer types, which complicates debugging. This patch avoids those issues by aggregating captured arguments in a struct to pass to the fork_call.Reviewed By: jdoerfertDifferential Revision: https://reviews.llvm.org/D102107

            List of files:
            /llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected</description>
        <pubDate>Tue, 15 Jun 2021 17:30:12 +0000</pubDate>
        <dc:creator>Giorgis Georgakoudis &lt;georgakoudis1@llnl.gov&gt;</dc:creator>
    </item>
<item>
        <title>df729e2b - [OpenMP] Overhaul `declare target` handling</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected#df729e2b</link>
        <description>[OpenMP] Overhaul `declare target` handlingThis patch fixes various issues with our prior `declare target` handlingand extends it to support `omp begin declare target` as well.This started with PR49649 in mind, trying to provide a way for users toavoid the &quot;ref&quot; global use introduced for globals with internal linkage.From there it went down the rabbit hole, e.g., all variables, even`nohost` ones, were emitted into the device code so it was impossible todetermine if &quot;ref&quot; was needed late in the game (based on the name only).To make it really useful, `begin declare target` was needed as it cancarry the `device_type`. Not emitting variables eagerly had a rippleeffect. Finally, the precedence of the (explicit) declare target listitems needed to be taken into account, that meant we cannot just lookfor any declare target attribute to make a decision. This caused thehandling of functions to require fixup as well.I tried to clean up things while I was at it, e.g., we should not &quot;parsedeclarations and defintions&quot; as part of OpenMP parsing, this will alwaysbreak at some point. Instead, we keep track what region we are in andact on definitions and declarations instead, this is what we do fordeclare variant and other begin/end directives already.Highlights:  - new diagnosis for restrictions specificed in the standard,  - delayed emission of globals not mentioned in an explicit    list of a declare target,  - omission of `nohost` globals on the host and `host` globals on the    device,  - no explicit parsing of declarations in-between `omp [begin] declare    variant` and the corresponding end anymore, regular parsing instead,  - precedence for explicit mentions in `declare target` lists over    implicit mentions in the declaration-definition-seq, and  - `omp allocate` declarations will now replace an earlier emitted    global, if necessary.---Notes:The patch is larger than I hoped but it turns out that most changes doon their own lead to &quot;inconsistent states&quot;, which seem less desirableoverall.After working through this I feel the standard should remove theexplicit declare target forms as the delayed emission is horrible.That said, while we delay things anyway, it seems to me we check toooften for the current status even though that is often not sufficient toact upon. There seems to be a lot of duplication that can probably betrimmed down. Eagerly emitting some things seems pretty weak as anargument to keep so much logic around.---Reviewed By: ABataevDifferential Revision: https://reviews.llvm.org/D101030

            List of files:
            /llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected</description>
        <pubDate>Thu, 22 Apr 2021 05:57:28 +0000</pubDate>
        <dc:creator>Johannes Doerfert &lt;johannes@jdoerfert.de&gt;</dc:creator>
    </item>
<item>
        <title>cd1bd6e5 - [Utils] Check for more global information in update_test_checks</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected#cd1bd6e5</link>
        <description>[Utils] Check for more global information in update_test_checksThis allows to check for various globals (metadata/attributes/...) andalso resolves problems with globals (metadata/attributes/...) beingreused across different prefixes.Reviewed By: sstefan1Differential Revision: https://reviews.llvm.org/D94741

            List of files:
            /llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected</description>
        <pubDate>Fri, 15 Jan 2021 03:13:23 +0000</pubDate>
        <dc:creator>Johannes Doerfert &lt;johannes@jdoerfert.de&gt;</dc:creator>
    </item>
<item>
        <title>ac73b73c - [clang] Add mustprogress and llvm.loop.mustprogress attribute deduction</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected#ac73b73c</link>
        <description>[clang] Add mustprogress and llvm.loop.mustprogress attribute deductionSince C++11, the C++ standard has a forward progress guarantee[intro.progress], so all such functions must have the `mustprogress`requirement. In addition, from C11 and onwards, loops without a non-zeroconstant conditional or no conditional are also required to makeprogress (C11 6.8.5p6). This patch implements these attribute deductionsso they can be used by the optimization passes.Differential Revision: https://reviews.llvm.org/D86841

            List of files:
            /llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected</description>
        <pubDate>Mon, 02 Nov 2020 21:03:21 +0000</pubDate>
        <dc:creator>Atmn Patel &lt;a335pate@uwaterloo.ca&gt;</dc:creator>
    </item>
<item>
        <title>7c8bb409 - [UpdateCCTestChecks] Include generated functions if asked</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected#7c8bb409</link>
        <description>[UpdateCCTestChecks] Include generated functions if askedAdd the --include-generated-funcs option to update_cc_test_checks.py so that anyfunctions created by the compiler that don&apos;t exist in the source will also bechecked.We need to maintain the output order of generated function checks so thatCHECK-LABEL works properly.  To do so, maintain a list of functions output foreach prefix in the order they are output.  Use this list to output checks forgenerated functions in the proper order.Differential Revision: https://reviews.llvm.org/D83004

            List of files:
            /llvm-project-15.0.7/clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected</description>
        <pubDate>Mon, 13 Jan 2020 18:16:35 +0000</pubDate>
        <dc:creator>David Greene &lt;dag@cray.com&gt;</dc:creator>
    </item>
</channel>
</rss>
