Another simple solution is to use "typedef uint64_t Attributes " w/o any enums (just "const uint64_t  None = 0", etc). <div>This should work now because we already cleaned up all uses of unsigned, but someone may use unsigned instead of Attributes later.</div>
<div>We can make such bugs easier to discover by moving half of the attribute constant to the higher 32-bits. </div><div>? </div><div><br></div><div>--kcc</div><div><br><br><div class="gmail_quote">On Tue, Feb 7, 2012 at 12:53 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com">kcc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I see the problem. <div>Let me try to come up with a solution that does not involve constructors but also does not sacrifice type safety. </div>
<div><br><div class="gmail_quote"><div class="im">On Tue, Feb 7, 2012 at 12:01 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kostya,<br>
<br>
One unexpected piece of fallout in your recent attributes change (r148553) was that it introduced a bunch of static constructors into .o files that #include Attributes.h, due to stuff like this:<br>
<br>
const Attributes None      (0);     ///< No attributes have been set<br>
const Attributes ZExt      (1<<0);  ///< Zero extended before/after call<br>
const Attributes SExt      (1<<1);  ///< Sign extended before/after call<br>
const Attributes NoReturn  (1<<2);  ///< Mark the function as not returning<br>
<br>
We really don't like static ctors in LLVM, because it is often used as a library, and they cause startup-time performance hits and other bad news.  I'm surprised we don't have an explicit section about it in the CodingStandards, but we do have:<br>


<a href="http://llvm.org/docs/CodingStandards.html#ll_iostream" target="_blank">http://llvm.org/docs/CodingStandards.html#ll_iostream</a><br>
<br>
... which talks about the same thing.<br>
<br>
Anyway, as it turns out, LLVM can optimize those static ctors away in some cases, but not all (e.g. -O0).  This was found because LLDB builds with -Wstatic-constructor and this header change is causing a flood of warnings.<br>


<br>
<br>
I can think of two ways to fix this.  One is to replace all of these with "get" functions, which would be really really ugly.  </blockquote><div><br></div></div><div>grrrr </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

A better change would be to replace these with enums, eliminating the whole problem.  Are 64-bit enums portable enough to be used here?<br></blockquote><div><br></div></div><div>We had a problem with 64-bit enums on the windows side, so I guess the answer is "not portable"</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If not, we could split this into two enums (one for attributes 0-31 and one for attributes 32+), and define the appropriate constructors in Attribute that take them, and define the appropriate operator| implementations that merge them (returning an Attribute).<br>


<br>
Can you take a look at this?  It's a pretty big problem for LLDB and other clients that use -Wstatic-constructor.<br></blockquote><div><br></div></div><div>--kcc  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<span><font color="#888888"><br>
-Chris<br>
</font></span></blockquote></div><br></div>
</blockquote></div><br></div>