Displaying 3 results from an estimated 3 matches for "enumerands".
2013 Nov 10
1
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
...a web search that platform compilers have a
tradition of defining the platform and architecture like this so the
only reason #undef NetBSD is alone there is that you were the first to
compile on the less common platforms who actually bothered to submit a
patch.
The right fix would be to prefix the enumerands in Triple.h or move the
enums into a private header (probably not feasible because they're used
externally).
Alp.
>
> INT64_MAX as seen by the context is about a AIX specific header bug.
>
> alloca has a comment about VC++. Might be better to add a conditional
> around it and s...
2013 Nov 10
0
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On Sun, Nov 10, 2013 at 01:42:24PM +0000, Alp Toker wrote:
> |#undef NetBSD||
> ||#undef mips||
> ||#undef sparc||
> ||#undef INT64_MAX||
> ||#undef alloca|
>
> This is not OK to do globally -- even if LLVM doesn't care about the
> definition, maybe embedding applications or OS headers do?
Given that 3 of the 5 #undefs are directly relevant for me -- they exist
2013 Nov 10
8
[LLVMdev] Goal for 3.5: Library-friendly headers
With the recent thread on using C++11 in LLVM/clang, one of the
recurring themes was a desire to make the internal headers more consumable.
While I don't personally want any kind of stability guarantee for
internal headers, I do think we can do more to ensure that any given
snapshot of the headers is consumable from different compilers and build
configurations.
In practice this means