similar to: [LLVMdev] DataTypes.h for Visual C

[please CC the llvm mailing list] Jochen Wilhelmy <j.wilhelmy at arcor.de> writes: >> What's that extra code path? >> > > #ifndef _MSC_VER > ... > #else /* _MSC_VER */ > /* Visual C++ doesn't provide standard integer headers, but it does provide > built-in data types. */ > > ... extra code path ... > > #endif Sorry, that doesn't

>>> What's that extra code path? >>> >>> >> #ifndef _MSC_VER >> ... >> #else /* _MSC_VER */ >> /* Visual C++ doesn't provide standard integer headers, but it does provide >> built-in data types. */ >> >> ... extra code path ... >> >> #endif >> > Sorry, that doesn't show an extra

Hi I noticed that these defines (line 35 to 37) are hardcoded in the DataTypes.h include file: ---------------- #define HAVE_SYS_TYPES_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_STDINT_H 1 ---------------- Shouldn't they have be defined by the configure script into llvm/Config/config.h? Henrik _________________________________________________________________ Undg� pop-ups med MSN Toolbar

Henrik Bach wrote: > Hi > > I noticed that these defines (line 35 to 37) are hardcoded in the > DataTypes.h include file: > ---------------- > #define HAVE_SYS_TYPES_H 1 > #define HAVE_INTTYPES_H 1 > #define HAVE_STDINT_H 1 > ---------------- > > Shouldn't they have be defined by the configure script into > llvm/Config/config.h? These lines are set by

Hi! when compiling projects using llvm 2.9 and ms vc 10 I get these warnings: 1>e:\Jochen\Lib\lib\include\llvm/Use.h(218): warning C4624: 'llvm::AugmentedUse' : destructor could not be generated because a base class destructor is inaccessible 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdint.h(72): warning C4005: 'INT8_MIN' : macro redefinition

Hi By manipulating a #define for G++ I've managed to compile int64_t 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

>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

> > What do you want to improve exactly? Do you experience > problems? > not only iterator.h but also DataTypes.h I also put back iterator.h because at the trunk of llvm, iterator.h.in and iterator.h.cmake still there:( My improvement is now we didn't to generate DataTyes.h, we just need to generate config.h, And everything is configured at config.h, but not in seperate files.:)

Hi Yonggang! On Aug 27, 1:02 pm, 罗勇刚(Yonggang Luo) <luoyongg... at gmail.com> wrote: > Because this patch must be applied in one time so that don't broken > the buildbot system. > So I just submit the configure and cmake at the same time. > Also, this patch add two new file > iterator.h > and > DataTypes.h What do you want to improve exactly? Do you experience

Because this patch must be applied in one time so that don't broken the buildbot system. So I just submit the configure and cmake at the same time. Also, this patch add two new file iterator.h and DataTypes.h for the reason that patch doesn't support for svn's rename mechanics. So I just add these two file and doesn't delete the old history files Because I doesn't get

Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> writes: > On Mon, Jun 20, 2016 at 05:05:18PM +0000, Paweł Bylica via llvm-dev wrote: >> On Sun, Jun 19, 2016, 17:57 Joerg Sonnenberger <joerg at bec.de> wrote: >> >> > On Sun, Jun 19, 2016 at 03:24:22PM +0000, Paweł Bylica via llvm-dev wrote: >> > > Hi LLVM, >> > > >>

Can you send me the config.log? Jean-Marc Le vendredi 13 mai 2005 ? 00:16 +0200, Pierre a ?crit : > Jean-Marc Valin wrote: > > What platform (OS, compiler/version) > > GNU/Linux > kernel 2.6.11.8 > gcc 3.4.3 > > > Also, does it work with no options. > > No, I just tried with just "./configure" and I have the same error. > > -- Jean-Marc

Hi! what about #if !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS) in front of the constant macros for visual c to emulate the behaviour of stdint.h more precisely? -Jochen

On 02/07/12 12:03 am, Erik de Castro Lopo wrote: > Dave Yeo wrote: > >> This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been >> been replaced by klibc. Considering the age of EMX and lack of testing >> and that klibc contains so many improvements I think this is exceptable. > > Sorry Dave, I can't do that. Or rather sorry, the patch

In DataTypes.h starting on line 121 are these lines: #define INT8_C(C) C #define UINT8_C(C) C #define INT16_C(C) C #define UINT16_C(C) C #define INT32_C(C) C #define UINT32_C(C) C ## U #define INT64_C(C) ((int64_t) C ## LL) #define UINT64_C(C) ((uint64_t) C ## ULL) They are conflicting with the cstdint when we have updated headers in our MSVC build. I could have sworn I talked about this

From: Tanu Kaskinen <tanu.kaskinen at linux.intel.com> Not everyone who includes speexdsp_config_types.h will have a test which defines those, and if we've chosen to use the stdint types at configure time then we know exactly which header(s) are available, so just choose the best one then and generate the header to use it. This patch, including the above text, is copied from a commit

Testing for __STDC_CONSTANT_MACROS has the advantage that you are forced to define __STDC_CONSTANT_MACROS on win32. If you then switch to another platform the project still compiles. -Jochen

Hi, I have an Ices2 comp problem, it can't find libshout. I have installed Libshout 2.0 in /home/Darkmeteor the configure line I'm using for ices2 is : ./configure --prefix=/home/Darkmeteor --with-ogg-prefix=/home/Darkmeteor --with-vorbis-prefix=/home/Darkmeteor --with-shout-prefix=/home/Darkmeteor Problem : checking for Ogg... yes checking for Vorbis... yes checking for Shout... no

Hi all, Nice one for a Friday afternoon ... I'm trying to follow this section of the manual : http://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-Undefined-Behaviour-Sanitizer to build R-devel (as of a few hours ago: rev 66684) with -fsanitize=undefined,address. My OS is Linux Mint Debian Edition. To get gcc-4.9 I added Debian testing to my apt sources and ran : sudo

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 ./config.log. ./configure creates this as it runs > as a trace of the path it took through ./configure. Work backwards > from the end to find out what it didn't like. I remember SourceForge's compile farm has an OpenBSD x86