<?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 constexpr-variables.cu</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>f7f2e426 - PR47805: Use a single object for a function parameter in the caller and</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCUDA/constexpr-variables.cu#f7f2e426</link>
        <description>PR47805: Use a single object for a function parameter in the caller andcallee in constant evaluation.We previously made a deep copy of function parameters of class type whenpassing them, resulting in the destructor for the parameter applying tothe original argument value, ignoring any modifications made in thefunction body. This also meant that the &apos;this&apos; pointer of the functionparameter could be observed changing between the caller and the callee.This change completely reimplements how we model function parametersduring constant evaluation. We now model them roughly as if they werevariables living in the caller, albeit with an artificially reducedscope that covers only the duration of the function call, instead ofmodeling them as temporaries in the caller that we partially &quot;reparent&quot;into the callee at the point of the call. This brings some minordiagnostic improvements, as well as significantly reduced stack usageduring constant evaluation.

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCUDA/constexpr-variables.cu</description>
        <pubDate>Tue, 13 Oct 2020 17:03:02 +0000</pubDate>
        <dc:creator>Richard Smith &lt;richard@metafoo.co.uk&gt;</dc:creator>
    </item>
<item>
        <title>69f7c006 - Revert &quot;PR47805: Use a single object for a function parameter in the caller and&quot;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCUDA/constexpr-variables.cu#69f7c006</link>
        <description>Revert &quot;PR47805: Use a single object for a function parameter in the caller and&quot;Breaks a clangd unit test.This reverts commit 8f8b9f2cca0b73314342c721186ae9c860ca273c.

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCUDA/constexpr-variables.cu</description>
        <pubDate>Wed, 14 Oct 2020 02:31:41 +0000</pubDate>
        <dc:creator>Richard Smith &lt;richard@metafoo.co.uk&gt;</dc:creator>
    </item>
<item>
        <title>8f8b9f2c - PR47805: Use a single object for a function parameter in the caller and</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCUDA/constexpr-variables.cu#8f8b9f2c</link>
        <description>PR47805: Use a single object for a function parameter in the caller andcallee in constant evaluation.We previously made a deep copy of function parameters of class type whenpassing them, resulting in the destructor for the parameter applying tothe original argument value, ignoring any modifications made in thefunction body. This also meant that the &apos;this&apos; pointer of the functionparameter could be observed changing between the caller and the callee.This change completely reimplements how we model function parametersduring constant evaluation. We now model them roughly as if they werevariables living in the caller, albeit with an artificially reducedscope that covers only the duration of the function call, instead ofmodeling them as temporaries in the caller that we partially &quot;reparent&quot;into the callee at the point of the call. This brings some minordiagnostic improvements, as well as significantly reduced stack usageduring constant evaluation.

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCUDA/constexpr-variables.cu</description>
        <pubDate>Tue, 13 Oct 2020 17:03:02 +0000</pubDate>
        <dc:creator>Richard Smith &lt;richard@metafoo.co.uk&gt;</dc:creator>
    </item>
<item>
        <title>ab870f30 - Revert &quot;PR47805: Use a single object for a function parameter in the caller and&quot;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCUDA/constexpr-variables.cu#ab870f30</link>
        <description>Revert &quot;PR47805: Use a single object for a function parameter in the caller and&quot;The buildbots are displeased.This reverts commit 8d03a972ce8e92815ffe3d5d86aa027605ed92e2.

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCUDA/constexpr-variables.cu</description>
        <pubDate>Tue, 13 Oct 2020 22:59:00 +0000</pubDate>
        <dc:creator>Richard Smith &lt;richard@metafoo.co.uk&gt;</dc:creator>
    </item>
<item>
        <title>8d03a972 - PR47805: Use a single object for a function parameter in the caller and</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCUDA/constexpr-variables.cu#8d03a972</link>
        <description>PR47805: Use a single object for a function parameter in the caller andcallee in constant evaluation.We previously made a deep copy of function parameters of class type whenpassing them, resulting in the destructor for the parameter applying tothe original argument value, ignoring any modifications made in thefunction body. This also meant that the &apos;this&apos; pointer of the functionparameter could be observed changing between the caller and the callee.This change completely reimplements how we model function parametersduring constant evaluation. We now model them roughly as if they werevariables living in the caller, albeit with an artificially reducedscope that covers only the duration of the function call, instead ofmodeling them as temporaries in the caller that we partially &quot;reparent&quot;into the callee at the point of the call. This brings some minordiagnostic improvements, as well as significantly reduced stack usageduring constant evaluation.

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCUDA/constexpr-variables.cu</description>
        <pubDate>Tue, 13 Oct 2020 17:03:02 +0000</pubDate>
        <dc:creator>Richard Smith &lt;richard@metafoo.co.uk&gt;</dc:creator>
    </item>
<item>
        <title>049d8607 - [CUDA][HIP] Fix constexpr variables for C++17</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCUDA/constexpr-variables.cu#049d8607</link>
        <description>[CUDA][HIP] Fix constexpr variables for C++17constexpr variables are compile time constants and implicitly const, thereforethey are safe to emit on both device and host side. Besides, in many casesthey are intended for both device and host, therefore it makes senseto emit them on both device and host sides if necessary.In most cases constexpr variables are used as rvalue and the variablesthemselves do not need to be emitted. However if their address is taken,then they need to be emitted.For C++14, clang is able to handle that since clang emits them withavailable_externally linkage together with the initializer.However for C++17, the constexpr static data member of a class or template classbecome inline variables implicitly. Therefore they become definitions withlinkonce_odr or weak_odr linkages. As such, they can not have available_externallylinkage.This patch fixes that by adding implicit constant attribute tofile scope constexpr variables and constexpr static data membersin device compilation.Differential Revision: https://reviews.llvm.org/D79237

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCUDA/constexpr-variables.cu</description>
        <pubDate>Fri, 01 May 2020 15:30:24 +0000</pubDate>
        <dc:creator>Yaxun (Sam) Liu &lt;yaxun.liu@amd.com&gt;</dc:creator>
    </item>
</channel>
</rss>
