similar to: [LLVMdev] "-march" trashing ARM triple

On Mar 2, 2012, at 12:04 AM, David Meyer <pdox at google.com> wrote: > ARM subtarget features are determined by parsing the target tuple string TT. (ParseARMTriple(StringRef TT) in ARMMCTargetDesc.cpp) > > In llc, the -march setting overrides the architecture specified in -mtriple. So when you invoke: > > $ llc -march arm -mtriple armv7-none-linux ... > >

Hi Fred, Thanks. How did you get to " The build log show this error: /Users/buildslave/as-bldslv9/lld-x86_64-darwin13/llvm.src/lib/Target/ARM/MCTargetDesc/ARMMCTargetDesc.cpp:92:11: error: enumeration values 'KalimbaSubArch_v3', 'KalimbaSubArch_v4', and 'KalimbaSubArch_v5' not handled in switch [-Werror,-Wswitch] switch (triple.getSubArch()) { " from here

I'm working on lldb. I've just submitted a very small change (r217229) to Triple.h/.cpp. Soon after I get a mail subject: buildbot failure in LLVM on lld-x86_64-darwin13 Details: http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/2571 Blamelist: mg11 My small change certainly did not cause lldb's build to fail on my machine. I looked into the build-log:

Rafael, Use this bitcode: define i32 @main() nounwind { entry: %call = tail call i32 inttoptr (i64 256 to i32 ()*)() nounwind ret i32 0 } And this command: $ llc -mtriple "i686-linux-gnu" test.ll -o test.s -filetype=asm -relocation-model=pic - pdox

Rafael, I believe your example is not related to IsLegalToCallImmediateAddr. This is an example of calling to an immediate address: typedef int (*funcptr)(void); int main() { funcptr foo = (funcptr)0x100; foo(); } If IsLegalToCallImmedateAddr is true, this generates a call to absolute address 0x100: call 0x100 This requires a relocation of the value 0x100 - PC. (NOTE: this is NOT the

2011/10/17 David Meyer <pdox at google.com>: > Rafael, > > I believe your example is not related to IsLegalToCallImmediateAddr. > > This is an example of calling to an immediate address: > > typedef int (*funcptr)(void); > > int main() { >  funcptr foo = (funcptr)0x100; >  foo(); > } > > If IsLegalToCallImmedateAddr is true, this generates a call to

> Hey Luke, > > Unfortunately, the 'state of the art' is that llc only really supports > emission of native assembly files (-filetype=asm) which can then be > assembled and linked with your native gas/ld. > > There is some source support for 'object file generation', exposed via > the -filetype=obj flag to llc, but it is not complete, and totally > broken

Hi On AArch64 (ARM 64-Bit Platform), I see there is an inconsistency in the values accepted by -march option between clang and llc. --- $ llc -march=aarch64 -mattr=help 2>&1 | grep error $ #No Error $ llc -march=armv8a -mattr=help 2>&1 | grep error llc: error: invalid target 'armv8a'. $ clang -march=armv8a -E - < /dev/null 2>&1 | grep error $ #No Error $

Current llvm svn fails make check when built for only x86... [100%] Running the LLVM regression tests FAIL: LLVM :: DebugInfo/inlined-vars.ll (3994 of 7466) ******************** TEST 'LLVM :: DebugInfo/inlined-vars.ll' FAILED ******************** Script: -- /sw/src/fink.build/llvm33-3.3-0/llvm-3.3/build/bin/./llc -O0 <

Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

> And this command: > > $ llc -mtriple "i686-linux-gnu" test.ll -o test.s -filetype=asm > -relocation-model=pic I can reproduce it now. Sorry, I was using a test returning void and we don't have tail call of immediate. My impression in that the right fix would be to just remove the "isTargetELF()". It would make the function correct for ELF and not less

This is from https://stackoverflow.com/questions/48360685/no-targets-in-targetregistry I have the following code, which should get the default llvm::Target. auto const targetTriple = llvm::sys::getDefaultTargetTriple(); llvm_module.setTargetTriple(targetTriple); std::string error; auto const * target = llvm::TargetRegistry::lookupTarget(targetTriple, error); if (target ==

Clang patch for X32 support. Applies against current trunk. --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6 backward compatibility">; def m3dnowa : Flag<["-"], "m3dnowa">,

On Wed, Mar 20, 2013 at 6:42 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > Current llvm svn fails make check when built for only x86... Ah, right, need to put that behind a "requires"... hrm. (or I could just drop it & let the machines that are armv5 native catch this) > > [100%] Running the LLVM regression tests > FAIL: LLVM ::

Sergey, Here's a patch on llvm-gcc which adds a flag "-fuse-llvm-va-arg". (Note that this patch won't ever be part of llvm-gcc upstream. It will most likely be deprecated by later changes.) - pdox -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110220/f814866f/attachment.html>

I think we need to take a step further back and re-enter from the right starting point. The thing that's bothering me about the push back so far is that it's trying to discuss and understand the consequences of resolving the core problem while seemingly ignoring the core problem itself. The reason I've been steering everything back to GNU Triple's being ambiguous and inconsistent

I hope this is addressed by r177545 - please let me know if this test is still failing for you after that change. On Wed, Mar 20, 2013 at 8:38 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Wed, Mar 20, 2013 at 6:42 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: >> Current llvm svn fails make check when built for only x86... > > Ah, right, need to put

[+llvmdev, -llvm-dev] (Oopsies, llvmdev doesn't have a hyphen in it like all the others do) On 6/17/14, 10:45 AM, Jonathan Roelofs wrote: > [+llvm-dev, cfe-dev] > > Was "Re: [PATCH] ARM: allow inline atomics on Cortex M" > > On 6/17/14, 10:42 AM, Jonathan Roelofs wrote: >> >> >> On 6/17/14, 9:35 AM, Renato Golin wrote: >>> On 17 June 2014

Dear llvm, Recently (approximately a week ago) Clang and LLVM started to failed at building. Assuming it was my incompetence, I cleared everything and started witha fresh checkout (not that I changed it though). I am on Ubuntu 10.04 LTS 64-Bit. And I configure and compile with CMake. The error message I get at approximatley 66% is as follows: Linking CXX executable ../../bin/llvm-mc

FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg flag to Clang. Applies against mainline. (As discussed, va_arg isn't really supported well so this probably doesn't work well on anything other than simple code, YMMV, etc) ~Will On Thu, May 12, 2011 at 12:29 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > Have these changes made it to mainline? Is