similar to: [LLVMdev] [PATCH] test-suite/bullet: unbreak linking

Index: MultiSource/Benchmarks/Bullet/Makefile =================================================================== --- MultiSource/Benchmarks/Bullet/Makefile (revision 92478) +++ MultiSource/Benchmarks/Bullet/Makefile (working copy) @@ -1,6 +1,6 @@ LEVEL = ../../../ PROG = bullet -CPPFLAGS += -Iinclude -DNO_TIME +CPPFLAGS += -I$(PROJ_SRC_DIR)/include -DNO_TIME LDFLAGS = -lstdc++ include

On Tue, Jan 05, 2010 at 04:43:33PM +0300, Gregory Petrosyan wrote: > 'make TEST=example' works, 'make TEST=jit' and 'make' work too. Any ideas about what is going wrong here? No idea why this stuff was there... Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92512) +++

We've got both an sqrtf and an expf opcode in our architecture. If I call sqrt() on the C side, I see the sqrtf opcode show up in the generated assembly. However, if I call exp() on the C side, I don't see the expf opcode show up on the generated assembly, I see a call to an exp function from libm. Here's what we've got in our TargetInstrinfo.td file for both of these

This is in response to NO_FLOAT_MATH_LIB not getting set on Solaris. The patchlet below - makes configure check for sqrtf(), - defines HAVE_SQRTF if sqrtf() has been found, - uses HAVE_SQRTF in lib/os.h. NO_FLOAT_MATH_LIB isn't used any longer. --- configure.in.orig Fri Mar 30 02:02:35 2001 +++ configure.in Fri Mar 30 02:10:16 2001 @@ -162,6 +162,7 @@ dnl

Hi I'm having a problem compiling opus-tools-0.1.7. Version opus-tools-0.1.6 seems to compile OK. I've tried with opus-1.0.3 and opus-1.1-beta. The errors are like this:- "undefined reference to `sqrtf'" etc. This OS is Peppermint Three, similar to Ubuntu 12.04. It uses:- gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Google says it's maybe something to do

Hi Daniel, I know you only did a small change to support big/little endian reference outputs, but maybe you can help me. I'm running the test-suite on AArch64 and it's correctly detecting little-endian, even setting the ENDIAN=little on configure and Makefiles alike, but it still generates "big-endian" from Makefile.programs. Here's the first lines of: sandbox/test-...$

sqrtf is detected by code in SelectionDAGBuilder.cpp. This gets turns into a FSQRT ISD node type that the target can handle just like any other ISD node. If the target doesn't mark ISD::FSQRT as Legal or Custom then ExpandNode in LegalizeDAG.cpp turns it back into a sqrtf libcall. On Sun, Jan 20, 2013 at 11:34 AM, David Given <dg at cowlark.com> wrote: > On 20/01/13 19:20,

Apps building against libvorbis 1.0b4 will fail to link on Solaris 2.7 because libvorbis uses atanf, sqrtf, etc., which aren't available on that platform. In lib/os.h, there are a couple of workarounds (ifdef DARWIN, ifndef GNUC), but I'm building on Solaris with gcc, so this doesn't help me any. :) Attached is a patch to configure.in which checks for sqrtf in libm, and if it finds

On 20/01/13 19:20, Caldarale, Charles R wrote: [...] > That's because there is no llvm.ceil.* intrinsic defined in include/llvm/Intrinsics.td for 3.2 Ah. Yes, that would explain it... does this mean that I can rely on all the intrinsics listed existing for the common types (int, float, double)? Or should I be trying to follow the libc call route? I've noticed that llc is successfully

Hi! in the llvm code there are several places with hardcoded function names for e.g. sin, sinf, sqrt, sqrtf etc., namely ConstantFolding.cpp InlineCost.cpp SelectionDAGBuilder.cpp IntrinsicLowering.cpp TargetLowering.cpp my question is: wouldn't it be beneficial to use intrinsics for this? for example a c/c++ frontend (clang) could translate the function calls to intrinsics and then in a

On Jan 5, 2010, at 6:22 AM, Gregory Petrosyan wrote: > On Tue, Jan 05, 2010 at 04:43:33PM +0300, Gregory Petrosyan wrote: >> 'make TEST=example' works, 'make TEST=jit' and 'make' work too. Any >> ideas about what is going wrong here? > > No idea why this stuff was there... looks like some lines got moved, fixed on mainline, thanks. -Chris >

On 2 April 2013 21:20, Török Edwin <edwin+ml-debian at etorok.net> wrote: > You can pass all the filenames from the inputs/ directory directly on the > command-line, instead of specifying -r inputs/. > That way the order of scanning will be exactly the one specified on the > command-line. > Hum, I think I can fix that with Make... --renato -------------- next part

On 04/02/2013 11:06 PM, Daniel Dunbar wrote: > On Tue, Apr 2, 2013 at 11:46 AM, Renato Golin <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote: > > On 2 April 2013 19:20, Daniel Dunbar <daniel at zuster.org <mailto:daniel at zuster.org>> wrote: > > What is it that makes the output of the program asynchronous? The output is

Hi, Using trunk llvm ; on powerpc (powerpc64/power7); trying to do a "gmake check", the sed bits in test/Makefile appear to be getting tripped up when trying to generate lit.site.cfg. I've started to hack at it, made a little bit of progress, but wonder if I'm just digging myself a hole. Highlights of what I've poked at are below.. Comments or thoughts? Thanks,

Hi, >> in the llvm code there are several places with hardcoded function >> names for e.g. sin, sinf, sqrt, sqrtf etc., namely >> ConstantFolding.cpp >> InlineCost.cpp >> SelectionDAGBuilder.cpp >> IntrinsicLowering.cpp >> TargetLowering.cpp >> >> my question is: wouldn't it be beneficial to use intrinsics for this? >> for example a

Hi Torok, I've used a hard-coded list on the input parameter and still got some output (slightly) scrambled between two different bots... INPUT = $(PROJ_SRC_DIR)/inputs/clam.cab \ $(PROJ_SRC_DIR)/inputs/clamdoc.tar.gz \ $(PROJ_SRC_DIR)/inputs/clam.exe \ $(PROJ_SRC_DIR)/inputs/clam.exe.bz2 \ $(PROJ_SRC_DIR)/inputs/clam-v2.rar \

Hi! I'm trying to build a backend outside the LLVM source tree. My directory structure is as follows: llvm -- the root of the LLVM source tree llvm/lib/Target -- where the standard backends are stored (Sparc, etc). my_dir/my_backend -- where I store the backend I'm writing. I've been fiddeling with the variables documented in the llvm/Makefile.common (LEVEL, LLVM_SRC_ROOT,

Hello, Ekaterina. FYI, my configure has '--host=i686-pc-mingw32' w/o any additional variables. and then the build host (ppc fedora 12) has toolchain 'i686-pc-mingw32-*'. It could build everything successfully, but I have not built it for a few months :p 2010/11/30 Ekaterina Sanina <ekaterina.sanina at gmail.com>: > cross-compile-build-tools: >         $(Verb) if [ !

1) I find typo in Makefile.rules in printvars rule: - $(Echo) "Preconditions: " '$(Preconditions)' + $(Echo) "PreConditions: " '$(PreConditions)' 2) In Makefile.config.in PROJ_SRC_DIR define for LLVM build mode as PROJ_SRC_DIR := $(subst //,/,$(LLVM_SRC_ROOT)/$(patsubst $(PROJ_OBJ_ROOT)%,%,$(PROJ_OBJ_DIR))) and for other project build mode as PROJ_SRC_DIR

Hi, Seems like it's not linking with libm. I suspect it has to do with linking statically with libopus.a (is that intended?). Maybe opus-tools relies on the fact that libopus is linked with libm and doesn't explicitly add it? Greg? Jean-Marc On 09/24/2013 06:09 AM, bat guano wrote: > Hi > I'm having a problem compiling opus-tools-0.1.7. > Version opus-tools-0.1.6 seems to