similar to: [LLVMdev] A few small errors in the language reference guide

On 30 Jun 2010, at 18:40, Devang Patel wrote: > On Wed, Jun 30, 2010 at 1:57 AM, Artur Pietrek <pietreka at gmail.com> > wrote: >> The problem is that you put difference between two labels >> .Lset7 = .Lsection_line_begin-.Lsection_line ## DW_AT_stmt_list >> and that will be evaluated by assembler to a constant. It has to be >> a label, >> not a

Hi, Having just found an ABI conformance bug in a compiler front-end, I am curious: is the state of target-independent argument lowering in LLVM still the same as when this thread was taking place?: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/thread.html#59387 Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 01/08/14 19:37, Reid Kleckner wrote: > What happens if you drop appending linkage? I think it will just work, > since you are already using a custom section, which will ensure that all > the data appears contiguously in memory. Thanks for the suggestion, but it still puts everything in a single .section statement. > Although, I do worry about what LLVM's alias analysis will

On Tue, Aug 17, 2010 at 7:09 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > > On ELF platforms (at least Linux and FreeBSD) and on Windows, both of > the following are labels (i.e., absolute addresses to be relocated by > the linker) as opposed to offsets relative to the relevant section's > start, even though the DWARF standard says they are offsets: > *

On 30 Jul 2014, at 21:29, Ulrich Weigand wrote: > The ELFv1 ABI is used on 64-bit big-endian Linux and AIX. There's one small difference between the two: with the 64 bit ELFv1/ SVR4 ABI, tail padding for structs passed by value is only performed in case the struct is larger than 8 bytes, while for AIX 64 bit it's always done. As an aside, on Darwin/ppc64 it's done if the

On Wed, Sep 1, 2010 at 5:31 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > > On 01 Sep 2010, at 08:47, Talin wrote: > > > Once again, I have no idea what this means or how to go about > > debugging it. > > This is my biggest frustration with DIFactory - there's absolutely > > no way to > > verify that the DWARF debugging information that

On 26 Aug 2010, at 10:32, Krister Wombell wrote: > I've also been looking at debugging with ELF and noticed the same > problem as > Renato. I just sent a patch to llvmcommits that fixes the problem. > DW_at_stmt_list needs to emit a label(and therefore a relocation) > for the > offset rather a constant 0, then the linker can fixup the offset as it > shuffles object

On 04 Aug 2014, at 09:27, Reid Kleckner wrote: > On Sat, Aug 2, 2014 at 7:51 AM, Jonas Maebe > <jonas.maebe at elis.ugent.be> > wrote: > >> On 01/08/14 19:37, Reid Kleckner wrote: >> >>> What happens if you drop appending linkage? I think it will just >>> work, >>> since you are already using a custom section, which will ensure

On 01 Sep 2010, at 08:47, Talin wrote: > Once again, I have no idea what this means or how to go about > debugging it. > This is my biggest frustration with DIFactory - there's absolutely > no way to > verify that the DWARF debugging information that I've emitted into > my module > is correct or even sensible. The only way to test it is to try and > debug

On 2009-02-08, at 05:59, Jonas Maebe wrote: > The proposal suggests to change/split the existing sub/add/mul > opcodes. This makes me wonder to what extent it is (currently, or > ever) advisable for an external compiler to generate LLVM IR. Is > there a plan to stabilise at some point and guarantee backwards > compatibility to a certain extent, or should compilers that are

On Wed, Jun 30, 2010 at 1:57 AM, Artur Pietrek <pietreka at gmail.com> wrote: > Hi Devang, > Thanks for working on that. Unfortunately after your change it still doesn't > work (I've tried x86 and our backend under Linux). What errors exactly you are seeing ? > The problem is that you put difference between two labels > .Lset7 = .Lsection_line_begin-.Lsection_line ##

On 25 Aug 2010, at 23:11, Renato Golin wrote: > As far as I understood, there is nothing wrong with the way clang > deals with stmt_list. The encoding is correct (AFAIK) and the offsets > are always zero in every object file, as there is only one line table > and one debug_info. Are you taking into account the relocation information? Use "objdump - Dr" on an the object

Hi, I found a mysterious behavior of LLVM optimizer. I compiled the following code by clang -emit-llvm -S: #include <stddef.h> static const struct t {char t[4]; char s;} p = {{}, 'a'}; char f() { return ((char*)&p)[offsetof(struct t, s)]; } then I obtained the following LLVM IR: %struct.t = type { [4 x i8], i8 } @p = constant %struct.t { [4 x i8] zeroinitializer, i8 97

Hi, Is there a way in llvm IR to emit multiple data elements within a single compilation unit that a) are guaranteed to appear sequentially in the final binary (in the order they appear in the llvm IR), and b) will be removed on an individual basis by the optimizers and/or linker in case they are not referenced from anywhere ? Defining them as "appending" puts them all into a

On 08 Feb 2009, at 14:41, Gordon Henriksen wrote: > On 2009-02-08, at 05:59, Jonas Maebe wrote: > >> The proposal suggests to change/split the existing sub/add/mul >> opcodes. This makes me wonder to what extent it is (currently, or >> ever) advisable for an external compiler to generate LLVM IR. Is >> there a plan to stabilise at some point and guarantee backwards

I've also been looking at debugging with ELF and noticed the same problem as Renato. I just sent a patch to llvmcommits that fixes the problem. DW_at_stmt_list needs to emit a label(and therefore a relocation) for the offset rather a constant 0, then the linker can fixup the offset as it shuffles object files around. Krister On Thu, Aug 26, 2010 at 5:11 AM, Renato Golin <rengolin at

Hello, I'm looking into creating an llvm backend for the Free Pascal Compiler (<http://www.freepascal.org>). After reading a bit through the documentation and looking at some code generated by llvm-gcc, I have a couple of questions: 1) is there a way to specify ranges in the switch statement? Pascal supports switch statements (called "case" statements there) which

On 30/09/16 20:10, Reid Kleckner wrote: > On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be > <mailto:jonas-devlists at watlock.be>> wrote: > > So, can I use invoke and landingpad without using any of the other > exception handling intrinsics? (in combination with a dummy personality > function) Or will LLVM in all cases insist on

On 18 Aug 2015, at 17:23, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Freestanding code is still documented to require memset and a few other > things. I had found a few messages mentioning that they are required when generating freestanding code with clang (and GCC), but nothing about llvm. Could you point me to that documentation so I know what I have

Hi, Is there something wrong with my inline assembly below? *** target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple = "x86_64-apple-macosx10.5" define void @"\01_SYSTEM_$$_SETMXCSR$LONGWORD"(i32 %p.w) nobuiltin { ; [71] procedure