search for: valuemasks

On Thu, Dec 1, 2011 at 9:11 AM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 1, 2011, at 12:08 AM, David Blaikie wrote: > >> On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: >>> On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: >>>> For a bit of an experiment I've been trying to compile LLVM & Clang

On Dec 1, 2011, at 1:13 PM, David Blaikie wrote: >>> (there's also some legitimate unreachable code warnings I'd be happy >>> to fix as I find them, things like: >>> >>> --- a/lib/Support/CommandLine.cpp >>> +++ b/lib/Support/CommandLine.cpp >>> @@ -294,10 +294,7 @@ static inline bool ProvideOption(Option *Handler, >>>

On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: > On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: >> For a bit of an experiment I've been trying to compile LLVM & Clang >> with -Weverything (disabling any errors that seem like more noise/less >> interesting). One warning I've recently hit a few instances of is >>

Question: How hard should tblgen try to fit constants into a particular type? My case is an xor with i8 immediate where I'm using 0xff in as the immediate value. 0xff should fit into i8 if treated as unsigned, but CodeGenDAGPatterns.cpp assumes that any and all integers less than 32-bits are signed. Should tblgen try to see if the sign-extended version of the constant could fit into the

On Dec 1, 2011, at 12:08 AM, David Blaikie wrote: > On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: >> On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: >>> For a bit of an experiment I've been trying to compile LLVM & Clang >>> with -Weverything (disabling any errors that seem like more noise/less >>> interesting).

...E_BELL (1 << 2) +#define ACTION_VALUE_EDGE (1 << 3) +#define ACTION_VALUE_EDGEBUTTON (1 << 4) +#define ACTION_VALUES_ALL \ + ( ACTION_VALUE_KEY \ + | ACTION_VALUE_BUTTON \ + | ACTION_VALUE_BELL \ + | ACTION_VALUE_EDGE \ + | ACTION_VALUE_EDGEBUTTON ) + +static int actionValueMasks[] = { + ACTION_VALUE_KEY, + ACTION_VALUE_BUTTON, + ACTION_VALUE_BELL, + ACTION_VALUE_EDGE, + ACTION_VALUE_EDGEBUTTON +}; - a->button.button = 0; - a->button.modifiers = 0; +enum { + ACTION_TYPE_KEY = 0, + ACTION_TYPE_BUTTON, + ACTION_TYPE_BELL, + ACTION_TYPE...

The rgl package currently crashes R when running under Xvfb (the "virtual frame buffer" server), at least on MacOSX. It makes sense that it shouldn't be able to work there (it needs interactivity), but I don't know how to detect the problems before they cause the crash. Currently the error happens the first time you try to open an rgl window; when rgl calls XCreateWindow R

Allow me to rephrase my question: How much agony and gnashing of teeth will I cause if I commit this patch to tblgen (fully tested and changes to DAGISelEmitter.cpp also committed)? -scooter On Feb 8, 2008, at 6:43 PM, Scott Michel wrote: > Question: How hard should tblgen try to fit constants into a > particular > type? > > My case is an xor with i8 immediate where

My feeling is tblgen shouldn't make assumptions about whether the backend will treat the value as signed or unsigned (after all MVT::ValueType does not convey sign information). Perhaps it's cleaner to just check if it fits as unsigned? Chris? Evan On Feb 8, 2008, at 6:43 PM, Scott Michel wrote: > Question: How hard should tblgen try to fit constants into a > particular

On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: > For a bit of an experiment I've been trying to compile LLVM & Clang > with -Weverything (disabling any errors that seem like more noise/less > interesting). One warning I've recently hit a few instances of is > -Wweak-vtable which is, in fact, an explicitly documented LLVM coding > standard (

For a bit of an experiment I've been trying to compile LLVM & Clang with -Weverything (disabling any errors that seem like more noise/less interesting). One warning I've recently hit a few instances of is -Wweak-vtable which is, in fact, an explicitly documented LLVM coding standard ( http://llvm.org/docs/CodingStandards.html#ll_virtual_anch ). Some instances of this have been easy to

On Thu, Dec 1, 2011 at 9:11 AM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 1, 2011, at 12:08 AM, David Blaikie wrote: > >> On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: >>> On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: >>>> For a bit of an experiment I've been trying to compile LLVM & Clang

Hello, I have my work on the nv vpe video decoder in a functional state. In case you didn't know this decoder accelerates mpeg2 video at the idct/mc level. I have verified that it works on nv40 hardware. I believe it works on nv30 hardware (and maybe some earlier hardware), but I cannot verify since I have none. I will reply with patches against the kernel, drm, ddx and mesa for