similar to: [LLVMdev] [PATCH]: MSVC build enhancements

José Fonseca <jose.r.fonseca at gmail.com> writes: > Attached are two patches with MSVC build enchancements. > > They are quite trivial, but were necessary to correctly link LLVM > libraries with Mesa3D on Windows. [snip] > add_llvm_definitions( -D_SCL_SECURE_NO_DEPRECATE ) > + add_llvm_definitions( -D_SECURE_SCL=0 ) With this setting the default LLVM build becomes

To the mailing list this time... On Sat, Mar 6, 2010 at 4:26 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Sat, Mar 6, 2010 at 4:19 PM, José Fonseca <jose.r.fonseca at gmail.com> wrote: >>>> --- a/include/llvm/System/DataTypes.h.cmake >>>> +++ b/include/llvm/System/DataTypes.h.cmake >>>> @@ -100,6 +100,9 @@ typedef u_int64_t uint64_t;

Le 06/03/2010 11:43, José Fonseca a écrit : > Attached are two patches with MSVC build enchancements. > > They are quite trivial, but were necessary to correctly link LLVM > libraries with Mesa3D on Windows. > > Jose > > Are you volontary trying to break everyone build (just to build your own project), or have you no idea of the effect of this change:

On Sat, Mar 6, 2010 at 11:33 AM, Cédric Venet <cedric.venet at laposte.net> wrote: > Le 06/03/2010 11:43, José Fonseca a écrit : >> >> Attached are two patches with MSVC build enchancements. >> >> They are quite trivial, but were necessary to correctly link LLVM >> libraries with Mesa3D on Windows. >> >> Jose >> > > Are you volontary

This patch splits LLVM_USE_CRT into new CMake variables LLVM_USE_CRT_DEBUG, LLVM_USE_CRT_RELEASE, etc (one for each build type). It also automatically detects which CRT was already chosen by CMake's defaults in the CMAKE_CXX_FLAGS_* variables, and defaults to those values. (Before, it was using add_llvm_definitions(), which worked...somehow, but CMAKE_CXX_FLAGS_RELEASE and friends were still

nobled <nobled at dreamwidth.org> writes: > This patch splits LLVM_USE_CRT into new CMake variables > LLVM_USE_CRT_DEBUG, LLVM_USE_CRT_RELEASE, etc (one for each build > type). It also automatically detects which CRT was already chosen by > CMake's defaults in the CMAKE_CXX_FLAGS_* variables, and defaults to > those values. > > (Before, it was using

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

I believe the perf tool cannot profile/analyze the JITed code in MCJIT model. Can you please confirm this ? I was working on a patch to fix this. Another question, is the there any support to map the llvm IR with x86 generated assembly ? so its easier to analyze the code generator. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Erik de Castro Lopo wrote: >> because MSVS2005 doesn't provide stdint.h. According to MSDN, >> uintptr_t is defined in "STDDEF.H and other include files". > > Does the rest of FLAC actually support those compilers? Yes. I removed this #include and all projects were successfully built with MSVS 2005 Express. > Is it worth > continuing to support them? * At

> > 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

src/libFLAC/memory.c cannot be compiled with MSVS 2005 (and probably VS2008 too) after this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=7cbecbae9f70be770f7651d09531fec0de6f9cf5 because MSVS2005 doesn't provide stdint.h. According to MSDN, uintptr_t is defined in "STDDEF.H and other include files".

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

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

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

Hello, I was trying to compile Flac on MinGW/Msys but got an error stating SIZE_T_MAX is undefined. To fix this error I edited the file "flac-1.2.1/include/share/alloc.h" and made the following change: Starting at line #36 I changed: #ifndef SIZE_MAX # ifndef SIZE_T_MAX # ifdef _MSC_VER # define SIZE_T_MAX UINT_MAX # else # error # endif # endif # define SIZE_MAX SIZE_T_MAX

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

This lets CMake's GUI frontend show a drop-down list of the limited possible values for LLVM_USE_CRT, instead of the current freeform input field, so using the variable is less error-prone. -------------- next part -------------- A non-text attachment was scrubbed... Name: add-strings-property-to-msvc-crt.patch Type: text/x-patch Size: 673 bytes Desc: not available URL:

On 09/02/15 17:44, Emil Velikov wrote: > Hi Sedat, > > On 07/02/15 22:42, Sedat Dilek wrote: >> [ Please CC me I am not subscribed to mesa-dev and llvmdev MLs ] >> >> Hi, >> >> I already reported this when playing 1st time with my llvm-toolchain >> v3.6.0rc2 and mesa v10.3.7 [1]. >> The issue still remains in mesa v10.4.4. >> >> So,

Hi all, The following patch fixes cross compiling from Linux to windows. The existing code was doing: #if !defined _MSC_VER && !defined __MINGW32__ && !defined __EMX__ #include <stdint.h> /* for SIZE_MAX in case limits.h didn't get it */ #endif when it seems to make much more sense to just test for the presence of <stdint.h> and do: #ifdef