<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I would not recommend the leaky static construct (e.g. "static const
foo &f = *new foo();"). If LLVM is built as a dynamic library,
it can be unloaded and reloaded an indefinite number of times, and
each one of those iterations will leak one instance of 'foo'.<br>
<br>
Also, if LLVM is built by Windows MSVC 2013 (which LLVM supports),
then function level static creation is not thread safe (it is thread
safe with MSVC 2015). This can really get you in trouble if you
also use LTO, as some LTO variants will internally create a thread
for each object.<br>
<br>
<br>
<div class="moz-cite-prefix">On 3/9/2016 9:59 AM, David Blaikie via
llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CAENS6EvGB8XGtP+96YfMyG+jqaiyydm0RrJ7v-2rC2DBt6mstg@mail.gmail.com"
type="cite">
<p dir="ltr">Oh, yes, for sure. This should not be used for any
dynamic state. Such a thing can only used as an immutable
singleton of sorts.</p>
<p dir="ltr">If it is mutable then you break the usual thread
safety guarantees -two separate threads using two separate llvm
contexts shouldn't interfere with each other.</p>
<p dir="ltr">Not to mention, as you said, can break ongoing uses
of llvm by accumulating cruft. That's what the llvmcontext is
for - all that mutable state we can't find a better place for ;)</p>
<p dir="ltr">The leak itself is acceptable though, if those
conditions are met. So if you just need the map for some fixed
lookup table, the solution I suggested should be OK. It won't
produce an unrecoverable growing memory drain, etc.</p>
<div class="gmail_quote">On Mar 9, 2016 2:31 AM, "mats petersson"
<<a moz-do-not-send="true"
href="mailto:mats@planetcatfish.com">mats@planetcatfish.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>These type of constructs are less than ideal if you
have something that uses LLVM as a library in a "long
running" application (e.g. imagine something like photo
editor that compiles "filters", and a user that loads the
application on monday, and closes it on the following
thursday) , as there is no (trivial) way to know that this
stringmap exists, or that it may need cleaning out between
two compilations, for example. The risk with such
constructs is that they build up over time, and appear to
be "memory leaks". <br>
<br>
--<br>
</div>
Mats<br>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 9 March 2016 at 09:45,
valery pykhtin via llvm-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Right, but it produces a mem leak,
I'm not sure what is worse :-)</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Mar 9, 2016
at 10:49 AM, David Blaikie <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:dblaikie@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr">a static local still
produces a static dtor, though<br>
<br>
One of the ways you can get around this
is with a deliberate non-cleanup:<br>
<br>
const foo &getFoo() {<br>
static const foo &f = *new foo();<br>
return f;<br>
}<br>
<br>
<div>that way no global dtor runs.
Obviously only works if you don't need
foo's dtor to run.</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Mar
8, 2016 at 11:42 PM, Craig Topper
via llvm-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">I believe the
rule is only for global
variables. At least that's
what the first sentence in the
section says.
<div><br>
</div>
<div><span
style="color:rgb(0,0,0);font-family:'Lucida
Grande','Lucida Sans
Unicode',Geneva,Verdana,sans-serif;font-size:14px;line-height:21px">"Static
constructors and
destructors (e.g. global
variables whose types have
a constructor or
destructor) should not be
added to the code base,
and should be removed
wherever possible."</span><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div>On Tue, Mar 8, 2016
at 10:52 PM, valery
pykhtin via llvm-dev <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></a>></span>
wrote:<br>
</div>
</div>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div>
<div>
<div dir="ltr">Hi,
<div><br>
</div>
<div>I'm new here
and have a
question about the
rule in title. Is
the following use
case also
prohibited?</div>
<div><br>
</div>
<div>int
findNameId(StringRef
Name)</div>
<div>{</div>
<div> static
StringMap<int>
Map =
createSomeIDMap();</div>
<div> return
Map.lookup(Name);</div>
<div>};</div>
<div><br>
</div>
<div>It seems it
isn't influence
startup time and
doesn't create
initialization
order problems.
Clang isn't
complaining about
it with
-Wglobal-constructor
flag.</div>
<div><br>
</div>
<div>I'm asking
because under some
interpretation of
rule wording it
can be called
static constructor
too.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Valery</div>
</div>
<br>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing
list<br>
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer"
target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
</div>
<span><font color="#888888"><br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>~Craig</div>
</font></span></div>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer"
target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</body>
</html>