similar to: [LLVMdev] [cfe-dev] Clang error

Hi! Dale Johannesen schrieb: > > On Jun 16, 2007, at 12:35 AM, Duncan Sands wrote: > >>> Result compiled with llvm-g++ 2.0: >>> tan float: -2.18504 >>> tan double: 0.309336 >> >> This may be due to bug 1505. > > It fails on x86 using x87 floating point, with the inliner not run, > because of 1505, yes. Gonsolo, is that your situation? >

> > For the record, I just workarounded it in pocl by borrowing the > BreakConstantGEPs code from SAFECode. But for SPIR specs, IMHO, this should > be reconsidered. Yes, I agree. On 24 September 2012 15:08, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi>wrote: > Well, > > To be honest I'm not very comfortable with the whole constant GEP > idea. It's a

OK, I updated the text to LangRef in r209507 after some editing. On 05/11/2014 12:36 PM, Pekka Jääskeläinen wrote: > Hi, > > This looks good to me except that the first sentence > could already include "that refer to the same loop" or > similar. > > I could imagine that e.g. loop invariant code motion, > if applied to a parallel loop could hoist code out of >

Micah, Boaz, Do you guys have any ideas about how to fix this issue? Cheers, James On 24 September 2012 16:04, James Molloy <james at jamesmolloy.co.uk> wrote: > For the record, I just workarounded it in pocl by borrowing the >> BreakConstantGEPs code from SAFECode. But for SPIR specs, IMHO, this >> should >> be reconsidered. > > > Yes, I agree. > >

Will do. I will write something up. Hal, your concern below isn't so much with the proposed semantics but rather with the use - that optimizations must respect the loop for which the metadata applies, correct? Thanks Jon -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Monday, May 05, 2014 4:00 AM To: Tobias Grosser Cc: Pekka Jääskeläinen; Humphreys, Jonathan;

It is my view that this is an implementation detail and not an issue with the SPIR spec. As SPIR is just a representation of a program in a portable manner, it is up to the consumer of SPIR to correctly set up the kernels based on the devices calling convention/ABI when the SPIR binary is loaded for that specific device. From: mankeyrabbit at gmail.com [mailto:mankeyrabbit at gmail.com] On

Hi Pekka, On Tue, Feb 26, 2013 at 11:08 AM, Pekka Jääskeläinen < pekka.jaaskelainen at tut.fi> wrote: > > > Isn't it possible that multiple nested loops share the header and > the pre-header in normalized loops? Thus, then adding metadata to the > preheader's branch would make the MD ambiguous for nested loops. > > The header can't be shared, otherwise

I propose that we change the first paragraph of http://llvm.org/docs/LangRef.html#llvm-mem-parallel-loop-access-metadata: --- For a loop to be parallel, in addition to using the llvm.loop metadata to mark the loop latch branch instruction, also all of the memory accessing instructions in the loop body need to be marked with the llvm.mem.parallel_loop_access metadata. If there is at least one

Hi All I'm having nightmares with FrameIndexes during my backend development :( I have ComplexPatterns defined for my two addressing modes (RR and RI). Most of the time, FrameIndex operands appear to be on load/store nodes, in which case everything works fine as my custom addressing modes matchers work fine. Unfortunately, I now have an add node which has a FrameIndex operand (this results

This patch adds a couple of interfaces to dump full or partial SelectionDAGs. The current code only prints the top-level SDNode. This patch makes it much easier to understand CannotYetSelect errors and those sorts of things. In particular, it helped me track down PR6019. Any objections to committing? -Dave -------------- next part -------------- A non-text attachment

Hi, Sorry, With a prod from Silviu (cc'd) I now understand - I was interpreting your use of "constant GEP" as "GEP with constant operand" as opposed to "ConstantGEP node" which of course can only take a Constant* operand, not a Value* operand. I now fully see the problem and realise that my solution is also prone to that problem :) Cheers, James On 24

Well, To be honest I'm not very comfortable with the whole constant GEP idea. It's a new thing to me and I do not fully understand its point in LLVM IR, so I probably wasn't very clear ;) Anyways, me bringing it up was meant as an example of what can happen if one (mis)uses the C function static variable semantics for something that really is a thread local variable (in usual thread

Commit-ID: 59f3f33338f371b3a30163406fbb5fe323503939 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=59f3f33338f371b3a30163406fbb5fe323503939 Author: James Cowgill <james.cowgill at mips.com> AuthorDate: Fri, 2 Mar 2018 08:33:02 -0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Wed, 2 Jan 2019 03:08:04 +0000 [klibc] mips/mips64: simplify

On Jun 16, 2007, at 12:35 AM, Duncan Sands wrote: >> Result compiled with llvm-g++ 2.0: >> tan float: -2.18504 >> tan double: 0.309336 > > This may be due to bug 1505. It fails on x86 using x87 floating point, with the inliner not run, because of 1505, yes. Gonsolo, is that your situation? (What happens is, there is a wrapper in the header file for std::tan (float),

alpha does not compile right now: arch/alpha/crt0.S: Assembler messages: arch/alpha/crt0.S:21: Warning: .ent directive without matching .end arch/alpha/crt0.S:21: Error: can't resolve `0' {.text section} - `L0' {.text section} make[1]: *** [arch/alpha/crt0.o] Error 1 It still doesnt work with that change, ash cant run external binaries, ./ash/sh $ ls ls: error 1 diff -p -purN

On Wednesday 13 January 2010 16:10, David Greene wrote: > This patch adds a couple of interfaces to dump full or partial > SelectionDAGs. The current code only prints the top-level > SDNode. This patch makes it much easier to understand > CannotYetSelect errors and those sorts of things. In particular, > it helped me track down PR6019. > > Any objections to committing?

found by Christian T. Steigies <cts@debian.org> usr/klibc/arch/m68k/crt0.o: In function `_start': usr/klibc/arch/m68k/crt0.S:(.text+0xe): undefined reference to `___libc_init' too many '_'. never seen jbsr, converted that to jsr. Signed-off-by: maximilian attems <maks@sternwelten.at> diff --git a/usr/klibc/arch/m68k/crt0.S b/usr/klibc/arch/m68k/crt0.S index

Hi Bryan and other klibc people. I have taken a stamp on the Makefiles for klibc, this is what I came up with. 1) No longer recompile on every invocation 2) Correct checking on dependencies 3) Simpler makefile syntax (almost all over the place) I compile-time tested it only. Two open issues: a) Do we realy use .a files for initramfs. I renemed that to the executable. b) I renamed

----- Original Message ----- > From: "Paul Redmond" <paul.redmond at intel.com> > To: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > Cc: "CVS Commit Messages for LLVM repository" <llvm-commits at cs.uiuc.edu>, "LLVM Developers Mailing List" > <llvmdev at cs.uiuc.edu> > Sent: Tuesday, January 29, 2013 3:27:03 PM

Hi! <tangens_bug.cc> #include <iostream> #include <cmath> int main() { float a = 0.3; double b = 0.3; float result_a = std::tan( a ); float result_b = std::tan( b ); std::cout << "tan float: " << result_a << std::endl; std::cout << "tan double: " << result_b << std::endl; }