<?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 PR19955.cpp</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>07910d6a - Sema: Allow dllimport entities in template args for mingw</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCXX/PR19955.cpp#07910d6a</link>
        <description>Sema: Allow dllimport entities in template args for mingwPreviously dllimport variables inside of template arguments relied onnot using the C++11 codepath when -fms-compatibility was set.While this allowed us to achieve compatibility with MSVC, it did so atthe expense of MingW.Instead, try to use the DeclRefExpr we dig out of the template argument.If it has the dllimport attribute, accept it and skip the C++11null-pointer check.llvm-svn: 211766

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCXX/PR19955.cpp</description>
        <pubDate>Thu, 26 Jun 2014 07:48:46 +0000</pubDate>
        <dc:creator>David Majnemer &lt;david.majnemer@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>82dd877e - Don&apos;t allow dllimport variables in constant initializers</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCXX/PR19955.cpp#82dd877e</link>
        <description>Don&apos;t allow dllimport variables in constant initializersThis is a follow-up to David&apos;s r211677. For the following code,we would end up referring to &apos;foo&apos; in the initializer for &apos;arr&apos;,and then fail to link, because &apos;foo&apos; is dllimport and needs to beaccessed through the __imp_?foo.  __declspec(dllimport) extern const char foo[];  const char* f() {    static const char* const arr[] = { foo };    return arr[0];  }Differential Revision: http://reviews.llvm.org/D4299llvm-svn: 211736

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCXX/PR19955.cpp</description>
        <pubDate>Wed, 25 Jun 2014 22:19:48 +0000</pubDate>
        <dc:creator>Hans Wennborg &lt;hans@hanshq.net&gt;</dc:creator>
    </item>
<item>
        <title>0c43d807 - AST: Initialization with dllimport functions in C</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCXX/PR19955.cpp#0c43d807</link>
        <description>AST: Initialization with dllimport functions in CThe C++ language requires that the address of a function be the sameacross all translation units.  To make __declspec(dllimport) useful,this means that a dllimported function must also obey this rule.  MSVCimplements this by dynamically querying the import address table locatedin the linked executable.  This means that the address of such afunction in C++ is not constant (which violates other rules).However, the C language has no notion of ODR nor does it permit dynamicinitialization whatsoever.  This requires implementations to _not_dynamically query the import address table and instead utilize a wrapperfunction that will be synthesized by the linker which will eventuallyquery the import address table.  The effect this has is, to say theleast, perplexing.Consider the following C program:__declspec(dllimport) void f(void);typedef void (*fp)(void);static const fp var = &amp;f;const fp fun() { return &amp;f; }int main() { return fun() == var; }MSVC will statically initialize &quot;var&quot; with the address of the wrapperfunction and &quot;fun&quot; returns the address of the actual imported function.This means that &quot;main&quot; will return false!Note that LLVM&apos;s optimizers are strong enough to figure out that &quot;main&quot;should return true.  However, this result is dependent on havingoptimizations enabled!N.B.  This change also permits the usage of dllimport declarators insideof template arguments; they are sufficiently constant for such apurpose.  Add tests to make sure we don&apos;t regress here.llvm-svn: 211677

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCXX/PR19955.cpp</description>
        <pubDate>Wed, 25 Jun 2014 08:15:07 +0000</pubDate>
        <dc:creator>David Majnemer &lt;david.majnemer@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>11a54c34 - AST: Address of dllimport functions isn&apos;t constant</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCXX/PR19955.cpp#11a54c34</link>
        <description>AST: Address of dllimport functions isn&apos;t constantThe address of dllimport functions can be accessed one of two ways:- Through the IAT which is symbolically referred to with a symbol  starting with __imp_.- Via the wrapper-function which ends up calling through the __imp_  symbol.The problem with using the wrapper-function is that it&apos;s address willnot compare as equal in all translation units.  Specifically, it willcompare unequally with the translation unit which defines the function.This fixes PR19955.llvm-svn: 211570

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCXX/PR19955.cpp</description>
        <pubDate>Tue, 24 Jun 2014 06:40:51 +0000</pubDate>
        <dc:creator>David Majnemer &lt;david.majnemer@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>c28a964c - AST: Address of dllimport variables isn&apos;t constant</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCXX/PR19955.cpp#c28a964c</link>
        <description>AST: Address of dllimport variables isn&apos;t constantThe address of dllimport variables isn&apos;t something that can bemeaningfully used in a constexpr context and isn&apos;t suitable forevaluation at load-time.  They require loads from memory to properlyevaluate.This fixes PR19955.Differential Revision: http://reviews.llvm.org/D4250llvm-svn: 211568

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCXX/PR19955.cpp</description>
        <pubDate>Tue, 24 Jun 2014 05:59:13 +0000</pubDate>
        <dc:creator>David Majnemer &lt;david.majnemer@gmail.com&gt;</dc:creator>
    </item>
</channel>
</rss>
