search for: int8_max

...G_LONG_MIN LLONG_MIN #define LONG_LONG_MAX LLONG_MAX #define ULONG_LONG_MAX ULLONG_MAX #define QUAD_MIN LLONG_MIN #define QUAD_MAX LLONG_MAX #define UQUAD_MAX ULLONG_MAX ... --- /usr/include/limits.h --------------------- Which defintions do you think encompasses LLVM's expectations? INT8_MAX - SCHAR_MAX //signed INT8_MIN - SCHAR_MIN //signed INT16_MAX - SHRT_MAX //signed INT16_MIN - SHRT_MIN //signed INT32_MAX - LONG_MAX //signed INT32_MIN - LONG_MIN //signed ... UINT8_MAX - CHAR_MIN //unsigned #define _CHAR_UNSIGNED || __CHAR_UNSIGNED__ UINT8_MIN - (implicitly defined...

...type with ostream. Now, I'm stopped by some to me unknown constants: ----------------------------------- Compiling Constants.cpp Constants.cpp: In static member function `static bool llvm::ConstantSInt::isValueValidForType(const llvm::Type*, long long int)': Constants.cpp:368: error: `INT8_MAX' undeclared (first use this function) Constants.cpp:368: error: (Each undeclared identifier is reported only once for each function it appears in.) Constants.cpp:368: error: `INT8_MIN' undeclared (first use this function) Constants.cpp:370: error: `INT16_MAX' undeclared (first use t...

...MAX > #define ULONG_LONG_MAX ULLONG_MAX > > > #define QUAD_MIN LLONG_MIN > #define QUAD_MAX LLONG_MAX > #define UQUAD_MAX ULLONG_MAX > ... > --- /usr/include/limits.h --------------------- > > Which defintions do you think encompasses LLVMs expectations?: > > INT8_MAX - SCHAR_MAX //signed > INT8_MIN - SCHAR_MIN //signed > INT16_MAX - SHRT_MAX //signed > INT16_MIN - SHRT_MIN //signed > INT32_MAX - LONG_MAX //signed > INT32_MIN - LONG_MIN //signed > ... > UINT8_MAX - CHAR_MIN //unsigned - #define _CHAR_UNSIGNED || > __CHAR_UNSIGNED__...

>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

...LONG_LONG_MIN LLONG_MIN #define LONG_LONG_MAX LLONG_MAX #define ULONG_LONG_MAX ULLONG_MAX #define QUAD_MIN LLONG_MIN #define QUAD_MAX LLONG_MAX #define UQUAD_MAX ULLONG_MAX ... --- /usr/include/limits.h --------------------- Which defintions do you think encompasses LLVMs expectations?: INT8_MAX - SCHAR_MAX //signed INT8_MIN - SCHAR_MIN //signed INT16_MAX - SHRT_MAX //signed INT16_MIN - SHRT_MIN //signed INT32_MAX - LONG_MAX //signed INT32_MIN - LONG_MIN //signed ... UINT8_MAX - CHAR_MIN //unsigned - #define _CHAR_UNSIGNED || __CHAR_UNSIGNED__ UINT8_MIN - (implicitly 0?) UINT16_MAX...

...tion it appears in.) 78 #ifndef __FreeBSD__ 79 // Make it a process local mutex 80 errorcode = pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_PRIVATE); 81 #endif So I modified both occurrences of __FreeBSD__ to also check for __OpenBSD__. The next problem was INT8_MAX, etc., weren't being defined. include/llvm/Support/DataTypes.h.in is inadequate for this platform. I dumped a set of definitions into each file that wanted them as a bodge. Better autoconf tests could set up INT8_MAX, etc., on all platforms that don't define them. After that, the build co...

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

I just added __OpenBSD__ everywhere __FreeBSD__ was being tested (there were about a dozen places). I suspect we'll have to add one for NetBSD also one day (even DragonflyBSD?). INT8_MAX and friends ought to be declared by <stdint.h>. It is on FreeBSD. Ralph Corderoy wrote: >Hi again, > >I wrote: > > >>>I would like to test but the I modigied the configure to make >>>unknown = OpenBSD and Unix >>> >>> >>Have...

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

...e FORCE.. LUKE use the force.. of llvm that is. :) cheers all. Jeff Cohen <jeffc at jolt-lang.org> wrote: I just added __OpenBSD__ everywhere __FreeBSD__ was being tested (there were about a dozen places). I suspect we'll have to add one for NetBSD also one day (even DragonflyBSD?). INT8_MAX and friends ought to be declared by . It is on FreeBSD. Ralph Corderoy wrote: >Hi again, > >I wrote: > > >>>I would like to test but the I modigied the configure to make >>>unknown = OpenBSD and Unix >>> >>> >>Have you looked at ....

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

Hi! In DataTypes.h (generated from DataTypes.cmake) there is an extra code path for Visual C. This can produce macro redefinitions for INT8_MAX, INT8_MIN etc. since other headers may also define them. Therefore please protect the macros like INT8_C etc. Also it would be nice if the auto-generated HAVE_STDINT_H and HAVE_INTTYPES_H would be used also for Visual C since it is possible to add them to the global header directory (e.g. http://m...

Hi Josephm > I would like to test but the I modigied the configure to make unknown > = OpenBSD and Unix and go pretty far but it died right after 'supports > mkdir' yes... Could that have been `checking for mkdir...'? > then the next line was 'your system is unsupported'' Have you looked at ./config.log. ./configure creates this as it runs as a trace of the