search for: forscop

...orm"); But if we translate INVALID macro into function calls, then users has to add a function for this counter: void INVLIAD_SimpleLoop (...). This is because we cannot use the following macro combination in function calls: if (!Context.Verifying) \ ++Bad##NAME##ForScop; So, I do not think it is necessary to translate the INVALID macro into function calls. Do you still think we should translate INVALID macro into a serial of functions like "invalid_CFG, invalid_IndVar, invalid_IndEdge, ... ? In that case, I could provide a small patch file for this purpose...

.../D _DEBUG /D _WINDOWS /D _USRDLL /D [elided] /D _t_env_os_WIN32 /D [also-elided] /D _SCL_SECURE_NO_WARNINGS /D _CRT_SECURE_NO_WARNINGS /D OBJC_OLD_DISPATCH_PROTOTYPES=1 /D _WIN64 /D "__x86_64__= 1" /D _WINDLL /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"Debug\x64\\" /Fd"Debug\x64\vc120.pdb" /Gd /TP /wd4068 /wd4200 /wd4244 /wd4267 /wd4305 /wd4309 /wd4311 /wd4800 /FIC:\[top-level-dir]\[source-dir]\\[prefix-header].h /errorReport:prompt -m64 -fmsc-version=1800 -ferror-limit=1000 -m64 -fmsc-version=1800 [source-file].cpp...

...t; void INVLIAD_SimpleLoop (...). \ ^^ No uppercase in function names. > This is because we cannot use the following macro combination in function calls: > if (!Context.Verifying) \ > ++Bad##NAME##ForScop; > So, I do not think it is necessary to translate the INVALID macro into function calls. > Do you still think we should translate INVALID macro into a serial of functions like "invalid_CFG, invalid_IndVar, invalid_IndEdge, ... ? In that case, I could provide a small patch file for this...

...on.tlog /r C:\PYTHON-2.7.10\PCBUILD\KILL_PYTHON.C /b MSBuildConsole_CancelEvent306536dcec844c0c97517539ced8ed5d /c C:\Python-2.7.10\PCbuild\CL.exe /c /I..\Include /I..\PC /Zi /nologo /W3 /WX- /O2 /Ob1 /Oi /GL /D _WIN64 /D _M_X64 /D NDEBUG /D _WIN32 /GF /Gm- /MT /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fo"C:\Python-2.7.10\PCbuild\x64-temp-Release\kill_python\\" /Fd"C:\Python-2.7.10\PCbuild\x64-temp-Release\kill_python\vc120.pdb" /Gd /TC /errorReport:queue /USECL:MS_OPTERON /GS- kill_python.c TRACKER : error TRK0002: Failed to execute command: "C:\Python-2.7.10\PCbuild\C...

On 07/21/2013 07:33 PM, Star Tan wrote: > At 2013-07-22 01:40:31,"Tobias Grosser" <tobias at grosser.es> wrote: > >> On 07/21/2013 09:49 AM, Star Tan wrote: >>> Hi all, >>> >>> >>> I have attached a patch file to reduce the polly-detect overhead. >> >> Great. >> >>> My idea is to avoid calling TypeFinder in

...m > with the same settings, with MSVC (v141) and Clang (9), then I compared the > output. The compiler settings for all those projects were: > > /permissive- /GS /GL /W3 /Gy /Zc:wchar_t /Gm- /Ox /Ob2 /sdl /Zc:inline > /fp:precise /D "_MBCS" /errorReport:prompt /GF- /WX- /Zc:forScope /Gd /Oy > /Oi /MD /FC /EHsc /nologo /Ot /diagnostics:classic > > > > The MSVC compiler only failed the following test: > > EH: > ihateeh.cxx > > > > Clang however failed multiple tests: > EH: > > ihateeh.cxx > > > > SEH: > > seh0007.c...

At Microsoft we open sourced some of our compiler tests for exception handling on github. https://github.com/microsoft/compiler-tests We are looking into what it would take to get these to work with clang-cl. I’m planning to share a design document on the mailing list soon. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL:

...;NDEBUG" /D "EBUG" /D "ASAN_HAS_EXCEPTIONS=1" > /D "ASAN_DYNAMIC=1" /D "INTERCEPTION_DYNAMIC_CRT" /D > "__func__=__FUNCTION__" /D "CMAKE_INTDIR=\"RelWithDebInfo\"" /D > "_MBCS" /errorReport:prompt /WX- /Zc:forScope /GR- /Gd /Oy- /MD > /Fa"RelWithDebInfo/" /EHsc /nologo > /Fo"RTAsan_dynamic.i386.dir\RelWithDebInfo\" > /Fp"RTAsan_dynamic.i386.dir\RelWithDebInfo\RTAsan_dynamic.i386.pch" > > (Note how it uses /MD) > > So, basically, ninja is linking as though ev...

...op (...). \ > > ^^ No uppercase in function names. > >> This is because we cannot use the following macro combination in function calls: >> if (!Context.Verifying) \ >> ++Bad##NAME##ForScop; >> So, I do not think it is necessary to translate the INVALID macro into function calls. >> Do you still think we should translate INVALID macro into a serial of functions like "invalid_CFG, invalid_IndVar, invalid_IndEdge, ... ? In that case, I could provide a small patch file...

...!= R_NilValue; i++, args = CDR(args)) { // verbatim from the manual } return R_NilValue; } // END C/Cpp code Vcc Compilation settings: /I"C:\bin\R\R\include" /ZI /nologo /W3 /WX- /Od /Oy- /D "_WINDLL" /D "_MBCS" /Gm /EHsc /RTC1 /GS /fp:precise /Za /Zc:wchar_t /Zc:forScope /Fp"Debug\showArgs.pch" /Fa"Debug\" /Fo"Debug\" /Fd"Debug\vc100.pdb" /Gd /TP /analyze- /errorReport:queue /OUT:"C:\XXXX\Debug\showArgs.dll" /NOLOGO /LIBPATH:"C:\bin\R\R\bin\i386" /DLL "Rdll.lib" "kernel32.lib" "...

On Thu, Oct 23, 2014 at 3:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Thu, Oct 23, 2014 at 2:57 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >>>> On Thu, Oct

I'm trying to compile some large programs with clang on Windows (with a view to compiling to bit code and then running some whole program optimisations on the bit code). Take for example the Python 2.7 interpreter: As is typically the case, the usual build procedure involves running msbuild which invokes the Microsoft compiler. The most obvious procedure would then be to substitute

We inject a typedef for size_t here: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema.cpp?revision=218230&view=markup#l206 The typedef type is determined by calling getSizeType(). SizeType is (relevantly) calculated in two places: X86_64 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?revision=218666&view=markup#l3512 X86_32