similar to: [LLVMdev] Constants.cpp:368: error: `INT8_MAX' undeclared (first use this function)

>From: Chris Lattner <sabre at nondot.org> >Date: Wed, 14 Jul 2004 14:49:01 -0500 (CDT) > >There is currently support for building in non-cygwin windows environments >protected by _MSC_VER. You just need to broaden the scope of the #ifndef >to include internix. > Sorry Chris, but my DataTypes.h.in seems to be outdated (due to I'm porting LLVM 1.2), so I'm not

>From: Chris Lattner <sabre at nondot.org> >Date: Wed, 14 Jul 2004 14:49:01 -0500 (CDT) >The file you need to modify is here: >llvm/include/Support/DataTypes.h.in > >There is currently support for building in non-cygwin windows environments >protected by _MSC_VER. You just need to broaden the scope of the #ifndef >to include internix. > Sorry, Chris, but my

On Fri, 16 Jul 2004, Henrik Bach wrote: > >There is currently support for building in non-cygwin windows environments > >protected by _MSC_VER. You just need to broaden the scope of the #ifndef > >to include internix. > > > > Sorry Chris, but my DataTypes.h.in seems to be outdated (due to I'm porting > LLVM 1.2), so I'm not at the moment able to edit the

>From: John Criswell <criswell at cs.uiuc.edu> >Date: Wed, 14 Jul 2004 09:11:03 -0500 > > >The DataTypes.h header file is generated by the configure script and placed >into your build tree. My best guess is that your system's header files do >not correctly define these macros, so they are missing. > I did a search on the build and source trees, but neither

On Thu, 15 Jul 2004, Chris Lattner wrote: > Personally I think that we've waited much too long for the 1.3 release, BTW, for those who are interested in the differences between 1.2 and CVS, check out: http://llvm.cs.uiuc.edu/docs/ReleaseNotes.html#whatsnew Note that the release notes still need to be polished, but you'll get the basic idea. -Chris -- http://llvm.cs.uiuc.edu/

On Thu, 15 Jul 2004 18:05:21 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > BTW, for those who are interested in the differences between 1.2 and CVS, > check out: http://llvm.cs.uiuc.edu/docs/ReleaseNotes.html#whatsnew It might be a good idea to add a check-in script that puts the latest version of the pending ReleaseNotes.html into the web site directory and then link

On Thu, 15 Jul 2004, Reid Spencer wrote: > On Thu, 15 Jul 2004 18:05:21 -0500 (CDT) > Chris Lattner <sabre at nondot.org> wrote: > > > BTW, for those who are interested in the differences between 1.2 and CVS, > > check out: http://llvm.cs.uiuc.edu/docs/ReleaseNotes.html#whatsnew > > It might be a good idea to add a check-in script that puts the latest >

Silly me. Perhaps then just a more prominent link on the main page with something like a "what's coming in the next release" label ? Reid. On Thu, 15 Jul 2004 18:16:33 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > That is exactly what the http://llvm.cs.uiuc.edu/docs/ directory is: a > mirror of the docs directory in CVS. It's autoupdated on every

>From: "Reid Spencer" <reid at x10sys.com> >Date: Thu, 15 Jul 2004 18:33:30 -0400 > >On Thu, 15 Jul 2004 17:43:27 -0500 (CDT) > Chris Lattner <sabre at nondot.org> wrote: >>Sorry! LLVM 1.3 will probably be out in a few weeks... > >Speaking of which, what are your intentions for 1.3? Are you waiting on >CPR? Anything else? We're starting to

On Thu, 15 Jul 2004, Reid Spencer wrote: > > Another thing that is on my short list for 1.3 is to get as many .bc > > format changes out of the way as possible so the backwards compat code in > > the .bc reader is simpler. In particular, I would at least like to get > > placeholders for PR263 and maybe PR400. > > This I strongly agree with. We need to minimize impact

On Thu, 15 Jul 2004, Reid Spencer wrote: > On Thu, 15 Jul 2004 17:43:27 -0500 (CDT) > Chris Lattner <sabre at nondot.org> wrote: > > Sorry! LLVM 1.3 will probably be out in a few weeks... > > Speaking of which, what are your intentions for 1.3? Are you waiting on CPR? > Anything else? We're starting to get some traction with more developers and > I think doing

On Thu, 15 Jul 2004 17:43:27 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > Sorry! LLVM 1.3 will probably be out in a few weeks... Speaking of which, what are your intentions for 1.3? Are you waiting on CPR? Anything else? We're starting to get some traction with more developers and I think doing a release sooner rather than later might be worth it for all parties

On Thu, 15 Jul 2004 17:57:20 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > CPR would be really nice. There is also this ephemeral PPC support that > may or may not make it, but would be really awesome it if did. I would > also like to turn on some sort of interprocedural alias analysis by > default (for performance). CPR might make it in the next couple of weeks.

On Thu, 15 Jul 2004 18:19:11 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > This has no impact on the users at all... it has an impact on the > maintainers of the LLVM .bc file reader. :) The LLVM BC file reader has > to have compatibility code to support loading of all released LLVM > bytecode formats (1.0, 1.1, 1.2, etc). Good point. > There is always a

--- lib/Makefile.am | 27 ++ server/Makefile.am | 24 -- server/nbdkit.syms | 28 +-- server/public.c | 459 +--------------------------------- {server => lib}/extents.c | 4 +- lib/parse.c | 341 +++++++++++++++++++++++++ lib/password.c | 152 +++++++++++ lib/path.c | 97 +++++++

Folding for conversions: F32->(U{16/32}, S{16/32}) and (U{16/32}, {S16/32})->F32 Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 109 +++++++++++++++++++++ 1 file changed, 109 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp

Folding for conversions: F32/64->(U16/32, S16/32) and (U16/32, S16/32)->F32 No piglit regressions observed on nv50 and nvc0! Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- V2: fix usage of wrong variable V3: enable F64 support V4: - disable F64 support again - handle saturate flag: clamp to min/max if needed

On Fri, Jan 9, 2015 at 6:47 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > Folding for conversions: F32->(U{16/32}, S{16/32}) and (U{16/32}, {S16/32})->F32 > > Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> > --- > .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 109 +++++++++++++++++++++ > 1 file

Folding for conversions: F32/64->(U16/32, S16/32) and (U16/32, S16/32)->F32 No piglit regressions observed on nv50 and nvc0! Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- V2: fix usage of wrong variable V3: enable F64 support V4: - disable F64 support again - handle saturate flag: clamp to min/max if needed V5: clamp before rounding to nearest

Folding for conversions: F32->(U{16/32}, S{16/32}) and (U{16/32}, {S16/32})->F32 Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- V2: beat me, whip me, split out F64 .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 81 ++++++++++++++++++++++ 1 file changed, 81 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp