Displaying 20 results from an estimated 1000 matches similar to: "change in CMake variable names breaks existing uses and does not conform to CMake conventions"
2014 Sep 17
2
[LLVMdev] proposal to avoid zlib dependency.
On 17 September 2014 16:34, Mueller-Roemer, Johannes Sebastian
<Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
> I'll have another look tomorrow.
Thanks.
> IMO, it is unnecessary clutter. It will fail if ${ZLIB_LIBRARIES} or ${ZLIB_INCLUDE_DIRS} are used anyways as they will be set to NOTFOUND. Or we go back to a silent-fail solution:
Fair enough. I've never
2014 Sep 17
2
[LLVMdev] proposal to avoid zlib dependency.
On 17 September 2014 15:47, Mueller-Roemer, Johannes Sebastian
<Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
> It's half the way there. Configuring and compiling works, but linking fails, probably some definition mismatches...
It configured, compiled and linked okay for me. Could you look into it?
>
> But it can definitely be simplified, as due to the
2015 Sep 18
2
ExecutionEngine::runFunction and libffi
I noticed that runFunction (for MCJIT) is very limited. At the same time the interpreter already has a fairly generic way of calling functions from a pointer and a Function * (for description) using libffi. Would it make sense to pull that functionality out into a small support library and using it in MCJIT? As is runFunction isn't particularly usable.
--
Johannes S. Mueller-Roemer, MSc
Wiss.
2014 Aug 18
2
[LLVMdev] [PATCH][RFC]: Add fmin/fmax intrinsics
This is a problem with all floating point folding, not just with these operations. What Matt is proposing is consistent with how we fold other libm intrinsics.
—Owen
> On Aug 18, 2014, at 1:22 AM, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
>
> Wouldn’t it be better to use the target’s implementation (if there is one)
2015 Oct 06
2
Extra space in LLVM_DEFINITIONS causes CMake 3.1 to fail
I made this change (not specifically changing from a list to a string, but changing from a hardcoded value to the value
that was actually decided by cmake), and I checked that it works with cmake 2.8.12.2 which is the minimum version
set in CMakeLists.txt. So if it doesn’t work with cmake 3.1/3.2 then that looks like something new that was introduced
after 2.8.12.2.
I’ll have a look at this
2015 Oct 06
2
Extra space in LLVM_DEFINITIONS causes CMake 3.1 to fail
LLVM_DEFINITIONS used to be defined as
set(LLVM_DEFINITIONS "-D__STDC_LIMIT_MACROS" "-D__STDC_CONSTANT_MACROS")
Now it is defined as
set(LLVM_DEFINITIONS " -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS")
(note that it is no longer a cmake list but a string, and the string contains a leading space!)
This causes CMake 3.1 to emit
g++ -D
2015 May 11
4
[LLVMdev] Set up ExecutionEngine according to actual machine capabilities
I am currently setting up my Module with
module->setTargetTriple(llvm::sys::getProcessTriple()
#ifdef _WIN32
+ "-elf"
#endif
);
And my ExecutionEngine with
llvm::EngineBuilder(std::move(module))
.setErrorStr(&err)
.setMCPU(llvm::sys::getHostCPUName())
2015 Jan 27
3
[LLVMdev] build failure on mingw gcc 4.9.1
On Tue, Jan 27, 2015 at 10:02 AM, Mueller-Roemer, Johannes Sebastian
<Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
> Adding -D__MSVCRT_VERSION__=0x900 (or higher) to CMAKE_CXX_FLAGS and
> -lmsvcr90 (or higher) to CMAKE_CXX_STANDARD_LIBRARIES appears to work.
> -lmsvcrt80 does not work, contrary to the comment on the MinGW bug tracker.
> However, if you do not
[LLVMdev] [RFC] Late May Update: Progress report on CMake build system's ability to replace autoconf
2015 May 29
1
[LLVMdev] [RFC] Late May Update: Progress report on CMake build system's ability to replace autoconf
Yes, that's the idea, when you -DLLVM_OPTIMIZED_TABLEGEN=ON tblgen is
built in Release in addition to whatever /property:Configuration= is.
2015-05-29 10:03 GMT+03:00 Mueller-Roemer, Johannes Sebastian <
Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>:
> That it’s faster is no surprise. Is the Release tblgen even built when
> you build in Debug mode? Otherwise this
2015 Jan 27
2
[LLVMdev] build failure on mingw gcc 4.9.1
I encountered a new build failure (r227128) on my nightly build of LLVM for MinGW:
FAILED: cmd.exe /c cd . && D:\MinGW\x86_64-4.9.1-release-posix-seh-rt_v3-rev0\mingw64\bin\c++.exe -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=gnu++11 -g
2014 Sep 24
2
[LLVMdev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
Indeed, mingw and pthreads have C++11 atomics, so building clang (with
atomics) should be possible even in cross compilation. I have no idea what
is the win from *not* using winpthreads, it is one small DLL file with BSD
license.
For context (does not matter to mingw as host for buiilding clang but
matters for clang running with mingw environment), clang TLS implementation
is not same as mingw so
[LLVMdev] [RFC] Late May Update: Progress report on CMake build system's ability to replace autoconf
2015 May 29
0
[LLVMdev] [RFC] Late May Update: Progress report on CMake build system's ability to replace autoconf
That it’s faster is no surprise. Is the Release tblgen even built when you build in Debug mode? Otherwise this introduces the need to build Release before Debug.
--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5 | 64283 Darmstadt | Germany
Tel +49 6151 155-606 | Fax +49
[LLVMdev] [RFC] Late May Update: Progress report on CMake build system's ability to replace autoconf
2015 May 29
2
[LLVMdev] [RFC] Late May Update: Progress report on CMake build system's ability to replace autoconf
Both Release and $CONFIG tblgen are built but the Release one is always
used. At least with Visual C++ the Release tblgen is much faster than the
Debug one.
2015-05-29 9:37 GMT+03:00 Mueller-Roemer, Johannes Sebastian <
Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>:
> Do they really allways put them into Release/bin or rather $<CONFIG>/bin?
>
>
>
> --
>
2014 Sep 17
2
[LLVMdev] proposal to avoid zlib dependency.
On 17 September 2014 13:27, Mueller-Roemer, Johannes Sebastian
<Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
> Yes, this is incredibly annoying, so please avoid that. However I noticed that the current solution using CMake is broken, as I cannot enter my own ZLIB_ROOT, since no proper find_package is used.
I just had a go at hacking this so that we use
2016 Mar 02
2
Incorrect return values for APFloat::convertFromString?
I noticed some odd behavior with APFloat's convertFromString method.
1. If I pass the hex representation of the closest value to 0.1 (0x19999Ap-24), everything is fine and opOk is returned. However, if I pass the same value as a decimal string (0.10000002384185791015625), opInexact is set.
2. On the lower end of the scale, the smallest denormal 0x1p-149 returns opOk, but the
2014 Aug 18
3
[LLVMdev] [PATCH][RFC]: Add fmin/fmax intrinsics
Hi Carter,
I would strongly advise you against this direction. I’m aware of two directions that existing languages go in defining min/max operations:
- IEEE 754, C, Fortran, Matlab, OpenCL, and HLSL all define it not to propagate NaNs
- C++ (std::min/std::max) and OpenGL define it in the trinary operator manner: (a < b) ? a : b
What you’re proposing does not match any existing languages
2014 Sep 18
3
[LLVMdev] proposal to avoid zlib dependency.
There is still one reason this should NOT be done:
If some other library which uses LLVM wants to use zlib (either the system version or one built by hand) we will have linker issues with multiple definition, as LLVM only works with static libraries on Windows. Unless LLVM uses a custom prefix for its internal ZLib, which would “only” lead to more binary bloat.
--
Johannes S. Mueller-Roemer, MSc
2014 Jun 17
2
[LLVMdev] [patch] EXPORTED_SYMBOL_FILE using mingw and cmake
Hi,
this is my first post to this list, so please excuse if submitting a patch without previous discussion is considered bad form or anything similar. I encountered a bug in the CMake build while using MinGW (non-MSYS, non-CYGWIN) where the LTO_export fails with a "The syntax of the command is incorrect" error. This error was previously fixed for Windows in general using
[LLVMdev] [RFC] Late May Update: Progress report on CMake build system's ability to replace autoconf
2015 May 29
0
[LLVMdev] [RFC] Late May Update: Progress report on CMake build system's ability to replace autoconf
Do they really allways put them into Release/bin or rather $<CONFIG>/bin?
--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5 | 64283 Darmstadt | Germany
Tel +49 6151 155-606 | Fax +49 6151 155-139
johannes.mueller-roemer at igd.fraunhofer.de |
2014 Jul 23
2
[LLVMdev] [patch] EXPORTED_SYMBOL_FILE using mingw and cmake
The new patch works fine, but considering the discussion on the CMake bug tracker, I'm would say that TO_NATIVE_PATH shouldn't be used at all.
________________________________________
From: Dan Liew [dan at su-root.co.uk]
Sent: Wednesday, July 23, 2014 10:38 AM
To: Mueller-Roemer, Johannes Sebastian
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] [patch] EXPORTED_SYMBOL_FILE using mingw