[llvm-commits] fix the MSVC warning in include/llvm-c/Core.h

[Kostya Serebryany]

On Tue, Jan 24, 2012 at 11:47 PM, Chandler Carruth <chandlerc at google.com>wrote:

> FYI, I think Nick wanted to chime in on this, but he's kinda busy, so I
> just wanted to update thread and put it on his radar.
>
> Kostya, as a temporary measure, and until we figure out the right
> long-term solution, in r148937 I've removed this attribute from the C API's
> enum, but only that enum. AFAICT, this should have no impact on your usage,
> and just cause trouble for folks mixing ASan and the C API, which seems
> very unlikely.
>

Thanks, Chandler!

--kcc



>
> On Mon, Jan 23, 2012 at 12:01 PM, Eli Friedman <eli.friedman at gmail.com>wrote:
>
>> On Mon, Jan 23, 2012 at 11:02 AM, Kostya Serebryany <kcc at google.com>
>> wrote:
>> > My previous change in include/llvm-c/Core.h that introduced 64-bit
>> > Attributes (r148553) caused a warning
>> > while building with MSVC. http://llvm.org/bugs/show_bug.cgi?id=11828
>> > The following patch fixes the problem (use "static const uint64_t"
>> instead
>> > of enum).
>> > Ok to commit?
>> >
>> > --kcc
>> >
>> > Index: include/llvm-c/Core.h
>> > ===================================================================
>> > --- include/llvm-c/Core.h  (revision 148708)
>> > +++ include/llvm-c/Core.h  (working copy)
>> > @@ -92,7 +92,7 @@
>> >  /** Used to get the users and usees of a Value. See the llvm::Use
>> class. */
>> >  typedef struct LLVMOpaqueUse *LLVMUseRef;
>> >
>> > -typedef enum {
>> > +static const uint64_t
>> >      LLVMZExtAttribute       = 1<<0,
>> >      LLVMSExtAttribute       = 1<<1,
>> >      LLVMNoReturnAttribute   = 1<<2,
>> > @@ -119,8 +119,8 @@
>> >      LLVMReturnsTwice = 1 << 29,
>> >      LLVMUWTable = 1 << 30,
>> >      LLVMNonLazyBind = 1U << 31,
>> > -    LLVMAddressSafety = 1ULL << 32
>> > -} LLVMAttribute;
>> > +    LLVMAddressSafety = 1ULL << 32;
>> > +typedef uint64_t LLVMAttribute;
>> >
>> >  typedef enum {
>> >    /* Terminator Instructions */
>>
>> Hmm... actually, I'm not sure this is okay; it's a
>> non-binary-compatible change to the C API.
>
>
> Nick seemed to think that such changes were inevitable and not a big deal.
> I'm not at all sure. I took the conservative move as I mentioned above and
> restored the C interface to its previous state as we don't need the
> functionality there anyways. We can figure out the right way to introduce
> it now w/o warnings or other noise.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120127/580e06f6/attachment.html>